могу побольше

Я считаю, что не нужно из крайности в крайность. Если есть например компонент в виде datepicker, то не нужно все пропсы этого компонента вытаскивать в глобальный стейт. А если этих дейтпикеров больше чем один, то это превращается в попа-боль. Короче, делайте как хотите, вам потом с этим кодом жить

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

Я считаю, что не нужно из крайности в крайность. Если есть например компонент в виде datepicker, то не нужно все пропсы этого компонента вытаскивать в глобальный стейт. А если этих дейтпикеров больше чем один, то это превращается в попа-боль. Короче, делайте как хотите, вам потом с этим кодом жить

нужна вся логика в одном месте

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

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

а потом HOC в котором 100500 ифов

нужна вся логика в одном месте

даже show/hide дейтпикера? Бредятина

нахер надо

а потом HOC в котором 100500 ифов

почему?

бизнес логика отдельно от логики компонентов

Каждый HOC отвечает за свое дело. Только загрузка данных с сервера, например.

Если логика сложнее, то и не нужно ее сувать в этот HOC

бизнес логика отдельно от логики компонентов

т.е. если у тебе есть БИЗНЕС логика спрятать компонент

то это нужно в компоненте ?

а как же re-usage

т.е. если у тебе есть БИЗНЕС логика спрятать компонент

кейс в студию

sek

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

без какой либо конкретики

есть 2 селекта

1 зависит от другого

т.е. список 2 селекта зависит от выбора в первом

где держать логику ?

возьми компонент посложнее простого селекта/инпута

мы же не про сложность

я про кейс

где держать логику ?

в родительском компоненте? Эти селекты не в воздухе же летают

вооот

это классический подход

где у тебя эсть БИЗНЕС логика в компоненте

так сказать в "умном"

или ViewModel

а вот после перехода на mobx у меня ВСЯ бизнес логика только в сторе

печально.

наоборот

бизнес логика отдельно от логики компонентов

твои же слова

почему бизнес логика у тебя в компоненте

я те про одно, ты мне про другое

наоборот

ну вот, а теперь представь что у тебя 1000 таких вот компонентов, где есть два селекта? И что тогда делать?

сорри. не оч понял проблему

почему бизнес логика у тебя в компоненте

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

https://github.com/quri/react-bootstrap-datetimepicker - вот например

ок

привести пример с пикером ?

ты предлагаешь всё говно из компонента выносить наружу?

сорри. не оч понял проблему

ну у тебя же вся логика хранится в одном месте. В сторе. Получается если у тебя есть 1000 одинаковых компонентов, данные для которых хранятся в строе

выбор даты ?

Если реально тебе нужен будет только onChange и value

в бизнес логике

то у тебя в сторе будет 1000 одинаковых структур?

стоп. мы друг друга не поняли )

Мне тоже так кажется

лол

если ты пишеш либу - мобкс не нужен

напили компонент и дай норм апи как onChange и value

я про бизнес логику выбора даты

например запрещать выбор даты

например запрещать выбор даты

еще один пропс для дэйтпикера и все

зачем это в сторе хранить?

а если зависит от данных ?

Я так понял, Kich говорит о том, что не надо все из компонента доставать. В сторе хранятся только те данные, которые нужны в разных местах

да

всё верно

Хранить открыт или нет дэйтпикер в сторе

это извращение

о нет

конечно нет!

ERROR: S client not available

я про например форму с 25-30 инпутов

Просто изначально было утвержение что setState не нужен :)

я про например форму с 25-30 инпутов

Так смотри, у тебя есть компоненты - чаще всего это самый простой ui. Форма из 25-30 инпутов

Это уже не компонент, это уже контейнер

вооот

это класический подход который я использовал

я делал конейнер

И он тебе не подошел?

в нем держал стейт

и прокидывал пропсы

все было ок

все было ок

ноооо?

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

это норм

когда приложение мелкое

про сет стейт https://medium.com/@mweststrate/3-reasons-why-i-stopped-using-react-setstate-ab73fc67a42e#.zd33q1lkv

от автора mobx

так вот

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

а когда только стейт (именно стейт)

и тогда начинаеться

чтобы чтото поменять нужно 3 места

экшн стор и котейнер

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

Но кроме бизнеслогики

У компонента может быть и своя, свое поведение

Вот его и нужно хранить в стейте, даже у контейнера может быть такая ситуация

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

вот для поведения - стейт норм

но это оч трудно контролировать

потомучто isSomeTrickyComputation ? <renderOne> : <renderAnother>

это бизнес логика

я не про