То есть запрос на сохранение мне в любом случае нужно отправлять, а вот стоит ли обновлять и как это уже другое дело)

Не, понятно что сохранять надо. Но то что сохранённый объект из базы после этого опять загружать, чтобы получить эти изменения там откуда мы только что вызвали редактирование это не полностью хорошо и я уверен ты так не делаешь просто я всё как обычно превратно понял.

А по поводу того когда юзеру показать изменения, ну он как-то должен узнать что данные сохранились или нет. Я бы ещё подумал в сторону что делать если нет, как сообщить, откатить значение

В идеале конечно было бы при ошибке сообщить, а при положительном результате ничего не сообщать, но тогда возможно будет задержка и будет заметно. Нужно в общем попробовать разные варианты что бы понять как лучше.

Ну а если обновлять на клиентской стороне сразу а после сохранения уведомление выдавать? Есть же toast готовые. А если ошибка, то откатывать значение и опять уведомление.

Предполагаем что ошибки будут реже успешных операций

выдавать уведомление после сохранения не вижу смысла

я делаю трелло, представь после каждого создания/изменение выводить сообщение

Ну тогда до успеха не показывай обновление

Хотя не

я делаю трелло, представь после каждого создания/изменение выводить сообщение

это у тебя задание такое ? прикольно

это у тебя задание такое ? прикольно

Нет, это я просто делаю, к сожалению прогадал немного, там сложных заданий как таковых нет, а вот на вёрстку потратил много времени.

Кстати, вот возник еще вопрос. Каким образом можно отменить нг-шоу через контроллер? То есть я могу закрыть через vm.example, а через example соответственно не могу. Но из за нг репита этот vm.example открывает/закрывает все элементы.

vm это this

разве что переходить на ng-class и добавлять каждому уникальное значение, тогда можно будет дотянуться до нужного элемента

Ты очень непонятно рассказываешь))

Если тебе надо управлять видимостью каждого элемента, то ты можешь или в нем самом булевое поле хранить с состоянием или внешний справочник ид - видимость и потом по нему определять

Если тебе надо управлять видимостью каждого элемента, то ты можешь или в нем самом булевое поле хранить с состоянием или внешний справочник ид - видимость и потом по нему определять

Видимо сам не особо понимаю, раз не могу нормально донести, ну или ты не понимаешь) Ну вот у элемента есть нг-шоу/хайд, это и есть по сути булевое поле (показать/отключить). У каждого элемента в нг-репите у него одно и тоже имя. Когда я его изменяю внутри элемента при клике, всё работает. Достучаться из контроллера до него я не могу. Но могу достучаться если его сделать как бы глобальным для данного контроллера, добавив vm. Но тогда в каждом элементе нг репита будет vm.example и из за изменений в контроллере оно будет меняться не у нужного элемента а у всех.

Постарался доступнее описать)

Не, это у тебя переменная в скоупе репита

ага

Элементы репита каждый в своём как бы неймспейсе, домене живёт

Значит тебе в контроллере надо или мапу элементов создавать

Либо в самой модели в элементе хранить состояние

Чтобы в контроллере списка иметь доступ

И то и другое будет работать быстро, по крайней мере проверка

Чтобы в контроллере списка иметь доступ

я тут немного не понял, что за список?

Ну по которому репит бежит

аа

В модели проще хранить

ну мне конечно сейчас удобнее в элементе хранить состояние

точнее я сказал бы проще

Так и храни)

Я просто думал немного переделать для красоты, что бы определённые вещи закрывались после удачного сохранения в бд

ну да ладно, что-то придумаю

спасибо

Ребят, подкиньте идею. Как вы считаете разные открывающиеся менюшки в моб версии привязывать к экрану или к остальному контенту?

уточню, что это не меню всей страницы, а просто какие-то дроп менюшки для каких-то действий

всем привет*)

лучше к экрану в мобильной версии

лучше к экрану в мобильной версии

спасибо

ребят, а тач и клик одинаково обрабатываются?

То есть если пользователь в моб версии начнёт прокручивать, а клик должен закрыть окно. Оно закроется?

