не очень я все это понимаю, я в целом за глобальные сторы, храню в них данные, селекторы, действия, изменяющие данные. Вместо внутреннего стейта типа tooltipIsShown тоже по большей части использую глобальный. Но вот всяческие onClickOutside, onKeyDown, handleFormSubmit все равно оставляю внутри компонентов, так как они относятся ко внутренней схеме их работы. Если все вынести в глобал, он станет прегромаднейшим и работать с таким будет сложно

А зачем такое может понадобиться?

не очень я все это понимаю, я в целом за глобальные сторы, храню в них данные, селекторы, действия, изменяющие данные. Вместо внутреннего стейта типа tooltipIsShown тоже по большей части использую глобальный. Но вот всяческие onClickOutside, onKeyDown, handleFormSubmit все равно оставляю внутри компонентов, так как они относятся ко внутренней схеме их работы. Если все вынести в глобал, он станет прегромаднейшим и работать с таким будет сложно

каких файлов?

в принципе со сворачиванием кода в текстовых редакторах позволяет держать много строк кода в одном файле

Ребята помогите пожалуйста с архитектурой проекта,
пока опыта мало с большими проектамию
Пока структура такая (на фото).
В Services хранить подключение к базе?
потом импортировать в главный index.js и перекинуть пропсами к нижним компонентам?
Желательно ли использовать Redux?
И еще вопрос допустим пустил проект в production  как потом сделать изменения, заново билдить?
Спасибо за ответы!

в принципе со сворачиванием кода в текстовых редакторах позволяет держать много строк кода в одном файле

все что касается непосредственно вьюшки - остается во вьюшке. это понятно. но там нет ничего сверхестественного. например твой onClickOutside превращается в useOnClickOutside

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

можно мне не объяснять, на хуках уже немало проектов написал) Получаются длинные цепочки из этих use, причем взаимосвязанных, так как одним нужны результаты других. Это в целом неудобно, какой механизм композиции бы ни использовался

да я насчет архитектуры проекта заморачиваюсь. где хранить thunk-экшены. если их я захочу например разделить на 5 файлов. или их держат в 1 файле? и называют actions.js

да я насчет архитектуры проекта заморачиваюсь. где хранить thunk-экшены. если их я захочу например разделить на 5 файлов. или их держат в 1 файле? и называют actions.js

ну короче субъективщина да?) а про порядок вызова мне не понятен довод. ты ж не ждешь от функций что результат вызова функции можно использовать раньше вызова этой функции. так почему здесь такая претензия?

На, там все базовые принципы как делить

претензия к тому, что у хуков нет общей точки, как у классов есть this.context & this.props & доступ ко всем методам в каждом из методов. Неудобненько

да я насчет архитектуры проекта заморачиваюсь. где хранить thunk-экшены. если их я захочу например разделить на 5 файлов. или их держат в 1 файле? и называют actions.js