Композитная структура фронтенд проекта
Многие мои знакомые в курсе, что я недолюбливаю FSD. В целом, мне не импонируют любые достаточно плоские методологии структурирования проектов - как раз из-за своей плоскости. “Плоским” я называю структуру, в которой у нас существуют директории, предполагающие наличие большого количества содержимого. Например, папочка components, в которой может быть 100 и более компонентов. В таком количестве очень сложно найти то, что тебе нужно. Сегодня поделюсь рецептом структуры, которой пользуюсь я сама. Дисклеймер: возможно, он уже был где-то и кем-то описан - но я про это не в курсе 😊 Я называю такую структуру композитной, потому что она напоминает мне паттерн “компоновщик” (Composite). Итак:
1️⃣ На верхнем уровне я располагаю основные директории - app (главный файл, конфиги приложения), pages (страницы), components (компоненты), helpers (хелперы), store (стор). Важно: в components мы кладем не любые компоненты, а только глобальные - то есть такие, которые используются повсюду в нашем приложении. Аналогично используем хелперы и стор - только для глобальных сущностей.
2️⃣ В pages создаем страницы.
3️⃣ В страницах повторяем верхнюю структуру:
4️⃣ Внутри компонентов структура может снова повторяться: например, компонент
5️⃣ Для каждой страницы действуем по аналогичному принципу.
Таким образом, общий принцип: кладем сущность туда, где она непосредственно используется. Если сущность используется в нескольких местах, кладем на общий уровень для мест использования. На примере компонентов:
🔵 Компонент
🔵 Компонент
🔵 Компонент
#архитектура
Многие мои знакомые в курсе, что я недолюбливаю FSD. В целом, мне не импонируют любые достаточно плоские методологии структурирования проектов - как раз из-за своей плоскости. “Плоским” я называю структуру, в которой у нас существуют директории, предполагающие наличие большого количества содержимого. Например, папочка components, в которой может быть 100 и более компонентов. В таком количестве очень сложно найти то, что тебе нужно. Сегодня поделюсь рецептом структуры, которой пользуюсь я сама. Дисклеймер: возможно, он уже был где-то и кем-то описан - но я про это не в курсе 😊 Я называю такую структуру композитной, потому что она напоминает мне паттерн “компоновщик” (Composite). Итак:
1️⃣ На верхнем уровне я располагаю основные директории - app (главный файл, конфиги приложения), pages (страницы), components (компоненты), helpers (хелперы), store (стор). Важно: в components мы кладем не любые компоненты, а только глобальные - то есть такие, которые используются повсюду в нашем приложении. Аналогично используем хелперы и стор - только для глобальных сущностей.
2️⃣ В pages создаем страницы.
3️⃣ В страницах повторяем верхнюю структуру:
components, helpers, store. Сразу уточню, что папочки добавляем по мере создания файликов - пустые папки нам не нужны :) Но на этом уровне кладем сюда только те компоненты/хелперы/стор, которые используются на этой странице. То есть в pages/Home/components может лежать, например, компонент Hero - если он используется на главной странице и больше нигде.4️⃣ Внутри компонентов структура может снова повторяться: например, компонент
Hero может содержать дочерние компоненты, а также может содержать хелперы.5️⃣ Для каждой страницы действуем по аналогичному принципу.
Таким образом, общий принцип: кладем сущность туда, где она непосредственно используется. Если сущность используется в нескольких местах, кладем на общий уровень для мест использования. На примере компонентов:
🔵 Компонент
Card используется только на странице Catalog - кладем компонент в src/pages/Catalog/components/Card🔵 Компонент
CardHeader используется только внутри компонента Card - кладем компонент в src/pages/Catalog/components/Card/components/CardHeader🔵 Компонент
Button используется везде - кладем в src/components.#архитектура
1🔥15👍7❤4