Так-то это отдельные события. Но не проверял)

Хотя наверное будет обрабатываться как одно, должен додуматься. Даже жиквери по-моему умел понимать что надо обратить его как клик

тогда еще вопрос, в хроме когда смотришь мобильную версию всё работает как будет в смартфоне? или не факт?)

тогда еще вопрос, в хроме когда смотришь мобильную версию всё работает как будет в смартфоне? или не факт?)

вообще не)

Эмуляция всегда имеет погрешность) я бы не рассчитывал на 100%

Я уточню, я имею ввиду именно события, а не внешний вид.

или это ответы были про события?

онтач пораждает онклик - все хорошо в современных браузерах нет смысла хендлить отдельно он клик и он тач

если ето не свайп

понятно, спасибо

Я вот с вами пообщался недельку и понял что мой код полное г...

😕

во всяком случае часть на ангуляре и штмл

как теперь жить 😂

это нормально, не переживай

ты приобретаешь новые навыки, знания, переоцениваешь архитектуру и понимаешь что все плохо, так постоянно

Смирись, познай дзен, смени работу)

добавлял элементы что бы повысить вотчеры, надеялся увидеть лаги или краш, дошёл до 3.6к вотчеров, всё норм работает, надоело)

Ребят, а вы все ошибки обрабатываете на фронте? Мой вопрос заключается в том, что я все ошибки обрабатываю на бэке и по идее там ничего лишнего не должно произойти, некоторые для корректности ввода обрабатываю на фронте еще. И вот стоит ли бесполезные ошибки обрабатывать на фронте. Типа там если нет айди, я уже знаю что бэк вернёт ошибку, зачем отправлять запрос.

Я уточню, я имею ввиду именно события, а не внешний вид.

Тем более)

Ребят, а вы все ошибки обрабатываете на фронте? Мой вопрос заключается в том, что я все ошибки обрабатываю на бэке и по идее там ничего лишнего не должно произойти, некоторые для корректности ввода обрабатываю на фронте еще. И вот стоит ли бесполезные ошибки обрабатывать на фронте. Типа там если нет айди, я уже знаю что бэк вернёт ошибку, зачем отправлять запрос.

Делай так, что бы вообще не было возможностей такие кейсы делать Ну а если же есть - то делай. Но не ради уберечь бэк от ошибок и лишней нагрузки, а что бы пользователя тыкнуть мордой в некорректные данные

Делай так, что бы вообще не было возможностей такие кейсы делать Ну а если же есть - то делай. Но не ради уберечь бэк от ошибок и лишней нагрузки, а что бы пользователя тыкнуть мордой в некорректные данные

Не, то что пользователь должен вводить я само собой проверяю, а вот вдруг какой-то сбой будет именно программный и какой-то айди не дойдёт, я могу пользователю сразу выдать какое-то сообщение об ошибке, заранее зная что будет ошибка и что это ошибка программная

Не, то что пользователь должен вводить я само собой проверяю, а вот вдруг какой-то сбой будет именно программный и какой-то айди не дойдёт, я могу пользователю сразу выдать какое-то сообщение об ошибке, заранее зная что будет ошибка и что это ошибка программная

не, херня) Дурной кейс

не, херня) Дурной кейс

Я так понял, ответ, не нужно такое проверять) Верно?)

Да

Ребят, а может кто в 2х словах описать как в спа делается авторизация? Я что-то читаю не могу догнать, я понял что можно просто заблокировать какие-то элементы на нажатие. А вот как вообще это происходит, что бы без регистрации, пользователь добавив в адрес /home например, не попал на страницу. Или же делается отдельно авторизация а потом редирект на спа?

всем привет*

Привет

То что ты говоришь - через защиту маршрутов

То есть ты должен определять аутентифицирован ли пользователь - подошли ли логин и пароль

И авторизован ли он - соотвествуют ли его разрешения запрошенным

В нг 2+ в роутере вроде встроенные гварды есть

В 1 - каждый свои лисапеты придумывает

Вот при переходе на маршрут тебе надо проверять это всё

https://github.com/mikemclin/angular-acl

Смотри там например, protecting a route