#DataFlow Про глобальные сторы

[azinit]

Хочется статью, с базовым описанием того, что лучше хранить стейт максимально ближе к использованию
(на грани с дата-флоу)

[azinit]

Взято из личного ответа, обобщающего ответы из чата

---

Ну я на этом поприще тоже много экспериментировал, в том числе с неким "общим глобальным сторам"
(в том числе для "переиспользования" в других местах, куда без этого)
Но потом быстро стали появляться надстройки глобального лоадинга типа isLoadingTable , isLoadingFilters и т.п.Т.е. пришло все по итогу к рили тому, чтобы каждый полноценный виджет/фича хранили состояние isLoading локально
Да и современные практики дата-флоу (как у эффектора) в целом нас побуждают к тому, чтобы мы по-минимуму хранили что-то глобально
(т.к. на это легко подвязаться и сломаться, из-за того что кто-то это поменял)
https://t.me/feature_sliced/7244
Похожая концепция проявляется и у конкретных решений типа react-query и apollo
(если же делаем свое "кеширование" с редаксом/эффектором - то в целом все тоже сводится к тому, что есть условные { data, loading, error } у каждого запроса)
https://react-query.tanstack.com/guides/queries#query-basics

Т.е. резюмируя - глобальный лоадинг почти наверняка не нужен в твоих случаях
И тем более чтобы отдельный entity ради этого заводить)Это как раз больше про технический аспект реализации

---

[azinit]

*Подчеркну - вопрос на грани с дата-флоу, 
и во многом зависит от специфики проекта, 
т.е. не регламентируется методологией
(но то что ниже - это скорее субъективный опыт)

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

https://t.me/feature_sliced/7244
https://t.me/feature_sliced/7083

[azinit]

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

Кажется, это просто не очень идея 🤔

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

В рамках рилворлда, где требуемый результат заранее известен и не меняется,
 это решение мб и сойдет, но оно не оч "реалистичное" тогда

https://t.me/feature_sliced/4583

[azinit]

Не уверен, что делать один стор с ошибкой на проект - верное решение 🤔

Что если у тебя упадут два запроса друг за другом?

Думаю, вернее отдельно описывать обработку ошибок 
в рамках конкретных фичей/сущностей/виджетов - я делаю так
В том числе и представление ошибок в интерфейсе

https://t.me/feature_sliced/9326