Компоненты utils потока ReactJS

там интересно статьи который описывает 4 основных класса, представленных в Flux Utils.

  1. магазине
  2. ReduceStore
  3. MapStore (удалено из 3.0.0)
  4. контейнер

но не очень ясно, что следует использовать для определенных ситуаций. Есть только 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 упрощение: делая ваш магазин чистым, вы можете сделать определенные предположения. Поскольку сокращения детерминированы, каждый может выполнить сокращения в любое время и получить то же самое результат, поэтому отправка потока действий практически идентична отправке необработанных данных. Аналогично, отправка необработанных данных вполне разумна, потому что вам было гарантировано отсутствие побочных эффектов: если вся моя программа сделана из ReduceStores, и я перезаписываю состояние одного клиента с состоянием другого (вызывая необходимые перерисовки), мне гарантирована идеальная функциональность. Ничто в моей программе не может измениться из-за действия а не данные.

в любом случае, 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, потому что мне легче рассуждать. Я забочусь о том, чтобы мои магазины были чисто функциональными путь. Но если нет, этот класс хорош.