FSM 3: Структурирование масштабируемой кодовой базы

Добро пожаловать в часть 3 руководства Fresh Start Meteor, которое поможет вам создать новый проект Meteor с использованием ES6, React, Redux, FlowRouter и Sass. Чувствовать себя потерянным? Начните с Часть 1.

Создать хорошо масштабируемую и организованную структуру каталогов сложнее, чем кажется. ЦРТ дает некоторые рекомендации, но официальное Руководство по Метеорам оставляет большую часть его на индивидуальную интерпретацию. Пришло время иметь твердый стандарт, поэтому я думаю, что он имеет большой смысл (читайте дальше, чтобы узнать, как я к нему пришел):

client/
    compatibility/
imports/
    api/
        methods/
        publications/
    startup/
        client/
        routes/
        server/
    ui/
        components/
        layouts/
        pages/
        styles/
            abstracts/
            base/
            elements/
            vendors/
node_modules/
private/
public/
server/
tests/

Отлично, давайте рассмотрим, для чего предназначен каждый из этих каталогов.

Специальные каталоги Метеора

В дополнение к папке .meteor/ в Meteor есть восемь «специальных каталогов», которые отличаются друг от друга уникальным образом, как описано в различных частях официального руководства:

  • client/:файлы, которые загружаются только на клиенте и автоматически объединяются и минимизируются в производственном режиме (но не в режиме разработки).
  • client/compatibility/: сторонние библиотеки JavaScript, которые полагаются на глобальные переменные, поэтому их нельзя обернуть в область переменных (хорошо, если вы используете плагины ES5). Они выполняются перед другими JS-файлами на стороне клиента.
  • imports/: файлы, которые никогда не загружаются автоматически и должны быть импортированы вручную. Большая часть вашего приложения будет написана здесь; см. Об импорте и трех подкаталогах импорта ниже.
  • node_modules/: пакеты NPM, которые никогда не загружаются автоматически и должны быть импортированы вручную, как imports/, но для сторонних пакетов вместо вашего собственного кода.
  • private/: файлы, доступные только серверу, например личные данные и другие конфиденциальные файлы.
  • public/: файлы, предоставляемые клиенту как есть, доступные по URL-адресу верхнего уровня (начинающемуся с «/»), например favicon.ico, фоновые изображения, пакеты веб-шрифтов, robots.txt, и Т. Д.
  • server/: файлы, которые загружаются только на сервер и никогда не передаются клиенту, например конфиденциальный код, содержащий пароли.
  • tests/: файлы, которые никогда не загружаются автоматически и предназначены для использования внешними средствами запуска тестов (за пределами встроенных инструментов тестирования Meteor). Я не буду освещать этот каталог, потому что мне пока достаточно инструментов Meteor.

Об импорте и трех подкаталогах импорта

Принятие Meteor 1.3 стандарта ES2015 представило модули и импорт, которые вместе открыли дверь для лучшей организации приложений Meteor.

Чтобы в полной мере использовать модульную систему и гарантировать, что наш код запускается только тогда, когда мы его запрашиваем, мы рекомендуем размещать весь код вашего приложения в каталоге imports/. - Официальное руководство по метеорам

ЦРТ также предлагает разделить импорт на три категории: код, который запускается при запуске приложения (imports/startup/), данные и бизнес-логика (imports/api/), и визуализация пользовательского интерфейса (imports/ui/). Это помогает держать все в порядке и легко найти.

Каталог startup/ будет содержать код запуска как для клиента, так и для сервера, поэтому, чтобы избежать путаницы, я считаю целесообразным создать client/ и server/ здесь, а также каталог routes/. Объявляя свои маршруты за пределами каталогов клиента и сервера, вы предоставляете маршруты для обоих. Сейчас это может показаться не таким уж большим делом, но, начав таким образом, вы подготовите себя к внедрению рендеринга на стороне сервера (SSR) позже, если вы того пожелаете.

Каталог api/ будет иметь отдельные подкаталоги, соответствующие каждой из ваших коллекций, и будет содержать код для коллекции, публикации и соответствующие методы.

Каталог ui/ можно разбить на каталоги layouts/, pages/ и components/, чтобы лучше организовать различные слои шаблонов.

