IN
что-то мало иероглифов в чате
Поменяй ник на иероглифы, тож админа дадут)
Size: a a a
2020 July 16
АБ
это странновато звучит, как будто компоненты все становятся "тупыми", а все, что им нужно - в глобальном стейте. Тогда и хуки не нужны)
а им и не нужно быть "умными" или "глупыми". все что им нужно делать - отрисовывать данные и реагировать на их изменения. ну иногда сообщать о маунте/анмаунте. все остальное вполне спокойно выносится на уровень стейт менеджера
ei
!ро нечитаемый ник
DT
это странновато звучит, как будто компоненты все становятся "тупыми", а все, что им нужно - в глобальном стейте. Тогда и хуки не нужны)
Понятие тупой и умный компонент уже давно устарело. Не понимаю зачем на нем зацикливаться. Хуки нужны хотя бы чтобы из стора тягать данные
АБ
!ро нечитаемый ник
хнык(
И
В целом недостатки хуков можно разбить на семантические (синтаксис, основанный на соглашениях), анти-best-practice (смешение синхронного и асинхронного кода, сайд-эффекты в колбэках, раздувание чистых функций и смешение ответственности), сложностей в композиции (т.к. нет доступа к общим props и context, приходится передавать их в каждую функцию напрямую, что приводит к запутанному клубку), деградации перфоманса (т.к. приходится либо обкладывать многие части useCallback / useMemo, либо логика будет пересоздаваться на каждый ререндер и не будет работать сравнение по ссылкам).
В классах же:
- инкапсулированная логика с методами, в которых уже есть доступ к props, context и другим методам
- чистые render-функции
- человекопонятный жизненный цикл
- простота установки переменных (ref / не ref)
- одинаковые функции типа this.handleChange без оборачивания в дополнительный useCallback (бонус — легкость удаления обработчиков вроде addEventListener)
- возможность применения декораторов в @-синтаксисе как глобально к классу, так и к методам
В классах же:
- инкапсулированная логика с методами, в которых уже есть доступ к props, context и другим методам
- чистые render-функции
- человекопонятный жизненный цикл
- простота установки переменных (ref / не ref)
- одинаковые функции типа this.handleChange без оборачивания в дополнительный useCallback (бонус — легкость удаления обработчиков вроде addEventListener)
- возможность применения декораторов в @-синтаксисе как глобально к классу, так и к методам
Ну хз, есть здравое зерно в этих словах, мне тоже хуки не во всём нравятся. Но лучше уж синхронизация через хуки, чем по жизненному циклу мазать
OT
сетевые thunk-экшоны я так понимаю правильно хранить в
src/store/actionMain.js
src/store/actionCommon.js
рядом с src/store/actionCreators.js
?ES
Друзья, посоветуйте:
ei
Oruj Tatiyev
сетевые thunk-экшоны я так понимаю правильно хранить в
src/store/actionMain.js
src/store/actionCommon.js
рядом с src/store/actionCreators.js
?src/features/users/module/actions.js
ei
src/lib/store/modules/some-global-module/actions.js
ES
Друзья посоветуйте:
Существует-ли возможность реализации замены статических файлов без пересборки проекта?
Существует-ли возможность реализации замены статических файлов без пересборки проекта?
OT
src/lib/store/modules/some-global-module/actions.js
ок а если ты хочешь разделить экшэны на модули?
DK
а им и не нужно быть "умными" или "глупыми". все что им нужно делать - отрисовывать данные и реагировать на их изменения. ну иногда сообщать о маунте/анмаунте. все остальное вполне спокойно выносится на уровень стейт менеджера
не очень я все это понимаю, я в целом за глобальные сторы, храню в них данные, селекторы, действия, изменяющие данные. Вместо внутреннего стейта типа tooltipIsShown тоже по большей части использую глобальный. Но вот всяческие onClickOutside, onKeyDown, handleFormSubmit все равно оставляю внутри компонентов, так как они относятся ко внутренней схеме их работы. Если все вынести в глобал, он станет прегромаднейшим и работать с таким будет сложно
ei
Oruj Tatiyev
ок а если ты хочешь разделить экшэны на модули?
че?
OT
на несколько файлов
ei
Oruj Tatiyev
на несколько файлов
А зачем такое может понадобиться?
ei
В рамках 1 модуля
DK
Друзья посоветуйте:
Существует-ли возможность реализации замены статических файлов без пересборки проекта?
Существует-ли возможность реализации замены статических файлов без пересборки проекта?
каких файлов?
K
Ребята помогите пожалуйста с архитектурой проекта,
пока опыта мало с большими проектамию
Пока структура такая (на фото).
В Services хранить подключение к базе?
потом импортировать в главный index.js и перекинуть пропсами к нижним компонентам?
Желательно ли использовать Redux?
И еще вопрос допустим пустил проект в production как потом сделать изменения, заново билдить?
Спасибо за ответы!
пока опыта мало с большими проектамию
Пока структура такая (на фото).
В Services хранить подключение к базе?
потом импортировать в главный index.js и перекинуть пропсами к нижним компонентам?
Желательно ли использовать Redux?
И еще вопрос допустим пустил проект в production как потом сделать изменения, заново билдить?
Спасибо за ответы!
K
