Можно вопрос из зала: нафига общий стейт?

Тогда само собой последует то, что общий стейт не нужен

Тогда само собой последует то, что общий стейт не нужен

Ну, я о том же.

Можно вопрос из зала: нафига общий стейт?

если не нужен, то мой пост не для тебя

Эм...

Сурово.

тогда рушится возможность трансфера изменений между одноуровневыми стейтами { a, b }

Не рушится, почему. Стейт лежит на уровень выше сервисов/компонентов которые его используют

"Ты не веришь в мою религию, поэтому пшёл нахер."

Тогда само собой последует то, что общий стейт не нужен

типа подход общих экшенов рушит модульность стейта

а если ты не знаешь что за изменение произошло, то не знаешь как на него реагировать

типа подход общих экшенов рушит модульность стейта

А они тоже принадлежат иерархии и расположены локально

т.е. получается стейт a и стейт b должны знать минимум стейт в котором находятся

?

или иметь прямой доступ друг к другу

Даже интересно к чему это придёт)

всё я решил проблему, нужен прямой доступ между part state'ами

@ZeroBias А какая проблема решается изначально?

Вербозность и трудоемкость описания событий в приложении и обновления данных

Подскажите, почему в user и, соответственно, в payload ничего не записывается? try { const cards = yield call(fetchCardsApi) console.log("CARDS1", cards) yield put({ type: actionTypes.LOAD_CARDS_SUCCESS, payload: cards }) console.log("CARDS2", cards) }catch(e) { yield put({ type: actionTypes.LOAD_CARDS_FAILURE, payload: e.message }) } Где fetchCardsApi возвращает после GET запроса массив объектов

Вербозность и трудоемкость описания событий в приложении и обновления данных

Разбиение на небольшие маленькие части разве не решает эту проблему?)

а так, но проблема в другом, допустим структуру { a: { b: { c:{} } } } a,b,c - стейты я говорил про то, что a должен знать про b, чтобы иметь возможность изменять в неём значения

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

Разбиение на небольшие маленькие части разве не решает эту проблему?)

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

если собирать стейт снизу вверх, получается что a не знает про b и c изначально, т.е. не может с ними манипулировать

Всё началось с того, что я захотел объявлять эпики рядом с кодом за который они отвечают

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

Он глобавлен только в модели биндингов react-redux

И понеслось))

Он глобавлен только в модели биндингов react-redux

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

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

Поясни в чём проблема с локальностью.

Я не вижу проблемы. Дёргаешь "диспач" нужного стора. Вот тебе и локальность.

Если говорить в общем, то все операции с массивами в редаксе заменяются на операции с деревьями и это челлендж реально

Я тоже думал ща запилю по быстрому

Так, возможно, я не понимаю слово локальность. Можешь пояснить?

Ты представляешь себе концепцию features? Про нее чаще всего сова говорит

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

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

Да, это понятно.

Соответственно, стор (условно, редакс стор) тоже будет объявлен прямо внутри feature, и все эвенты для него тоже

Верно.

видимо, подмоги не будет, ладно))

Получается единый для каждой фичи, но не глобальный стор

Да.

ну вот, это типа и есть локальность

И в чём проблема?)

подскажите плз, есть ли какой-то норм автокомплит для реакта ? эммет не работает в jsx...

Если говорить в общем, то все операции с массивами в редаксе заменяются на операции с деревьями и это челлендж реально

Я именно так понимаю локальность.

напрягает каждый раз теги закрывать

подскажите плз, есть ли какой-то норм автокомплит для реакта ? эммет не работает в jsx...

@ide_ru

Если говорить в общем, то все операции с массивами в редаксе заменяются на операции с деревьями и это челлендж реально

А в чём связь?

Я просто связи между этими утверждениями не улавливаю.

Локальность подразумевает вложенность

Вложенность подразумевает деревья Деревья подразумевают что всё будет оч весело))

Локальность подразумевает вложенность

Ты всё хранишь в едином сторе?

Серьёзно?

Нет

Тогда не понимаю)

Наоборот

Серьёзно?

это плохо ?

Да

это плохо ?

Всё в одной куче - плохо.

Локальность подразумевает вложенность

Поясни это.

я вчера в доке редакса читал, что он против нескольких сторов

Подразумевает вложенность чего?

Мы тоже все читали

Представь себе (не знаю как к этому отнесется сова правда), что у тебя одни фичи составляются из других, более мелких

я вчера в доке редакса читал, что он против нескольких сторов

В интернете много чего пишут)

Представь себе (не знаю как к этому отнесется сова правда), что у тебя одни фичи составляются из других, более мелких

Звучит норм.

ERROR: S client not available

В интернете много чего пишут)

так это ж оф документация

Воот, но ведь фичи у нас имеют свой стор

в таких обычно гайды прописывают :)

Воот, но ведь фичи у нас имеют свой стор

И?

И?

получается та же самя вложенность

Ты считаешь, что их сторы должны в одном месте храниться?

А зачем?

Не теряй нить

Каждый стор хранится у себя на уровне

Не вместе

Ок.

И это значит что более крупный стор составляется из более мелких

Нет, не значит.

Нет, не значит.

для ssr значит

для ssr значит

Поясни.

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

Поясни.

чтобы восстановить состояние с сервера на клиенте, в случае нескольких сторов, ты должен установить связь между моментом создания стора и местом его в хранилище(объекте состояний)

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

Ну, они полностью изолированы.

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

+

чтобы восстановить состояние с сервера на клиенте, в случае нескольких сторов, ты должен установить связь между моментом создания стора и местом его в хранилище(объекте состояний)

Ок, пусть это будет не объект, а список.

Ну, они полностью изолированы.

В реальности так получается не всегда

Ок, пусть это будет не объект, а список.

Не будет, это будет дерево и тому кто пишет библиотеку придётся с этим иметь дело

В реальности так получается не всегда

Не спорю. Часто придётся один и тот же компонент коннектить к множдеству сторов.

Вот, да

Ок, пусть это будет не объект, а список.

список, т.е. получается тебе нужно знать id стора чтобы восстановить ему значение, т.е. его нужно указать

список, т.е. получается тебе нужно знать id стора чтобы восстановить ему значение, т.е. его нужно указать

Ну, пусть генерится, не проблема.

а это практически реализация вложенности ты именуешь стор

Представь себе (не знаю как к этому отнесется сова правда), что у тебя одни фичи составляются из других, более мелких

у меня именно так и есть

Сова, слушай, а ты темы доклада заспойлерить можешь?

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

МЫ ВСЁ ДЕЛАЛИ НЕ ТАК

А туда, грубо говоря, кроме разбиения компонентов на сущности что-то будет?)