Оптимизация Flux: хранит действия диспетчеризации, вызовы AJAX в Web API Utils?

Я понимаю, что этот образ был последним руководством большинства, если не всех, программистов Flux. Имея этот поток в виду, у меня есть несколько вопросов:

Правильно ли/очень желательно иметь все мои вызовы $.ajax внутри моих Web API Utils?
- Обратные вызовы вызывают создателей действия, передавая данные в процессе
Если я хочу, чтобы мой Магазин совершил AJAX-вызов, мне сначала нужно вызвать Action Creator. Является ли принципиально неправильным вызов функции в Web API Utils непосредственно из Хранить?
Есть ли виртуальная односторонняя стрелка, соединяющая Сохранить с Action Creators?
- У меня много операций, которые не просматриваются через представления
Каковы Обратные вызовы между Диспетчер и Сохранить?
Что такое Веб-API здесь? Это где вы применяете API RESTful? Есть ли пример этого где-нибудь?

Можно ли использовать логику (чтобы узнать, какое Действие для отправки) в одном из моих Action Creators? В основном, это действие получает ответ от моего вызова AJAX. Это фрагмент:

var TransportActions = {
    receiveProxyMessage: function (message, status, xhr) {
        switch (message) {
            case ProxyResponses.AUTHORIZED:
                AppDispatcher.dispatch({
                    type: ActionTypes.LOGIN_SUCCESS,
                    reply: m
                });
                break;
            case ProxyResponses.UNAUTHORIZED:
                AppDispatcher.dispatch({
                    type: ActionTypes.LOGIN_FAIL,
                    reply: m
                });
                break;
            ...
        }
    }
}

Я видел много разных ответов в Интернете, но я до сих пор не уверен, как я включу их в свое приложение. TYIA!

Ответ 1

Правильно ли/очень желательно иметь все мои вызовы $.ajax внутри моих Web API Utils? Обратные вызовы вызывают создателей действия, передавая данные в процессе.

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

Я написал blogpost некоторое время назад, показывая один способ обработки запросов http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/

Если я хочу, чтобы мой магазин создал AJAX-вызов, мне сначала нужно позвонить в Action Creator, верно? Неправильно ли вообще вызвать функцию в Web API Utils непосредственно из Store?

Это хороший вопрос, и, насколько я видел, все делают это немного иначе. Flux (из Facebook) не дает полного ответа.

Как правило, вы можете использовать два подхода:

Вы можете сделать аргумент о том, что Store не должен "запрашивать" какие-либо данные, а просто переваривать действия и уведомлять представление. Это означает, что вы должны запускать действия "извлечения" внутри компонентов, если хранилище пуст. Это означает, что вам нужно будет проверить каждый просмотр данных, если он должен извлекать данные. Это может привести к дублированию кода, если несколько видов прослушивают один и тот же магазин.
Магазины являются "умными" в том смысле, что если их запрашивают данные, они проверяют, действительно ли у них есть состояние для доставки. Если они этого не делают, они сообщают API Utils об извлечении данных и возвращении состояния ожидания в представления.

Обратите внимание, что это "сказать API для извлечения данных" НЕ является операцией, основанной на обратном вызове, а "огнем и забыть". API будет отправлять действия после возвращения запроса.

Я предпочитаю вариант 2 для варианта 1, и я слышал, как Билл Фишер из команды Facebook сказал, что они делают это так же. (см. комментарии где-то в blogpost выше)

так Нет, по моему мнению, не совсем правильно назвать Api непосредственно из Магазина.

Есть ли виртуальная односторонняя стрелка, соединяющая Store to Action Creators?

В зависимости от реализации Flux это может быть очень удобно.

Каковы обратные вызовы между диспетчером и хранилищем?

Это единственные функции, которые могут фактически изменить состояние в магазине! каждый магазин регистрирует обратный вызов с Диспетчером. Все обратные вызовы вызываются всякий раз, когда действие отправляется. Каждый обратный вызов решает, нужно ли ему мутировать хранилище с учетом типа действия. Некоторые библиотеки Flux пытаются скрыть эту деталь реализации от вас.

