Redux: попытка избавиться от потребности думать во время запросов к API

[Veikedo]

Анализировать полученные данные и данные, лежащие в store, и, если там не хватает связанных по foreign key данных, делать еще запросы.

Что-то этого в статье не видно.
Явно, должно быть ещё middleware.

Кстати, схему делал в проекте с помощью https://github.com/mchlbrnd/normalizr-decorators с автогенерацией из моделей бекенда

[geoolekom]

Про middleware я написал в разделе «постановка задачи». Конечно, в статье его ещё нет — ведь компоненты описывать я буду только в следующей части. Там появится и middleware, и reducer, и action creator.

[raveclassic]

А все потому, что не нужно пытаться пихать в стор все подряд. Redux — это не про «хранение всего состояния приложения», хотя может показаться, что это так.

Нужен вам local-запрос, ну так сделайте его в контейнере, ничего криминального в этом нет. А если вам нужно в нескольких частях приложения отреагировать на его результат или ошибку — используйте redux.

[Veikedo]

А по-моему, это как раз про то.
Имея middleware и единую шину, мы можем контролировать и реагировать на любое действие централизованно, а не позволять произвол на местах (в контейнерах).
Взять ту же обработку ошибок/логгирование/телеметрию.

+без redux надо shouldComponentUpdate писать самому

[raveclassic]

Никто не спорит. Я лишь говорю, что делаться это должно с умом, без фанатизма и только там, где нужны эти реакции. Однако же вам придется заново компоновать такие запросы, так как они будут скорей всего нормализованы и уже собранное компонентами/контейнерами дерево композиции потеряется. И тут тоже ничего плохого нет, просто в 99% случаев этот момент — причина непонимания и недовольства.

[Tim152]

Конечно, рано или поздно данные на клиенте теряют актуальность — нам нельзя слепо полагаться на данные, которые когда-то давно к нам пришли с сервера. Поэтому надо предусмотреть механизм инвалидации старых данных и записать «время жизни» каждого типа данных в конфиг.

— такое решение пороховая бочка и кладезь ошибок, лучше подключить вебсокеты и тогда ваше хранилище станет отражением сервера

[geoolekom]

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

[raveclassic]

Можно же поднять посредника в лице чего-нибудь в духе pouchdb, и общаться как на клиенте, так и на бэке с этим хранилищем.

[jankovsky]

Солидарен с автором на счет сложности, поэтому отказался от этих всех вебпаков, но свой велосипед не хочется писать. Jquery или mootools побеждает это вот все.

[Druu]

А в чем преимущество предложенного решения перед стандартный workflow? Точно так же ведь надо объявить типы экшенов, создать экшен криэйторы, написать редьюсеры. Что изменилось?

[geoolekom]

Просто этот модуль мы пишем один раз и используем во всех проектах, правя только конфиги.

[Druu]

У вас одинаковые проекты что ли? Ну тогда да, повезло.

[geoolekom]

Прелесть в том, что если проект базируется на REST API, то этот пакет будет работать для всех таких проектов.

[Druu]

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

[sky2high0]

Посмотрите apollo-graphql. Там есть нужные вам функции и ещё много всего.