И
Что именно? Подход или то, что (как он говорит слышал) так делать не рекомендуется?
Лично я не вижу никакого удобства в этом
Лично я не вижу никакого удобства в этом
Подход
Size: a a a
2020 July 18
И
Приветствую! Интересует такой вопрос: используется ли на практике такой подход организация редаксовкого state - когда для каждой более менее крупной компоненты, зависящей от входящих данный, создается свой reducer. Мне такой подход кажется удобным, но слышал, что так делать не рекомендуется. Хотелось бы услышать ваше мнение
Не слышал, чтобы рекомендовали так НЕ делать, потому что не слышал, чтобы кто-то так делал)
b7
Приветствую! Интересует такой вопрос: используется ли на практике такой подход организация редаксовкого state - когда для каждой более менее крупной компоненты, зависящей от входящих данный, создается свой reducer. Мне такой подход кажется удобным, но слышал, что так делать не рекомендуется. Хотелось бы услышать ваше мнение
combine reducer же.
Л
Глупости какие-то
почему?
Л
а то я не понял, ясное дело что для всей приложухи не только 1 редюсер же
b7
Приветствую! Интересует такой вопрос: используется ли на практике такой подход организация редаксовкого state - когда для каждой более менее крупной компоненты, зависящей от входящих данный, создается свой reducer. Мне такой подход кажется удобным, но слышал, что так делать не рекомендуется. Хотелось бы услышать ваше мнение
Логично конечно разнести редьюсеры по разным файлам, по логике. Но думаю вовсе не стоит ориентироваться на строгое правило - по редьюсеру на компонент. По логике нужно разделять. И в combinereducers потом.
b7
Если стэйт используется только внутри конкретного компонента и его дочек, тот тут и редакс не нужен. Внутри компонента useState, на дочерние - контекст.
Л
Если стэйт используется только внутри конкретного компонента и его дочек, тот тут и редакс не нужен. Внутри компонента useState, на дочерние - контекст.
+
1
Если стэйт используется только внутри конкретного компонента и его дочек, тот тут и редакс не нужен. Внутри компонента useState, на дочерние - контекст.
А если из доч нужно передать в род
Л
А если из доч нужно передать в род
эээ, это как такое бывает
b7
А если из доч нужно передать в род
Контекст родительского
Л
это бывает если нужно вызвать пропс функцию и там передать некоторые данные, но прям делать локальный стейт еще один и передавать наверх не
b7
А если из доч нужно передать в род
В дочернем меняй контекст родителя. Если дочка что-то хочет отдать родителю, значит это стэйт не дочки, а Стейт родителя, раз оно надо родителю
b7
Переиспользуемый компонент не должен ничего отдавать родителю по своей сути, если только это не дочь одного родителя, то есть спроектирован как часть конкретного одного родителя. В таком случае опять же - стэй родителя меняем в дочке. В противном случае - признак неправильной архитектуры.
Если же такие архитектурные изъяны прикрывать редаксом, это становится вредно привычкой и плодит неконтролируемые потоки мутаций стейта. Что чревато прям.
Если же такие архитектурные изъяны прикрывать редаксом, это становится вредно привычкой и плодит неконтролируемые потоки мутаций стейта. Что чревато прям.
b7
Редакс то он вообще чем плох - чем плотней твои компоненты сидят на редаксе, тем меньше шансов переиспользовать их. Ключ к повторному использованию - локальные стейты и контексты. Максимальная автономность.
BB
onSuccessSubmit формы, onClick (и все другие нативные ребята) передают привет
Л
onSuccessSubmit формы, onClick (и все другие нативные ребята) передают привет
?
АБ
onSuccessSubmit формы, onClick (и все другие нативные ребята) передают привет
+
BB
А при чем тут мутабельность я вообще без понятия
АБ
А при чем тут мутабельность я вообще без понятия
+ я немного выпивши, поэтому буду просто плюсовать умные мысли:D