Компонент сам себе стор, а внешний стор это антипаттерн

[nektobit]

Внешний стор используется для того чтобы шарить состояние между компонентами. Такая нужда возникает не часто, не вижу проблем с этим. Правда я пишу только на ng/vue, не знаю как там с реактом:) И да, я тоже не пишу редьюсеры, помимо redux есть жизнь.

[cmyser]

Ну я вижу два пути, либо в родительском компоненте хранить состояние и передавать в дочек, либо в урл ставить значение

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

[unPayo]

Более чем странная логика у автора статьи. Что-то типа - "Некоторые владельцы (не известное количество) балконов (хранилищ общих данных для нескольких компонент в одном месте) марки Redux захламляют их (кладут туда и локальные данные). Долой балконы как класс! Покупайте квартиры марки $mol со встроенными балконами."

Так претензии к балконам конкретной марки? К их некорректному использованию? К балконам в принципе? Но встроенный в $mol балкон не перестает быть балконом и не имеет защиты от некорректного использования.

P.S. Я тоже не вижу большого смысла в инструментах типа Redux, Vuex. Но, хотелось бы видеть аргументированную объективную техническую критику. А не рассуждения на тему, что кто-то кое-где у нас порой...

[cmyser]

Претензия к сторам что они поощряют "захламление"

В моле тоже можно сделать супер компонент и передавать его везде, но даже при написании такой мысли закрадываются сомнения о целесообразности данного решения)

[unPayo]

А в чем тут могут быть сомнения?

Например, возьмем данные получаемые с сервера. А, как мне кажется, это львиная доля отображаемых данных в большинстве приложений. Одни и те же данные используются в разных компонентах. Вполне логично хранить "снимок" состояния данных сервера в одном месте в формате максимально приближенном к тому, в котором они приходят с сервера и с максимально мелкой степенью грануляции. И любой компонент может отображать нужные ему "гранулы" состояния сервера, свои локальные данные да и любую смесь из этих двух типов сделанную через какой-нибудь computed.

В данном случае абсолютно не важно как называется балкон инструмент. Лишь бы он обеспечивал необходимую функциональность. Я, например, строю такую схему на Mobx.

[Nomad-lab-sketch]

Я сам пришел к такой же модели, только реализация у меня своя. Так же scoped store который привязан к текущему месту использования. И если сам scop дестроится то и нет смысла хранить данные. Конечно могут быть ситуации когда реакт решит что надо компонент перерендерить и по итогу у нас заново структура хранения инициализируется и данные заново запрашиваются, это конечно не приятно. НО это заставляет правильно рендер оптимизировать что бы лишний раз не чего не пересоздавалось, но и тут есть цена.. в реакте управлять рендером напрямую нельзя к сожалению и сам реакт говорит "Не хочешь что бы я ререндерил узел? Выделяй память!". И это беда... т.к на высоконагруженных интерфейсах память может забиваться только так..

[cmyser]

О, на этот счёт могу посоветовать почитать вот эту статью https://habr.com/ru/articles/723728/