Comments 15
Анализировать полученные данные и данные, лежащие в store, и, если там не хватает связанных по foreign key данных, делать еще запросы.
Что-то этого в статье не видно.
Явно, должно быть ещё middleware.
Кстати, схему делал в проекте с помощью https://github.com/mchlbrnd/normalizr-decorators с автогенерацией из моделей бекенда
А все потому, что не нужно пытаться пихать в стор все подряд. Redux — это не про «хранение всего состояния приложения», хотя может показаться, что это так.
Нужен вам local-запрос, ну так сделайте его в контейнере, ничего криминального в этом нет. А если вам нужно в нескольких частях приложения отреагировать на его результат или ошибку — используйте redux.
Нужен вам local-запрос, ну так сделайте его в контейнере, ничего криминального в этом нет. А если вам нужно в нескольких частях приложения отреагировать на его результат или ошибку — используйте redux.
А по-моему, это как раз про то.
Имея middleware и единую шину, мы можем контролировать и реагировать на любое действие централизованно, а не позволять произвол на местах (в контейнерах).
Взять ту же обработку ошибок/логгирование/телеметрию.
+без redux надо shouldComponentUpdate писать самому
Никто не спорит. Я лишь говорю, что делаться это должно с умом, без фанатизма и только там, где нужны эти реакции. Однако же вам придется заново компоновать такие запросы, так как они будут скорей всего нормализованы и уже собранное компонентами/контейнерами дерево композиции потеряется. И тут тоже ничего плохого нет, просто в 99% случаев этот момент — причина непонимания и недовольства.
Конечно, рано или поздно данные на клиенте теряют актуальность — нам нельзя слепо полагаться на данные, которые когда-то давно к нам пришли с сервера. Поэтому надо предусмотреть механизм инвалидации старых данных и записать «время жизни» каждого типа данных в конфиг.
— такое решение пороховая бочка и кладезь ошибок, лучше подключить вебсокеты и тогда ваше хранилище станет отражением сервера
Солидарен с автором на счет сложности, поэтому отказался от этих всех вебпаков, но свой велосипед не хочется писать. Jquery или mootools побеждает это вот все.
А в чем преимущество предложенного решения перед стандартный workflow? Точно так же ведь надо объявить типы экшенов, создать экшен криэйторы, написать редьюсеры. Что изменилось?
Просто этот модуль мы пишем один раз и используем во всех проектах, правя только конфиги.
У вас одинаковые проекты что ли? Ну тогда да, повезло.
Прелесть в том, что если проект базируется на REST API, то этот пакет будет работать для всех таких проектов.
Ни разу не встречал такой ситуации, когда экшоны на клиенте четко соответствуют апи. Обычно отдельно слой взаимодействия с бекендом, отдельно — экшоны (они зависят от функциональности клиента, а не от апи, апи и слой взаимодействия с ним как раз могут быть заменены, а экшоны останутся теми же). Если в вашем случае это соответствие есть — тогда да, будет удобно все работать.
Посмотрите apollo-graphql. Там есть нужные вам функции и ещё много всего.
Sign up to leave a comment.
Redux: попытка избавиться от потребности думать во время запросов к API