darksladen, да, я настаиваю на том, что не нужно изобретать преждевременной оптимизации и объединять запросы для разнородных сущностей в один запрос. Реализуйте сначала по-простому - на каждую сущность по запросу. Но при этом думайте об удобстве пользователя и не грузите то, что пользователю никогда может не понадобиться.
darksladen, я не совсем представляю, что за систему вы строите, но обилие слайдеров и меню на странице - это не очень хороший UX. Для какой-нибудь корпоративной системы, которая работает в локальной сети это может быть нормально, но для системы ориентированной на пользователей интернета перегруженный интерфейс не самый лучший товарищ.
darksladen, насколько я понимаю в один конкретный момент посетитель просматривает один слайд, а не всю 1000 правильно? Зачем грузить всю тысячу, если посетитель, возможно, даже до третьего не дойдёт? Я бы предложил сделать в данном случае ленивую загрузку - грузить сразу только начальный слайд и один-два следующих, а при прокручивании слайдера подгружать следующие. Во-вторых, что это за сервер такой, что от 1000 запросов падает? Если запрос достаточно мелкий, то и обрабатываться на сервере он должен быстро. А значит сервер должен быть способен обрабатывать много таких запросов одновременно. В идеале вообще лучше сделать кэширование содержимого этих слайдов и отдавать их через ngnix.
darksladen, не совсем понял вопрос про меню и слайдеры. про какие 100 запросов идёт речь? у вас есть меню. всю её структуру можно получить одним запросом, это одна сущность - меню. то же и про слайдер у вас есть массив слайдов, которые вы хотите отобразить - информацию об этом массиве вы получаете одним запросом. если содержимое слайдов динамическое - данные для каждого слайда нужно подгружать отдельным запросом - это уже отдельная сущность, да и отзывчивость страницы это увеличит - пользователю не нужно ждать загрузки информации обо всех слайдах, чтобы начать просматривать первый.
Максим Тарабрин: Тут сложно однозначно сказать - делай так и никак иначе. Нужно смотреть на конкретную архитектуру. По идее я бы, наверное, сделал обработку ошибок авторизации в двух местах: в самом сервисе авторизации на этапе инициализации приложения. Это когда приложение стартует, берёт из кэша токен и проверяет его на валидность. А второе место - это сервис обработки всех запросов к серверу, обёртка над Http сервисом. В нём любая пришедшая с сервера ошибка авторизации вела бы к очистке токена и редиректу на страницу логина. А гард не должен по идее никаких асинхронных функций реализовывать, только проверять права доступа на страницу, загруженные ранее при логине.
leha_trushin: Ну значит, как я предложил в конце - новое значение добавляйте в конец, а для предыдущего запускайте анимацию скрытия. Это должно предотвратить прыгание картинки. Ещё можно организовать собственную очередь этих сообщений. Т.е. разделить промисы, которые генерируют данные с системой их отображения. Цепочка промисов просто добавляет новое значение в очередь, а отдельный класс по таймауту берёт из очереди сообщение и отображает его в модальном окне. Когда цепочка полностью завершилась нужно не забыть выключить таймаут. Это существенно усложнит систему, но если это настолько критично - отображать все промежуточные значения, то можно и заморочиться.
Общая архитектура мне кажется правильной. Конкретная реализация "диспетчера" может быть выполнена в виде очереди, как предложил Andrei Smirnov - это довольно элегантное решение. Единственное, что я бы изменил в том решении, которое вы описали - не использовал бы callback. Я бы сделал на Promise. Т.е. ваш диспетчер при запросе на элемент списка возвращает Promise, который либо сразу резолвится, если требуемые данные уже есть, либо резолвится тогда, когда данные будут получены с сервера.
raingo: Ну, при желании можно и ангуляр (по крайней мере последние версии) научить рендерингу в канвас, как мне кажется. Но реакт для этого всё же лучше подходит именно из-за большей гибкости и меньшей связности разных компонентов, вы правы. Если цель именно написание игр, то клиентскую часть я бы писал на React/Vue, а админку на Angular.
А код я бы существенно переработал. Я не до конца понял по фрагменту, как именно это всё работает. Поэтому лучше продумай как следует, когда этот класс is_active должен инициализироваться и когда устанавливаться.
Coder321: А почему нельзя создать пустой FormControl если нет подходящего на входе? На этапе инициализации создаёшь пустой контрол, как в примере выше, а если пришёл снаружи контрол, то заменяешь его.
gamma06: ну у тебя каждый элемент массива - это столбец таблицы. Поле "y-m" - это заголовок столбца. Тебе по сути нужно инвертировать массив, чтобы стобцы стали строками. А потом просто по ним пробежать и сгенерировать соответствующие DOM элементы. Сейчас навскидку не могу вспомнить, в какой библиотеке есть нужное преобразование массива. Должно быть в lodash или в чём-то подобном. Впрочем, можно и ручками реализовать.
Coder321: вообще-то у инпута всё само собой должно с формой связываться, насколько я помню. покажи свой шаблон, как сейчас реализовано, и напиши, что конкретно не устраивает. что-то я словесные объяснения не воспринимаю под вечер :(
Coder321: а какое ожидаемое поведение, я не очень понял. объясни подробнее, что ты хочешь получить в конце? что за атрибут formControl, в спецификации HTML нет такого атрибута.
