В флюсе, зачем нужен магазин?

В соответствии с Flux Architecture View использует действие для вызова диспетчера, который обновляет Store, в то время как просмотр прослушивания сохраняет события изменения.В флюсе, зачем нужен магазин?

Мой вопрос: зачем нам хранить?

Чтобы перечислить всех пользователей, мой компонент вызовет ListAllUsersAction, который в свою очередь вызовет мой API и обновит Store с помощью вызова API. Затем Store затем испускает событие изменения, которое прослушивает View. Но магазин также сохраняет результат. Зачем? Почему этот средний слой нужен? Я вообще не позвоню в магазин, так что этот уровень кэша не имеет для меня никакого смысла, и поскольку я генерирую больше событий, которые загружают больше данных, в конечном итоге все мои магазины будут иметь все состояние моего приложения, потому что в архитектуре потока ничего не говорится об очистке магазинов ,

Я что-то упустил?

источник

2015-02-09 Dmitry Kudryavtsev

Целью Flux Store является хранение данных, которые необходимо разделить на несколько компонентов. Если никакие компоненты не нуждаются в данных, кроме одного, и данные не будут преобразованы - не требуется магазин. – Roman

Хорошо, позвольте мне уточнить немного больше. Допустим, что сообщения нужны только в одном компоненте: PostList. В соответствии с вашим ответом мне не нужен PostStore в таком случае. Когда мой компонент PostList загружен, он вызывает LoadAllPostsAction, но ti, кого испускает Action? Компонент не может прослушивать Actions, потому что поток прерывается. Он должен быть Component -> Action -> Store -> Component, и это закрывает однонаправленный поток данных. Я ошибаюсь? –

Я только что наткнулся на [обсуждение] (https://groups.google.com/forum/#!topic/reactjs/pZYYbyOHKCs), которое должно помочь прояснить ситуацию, главным образом, 4-го и 5-го сообщений. –

магазины находятся в ведении состояния приложения и логики, так, например, скажем, вы выборки всех пользователей через ListAllUsersAction, вы получите массив из вашего API

var users = [{firstName: 'LIMELIGHTS'}, {firstName: 'SKWEE357'}];

Теперь, имена пользователей, по-видимому капитализируются так как ваш API решает, что это способ доставки данных.

Этого просто не будет, так что вы хотите исправить это. Использование только Реагировать или просто Действие, где бы вы поместили этот код, где бы это имело смысл? На ваш взгляд, ваш диспетчер или ваше действие? Нет, вы определенно не хотите загромождать свой компонент React с этим типом логики. И не имеет смысла делать это манипулирование данными в диспетчере или действии, они, в конце концов, просто уведомители, что что-то должно произойти.

источник

2015-02-09 21:56:38

Хорошая точка, но это не отвечает на следующий вопрос: я посетил страницу Users, UserListComponent, называемую ListAllUsersAction, которая заполняет UsersStore, который выбрал событие, на которое подписано UserListComponent. Все хорошо: теперь в хранилище есть данные пользователей, а также компонент (дублирование данных?). Затем я перехожу к другой странице, которая инициирует подобный поток, затем другой, а затем, и в конце концов, поскольку хранилище никогда не очищается, клиент будет иметь все состояние приложения. Кто несет ответственность за очистку магазинов? –

О, и еще один вопрос: скажем, компонент A и компонент B прослушивают изменения хранилища пользователя, но компонент A перечисляет пользователей в нижнем регистре, а B - их в верхнем регистре. Какие данные хранятся в хранилище? –

Это не дублирование данных, потому что компонент не управляет собственной конкурирующей копией данных, а просто извлекает нужные данные из Магазина. Когда пользователь переходит на разные страницы, вы можете сохранить предыдущие данные (возможно, они вернутся и ожидают, что они все еще будут там), или вы можете отключить Actions в 'componentWillUnmount', чтобы установить его в null. Элементы отображения, такие как верхний регистр и строчный регистр, должны быть установлены в представлениях, текст может быть сохранен, как вам нравится. –

Целью Flux является то, что поток данных легко понять, даже когда приложения становятся большими и сложными, так что новый человек может быстро повышаться, выяснять, что происходит, проверяя исходный код и уверен, что они могут вносить изменения, не нарушая ничего. Модульность и разделение проблем - большая часть этого. Магазины - это способ сохранить модели данных независимо от деталей уровня представления и установить единый источник правды для состояния приложения. Вы можете посмотреть любой код Магазина и посмотреть, какие данные он хранит, какие действия он отвечает, какие зависимости он имеет для данных в других магазинах. Это вопрос организации ради разработчиков, ценой менее компактного кода.

Для того, чтобы перечислить всех пользователей, мой компонент будет вызывать ListAllUsersAction , что в свою очередь будет вызывать мой API и будет обновлять магазин с результат API вызова.

Поскольку функция действий в основном заключается в предоставлении обновленных данных в хранилищах, вы можете просто сначала вызвать API, а затем просто создать одно действие для обработки результата.

как я генерировать больше событий, который загружает больше данных, в конечном итоге все мои магазины будут иметь все состояние моего приложения, поскольку поток архитектура ничего не говорит о чистке Stores.

Держа текущее состояния приложения является намеченной функцией Stores.Если действия пользователя или вызовы API заставляют данные изменять, действия уведомляют магазины и магазины, ответственные за соответствующее обновление данных (возможно, даже сбрасываются до нуля). Нет необходимости в какой-либо другой очистке, потому что магазины, «имеющие все государство», именно то, что они должны делать.

источник

2015-02-09 23:26:28

Я создал чат для вопроса. Я был бы рад, если бы вы смогли присоединиться к http://chat.stackoverflow.com/rooms/70619/flux-architecture-and-the-purpose-of-stores –

В флюсе, зачем нужен магазин?

ответ

Смежные вопросы