Это краткое справочное руководство по правилам, которые я использую для организации компонентов при создании приложения React. Я обнаружил, что наличие четко определенной системы помогает не только с организацией, но также помогает лучше определить, как компоненты сочетаются друг с другом, и максимизировать возможность повторного использования в кодовой базе.

Обязательно ознакомьтесь с расширенной версией этой статьи, если вас интересуют примеры кода, образцы репозитория и дополнительная информация об атомарном дизайне.

СОДЕРЖАНИЕ

• Структура приложения
• Правила атомов
• Правила молекул
• Правила организмов
• Правила шаблонов
• Правила страниц
• Правила маршрутов

Когда я изначально создаю приложение React, я помещаю весь код в /srcпапку. В /src/componentsпапке находятся все компоненты React, разделенные на пять категорий атомарного дизайна: атомы, молекулы, организмы, шаблоны и страницы. Для удобства они уже расположены в алфавитном порядке от самого маленького концептуального элемента до самого большого!

/routesПапка (которая может быть названа иначе, как в Next.js , где было бы также назвать pages) я бы рекомендовал держать отдельно от /components/pagesтого , чтобы отделить код страницы пользовательского интерфейса от кода приложения маршрутизации.

/..
--/node_modules
--/public
--/src
--|-/components
--|-|-/atoms
--|-|-/molecules
--|-|-/organisms
--|-|-/templates
--|-|-/pages
--|-/routes
--|-/styles
--|-/utility
--|-/etc...

Правила атомов

Атом является самым основным компонентом, так как общее , как может быть. Подумайте о кнопках, вводе или отформатированном тексте заголовка:

• Он не должен составлять другие компоненты / использовать только собственные элементы или компоненты, специфичные для платформы, аналогичные встроенным элементам
• Может иметь собственную разметку и стили
• Может поддерживать собственное внутреннее состояние
• Не должны быть тесно связаны с конкретными областями пользовательского интерфейса или логики.
• Не должен напрямую обращаться к состоянию приложения (или более высокого уровня)
• Не должно иметь никаких побочных эффектов, не связанных с пользовательским интерфейсом / макетом
• Не следует реализовывать бизнес-логику для конкретного приложения.

В молекулах атомы сочиняет , чтобы создать более сложный компонент, со своей разметкой и стайлинга добавить в смесь. Очень похоже на атомы, но представляйте что-то вроде многоразового фрагмента формы с вводом, меткой и сообщением об ошибке или карточкой продукта с заголовком, подзаголовком и изображением:

• Он состоит из одного или нескольких атомов.
• Может иметь собственную разметку и стили
• Может поддерживать собственное внутреннее состояние
• Не должны быть тесно связаны с конкретными областями пользовательского интерфейса или логики.
• Не должен напрямую обращаться к состоянию приложения (или более высокого уровня)
• Не должно иметь никаких побочных эффектов, не связанных с пользовательским интерфейсом / макетом
• Не следует реализовывать бизнес-логику для конкретного приложения.

Организм , где бизнес - логика приложения начинает выходить. Они могут соответствовать определенной функции или разделу приложения. Они также могут быть общеприменимыми, но тесно связаны с логикой приложения. Выборка данных и чтение / запись в состояние приложения должны в первую очередь происходить здесь (или, альтернативно, на уровне страницы). Это может быть вся форма, часть карточки покупок или профиль пользователя:

• Он более сложный, состоит из нескольких атомов и / или молекул и / или других организмов.
• Может иметь собственную разметку и стили
• Может получать данные для конкретного приложения
• Может реализовать бизнес-логику для конкретного приложения
• Может быть подключен к состоянию приложения (или более высокого уровня)
• Может быть тесно связан с определенной областью (пользовательским интерфейсом и / или логикой) приложения.
• Могут быть организованы в подпапки по логической категоризации (функция, страница и т. Д.)

Шаблон является способом для того, чтобы страницы вашего приложения совместимы. Они занимаются созданием макета и позволяют легко узнать, в какие области контента или функциональности нужно перейти. Есть несколько способов создания шаблонов. Я предпочитаю иметь один компонент, который принимает другие компоненты в качестве реквизита и вставляет эти дочерние элементы в разметку для конкретного макета:

• Это облегчает расположение нескольких организмов
• Может иметь собственную разметку и стили.
• Могут принимать и передавать реквизиты по мере необходимости.
• Не должен получать доступ к состоянию приложения (или более высокого уровня)
• Не должно иметь никаких побочных эффектов, не связанных с пользовательским интерфейсом / макетом
• Не следует реализовывать бизнес-логику для конкретного приложения.

Эти страницы являются последней частью головоломки Atomic Design, и каждый из них будет осуществлять определенный шаблон. Я предпочитаю очень простые компоненты страницы, но они могут быть более сложными, если вы предпочитаете простые маршруты ( см. Следующий раздел ). По сути, страница просто реализует шаблон, назначая правильных дочерних элементов правильным свойствам шаблона:

• Он реализует конкретный шаблон
• Может получать данные для конкретного приложения
• Может реализовать бизнес-логику для конкретного приложения
• Может быть подключен к состоянию приложения (или более высокого уровня)
• Не должно иметь собственной разметки и стилей

Наконец, маршруты , хотя и не являются частью атомарного дизайна сами по себе, по-прежнему важны для размышлений в React. Помимо обработки маршрутизации для вашего веб-сайта, маршруты могут брать на себя любые обязанности, которые страницы могут не выполнять. Один или другой компонент Page или Route должен быть относительно простым, а другой должен обрабатывать любую сложность, включая выборку данных, бизнес-логику, состояние приложения и т. Д.

• Он должен обрабатывать вещи, которые не обрабатываются страницами
• Может получать данные, относящиеся к конкретному приложению (если это не сделано в Pages)
• Может реализовать бизнес-логику для конкретного приложения (если это не сделано в Pages)
• Может быть связано с состоянием приложения (или более высокого уровня) (если это не сделано на страницах)
• Не должно иметь никаких компонентов, специфичных для пользовательского интерфейса.
• Не должно иметь собственной разметки и стилей

Опять же, если вы хотите более подробно изучить, как это работает на практике, прочтите следующее !

Подпишитесь на меня в Twitter @BenjaminWFox, чтобы узнать больше о технологиях, лидерстве и другом контенте, и обращайтесь с любыми мыслями или вопросами!

Первоначально опубликовано на https://benjaminwfox.com .