разделить на ui и логику, но че-то застопорился.
может у кого есть хороший пример структуры проекта? 😁
Папка имя компонента - компонент.tsx - компонент стили Бизнес логика в redux saga, запросы и вообще слой работы с АПИ в rtk query
https://feature-sliced.design/
может ты мог бы поделиться рабочим примером?)) "Архитектурная методология для фронтенд проектов" - это пока overkill для меня) меня только интересует, как разделяют обычно папку components
потенциально помойное ведро, перемудрёное имхо которое хоть и юзает яндекс но БЭМ тоже яндекс придумал, где сейчас бэм?)
аргументы? что лучше тогда?
там есть примеры и даже с кодом https://feature-sliced.design/examples Но если хочешь по простому, то pages <- компоненты на которые ссылается роутер components <- фичи твои ui <- переиспользуемая логика models store <- стейт
БЭМ перестал быть актуальным в СПА, ибо появились другие средства изоляции стилей аля модули и css in js, а не потому-что он плох
Для маленьких - перемудреное. Для больших - жизненная необходимость))
мы в компании просто делали как получается, я сидел даже на проекте где использовали атомную архитектуру (говно, имхо) самое пока лучшее это pages components и материал ui в папке theme
Значит не большой, раз вам хватало Components
Ну если мы говорим про работу над сервисами долгоживущими, то такой подход плох На счет атомная ахр то да, самому не нрав Но feature-sliced это очень крутая вещь для крупных проектов, над которым работают много команд
ну а как вы ui-ные компоненты отделяете от компонентов с морем логики?
а не тупой компонент куда?)
а зачем его вообще выделять? чтобы проще был поиск компонентов? находишь проблемное место и идешь по иерархии компонентов, вай нот
я банально где нужно в 2- ух или больше компонентах вызывать одно и тоже автматом в ui ложу, короче вся переиспользуемaя чехарда не знаю насколько правильно
Обсуждают сегодня