и эти дёрганья раздражают

Еще вопрос появился) Смотрите, когда я обновляю имя, по логике правильно будет отправить на запись в бд и при положительном ответе поменять имя. Но такая конструкция замедляет и немного сбивает процесс отображения. Есть другой вариант, менять надпись, отправлять в бд и потом обновлять данные. И есть 3й вариант, просто поменять надпись и отправить в бд, а потом уже отталкиваться от ошибок. Самый правильный мне кажется 1й, 2й более оптимальный в отображении и записи, а 3й работает лучше всего, но странный. Проконсультируйте плз.

это все относится к UX у некоторые сделано именно как 3 вариант статья где-то была лаже на vc.ru про это я использовал 2 вариант если у меня долгая операция допустим но все зависит от задачи обычно 1 вариант, обновлю в случаи успешного запроса 3 вариант это 2 только так нужно делать всегда если пытаешься 2 вариант использовать, тогда уже делай 3

Я бы хотел использовать 1й, но из за скорости приходится ставить 2й. А из за дёрганий хочу 3й)))

не ты не хоти, используй по назначению, по задаче

с умом вообщем

если у теб операция дорогая по времени, то тут уже нужно не мудрить на клиенте, а подключать сокеты, push уведомления

Понял, спасибо. Я думал 3й вариант вообще не очень, а оказывается и такой юзают.

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

А анимации при сохранении? Юзера развлекать надо

потом еще эта анимация будет дёргаться ?

представь анимацию в 0.03 сек)

на сайт эпилептикам нельзя будет заходить

Ну это пока 003

ну максимум у меня доходило до 0.1

Вообще смотреть надо

я хочу быстрый отклик, а не развлекухи)

А ты после обновления заново запрашиваешь данные? Ну, те же самые

не за то вы переживаете сначала ( я за время вашего запроса )

Или я не так всё понял

не за то вы переживаете сначала ( я за время вашего запроса )

можно поподробнее)

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

Да он дуется на мене :D

ааа

Я же не за тайминг, а за то что появление и пропадание элемента раздражает, такого не должно быть)

Ну с анимацией ок, отпадает

А при обновлении элемента после записи, это будет в любом случае

Какита так

хотя можно конечно не элемент обновлять, а только часть

сейчас попробую

Это почему так?

что почему?

В смысле кто вынуждает заново его загружать если клиент знает новое значение и операция сохранения без ошибок?

Зачем лишний запрос?

Для этого я и обновляю до сохранения в бд.

Зачем лишний запрос?

А как по другому мне его сохранить?

Для этого я и обновляю до сохранения в бд.

распиши всю ситуацию

Ну сохранил, обновил в клиентской коллекции что надо и никуда не пошёл. У тебя же всё есть на клиенте

сек, я попробую кое что, до меня опять во время разговора дошло

Ну сохранил, обновил в клиентской коллекции что надо и никуда не пошёл. У тебя же всё есть на клиенте

перезагрузил страницу и всё?

Не надо ничего перегружать

У тебя уже актуальные данные есть

Ну там где ты забираешь новое значение и передаешь его потом

Не, я имел ввиду если пользователь перезагрузит, а эти данные нигде не сохранены

Мы чето о разном говорим))

распиши всю ситуацию

Всё, дошло, в данном случае есть возможность обновлять не весь элемент, а его часть. Тогда не дёргается.

я просто вырезал элемент и вставлял новый

из за этого дёргалось

Мы чето о разном говорим))

Наверное) Любые изменения в любых данных нужно же куда-то сохранять. Но нужно постараться делать безболезненно. Вот как натолкнули меня на идею не элемент менять а только часть его.

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

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

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

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

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

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

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

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

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

Хотя не

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

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

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

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

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

vm это this

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

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

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

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

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

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

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

ага

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

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

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

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

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

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

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

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

аа

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

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

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

Так и храни)

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

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

спасибо

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

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

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

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

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

спасибо

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

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

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

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

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

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

вообще не)

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

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

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

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