Приветствую! Как вы решаете (и решаете ли вообще) проблемы производительности. Что мы видим:
JSON который нужно гонять по сети и он явно не может быть компактным для развесистых форм. Пользователи мобильных устройств не скажут нам спасибо.
интерпретатор "конфигурации" в сущности, понятные фреймворку. В данном случае это формы angular. В это время пользователь будет смотреть на наш классный лоадер?
переизбыток и компрометация информации о валидации. Мы показываем в открытом виде, то что будем проверять на сервере, кроме того клиент узнает то, что будет проверяться ТОЛЬКО на сервере. Выглядит как дыра и повод для размышления для пентестеров.
"Чаще всего эти задачи передаются бэкенд и фронтенд разработчикам, которые реализуют одну и ту же логику. " чаще всего, но всегда. И даже в вашем примере мы видим валидаторы, только для бекенда. Как будто, если вы хотите писать валидацию один раз, то ее нужно делать только на сервере, а на клиенте только отображать ошибки.
И еще вопрос со звездочкой: почему не использовали кодогенерацию? Кажется, что формализованные формы можно шаблонно запрограммировать и, увеличив время "сборки" приложения, дать огромный прирост производительности в рантайме клиентского приложения.
Как вы выполняете вывод больших списков в своих веб-проектах?
У Вас не будет проблем с большими списками если не будет больших списков) Давайте будем честными, никто в здравом уме не захочет скроллить 3 часа чтобы выбрать 345684132489751324 элемент. Поэтому я пошел по принципу вот вам 10/50/100 первых опции и возможность поиска по списку, как только пользователь начинает вводить что он ищет — подсовываем ему подходящие опции в количестве 10/50/100.
а что с картинками и кнопками?
Приветствую! Как вы решаете (и решаете ли вообще) проблемы производительности. Что мы видим:
JSON который нужно гонять по сети и он явно не может быть компактным для развесистых форм. Пользователи мобильных устройств не скажут нам спасибо.
интерпретатор "конфигурации" в сущности, понятные фреймворку. В данном случае это формы angular. В это время пользователь будет смотреть на наш классный лоадер?
переизбыток и компрометация информации о валидации. Мы показываем в открытом виде, то что будем проверять на сервере, кроме того клиент узнает то, что будет проверяться ТОЛЬКО на сервере. Выглядит как дыра и повод для размышления для пентестеров.
"Чаще всего эти задачи передаются бэкенд и фронтенд разработчикам, которые реализуют одну и ту же логику. " чаще всего, но всегда. И даже в вашем примере мы видим валидаторы, только для бекенда. Как будто, если вы хотите писать валидацию один раз, то ее нужно делать только на сервере, а на клиенте только отображать ошибки.
И еще вопрос со звездочкой: почему не использовали кодогенерацию? Кажется, что формализованные формы можно шаблонно запрограммировать и, увеличив время "сборки" приложения, дать огромный прирост производительности в рантайме клиентского приложения.
У Вас не будет проблем с большими списками если не будет больших списков) Давайте будем честными, никто в здравом уме не захочет скроллить 3 часа чтобы выбрать 345684132489751324 элемент. Поэтому я пошел по принципу вот вам 10/50/100 первых опции и возможность поиска по списку, как только пользователь начинает вводить что он ищет — подсовываем ему подходящие опции в количестве 10/50/100.