Что такое веб-API? Это где вы применяете API RESTful? Есть ли пример этого где-нибудь?

Я думаю, что на изображении прямоугольник Web API представляет собой фактический сервер, API Utils - это те, которые совершают вызовы на сервер (т.е. $.ajax или суперагент). Скорее всего, RESTful API обслуживает JSON.

Общий совет:

Flux - совершенно свободная концепция, и точные реализации меняются от команды к команде. Я заметил, что Facebook изменил некоторые подходы здесь и там со временем. Точный цикл строго не определен. Есть некоторые довольно "фиксированные" вещи, хотя:

Существует диспетчер, который отправляет все действия во все магазины и разрешает только одно действие в то время, чтобы предотвратить адскую цепочку событий.
Магазины - это приемники действий, и все состояния должны быть изменены посредством действий.
действия "огонь и забыть" (никаких обратных вызовов!)
Представления получают состояние из хранилища и действий с огнем.

Другие вещи выполняются иначе, чем от реализации до реализации.

Ответ 2

Правильно ли/очень желательно иметь все мои вызовы $.ajax внутри моих Web API Utils? Обратные вызовы вызывают создателей действия, передавая данные в процессе.

Совершенно верно.

Если я хочу, чтобы мой Store сделал AJAX-вызов, мне сначала нужно вызвать Action Creator, верно? Является ли принципиально неправильным вызов функции в Web API Utils непосредственно из Store?

Сначала спросите себя, почему ваш магазин должен выполнить вызов API. Единственная причина, по которой я могу думать, это то, что вы хотите кэшировать полученные данные в магазинах (я делаю это).

В самых простых реализациях Flux все действия создаются только из View и Server. Например, пользователь посещает представление "Профиль", представление вызывает создателя действий profileRequest, вызывается ApiUtils, некоторые данные поступают, создается ServerAction, само обновление ProfileStore и ProfileView соответственно.

С кешированием: ProfileView запросить ProfileStore для какого-либо профиля, в хранилище его нет, поэтому возвращает пустой объект с загрузкой состояния и вызывает ApiUtils для извлечения этого профиля (и забывает об этом). Когда вызов завершится, будет создан ServerAction, ProfileStore будет обновлять себя и т.д. Это отлично работает. Вы также можете вызвать и ActionCreator из магазина, но я не вижу преимущества.

MartyJS делает что-то подобное. Некоторые реализации потоков делают то же самое с promises.

Я думаю, что важная часть: когда данные возвращаются в систему, вызывается ServerActionCreator с новыми данными. Затем он возвращается обратно в магазины.

Я считаю, что магазины должны только запрашивать данные, все действия, изменяющие состояние (обновления), должны быть инициированы пользователем (из представлений). Инженеры из Facebook писали об этом здесь: https://news.ycombinator.com/item?id=7719957

Есть ли как виртуальная односторонняя стрелка, соединяющая Store to Action Creators?

Если вы хотите, чтобы ваши магазины были умными: да. Если вы хотите, чтобы ваше приложение было простым: нет, перейдите в раздел "Виды".

Каковы обратные вызовы между диспетчером и хранилищем?

Это обработчики отправки, которые вы находите в магазинах. Диспетчер запускает действие, хранит прослушивание этого события пожара и что-то делает с действием/полезной нагрузкой.

Что такое веб-API? Это где вы применяете API RESTful? Есть ли пример этого где-нибудь?

Вот где ваши аякс-звонки идут. Обычно это будет означать некоторый REST API, но может также быть веб-сайтами или что-то еще. Мне всегда нравится этот урок: http://fancypixel.github.io/blog/2015/01/29/react-plus-flux-backed-by-rails-api-part-2/

Отказ от ответственности: это мои интерпретации Flux. Сам Flux действительно не решает выборку данных, поэтому они придумали Relay и GraphQL в FB