Архитектура в React: правильная структура приложения [Frontend]
React – одна из самых популярных библиотек для создания пользовательских интерфейсов, и правильная архитектура приложения играет важную роль в его успехе. В этой статье мы рассмотрим, как создать правильную структуру приложения на фронтенде с использованием React.
Компонентный подход
React основан на компонентном подходе, что означает, что пользовательский интерфейс разбивается на отдельные компоненты, которые являются независимыми и могут быть многократно использованы. Это позволяет создавать более современные и масштабируемые приложения.
Структура каталогов
Для создания правильной структуры приложения в React, рекомендуется разбить компоненты, стили, изображения и другие ресурсы на отдельные каталоги. Например:
/ -- src/ ---- components/ ------ Header.js ------ Footer.js ---- styles/ ------ main.css ---- images/ ------ logo.png
Рутовый компонент
Один из ключевых компонентов в React – это рутовый компонент, который является точкой входа в приложение. Он обычно содержит маршруты и другие статические элементы, которые не относятся к конкретным страницам или разделам приложения.
Структура компонента
Каждый компонент в React должен быть разбит на отдельные файлы – .js для логики и .css для стилей. Это помогает сохранить код чистым и упорядоченным.
Использование контейнеров и компонентов
Для улучшения переиспользуемости и управления состоянием данных рекомендуется использовать контейнерные компоненты для управления состоянием и отображения данных, а презентационные компоненты для отображения интерфейса.
💥Полезный контент про разработку + памятка FSD – https://t.me/xlok1e/21
UPD: Слой Processes устарел и больше не используется
пук-пук среньк fsd 🥱
Было бы классно если ты бы рассказал какие есть недостатки в atomic design
8:55 – "для тех кто только напичает….. может показаться сложным и непонятным" – я тебе больше скажу, я в разработке много лет и если бы я не знал эти архитектуры я бы ничего не понял из видео, особенно слово "срезы" что это вообще такое )))))
Без обид. Но, в видео вы просто пересказали(содрали) то, что написано на первых страницах документации FSD. Смысла данного видео не понимаю.
Horosho razlojil po polochkam, spasibo.
Processes помечены как deprecated
Хорошее видео. Молодец!
Привет, не мог бы ты рассказать о себе в какой ты компании работаешь?
Когда то и я абсолютно идентично относился к отношениям и семье. Это и есть главная ошибка, так как есть отношения, есть семья. Два абсолютно разных измерений. Имея семью: супругу и детей. Нужно и судить исходя из этого факта. Потому что ты уже не холостой парень, ты лично отвечаешь за детей. Это твое решение и решение супруги взять такую огромную ответственность на себя. Соответсвенно, вы должны детям обеспечить: детство, здоровое самолюбие и адекватную самооценку. Разрушая брак, рушиться их психика.
Это все априори подразумевает что вы оба с супругой будете делать все для обратного. Это не просто.
Думаете о браке? Значит прими следующее: все проблемы можно решить. Рушить брак, это не обсуждаться. Это фундамент, на котором нужно строить.
Не готовы? Не делайте детей.
Смотря на некоторых родителей, возникает вопрос – почему нету до сих пор что-то вроде обязательных «курсов для будущих родителей» много чего станет лучше, что касается воспитания.
Я конечно не думаю, что Эдвард прочтет это, но поскольку считаю эту инфу очень важной, может кому-то поможет.
Не фронт разработчик, но фронтовые задачи иногда делаю, понравилась вариация фиче ориентированной концепции, когда компоненты лежат в рамках фич, и выносятся на уровень иерархии так чтобы использоваться только в дочерних папках, но не в родительских, общие базовые же компоненты типо кнопок, тогглов, тупых иконок и тд используемых в нескольких фичах можно вынести в отдельный проект или папку. Потому что для большого приложения условные папка components заспамилась настолько сильно, что проще что-то найти через поиск по возможному имени файла, чем скроллить компоненты.
Мы испрльзуем принцип fsd, но подогнали под себя. Добавили слой routers между app и остальными. И сократили другие слои. Так между app и shared мы оставили entities и features(объединяем несколько сущностей), иногда pages для объединения фичей. И после добавили routers. Очень удобно вышло 👍🏻
Больше спасибо за объяснение!!! Все предельно понятно❤
Спасибо! У тебя хорошая подача материала. Полезно и для PM'ов.
Отличный контент и подход к подаче материала, приятно слышать и видеть) Очень просто о сложном, так держать)
С папкой App не совсем понял. Зачем там размещать fonts и styles если ты сказал, что общие компоненты должны быть размещены в shared?
Предлагаю такой подход:
1) applications. Тут все понятно, если у вас есть допустим форум и магазин, глупо их делать в одной app, хотя и в разных проектах тоже не всегда хорошо, ведь могут существовать множественные связи.
2)Название может быть разным, допустим Features. Отвечает за конкретный функционал: товары, заказы, корзина.
3.1)модели: понятно
3.2)data-access: сервисы, которые загружают наши модели из сервера
3.3)pages: понятно, конкретнве страниця,
3.4)components(widgets): тоже понятно.
3.5)ui (только представления, без подгрузки с сервера)
3.6) разные другие сервиса (гуарды, интерсепторы…), Могут быть перенесены на слои повыше.
В общем, между этим и показанной структурой очень много схожего
NX, вот где истина
Очень хорошо всё пояснил! Благодарю!
"Каждый пост тоже будет являться виджетом" (5:51) – вот тут по моему есть небольшая ошибка.
Виджетом тут будет являться весь PostList, который эти посты рендерит.
А каждый пост это entity, который пропсом принемает какие либо actions (в нашем случае это лайк и коммент поста, которые пробрасываются ему в момент рендера в PostList). Сам PostCard (entity) абсолютно не знает, что за actions он будет принимать, но эти actions он внутри себя просто отрисовывает, если они есть.
То, что кнопка лайка была названа виджетом (6:05), попахивает нарушением правил FSD, потому что в этом случае пост ( ранее тоже названый виджетом ) использует внутри себя другой виджет ( вот эту кнопку лайка ), а разрешено использовать только нижележащие слои. Лично я бы положил эту кнопку лайка в "ui" сегмент фичи, которая также отрисовывает и количество лайков конкретного поста ( во время рендера можно ведь прокинуть id конкретного поста, а дальше уже дело фичи отрисовать количество ).
На счет того, что "фото" было помещено в entities тоже у меня возникают какие-то сомнения – фото это просто фото же, а entities – я частенько даю им такое определение – это как бы визуальная репрезентация того, что хранится в базе данных. Ну например PostCard это же entity, который показывает в виде карточки ту информацию, что хранится в бд.
Кстати, разве слой processes не вычеркнули?
(9:39) Лично я предпочел бы хранить "api" сегмент или запрос к серверу в том же модуле (slice), в котором он используется (например features/like-post/api/ ), просто чтоб все было рядом и не шататься между разными слоями, но это уже не правило FSD.
По остальному примечаний у меня вроде нет, а кто хочет еще подробнее про FSD – рекомендую у UlbiTV посмотреть ролик про архитектуры фронта. Потом можно на официальном сайте посмотреть документацию и примеры работ, а дальше… только практика, всем удачи🤞