[React.js] Разные варианты хранилищ...
 

Когда начал читать и пробовать React.js, меня удивило количество всяких наворотов вокруг хранения, изменения и чтения состояния в приложениях...

Но ни одни навороты, на мой взгляд, никак не облегчают разработку ПО. Куча импортов... Функций...

Роутинг можно оставить, он не особо усложняет дело, благо с histiry вроде разобрались. :D

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

Или есть таки какой-то профит во всех этих наворотах?
Поделитесь опытом в разработке на React.js, может пригодится не только мне но и кому-то еще...

Вот казалось бы, реакт тупо рендерер, и ничего проще чем ) document.getElementById('').append() - но тем не менее он весит аж 200кб, вывод: что-то не все просто.

Для тех, кто не очень в курсе:

https://pomb.us/build-your-own-react/

-
Насчет state management, есть глобальный стейт и локальный, (выяснил эмпирическим путем), с реактом дружу с 12 версии, поэтому я попробовал практически все что было :)

Redux - нормальное решение, можно его брать, существует давно, дев.тим постоянно что-то улучшает... сейчас уже есть RTK (redux toolkit). Простая установка. Подходит для глобального стэйта... были у меня как-то вопросы, те же дев.тим бодро в дискорде отвечали, от них же было утверждение, что для локального стэйта можно использовать Context, и useState... это пожалуй самый большой облом. Хотелось бы all-in-one. Порог вхождения - средний, в том плане, что нужно хорошо понимать javascript. Недавно вышел RTKQ (redux toolkit query) - интересно.

Apollo - это пожалуй самый приближенный вариант ) как должно быть... я про cache & invalidate, reactive vars, optimistic update, etc...

MobX - подкупает своей простотой... не прижился. Нет транспортного слоя, это про аналог RTKQ.

Recoil - пишут что официальная команда делает систему хранилища. Покрутил, повертел ну пока хз.

Context - слишком много ручной работы.

Все оно примерно одно и тоже, но только по другому. Что не возьми будут свои подводные камни и не так как хотелось бы )...

-
Насчет профита, ну прокачаешь свой скилл в понимании концепций, будешь легко разбираться в новых штуках. Программы сами не напишутся :) в какой-то момент понимаешь какой ты упоротый упырь, все знаешь, все понимаешь ) а живешь как бомжара... Надо было на манагера ) учиться... рукой водить, получать больше, в xsl ) галочки ставить... а не бороться со всякими IE6, es100500..

Не учись на программистов ) это сделает вас несчастными )

--
На счет событий + стор + хук = здесь есть один жирный недостаток, не получится сделать SSR ) без headless browsers

Тут на все 100% правильно! :D

Вот его и рассматривал более подробно.
Но пока не нашел ничего в нем "улучшающего" в сравнении с "моим" подходом через события. :-?
Они пропсы не тянут до элемента, зато оберток накручивают будь здоров!
В моем случае ничего крутить не нужно, но пропсы прокидывать до конечного элемента придется.

Даже рассказать новичкам или другим не особо "продвинутым" сотрудникам, как работает тот или иной вариант достаточно проблематично. :(
С "моим" вариантом таких сложностей нет. Отследить пропсы по цепочке не сложно...

Сейчас почитаю про это... :blink:

SuperZen, ты про вот это?

Что такое [B]SSR[/B]. [B]SSR [/B]– (анг. аббревиатура от Server Side Rendering) это технология, которая позволяет, с помощью Node.js, запускать JavaScript код на сервере (а не в браузере как обычно) и готовый результат отправлять пользователю, избегая лишней нагрузки на его браузер и компьютер.

Так у меня все элементы рендарятся согласно стейту... Т.е. и тут я смогу все свои страницы запустить на Node.js и получить хтмл (согласно переданным пропсам).
Ведь мои события обеспечивают только "динамику" на самом сайте. А статику создать вообще нет проблем.
Т.ч. про это я думал... Но пока не использовал. :no:

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

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

В общем, я бы порекомендовал именно MobX

MobX - это плохой vue/reactivity.(ну точнее наоборот, vue/reactivity - это MobX сделаный нормально)
То что вместо массивов юзается какая-то херня, которая требует плясок - это для меня абсолютный диал брикер.

Плюс когда я поизучал как склеивается MobX с, собственно, React, у меня в очередной раз заполыхал зад. React он, конечно, not opinionated, но и расширить его на самом деле нельзя. MobX туда засунут чисто через костыли.

Такой банальной, казалось бы, вещи как использование props совместно с computed для динамического локального состояния тоже получить невозможно без двойного рендера и кучи оверхеда.

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

Я соглашусь с этим. Поскольку не понял зачем они все так наворачивают и в чем от такого получают преимущество... :D

какие там засады с массивом?

я знаю только одну - когда делаешь arr[i] = someValue, триггерятся подписчики на все элементы. Ну то есть использовать массив с примитивами или иммутабельными объектами - не очень.

тут как хочешь склеивать, так и склеивается. Можно закинуть сторы в контекст и доставать их оттуда

const myStore = useMyStore()

потом этот myStore юзать или передавать в дочерние компоненты.

MobX - лишь механизм, не более того.

можно пример?

ФП-шники любят такие конструкции ))