Но куда мы должны поместить наши таблицы стилей?

Хороший вопрос. Последним и наиболее сложным с организационной точки зрения аспектом этой структуры являются таблицы стилей. ЦРТ не дает никакого представления об их размещении, так что это в значительной степени зависит от наших собственных рассуждений. Я вижу три способа, которыми это можно было бы разумно сделать:

  1. Мы могли бы поместить их в каталог client/styles/.
  2. Мы могли бы поместить их в каталог imports/ui/styles/.
  3. Мы могли бы сгруппировать отдельные таблицы стилей в соответствующих каталогах макетов, страниц и компонентов, а также разместить все глобальные стили в каталоге imports/ui/styles/.

При оценке этих вариантов я учитывал несколько вещей:

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

Вариант 1 позволяет нам получить наши стили как можно более высокого уровня, но не следует основанному на импорте шаблону остальной части нашего приложения (благодаря ES6), и при редактировании данной части пользовательского интерфейса у нас будет для перехода к двум разным каталогам в дереве.

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

Вариант 3 — мой любимый — он не только соответствует нашей логике импорта, но и каждая таблица стилей для данного макета, страницы или компонента находится в каталоге с той частью пользовательского интерфейса, которую он изменяет. Это усиливает модульность таблицы стилей и упрощает поиск всего, что нам нужно для внесения изменений. Чтобы сделать это как можно более чистым, требуется немного дополнительной инфраструктуры (поэтому с этим связано немного больше первоначальных затрат), но, на мой взгляд, преимущества намного перевешивают затраты.

Структура каталогов таблиц стилей

Теперь, когда мы знаем, куда поместить наши таблицы стилей, давайте поговорим об организации таблиц стилей! Я предлагаю следовать модифицированной версии шаблона 7–1, которую я разработал, чтобы соответствовать остальной части нашей архитектуры на основе Meteor, как описано в начале этой статьи. Распределение выглядит следующим образом (в порядке загрузки):

  • abstracts/ стили — это ваши глобальные миксины, функции и другие помощники SCSS, которые на самом деле не будут компилироваться в CSS, но помогут вам написать более чистый SCSS.
  • vendors/ стили — это то место, где вы будете включать сторонние стили, примеси и т. д.
  • базовые/ стили — это ваши значения по умолчанию и глобальные параметры (например, Нормализация и правила типографики).
  • Стили elements/ предназначены для таких вещей, как кнопки, поля форм, всплывающие подсказки и т. д., которые либо встроены в спецификацию HTML, либо представляют собой небольшие компоненты, которые вы разрабатываете самостоятельно и не требуют никакой логики.
  • Стили ../components/ специально относятся к отдельным компонентам, таким как панель навигации, выпадающее меню, контактная форма и т. д., что позволяет легко повторно использовать их на любой странице, в любом макете или на любом проект
  • Стили ../pages/ предназначены для любых стилей, которые конкретно относятся к одной странице и никаким другим.
  • Стили ../layouts/ предназначены для любых общих элементов на всех страницах с каждым заданным макетом, которые нельзя разделить на отдельные страницы или компоненты.

Если вы искали шаблон 7–1, вы, вероятно, заметили небольшую разницу в номенклатуре между этим и традиционным 7–1. Не волнуйтесь! Поскольку наша существующая настройка Meteor установила значения, связанные как с макетами, так и с компонентами, я изменил каталоги SCSS, чтобы они соответствовали:

  • 7–1 «макеты» теперь называются «компонентами» (шапка, нижний колонтитул, боковая панель, панель навигации и т. д.)
  • 7–1 «компоненты» теперь либо по-прежнему являются «компонентами» (если у них есть логика, например, галереи, карусели и т. д.), либо они теперь являются «элементами» (например, кнопки, поля форм и т. д.).
  • 7–1 «темы» теперь являются «раскладками» (приложение, админка и т. д.)

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



Вы можете помочь сделать это руководство лучше, комментируя, когда что-то кажется неясным, бесполезным или просто неправильным. Пожалуйста, будьте ясны, подробны и сохраняйте позитивный настрой! Если у вас есть предложения для будущих статей или вопросы о руководстве в целом, пишите мне в Твиттере:@teaganatwaterБольшое спасибо!