Comments 22
Ваши картинки еще больше запутали :)
Сам использую Flux подход и мне нравится, как он привносит понятную структуру и большую прозрачность в происходящее.
Но что я не люблю в таких статьях, так это упрощение типа «посмотрите на MVC — всё влияет на всё, куча стрелочек во все стороны, а теперь посмотрите на Flux — все стрелочки one way!», типа такого:
Но давайте посмотрим на Flux объективно:
1) у нас не один «прямоугольничек» View, их много — это целая иерархия React компонент
2) каждый View (React компонент) может генерировать Action
3) все Action проходят через единый Dispatcher, но если взглянуть на эту ситуацию как она есть на самом деле: каждый Action может быть обработан несколькими Store, каждый Store может обработать несколько Action — тут всё та же паутина стрелочек many-to-many между Action и Store
4) Store могут зависеть от других Store через механизм waitFor — это и есть каскадные обновления, только завёрнутые в промисы
5) Каждый Store может влиять на рендринг одного или нескольких View, а каждый View может зависеть от нескольких Store — опять паутина many-to-many стрелочек
6) И, наконец, рендринг одних View влияет на другие View, ведь это иерархия React компонент
Вот как это выглядит:
А теперь попробуйте на картинке про MVC взять все стрелочки, которые нарисованы влево (от View к Mode) и нарисовать их по большой дуге по часовой стрелке, вставив по пути квадратики «Action» — получается Flux!
Иными словами: Flux — это такой правильно нарисованный MVC с переименованными терминами (Model -> Store, Controller -> Action Creator + Dispatcher).
P.S. я не против Flux, я только за! Я против упрощений в попытках сравнить MVC и Flux, с которых начинается каждая первая статья про Flux.
Но что я не люблю в таких статьях, так это упрощение типа «посмотрите на MVC — всё влияет на всё, куча стрелочек во все стороны, а теперь посмотрите на Flux — все стрелочки one way!», типа такого:
Но давайте посмотрим на Flux объективно:
1) у нас не один «прямоугольничек» View, их много — это целая иерархия React компонент
2) каждый View (React компонент) может генерировать Action
3) все Action проходят через единый Dispatcher, но если взглянуть на эту ситуацию как она есть на самом деле: каждый Action может быть обработан несколькими Store, каждый Store может обработать несколько Action — тут всё та же паутина стрелочек many-to-many между Action и Store
4) Store могут зависеть от других Store через механизм waitFor — это и есть каскадные обновления, только завёрнутые в промисы
5) Каждый Store может влиять на рендринг одного или нескольких View, а каждый View может зависеть от нескольких Store — опять паутина many-to-many стрелочек
6) И, наконец, рендринг одних View влияет на другие View, ведь это иерархия React компонент
Вот как это выглядит:
А теперь попробуйте на картинке про MVC взять все стрелочки, которые нарисованы влево (от View к Mode) и нарисовать их по большой дуге по часовой стрелке, вставив по пути квадратики «Action» — получается Flux!
Иными словами: Flux — это такой правильно нарисованный MVC с переименованными терминами (Model -> Store, Controller -> Action Creator + Dispatcher).
P.S. я не против Flux, я только за! Я против упрощений в попытках сравнить MVC и Flux, с которых начинается каждая первая статья про Flux.
Я бы начал с того, что MVC тут в принципе неправильно нарисован. Стрелок от View к Model быть не может, модель обновляют только контроллеры.
Модель изменяет другую модель только через агрегирование (в том числе — объект, владеющий обеими моделями). Ну и в зависимости от задач — паттернов проектирования на самые разные ситуации кучи.
Объясните на пальцах в чем принципиальное новшество Flux кроме того, что он породил пару [лишних] абстракций? Однонаправленное движение событий? В MVC оно и так из коробки (пока кто-то не пытается накастылить и править модель прямо из вью, перемешивая все в кучу).
UPD: стрелка от View к Mode есть, но она обозначает «запрос данных», а не их изменение. В случае подписки на изменение модели вьюшкой в автоматическом режиме стрелку можно опускать.
Модель изменяет другую модель только через агрегирование (в том числе — объект, владеющий обеими моделями). Ну и в зависимости от задач — паттернов проектирования на самые разные ситуации кучи.
Объясните на пальцах в чем принципиальное новшество Flux кроме того, что он породил пару [лишних] абстракций? Однонаправленное движение событий? В MVC оно и так из коробки (пока кто-то не пытается накастылить и править модель прямо из вью, перемешивая все в кучу).
UPD: стрелка от View к Mode есть, но она обозначает «запрос данных», а не их изменение. В случае подписки на изменение модели вьюшкой в автоматическом режиме стрелку можно опускать.
глядя на последние тенденции в архитектуре (в том числе то что на самом сайте flux) я обратил внимание на две вещи:
1. чем больше приложение, тем меньше реакт компоненов имеют доступ к store. это или один (или несколько) controller views, которые агрегируют данные и передают дереву компонентов (дерево в свою очередь pure и не имеет сайд эффектов). Или же это использование higher order components (https://github.com/yahoo/fluxible-addons-react/blob/master/docs/api/connectToStores.md) которые абстрагируют дерево компонентов от stores, и приложение становится зависимо полностью от переданных props.
2. чем больше приложение, тем меньше количество stores. Одна из проблем Flux это то что stores разделяют две ответственности: (1) Бизнес логика приложение (что случилось в приложение, что нужно сделать) и (2) управление данными (как модифицировать определенный объект). Если все состояние приложения поместить в один store, который внутри имеет сложную структуру но на поверхности имеет простой интерфейс (обработчики actions), то это упразднит необходимость в использовании waitFor. сам waitFor сигнализирует что имеется зависимость данных, которая искуственна разделена на несолкько stores. (om и redux например изначально хранили все состояние в одной неделимой структуре данных)
С учетом этих двух пунктов, количество стрелочек в диаграмме архитектуры значительно сокращается. И так как все они идут в одном направлении, элементы архитектуры можно группировать.
1. чем больше приложение, тем меньше реакт компоненов имеют доступ к store. это или один (или несколько) controller views, которые агрегируют данные и передают дереву компонентов (дерево в свою очередь pure и не имеет сайд эффектов). Или же это использование higher order components (https://github.com/yahoo/fluxible-addons-react/blob/master/docs/api/connectToStores.md) которые абстрагируют дерево компонентов от stores, и приложение становится зависимо полностью от переданных props.
2. чем больше приложение, тем меньше количество stores. Одна из проблем Flux это то что stores разделяют две ответственности: (1) Бизнес логика приложение (что случилось в приложение, что нужно сделать) и (2) управление данными (как модифицировать определенный объект). Если все состояние приложения поместить в один store, который внутри имеет сложную структуру но на поверхности имеет простой интерфейс (обработчики actions), то это упразднит необходимость в использовании waitFor. сам waitFor сигнализирует что имеется зависимость данных, которая искуственна разделена на несолкько stores. (om и redux например изначально хранили все состояние в одной неделимой структуре данных)
С учетом этих двух пунктов, количество стрелочек в диаграмме архитектуры значительно сокращается. И так как все они идут в одном направлении, элементы архитектуры можно группировать.
Мне тоже очень не нравится эта идея с waitFor. А вы не знаете примеров сравнительно большого open-source приложения с одним сложным (желательно immutable и полиморфным) стором? :)
большие приложения реального мира обычно не опенсорсят :)
у fluxible есть репозиторий с небольшими примерами (https://github.com/yahoo/flux-examples)
они используют HOC и предоставляют изоморфность.
у fluxible есть репозиторий с небольшими примерами (https://github.com/yahoo/flux-examples)
они используют HOC и предоставляют изоморфность.
Не знаю, подходит ли это под ваши требования, но существует довольно популярная Flux-реализация — redux, которая как раз оперирует только одним стором и пропагандирует иммутабельность.
Да я удивляюсь, что сам dmitriiabramov мне его не посоветовал)
deleted
плюсую, сам такого же мнения, не так все просто как нам его продают.
Я вот недавно столкнулся с простой проблемой. Допустим вы делаете админку. Получается у вас все сторы превращаются в гигантские статические переменные, причем некоторые еще понятны, UsersStore — ок, список пользователей. А вот где держать пользователя при переходе на /users/:id? В UserStore? Тогда каждый раз оно будет обновляться, в итоге это просто глобальная переменная
я думаю что текущего пользователя держать отедльно не нужно. `/users/:id` это раут, и держать его нужно в RouteStore или чем-то подобном. когда браузер переходит по ссылке `/users/1`, RouteStore будет иметь значения `this.currentRoute = 'users'` и `this.currentParams = {id: 1}`.
Имея id текущего юзера можно легко вытащить нужные данные из UsersStore.
Имея id текущего юзера можно легко вытащить нужные данные из UsersStore.
Почему вконтакте никогда не было бага с нотификациями?
Есть ощущение, что успешно решается самими же придуманная проблема.
Есть ощущение, что успешно решается самими же придуманная проблема.
У вк есть баги с нотификациями.
Первый: если открыто несколько вкладок с вк, то уведомления в правом нижнем углу будут показывать количество сообщений умноженное на количество вкладок. Т.е. у вас открыто 3 вкладки с вк (аудио + диалоги + что-то еще), вам кто-то присылает два сообщения, но справа внизу у вас будет показывать не 2, а 6 входящих сообщений.
Второй: не обновляются badges сообщений в левом боковом меню, если нажать на "+1", то сообщения покажет, причем уже прочитанными, а сама цифра пропадает только после рефреша страницы.
Так что не надо тут про вк.
Первый: если открыто несколько вкладок с вк, то уведомления в правом нижнем углу будут показывать количество сообщений умноженное на количество вкладок. Т.е. у вас открыто 3 вкладки с вк (аудио + диалоги + что-то еще), вам кто-то присылает два сообщения, но справа внизу у вас будет показывать не 2, а 6 входящих сообщений.
Второй: не обновляются badges сообщений в левом боковом меню, если нажать на "+1", то сообщения покажет, причем уже прочитанными, а сама цифра пропадает только после рефреша страницы.
Так что не надо тут про вк.
Весьма экзотичные, на мой взгляд, ошибки. Не имею привычки открывать соц.сети в нескольких вкладках.
А вот бага с нотификациями фейсбука бросалась в глаза каждый раз, когда я заходил на этот ресурс.
С неисчезающей цифрой не такой бесячий баг, как у фейсбука. Я вот даже не помню его, просто поверил Вам на слово, что он есть.
А вот бага с нотификациями фейсбука бросалась в глаза каждый раз, когда я заходил на этот ресурс.
С неисчезающей цифрой не такой бесячий баг, как у фейсбука. Я вот даже не помню его, просто поверил Вам на слово, что он есть.
Вконтакте ещё так можно повторить багу с уведомлением о сообщении.
Имеем 2 компьютера, на работе и дома. И там и там открыта вкладка вконтакта, один из компьютеров, допустим рабочий — в сне.
Сидя дома мы получаем сообщение, открываем его, читаем.
На следующий день приходим на работу — во вкладке висит уведомление о непрочитанном сообщении.
Имеем 2 компьютера, на работе и дома. И там и там открыта вкладка вконтакта, один из компьютеров, допустим рабочий — в сне.
Сидя дома мы получаем сообщение, открываем его, читаем.
На следующий день приходим на работу — во вкладке висит уведомление о непрочитанном сообщении.
Забавно, я понял эту схему когда разобрался с флюксом. Когда только разбирался в нём — картинки только запутали)
Sign up to leave a comment.
Flux в картинках