я думаю что текущего пользователя держать отедльно не нужно. `/users/:id` это раут, и держать его нужно в RouteStore или чем-то подобном. когда браузер переходит по ссылке `/users/1`, RouteStore будет иметь значения `this.currentRoute = 'users'` и `this.currentParams = {id: 1}`.
Имея id текущего юзера можно легко вытащить нужные данные из UsersStore.
большие приложения реального мира обычно не опенсорсят :)
у fluxible есть репозиторий с небольшими примерами (https://github.com/yahoo/flux-examples)
они используют HOC и предоставляют изоморфность.
глядя на последние тенденции в архитектуре (в том числе то что на самом сайте 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 например изначально хранили все состояние в одной неделимой структуре данных)
С учетом этих двух пунктов, количество стрелочек в диаграмме архитектуры значительно сокращается. И так как все они идут в одном направлении, элементы архитектуры можно группировать.
изначально во flux от facebook все flux объекты были синглонами. в браузере это не проблема — все в скоупе одного юзера, все данные принаджелат только этому юзеру. один dispatcher, один store.
на сервере же все по-другому. если параллельно пришло 1000 рексестов от разных пользователей, то для каждого нужно создать свой контекст со своими данными. иначе все перемешается же :)
React предоставляет эту функциональность.
в двух словах. есть входные данные (user, mailbox, conversations) они отправляются в реакт компонент на сервере и рендерится в javascript string, после чего отправляется клиенту вместе с исходными данными.
на клиенте после того как все библиотеки загрузились, мы берем те же данные и отправляем в тот же реакт компонент и говорим ему взять готовую верстку которую мы уже получили с сервера. так как конечный html идентичный в обоих случаях, реакт достаточно умный для того чтобы начать работать с имеющейся версткой так как будто он только что отрендерил ее сам (никаких DOM взаимодействий)
я буду переводить\синхронизировать все что касается React at Yahoo Mail на хабре :)
долгое время мы сопротивлялись и не хотели использовать flux на сервере из-за сложности (синглтоны уже не могут быть синглтонами, каждый реквест должен создавать новый контекст для flux) но в конце концов пришлось перейти на сторону flux на клиенте и сервере.
про reflux, к сожалению, сказать ничего не могу. не знаком :)
в будущем размер ветаки вырастет до ~250-300KB. (в данный момент js yahoo mail аж под мегабайт) и для стариков из деревней с очень медленным интернетом это всеже проблема :) так же как и мобильный интернет бывает очень медленным.
и да. о браузерах я забыл. сейчас Yahoo Web Mail это два приложения. одно полностью клиентское на Javascript. и второе полностью серверное request-response (для IE 6, 7, 8). Использование ReactJS дает нам возможность переходить в режим полностью серверсайд рендера (если это один из IE), и на каждый запрос выдавать готовый html. что полностью избавляет от головной боли кросбраузерного javascript и поддержки двух приложений.
именно так. рассчитано на пользователей с медленным интернетом (которых к сожалению в yahoo mail очень много).
ReactJS + все библиотеки и исходный JS код для клиента занимает ~100KB что достаточно много для первого старта приложения. поэтом как только приходит запрос от пользователя, мы возвращаем готовую статическую html страницу с контентом и начинаем грузить весь оставшийся JS. как только JS загрузился, мы наворачиваем клиентское приложение на готовую верстку и оно становится интерактивным (вешаются onclick и т.д.)
Имея id текущего юзера можно легко вытащить нужные данные из UsersStore.
у fluxible есть репозиторий с небольшими примерами (https://github.com/yahoo/flux-examples)
они используют HOC и предоставляют изоморфность.
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 например изначально хранили все состояние в одной неделимой структуре данных)
С учетом этих двух пунктов, количество стрелочек в диаграмме архитектуры значительно сокращается. И так как все они идут в одном направлении, элементы архитектуры можно группировать.
на сервере же все по-другому. если параллельно пришло 1000 рексестов от разных пользователей, то для каждого нужно создать свой контекст со своими данными. иначе все перемешается же :)
в двух словах. есть входные данные (user, mailbox, conversations) они отправляются в реакт компонент на сервере и рендерится в javascript string, после чего отправляется клиенту вместе с исходными данными.
на клиенте после того как все библиотеки загрузились, мы берем те же данные и отправляем в тот же реакт компонент и говорим ему взять готовую верстку которую мы уже получили с сервера. так как конечный html идентичный в обоих случаях, реакт достаточно умный для того чтобы начать работать с имеющейся версткой так как будто он только что отрендерил ее сам (никаких DOM взаимодействий)
долгое время мы сопротивлялись и не хотели использовать flux на сервере из-за сложности (синглтоны уже не могут быть синглтонами, каждый реквест должен создавать новый контекст для flux) но в конце концов пришлось перейти на сторону flux на клиенте и сервере.
про reflux, к сожалению, сказать ничего не могу. не знаком :)
и да. о браузерах я забыл. сейчас Yahoo Web Mail это два приложения. одно полностью клиентское на Javascript. и второе полностью серверное request-response (для IE 6, 7, 8). Использование ReactJS дает нам возможность переходить в режим полностью серверсайд рендера (если это один из IE), и на каждый запрос выдавать готовый html. что полностью избавляет от головной боли кросбраузерного javascript и поддержки двух приложений.
ReactJS + все библиотеки и исходный JS код для клиента занимает ~100KB что достаточно много для первого старта приложения. поэтом как только приходит запрос от пользователя, мы возвращаем готовую статическую html страницу с контентом и начинаем грузить весь оставшийся JS. как только JS загрузился, мы наворачиваем клиентское приложение на готовую верстку и оно становится интерактивным (вешаются onclick и т.д.)