Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, paradok, Вы писали:

P>>так стандартный DOM документ-объект-модел...
P>>также есть шадоу дом....
P>>...
P>>вообще просто почитай или пролистай любую современную книжку хотя бы 2020 года по css/html
P>>...
P>>если кажется слишком низко-уровневым ...

Ф>Похоже ты суть вопроса не понял. Я спрашивал, как организуется логика изменения UI, если в ней участвует больше одного контрола. Вопрос задан в связи с тем, что ранее ты утверждал, что UI у вас делает дизайнер. Дизайнеры код обычно не умеют писать, соответственно код пишет программист. Если на стороне UI работает дизайнер, то логично полагать, что логику пишет программист на бэке. Соответственно, я полагаю, что на каждый клик пользователя стэйт отправляется на бэк. Бэк обрабатывает и отдаёт новый. Примерно так это было в WebForms. Но это моё предположение, мне интересно как на самом деле.

это уже не относится к дзайну... на каждый клик или только на существенные изменения на клиенте или на серере (сечас можно и события сервера без действи юзра на клиенте отображать а клиенте)

конкретно, в наших играх расставлять фишки на поле можно без посылки на серрвер, и это сделано полностью дизайнером на css и немного подправлено программистом
и сейчас рулят не клики, а тапы и события драг-н-дроп, фишка — это объект который можно переместить пальцем и дропнуть на объект клетка поля,
обработчик события дропа изменит некоторые переменные — изменение переменных делал программист.
после расстановки фишек, юзер может тапнуть на кнопку играть, обработчик тапа свяжется с серввером, пошлет состояние переменных, получит результат в блоке переменных,
обработчик написанный программистом обновит данные для таблиц рекордов, очистит игровое поле, и обновит данные для холдеров фишек. Примерно так.

Различные игровые и даже весьма сложные анимации делал дизайнер на сss и немного доработал программист на js.
адаптация к разным размерам экранов сделана полностью дизайнером на css

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, paradok, Вы писали:

P>>так стандартный DOM документ-объект-модел...
P>>также есть шадоу дом....
P>>...
P>>вообще просто почитай или пролистай любую современную книжку хотя бы 2020 года по css/html
P>>...
P>>если кажется слишком низко-уровневым ...

Ф>Похоже ты суть вопроса не понял. Я спрашивал, как организуется логика изменения UI, если в ней участвует больше одного контрола. Вопрос задан в связи с тем, что ранее ты утверждал, что UI у вас делает дизайнер. Дизайнеры код обычно не умеют писать, соответственно код пишет программист. Если на стороне UI работает дизайнер, то логично полагать, что логику пишет программист на бэке. Соответственно, я полагаю, что на каждый клик пользователя стэйт отправляется на бэк. Бэк обрабатывает и отдаёт новый. Примерно так это было в WebForms. Но это моё предположение, мне интересно как на самом деле.

это уже не относится к дзайну... на каждый клик насиловать сервер или только на существенные изменения на клиенте или на сервере
(сейчас можно и события сервера без действий юзера на клиенте отображать на клиенте) это зависит от того что вам больше нравится...

конкретно, обычно (но были и другие варианты), в наших играх, например, расставлять фишки на поле можно без посылки на сервер,
и это сделано полностью дизайнером на css и немного подправлено программистом js,
и сейчас рулят не клики, а тапы и события драг-н-дроп, фишка — это объект DOM который можно переместить пальцем и дропнуть на объект DOM клетка поля,
обработчик события дропа изменит некоторые переменные — изменение переменных делал программист.
после расстановки фишек, юзер может тапнуть на кнопку играть, обработчик тапа свяжется с сервером, пошлет состояние переменных, получит результат в блоке переменных,
обработчик написанный программистом обновит данные для таблиц рекордов, очистит игровое поле, и обновит данные для холдеров фишек. Примерно так.

Различные игровые и даже весьма сложные анимации делал дизайнер на сss и немного доработал программист на js.
адаптация к разным размерам экранов сделана полностью дизайнером на css