Компоненты utils потока ReactJS
там интересно статьи
который описывает 4 основных класса, представленных в Flux
Utils.
- магазине
- ReduceStore
- MapStore (удалено из
3.0.0
) - контейнер
но не очень ясно, что следует использовать для определенных ситуаций. Есть только 2 примера для ReduceStore
и Container
, но нет образцов для других, к сожалению.
не могли бы вы объяснить основные использование для этих 4 компонентов: , когда и здесь они должны использоваться в реальной жизни?
расширенные ответы и примеры кода будут действительно оценены!
обновление:
MapStore был удалены начиная от 3.0.0
1 ответов
тычками через код и чтение документации метода, вот что я могу разработать (я сам не использовал эти классы, так как я использую другие фреймворки Flux).
на самом деле полезно идти почти в обратном порядке для них.
контейнер
это не подкласс FluxStore
потому что это, естественно, не магазин. The Container
- это класс-оболочка для ваших компонентов React UI, которые автоматически извлекает состояние из указанных хранилищ.
например, если у меня есть приложение чата, управляемое реакцией, с компонентом, в котором перечислены все мои зарегистрированные друзья, я, вероятно, хочу, чтобы он вытащил состояние из LoggedInUsersStore
, который гипотетически будет массивом этих пользователей.
мой компонент будет выглядеть примерно так (производный от примера кода, который они предоставляют):
import {Component} from 'react';
import {Container} from 'flux/utils';
import {LoggedInUsersStore} from /* somewhere */;
import {UserListUI} from /* somewhere */;
class UserListContainer extends Component {
static getStores() {
return [UsersStore];
}
static calculateState(prevState) {
return {
loggedInUsers: LoggedInUsersStore.getState(),
};
}
render() {
return <UserListUI counter={this.state.counter} />;
}
}
const container = Container.create(CounterContainer);
эта оболочка автоматически обновляет состояние компонента, если его зарегистрированные хранилища измените состояние, и это делает это эффективно, игнорируя любые другие изменения (т. е. предполагается, что компонент не зависит от других частей состояния приложения).
я считаю, что это довольно прямое расширение принципов кодирования React Facebook, в котором каждый бит пользовательского интерфейса живет в контейнере высокого уровня.- Отсюда и название.
при использовании
- если данный компонент React полностью зависит от состояния нескольких явных хранилище.
- если это не зависит от реквизита сверху. Контейнеры не могут принимать реквизит.
ReduceStore
A ReduceStore
это магазин, полностью основанный на чистые функции---функции детерминированные на своих входах (таким образом, одна и та же функция всегда возвращает одно и то же для одного и того же ввода) и производит отсутствие наблюдаемых побочных эффектов (поэтому они не влияют на другие части кода).
например, лямбда (a) => { return a * a; }
is чисто: он детерминирован и не имеет побочных эффектов. (a) => { echo a; return a; }
is нечистая: он имеет побочный эффект (печать a
). (a) => { return Math.random(); }
is нечистая: он является недетерминированным.
ворота ReduceStore
упрощение: делая ваш магазин чистым, вы можете сделать определенные предположения. Поскольку сокращения детерминированы, каждый может выполнить сокращения в любое время и получить то же самое результат, поэтому отправка потока действий практически идентична отправке необработанных данных. Аналогично, отправка необработанных данных вполне разумна, потому что вам было гарантировано отсутствие побочных эффектов: если вся моя программа сделана из ReduceStore
s, и я перезаписываю состояние одного клиента с состоянием другого (вызывая необходимые перерисовки), мне гарантирована идеальная функциональность. Ничто в моей программе не может измениться из-за действия а не данные.
в любом случае, a ReduceStore
должен реализовывать только методы, явно перечисленные в его документации. getInitialState()
должен определить начальное состояние,reduce(state, action)
должны преобразовать state
дано action
(и не использовать this
вообще: это было бы недетерминированным / иметь побочные эффекты), и getState()
& areEqual(one,two)
должен обрабатывать отделение необработанного состояния от возвращенного состояния (чтобы пользователь не мог случайно изменить его).
например, счетчик было бы разумно ReduceStore
:
class TodoStore extends ReduceStore {
getInitialState() {
return 0;
}
reduce(state, action) {
switch(action.type) {
case 'increment':
return state + 1;
case 'decrement':
return state - 1;
case 'reset':
return 0;
default:
return state;
}
getState() {
// return `this._state`, which is that one number, in a way that doesn't let the user modify it through something like `store.getState() = 5`
// my offhand JS knowledge doens't let me answer that with certainty, but maybe:
var a = this._state + 1;
return a - 1;
}
}
обратите внимание, что ни одно из преобразований явно зависит от текущего состояния объекта: они действовали только на state
переменная они были переданы. Это означает, что экземпляр хранилища может вычислять состояние для другого экземпляра того же хранилища. Не так полезно в текущей реализации FB Flux, но все же.
при использовании
- Если вам нравится чисто функциональное программирование (ура!)
- и если вам это не нравится, чтобы использовать фреймворк, явно построенный с этим предположением (redux, NuclearJS)
- и вы можете разумно написать магазин, который является чисто функциональным (большинство магазинов могут, и если они не могут, может иметь смысл подумать об архитектуре немного больше)
Примечание: этот класс не обеспечить что ваш код является чисто функциональным. Я думаю, что он сломается, если вы НЕ ПРОВЕРИТЕ ЭТО сами.
я всегда использовать этот магазин. Если только мне не понадобится...
FluxMapStore [устарело]
этот класс больше не является частью потока!
это подкласс ReduceStore
. Это для таких чисто функциональных магазинов, которые оказываются картами внутри. В Частности, Неизменным.JS maps (еще одна вещь FB!).
у них есть методы для получения ключи и значения из состояния:
WarrantiesStore.at('extended')
, а не WarrantiesStore.getState().get('extended')
.
при использовании
- как и выше, а также
- если я могу представить этот магазин с помощью карты.
FluxStore
это подводит нас к FluxStore: класс хранилища catch-all и общая реализация концепции хранилища Flux.
два других магазина являются его потомками.
в документация мне кажется довольно ясной в отношении ее использования, поэтому я оставлю ее на этом
при использовании
- если вы не можете использовать два других
Store
util классы для хранения данных - и вы не хотите, чтобы свернуть свой собственный магазин
в моем случае это было бы никогда: я предпочитаю неизменяемые рамки, такие как redux и NuclearJS, потому что мне легче рассуждать. Я забочусь о том, чтобы мои магазины были чисто функциональными путь. Но если нет, этот класс хорош.