Дмитрий Пищалка: потому что надо стремиться к этому. Есть задачи где это недостижимо, есть задачи где можно в 100% случаев оперировать имутабельными штуками.
copal не нужно пихать все в объекты, это глупо. У вас есть модуль, маленькое изолированное простанство, у вас есть тело функций, маленькие изолированные пространства. Чем меньше мы состояния имеем - тем проще с системой работать. Вот и все. Погуглите "Uncle Bob - The failure of state"
vostotskiy: в хроме - не должно, в cordova - будет работать (если вы его настроите, по умолчанию пофигу на CORS). Для хрома можно просто поднять CORS прокси, их готовых вогон и маленькая тележка.
Артем Кустиков: у меня страница генерится за 100-200 милисекунд. И под "мультиплексированием" я подразумевал не HTTP2, а просто отдельный эндпоинт апишки который в один запрос достает мне данные для нескольких запросов, агрегация данных и т.д. Это можно сделать посредствам мидлвэров и таким образом невилировать время на бутстраппинг приложения (я еще и на PHP апишки пишу, ага).
Использовать http.request на сервере - нормальная практика, особенно в рамках MVP. Когда нагрузки начинают расти можно уже на zeromq переключиться и т.д, нам в принципе без разницы ибо все закрыто абстракцией и подменить реализацию мы можем в любой момент.
Суть в том что "оптимизации" надо применять не потому что так "правильно", а потому что проблемы возникают. Скажем с экономической точки зрения, проще не менять реализацию сервера, а просто быстренько написать адаптер для ноды. Это можно сделать за пару часов и невилировать лэтенси сети при первоначальной загрузке данных, что уже дает существенный прирост производительности. А уже потом можно поставить реверс-прокси кэши, заменить http на zeromq+messagepack и т.д. Но обычно даже это уже не нужно.
Александр Burn: оп ООП для PHP нет ни одной достойной книги, это так, предупреждение. Более-менее приличные книги на эту тему писались под Java и где-то в конце 90-х начале двухтысячных.
Артем Кустиков: это не диагноз, это способ оптимизации без дополнительного оверхэда в плане реализации бэкэнда, без увеличения связанности клиента и сервера. Могу заявлять, что способ этот более чем адекватный и рабочий как full-stack разработчик (то есть я пишу и апишки и клиент). Так же есть еще парочка хитростей, вроде мультиплексирования запросов и т.д.
Артем Кустиков: обычно запросы происходят на тот же сервер, а это невилирует лэтенси сети (а так же нет ограничений по количеству одновременных запросов и т.д, да и в пределах loopback интерфейсов MTU намного выше. Ну и да, кеширование тоже штука полезная.
copal: MVC это не концепция архитектуры. Это "паттерн" и как всякий паттерн он описывает систему в маленьком масштабе, описывает взаимодействие трех небольших компонентов. Это капля в море.
раутер это часть контроллера (переход на другой раут это также же действие пользователя как и клик на кнопку). На бэкэнде, где обычно применяют mediating controller MVC (или MVA) - контроллер это не один объект а цепочка адаптеров. От точки входа до экшена конкретного действия.
Ассет менеджер - это тоже не об архитектуре. Это об управлении асетами. Архитектура это чуть другое.
косательно сторов во flux - и да и нет. С точки зрения flux это хранилище состояния и то, что отвечает за обработку состояния. То есть это модель. А с чем стор связан, как экшены прокидываются дальше, это уже выходит за границу области ответственности flux.
copal: MVC + Event Sourcing = Flux !== MVC. Это адаптация концепции MVC, которая изначально была заточено для мутабельной модели, под имутабельность и функциональщину. Это не может быть "только вью" так как нам действия надо как-то дальше прокидывать. Либо же у нас все что на клиенте превращается во view и это уже сильно усложняет концепцию.
Заслуга FB тут в том, что они перестали вклинивать эти три буквы и назвали совсем по другому, потому путаницы быть не должно.
К примеру вы говорите о том, что можно использовать flux для отказа изменений в противовес momento. Но это не так. Вы не должны "удалять" произошедшие действия, так как это уже мутация состояния и может привести к побочным эффектам. Вместо этого вы можете только накатывать новые действия, которые отменяют старые. В этом основное отличие от momento.
Redux же - это адаптация концепции, суть которой сводится к "единому источнику правды". Вместо кучи маленьких сторов у вас один стор для всего состояния. В случаях с очень сложной логикой это реально дает профит, так как вы не паритесь по поводу синхронизации сторов и т.д.
В рамках MVC у вьюх модель нужна была только для того, что бы слушать события, что бы забрать состояние и обновить себя.
В целом вместо того что бы спорить как что называется, лучше понимать как что должно работать и почему именно так.
copal: опять вы со своими событийно-ориентированными играми.
Да, Flux это MVC + Event Sourcing, а поскольку Event Sourcing это деталь реализации модели, то Flux = канонический MVC, где view и модель напрямую общаются, без посредников. View в этом случае - композиция UI компонентов. Диспатчер экшенов - контроллер по своей сути. Просто в концепции flux мы оперируем имутабельными штуками (продвигая функциональные подходы), а значит состояние нам прокидывается не по запросу view а сверху.
По поводу "новых правил" - в angular2 активно форсируют rx.js и реактивное программирование, это далеко не то же самое что обычные ивенты.
Артем: зато материалов намного больше, и возможностей в плане обучения предоставляет больше. Скажем в Yii2 есть IoC но им никто не пользуется, а потом у людей формируются бредовые идеи о том что IoC мешает тестированию и т.д.
Артем: лучше проигнорировать существование Yii2 и вернуться к нему только когда есть опыт с другими фреймворками. Yii2 неплохой фреймворк только если ты знаешь что делаешь.
lega: вот честно, я глубоко в change detection еще не успел погрузиться, я последний месяц активно изучал другие штуки (docker, continuous delivery налаживал), вот планирую на следующей неделе вернуться к ангуляру и разбираться.
насколько я помню, у них более реактивный подход, учитывающий зависимости между состояниями. Яркий пример - фильтры, теперь они не на каждый $digest срабатывают, а только когда исходне значение поменялось (в случае stateless фильтров).
copal: dependency inversion. Рассмотрим на примере Angular2.
Angular предоставляет мне сервис для работы с HTTP и я завязываюсь на его интерфейс. У этого сервиса есть две реализации - для браузера через XmlHttpRequest и для сервера. В зависимости от окружения подтягивается нужный сервис.
Вывод - мой код просто использует сервис, и его не парит как именно происходил запрос. Мой код от этого не меняется вообще.
copal: повторюсь еще раз - разницы не должно быть вообще. "клиент" просто рендрится на сервере, но это все тот же клиент. Сервисный слой приложения будет абсолютно таким же, те же запросы к тем же API. Профит за счет того, что обычно это происходит на том же сервере, что и API, а значит у нас нет лэтенси, и инициализация приложения не требует загрузки всяких там ангуляров по сети (оно всегда будет в памяти висеть по сути).
Если бы разница была - в "изоморфности" вообще нет никакого смысла.
