Организация приложения React Redux для разработчиков и дизайнеров

Сходимся в новой структуре при создании нового приложения.

Создание новых веб-продуктов - это уникальная задача. Когда вы решаете строить, особенно с использованием новейших технологий, многое из того, что вы хотите сделать, либо не было сделано ранее, либо не использовалось передовыми методами.

Одна из новых технологий, которые мы выбрали для работы с интерфейсом Marshal, - это React. Хорошо это или плохо, у React нет мнения о том, как вы должны структурировать приложение. Есть несколько предложений сообщества, но для наших целей ни одно из них не было достаточно прагматичным. Когда приходит время организовать свой проект, вы можете задаться вопросом о том же, что и мы: как лучше всего организовать приложение React?

С чего мы начали

После долгих исследований нам больше всего понравился React с архитектурой Flux. После еще большего исследования мы нашли Redux - популярную реализацию Flux с множеством образовательных ресурсов и большим сообществом разработчиков. Итак, мы дополнили React Redux и Immutable.js. Используя эти технологии, мы изначально организовали приложение по концепциям React + Redux. На высоком уровне у нас были отдельные папки для actions, components, constants, containers и reducers.

Почему он сломался

В Marshal границы между разработчиками и дизайнерами намеренно размыты. Таким образом, наши разработчики много касаются CSS, а наши дизайнеры - JS. Наша первоначальная структура хорошо работала, когда проект был небольшим, и каждый день работал над новой функциональностью. Однако по мере приближения к запуску бета-версии рутинные задачи становились все более громоздкими. Наши разработчики обычно терялись в функциональной, но плоской структуре каталогов и без нужды переключались между файлами. Наши дизайнеры обычно изменяли компоненты, предполагая, что у них будет доступ к несуществующим переменным состояния. Реорганизовывать любую существующую часть приложения было мучительно медленно, и мы заметили, что члены команды создают импровизированные структуры в попытке сохранить свое здравомыслие.

Создание гибридной структуры

После шести месяцев работы над Marshal мы приняли гибридную структуру, сочетающую в себе аспекты как Rails, так и шаблонов доменного стиля, а также унифицированные папки компонентов / контейнеров и действий / констант.

/actions
/assets
/api
/components
/config
/reducers
index.jsx

index.jsx

Этот файл является точкой входа в наше приложение. Он инициализирует наше хранилище данных и прикрепляет приложение к DOM. Мы сохраняем это как можно более открытым текстом.

/ действия

Мы сохранили Действия в их собственной папке верхнего уровня. Действия не жестко привязаны к домену или функции; поэтому каталог по-прежнему плоский, и мы разбиваем Действия на файлы по тому, для чего они передают данные. Однако действия жестко привязаны к константам типа действия, поэтому мы решили объединить наши существующие константы в их соответствующий файл действий.

/ api

Эта папка содержит все функции, которые напрямую взаимодействуют с Marshal RESTful API. Во многих случаях действия и редукторы во многом совпадают. Marshal API - это еще одно приложение, полностью отдельное от интерфейсной части. Сохранение здесь наших функций, специфичных для API, позволяет нам более легко отслеживать, какие части внешнего интерфейса имеют соответствующие ресурсы в нашем API.

/ресурсы

Здесь живет весь конвейер активов, не связанных с JS. Мы категорически против встраивания CSS в наш JavaScript, но мы сохраним эти мнения для другого поста. У нас большой опыт работы с Rails, поэтому мы организовали его в виде иерархии папок ресурсов в стиле Rails.

/fonts
/images
/stylesheets

/компоненты

Наше первоначальное разделение компонентов и контейнеров было самым большим предметом разногласий среди команды Marshal Product. После долгих споров наша новая папка /components содержит несколько специальных папок для тех Компонентов, на которые полагаются несколько доменов.

/layouts
/modals
/shared  

В противном случае компоненты теперь вложены по доменам. Что еще более важно, поработав в течение 6 месяцев с нашими Компонентами и Контейнером в разных местах, мы отказались от этого подхода в пользу отдельных файлов, к которым добавляется Container, когда они становятся Компонентами Smart / Stateful. Контейнеры жестко привязаны к Компонентам - то есть у вас могут быть Компоненты, которым не требуются Контейнеры, но у вас никогда не будет Контейнера без соответствующего Компонента. Их объединение дает нашей команде несколько преимуществ:

  • Позволяет нам размещать их под общим доменом.
  • Позволяет легко найти все, что связано с доменом, над которым вы работаете.
  • Позволяет невероятно легко определить, какие компоненты имеют доступ к состоянию для данного домена.
  • Уменьшает беспорядок.
  • Делает счастливыми и разработчиков, и дизайнеров.
/home
  Home.jsx
/report
  /__tests__
  File.jsx
  FileListContainer.jsx
  ReportContainer.jsx
  Threat.jsx
/shared
  /buttons
    /__tests__
    Button.jsx

/ config

Эта папка содержит файлы конфигурации всего приложения для нашего хранилища данных, аналитики и маршрутизации, а также наш основной HTML-шаблон webpack.

/ редукторы

Как и Actions, наш каталог Reducers остается неизменным. Редукторы разбиваются на файлы тем, что они изменяют состояние. Между редукторами и действиями было достаточно разделения, поэтому мы решили не использовать что-то вроде паттерна Утки.

Сегодня

С тех пор, как мы приняли эту новую архитектуру, наша жизнь здесь, в Маршале, стала намного проще. Дизайнеры теперь чувствуют, что знают, когда есть связанная функциональность и где она находится. Девелоперы тоже уже видят дивиденды. Недавно они завершили крупное обновление до React Router v4, и наши краткие соглашения о компонентах / контейнерах облегчили переваривание и реализацию его декларативной структуры маршрутизации компонентов.

Мы твердо верим в прозрачность и отдачу. Поэтому, когда мы сталкиваемся с пустыми или скучными результатами Google, мы продолжим публиковать наши решения, чтобы стимулировать обсуждение и помогать другим. Мы учимся тонне и выявляем новые проблемы, требующие новаторских решений. Следуйте за нами здесь, на Medium, чтобы и дальше узнавать, чем занимается наша команда.

Пока я привлек ваше внимание, вам стоит попробовать Marshal Beta! Посетите https://marshal.io, запустите бесплатное сканирование и отправьте любые отзывы о своем опыте на [email protected]. Помогите нам сделать Marshal еще лучше и посмотрите, как мы используем React в действии.