Погуглите "Event Sourcing". Тут та же идея, только Event Sourcing это только управление состоянием (тобиш модель) а Flux - это MVC + Event Sourcing. А Redux это Flux + single source of truth.
Если у вас нет по сотне состояний на скрин, вам это все не очень то надо. А вот если отслеживать состояния боль - то вот такие штуки спасают.
Вы чего говорите-то? Flux - это mvc... Flux - это все тоже представление! Вы так и не можете выйти за пределы рамок вэб и постичь mvc и понятие настоящих компонентов.
Точнее сказать, Вы транслируете услышанное, но сами, как-будто не хотите сделать шаг вперед и сказать что кто-то, хоть и весомый, ошибается. Можно Вам один вопрос - что Вы будите делать, если завтра вдруг новым правилом angular2 станут события?
copal: опять вы со своими событийно-ориентированными играми.
Да, Flux это MVC + Event Sourcing, а поскольку Event Sourcing это деталь реализации модели, то Flux = канонический MVC, где view и модель напрямую общаются, без посредников. View в этом случае - композиция UI компонентов. Диспатчер экшенов - контроллер по своей сути. Просто в концепции flux мы оперируем имутабельными штуками (продвигая функциональные подходы), а значит состояние нам прокидывается не по запросу view а сверху.
По поводу "новых правил" - в angular2 активно форсируют rx.js и реактивное программирование, это далеко не то же самое что обычные ивенты.
Сергей Протько: сами fb говорят что flux это не mvc. Я тоже сначала счел что они знают "неправильную версию mvc" и именно по этому так говорят. Нет, они правы, если вслушаться в их слова, то они говорят что -"это не mvc, это сторы, которые хранят ссылки на модели". То есть суть flux в том, что границы компонента не заканчиваются самим react Component, а стор это логика компонента - логика представления. То есть стор это железное представление. То есть флюкс, это просто все тоже представление. И вот здесь хочу подметить, как я уже делал сотню раз, что Вы или кто-то другой, сам додумывает, как ему хочется, а именно они не говорят как это представление общается с моделью.
Вот Вы сейчас повторили в миниатюре то, почему развилось столько вариаций mvc.
И это и тот факт что вэб разработчики отвергают понятие представление js, родился redux, который урезал компонент отобрав его логику и опять смешал все в кучу.
И я читал о подходе, который Вы упоминаете и счел его "поканенужным", но дело не в том... Дело в том что его можно использовать, например, для ... ну я не знаю для чего, даже для отката операций существует моменто... но даже если его и использовать, то мне кажется как малую часть приложения, но не как основную архитектуру, как это в redux сделали.
И честно сказать я не понимаю что такое реактивное программирование. Когда я читаю, то вижу только обычную событийную модель.
Сергей Протько: и ещё, у компонентов нет модели, у них есть состояние. Компонент для приложения это один кирпичик, который может состоять и других кирпичиков, но они не могут быть реализованы по модели mvc, так как она на них просто не налезет. Компоненты это всегда представление.
copal: MVC + Event Sourcing = Flux !== MVC. Это адаптация концепции MVC, которая изначально была заточено для мутабельной модели, под имутабельность и функциональщину. Это не может быть "только вью" так как нам действия надо как-то дальше прокидывать. Либо же у нас все что на клиенте превращается во view и это уже сильно усложняет концепцию.
Заслуга FB тут в том, что они перестали вклинивать эти три буквы и назвали совсем по другому, потому путаницы быть не должно.
К примеру вы говорите о том, что можно использовать flux для отказа изменений в противовес momento. Но это не так. Вы не должны "удалять" произошедшие действия, так как это уже мутация состояния и может привести к побочным эффектам. Вместо этого вы можете только накатывать новые действия, которые отменяют старые. В этом основное отличие от momento.
Redux же - это адаптация концепции, суть которой сводится к "единому источнику правды". Вместо кучи маленьких сторов у вас один стор для всего состояния. В случаях с очень сложной логикой это реально дает профит, так как вы не паритесь по поводу синхронизации сторов и т.д.
В рамках MVC у вьюх модель нужна была только для того, что бы слушать события, что бы забрать состояние и обновить себя.
В целом вместо того что бы спорить как что называется, лучше понимать как что должно работать и почему именно так.
Сергей Протько: Вы говорите что redux это единый источник данных. Но каких данных? Картинки, текст (строки которые мы читаем), звуки - это все ассеты.
Получается что чем бы не был единый стор redux, он является ассет-манагером, как не крути. Но так же это означает что логики приложения в нем просто нет и быть не должно.
Ассет-манагер это круто и является самой последней правдой в архитектуре в которой присутствует представление. Ведь асеты, которые я перечислил выше не являются логикой представления и просто аморально хранить их в модели.
Идем дальше. Раз мы разобрались что существую данные-ассеты, коими являются ассеты, то ответьте мне на вопрос - разве сторы из flux являются моделями? Или же они являются датапровайдерами для ассетов? А вот теперь представьте что представление нуждается в ассете, как она его получит? естественно в приложении с событийной моделью, оно пошлет сообщение - "нуждаюсь в таком-то ассете" и когда ассет-манагер загрузит (если это требуется), то положит его в стор-провайдер, ссылка на который уже присутствует в представлении.
Хочу сделать Вам комплимент сказав что Вы просто офигенно рассказываете, люди Вам верят. Но чего Вы рассказываете, говоря о модели, компонентах и ассетах? Модель не имеет к этому отношения.
Поймите же, компоненты это представление -> представления работают только с данными представления и логикой представления -> как представление получит данные и как представление обработает их не касается никого! flux - это представление + очень продвинутый asset manager. И это вполне допустимо, что данные парсятся в провайдере.
Все наверное встречали вопросы - "как приспособить роутер в mvc", "как загрузить картинку по mvc"... ? Это глупо все натягивать на mvc, ведь это концепция архитектуры.
mvc не волнует, как представление получит данные-ассеты. Оно может их через сервис грузить или переложить это на плечи ассет-манагера - это mvc безразлично. Но mvc важно чтобы эти самые ассеты не в коем случаи не попали в модель. Или ещё чего хуже, что модель будет указывать как эти данные представление должно показывать.
Presenter подписывается на события от View
View эмитит события
Presenter ловит события и делает запросы в Model
При получении ответа от Model, Presenter обновляет View
И они правы, а следом говорят о mvvc -
ModelView подписывается на события от View
View эмитит события
ModelView ловит события и делает запросы в Model
При получении ответа от Model, ModelView обновляет View
следом они говорят что это одно и тоже! Но это не так! mvvc это когда представление шлет событие, представление-модель его ловит и что-то просит у модели, модель ему шлет событие и представление-модель тоже пересылает событие. Представление ловит и ЗАБИРАЕТ у представления-модели.
В mvp контроллер устанавливает представление, в mvvc представление забирает данные. Так же в mvvc представление работает с представлением так, будто они оба представления. Об этом и говорится на вики.
Модель (англ. Model), так же, как в классической MVC, Модель представляет собой фундаментальные данные, необходимые для работы приложения.
Представление (англ. View) — это графический интерфейс, то есть окно, кнопки и т. п. Представление является подписчиком на событие изменения значений свойств или команд, предоставляемых Моделью представления. В случае, если в Модели представления изменилось какое-либо свойство, то она оповещает всех подписчиков об этом, и Представление, в свою очередь, запрашивает обновленное значение свойства из Модели представления. В случае, если пользователь воздействует на какой-либо элемент интерфейса, Представление вызывает соответствующую команду, предоставленную Моделью представления.
Модель представления (англ. ViewModel) является, с одной стороны, абстракцией Представления, а с другой, предоставляет обёртку данных из Модели, которые подлежат связыванию. То есть, она содержит Модель, которая преобразована к Представлению, а также содержит в себе команды, которыми может пользоваться Представление, чтобы влиять на Модель.
Но видно автор не понял смысл слов "которыми может пользоваться". И вот теперь прочтя эту статью появятся небольшая армия изготовителей redupserov.... С ними тоже будет бесполезно спорить.
copal: MVC это не концепция архитектуры. Это "паттерн" и как всякий паттерн он описывает систему в маленьком масштабе, описывает взаимодействие трех небольших компонентов. Это капля в море.
раутер это часть контроллера (переход на другой раут это также же действие пользователя как и клик на кнопку). На бэкэнде, где обычно применяют mediating controller MVC (или MVA) - контроллер это не один объект а цепочка адаптеров. От точки входа до экшена конкретного действия.
Ассет менеджер - это тоже не об архитектуре. Это об управлении асетами. Архитектура это чуть другое.
косательно сторов во flux - и да и нет. С точки зрения flux это хранилище состояния и то, что отвечает за обработку состояния. То есть это модель. А с чем стор связан, как экшены прокидываются дальше, это уже выходит за границу области ответственности flux.
Сергей Протько: ну тогда это не паттерн, а мультипаттерн, который описывает архитектуру на основе множества паттернов, что делает mvc концепцией. Это как концепция города, где каждый занят своим делом, постовые управляют движением, монтеры чинят и управляющие управляют всеми. И если нарушить эту концепцию, то получится колхоз.
Говоря что сторы хранят состояния, нужно уже начать объяснять какое.. Ведь в сторе не будет хранится состояние кнопки. Я нажал на кнопку, родитель об этом узнал и что-то сделал. Сторы не задействованы, сторы flux. Вот сторы redux их хранят, ведь это все сразу, и выглядит так, как инлайн стили для css разработчика. Нет модели, её смешали с ассетами и все это ради того что было до времен ооп. У меня складывается ощущение, что в вэб прорвались программисты языка, который просто реально не может реализовывать ооп и поэтому они продвигают то, что выражается в redux. Лично мне только это приходит на ум, когда я вижу функцию состоящую из десятка switch. Такое ощущение, что люди не знают о map'ах. То есть как-будто этот код от туда, где даже hash реализовать нельзя, прходится тысячу switch писать.
Это я о коде с использованием redux.
И ещё раз скажу слова, которые нужно зазубрить - ассеты, коими являются картинки, звуки, видео и то что мы называем текст, это только дело представления. Точка. Любая парадигма должна это понимать. И не нужно ждать тысячу лет пока кто-то из весомых об этом скажет, нужно самому думать.
Ассет манагер, это самое сложно в приложении. Хороший ассет-манагер это неотъемлемая часть архитектуры, так как даже код может являтся подгружаемым ассетом. если я сделаю приложения показа кода, как например codepen, то подгружаемый код тоже будет являться ассетами. Это очень сложная система, совокупность большего количества паттернов чем все взятые mv**. То что сейчас происходит с js является внедрением ассет-манагера на уровне натива, но это ещё не скоро будет, если будет вообще.
Все эти redux, flux, mvc, mvp и остальные это еще не вся архитектура приложения, это всего лишь концепции UI архитектуры. Да, для мелких и средних приложений хватает одной этой UI архитектуры. Но для больших приложений (уровня google docs word, gmail) все это (redux, flux, mvc, mvp ...) является лишь частью большой архитектуры, и ее роль лишь отобразить каким либо образом сложные модели ядра приложения.
iKBAHT: так, а моя точка зрения как-то противоречит?
Для меня MVC/MVP/etc это лишь способ отделения UI от приложения. То есть M - приложение, та его часть которая граничит с UI, а VC - это UI layer. Не более. А как строится M - это уже дело приложения. Быть может там гексагональная слоеная архитектура, а может быть просто объект предметной области с DAO. Зависит от сложности приложения.
Я тоже ни как не могу понять для чего это все?
Правильно ли я понимаю, что мои приложения видимо еще не достаточно велики, и если я могу обойтись одним state в корневом родителе, передавая все потомкам в props, то лучше обойтись без Redux или Flux?
Средний
