vasIvas: у вас есть ES6 модули. Вы можете чисто теоритически в качестве резолвов прокинуть промисы при загрузке модулей но это надо много думать как это сделать. Я не уверен что в этом есть практический смысл, только для ооочень больших приложений и если у нас есть явное разделение.
vasIvas: зависит от количества операций. Если у вас операция происходит сотню раз в секунду - то полный цикл flux-а это возможно не лучший подход.
В этом коде нет ничего катострофического. Просто прямой вызов функции намного быстрее вызова через apply. За счет JIT оптимизаций скорость еще более возрастает, а вызовы через apply насколько я помню плохо поддаются оптимизации.
Когда мы говорим о коде который нам надо поддерживать - он должен быть впервую очередь понятным, а затем уже вход идут нефункциональные требования. Код же фреймворка должен быть максимально быстрым. Ну и да, я не понял о каком "оборачивании в функцию" вы говорите.
ps. buttle.js вроде как делает именно это, ресолвит граф зависимостей.
vasIvas: вы о чем именно? О всех тех микрооптимизациях которые позволяют значительно ускорить сборку объектов?
Вообще в angular1 было примерно так же, но больше комментов о том почему были приняты те или иные решения.
на данный момент актуальный код только в основном репозитории, когда будет произведен сплит - без понятия. https://github.com/angular/di.js То есть можно попробовать использовать модуль из основного модуля... но.. проще взять любой другой контейнер зависимостей.
vasIvas: в angular2 контейнер зависимостей это отдельный независимый компонент. Так что нет никаких проблем с использованием оного в react приложениях.
Ramil Z.: ну это так же спорный вопрос) большинство разработчиков воспринимает как контроллер как "место которое меняет модель". А контроллер должен только просить модель поменять состояние. По итогу мы можем видеть огромное количество толстых контроллеров, разрастание дублирования кода и т.д. Сейчас благо с этим чуть получше чем лет 5 назад.
Во фронтэнде все то же самое. Тот же MVC (собственно почти никто MVC не использует, на бэкэнде это MVA или Model2, а на фронтэнде это MVA, MVVM и другие вариации одной и той же идеи). Из последних трендов - Flux, который можно описать как канонический MVC 79-ого года и event sourcing.
Ramil Z.: если что любой фильтр можно использовать как сервис в контроллере. То есть если вам удобнее отфильтровать все ангуляром - воспользуйтесь оным. Но не в темплейте. Это более-менее безболезненно только в angular2 в силу асинхронности тамшнего аналога фильтров, ну и в целом это часть "логики", и логике не место в шаблонах. Ей и в контроллере места нет толком.
По поводу ресурсов. Из того что есть на данный момент могу порекомендовать только эдакий план по изучению ангуляра: https://github.com/gdi2290/ngExam
vasIvas: да, на сервере у нас все максимально упрощается. На сервер приходит запрос, мы запрашиваем все необходимые данные и как только они приходят, прокидываем их в компоненты. Мы ограничены запросом/ответом, в рамзках этого промежутка времени состояние поменяться не должно.
У вас предзятое отношение к подходам, вы смотрите все исключительно через призму того что вы уже понимаете и выходит коллизия. Попробуйте посмотреть на вещи по другому. Более спокойно.
Что до этой штуки с "сложными структурами" и тд. - не вижу смысла в этом и предпосылок.
Ну и да, вот этот вопрос который у вас возник - это по сути "преждевременная оптимизация". Я не думаю что у вас проблемы с производительностью на сервере.
vasIvas: вы когда-нибудь писали обычные web приложения? Ну те которые рендрят html, где на фронтэнде вообще нет JS и тд.? Мы можем там обойтись одним инстансом приложения?
Суть в разделении контекста. Если у нас все сервисы stateless, все UI компоненты stateless, то мы можем это добро реюзать из запроса в запрос, а то что имеет состояние (те же сторы) множить.
И да, универсального решения нет. У меня лично пока небыло необходимости в подобных вещах потому никакой конкретики сказать не смогу. А все что я видел и все о чем слышал - сугубо индивидуально. То что работает для одних не будет работать для других.
