Является ли обычной практикой получение данных хранилища от создателя действий в потоке?

Является ли обычной практикой в ​​потоковой архитектуре извлечение данных из хранилища в создателе действий? Если нет, значит ли это, что все необходимые данные для сетевых вызовов лучше передавать через параметры компонента?

У меня есть приложение с трехуровневым компонентом, и мне просто интересно, насколько реально копировать данные с уровня 1 на уровень 3.

Любое объяснение будет принята с благодарностью.


reactjs javascript reactjs-flux
person BJacobs    schedule 10.03.2015    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Это нормально, когда геттеры хранилищ вызываются в создателях действий, но обычно создатель экшена вызывает модуль WebAPIUtils, где будет найден фактический вызов геттеров хранилищ.

Я бы поставил под сомнение практику передачи через уровень представления чего-либо, что на самом деле не используется представлениями (обычно компонентами React).

Сетевые вызовы обычно выполняются в рамках специального служебного модуля. Их иногда называют модулями DataLoaders или WebAPIUtils. Они отличаются от других служебных модулей тем, что часто извлекают данные из хранилищ перед выполнением сетевых вызовов.

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

person fisherwebdev    schedule 10.03.2015
comment
Как вы решаете, когда поместить логику в генератор действий, WebAPIUtil или хранилище? Где должна работать логика кэширования (например, извлекать данные с сервера только в том случае, если данные еще не сохранены), например, в хранилище? - person Markus-ipse; 11.03.2015
comment
Что касается вопроса о магазине и создателе действия, я думаю, что это в основном вопрос стиля и уверенности ли вы, что ваша команда не совершит ошибку, обработав ответ непосредственно в магазине. Если вы поместите это в создателей экшена, вы не сможете совершить эту ошибку. Выберите один подход для проекта и придерживайтесь его. Для кеширования я видел разные подходы, но всем им явно нужен доступ к данным хранилища либо напрямую, либо через геттеры. Обычно мне нравится хранить все, что связано с XHR, в модуле Utils и просто вызывать его либо из магазина, либо из создателей действий. - person fisherwebdev; 20.03.2015
comment
@fisherwebdev Как вы гарантируете, что в магазине будут доступны правильные данные, когда они вам понадобятся? Что произойдет, если вызов ajax, заполняющий хранилище, еще не завершен? - person kevinrutherford; 22.05.2015
comment
Вызовы XHR обычно обрабатываются тремя различными действиями: STARTED, SUCCEEDED, FAILED. Я не совсем уверен, что вы имеете в виду, говоря о том, что в магазине есть правильные данные, когда они вам нужны, но слой представления просто отображает то, что находится в магазине. Если XHR исходит от пользовательского ввода, вы можете делать оптимистичные обновления, отображая данные, которые пришли с STARTED, а затем подтверждать/откатывать после появления SUCCEEDED или FAILED. В качестве альтернативы, или если ваш XHR предназначен для исходных данных, вы можете использовать нулевые значения в качестве заполнителей и просто показывать счетчик, если ваши данные нулевые. - person fisherwebdev; 23.05.2015
comment
Я бы посоветовал вам не использовать XHR для начальных данных, если вы можете помочь, а вместо этого попытаться получить данные, включенные в начальную загрузку страницы, просто ради лучшего взаимодействия с пользователем. Затем вы можете взять данные и отправить их в действии INITIAL_DATA_LOADED перед рендерингом. Но если получение данных с загрузкой страницы действительно невозможно, я бы использовал нули и счетчики. - person fisherwebdev; 23.05.2015