Опубликовано автор в категориях Верстальщику.

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

Компонентный подход

Очень сложно придерживаться модульности и компонентного подхода во фронтенде. Многое часто зависит от конкретного проекта. Важно как вы рендерите фронт, что используете. Однако, если у вас есть возможность придерживаться компонентного подхода в разработке фронтенда — вы должны это делать. Не обязательно придерживаться хрестоматийного определения компонентов, но вы должны, как минимум держать все вместе.

Кстати, вы можете использовать различное наименование для ваших компонентов, не меняя их сути: блоки, модули, компоненты… Но есть основные правила, которые работают для всех:

Принципы

  1. Каждый компонент имеет свое место в сорс-три вашего проекта — все что нужно для того, чтобы компонент выполнял свою функцию, должно содержать в едином каталоге файловой  структуры вашего проекта.
  2. Каждый компонент должен придерживаться принципов DRY (не повторяй сам себя) — то есть, функционал каждого конкретного компонента не должен повторять функционал какого-либо уже существующего
  3. Каждый компонент придерживается SRP (принцип единой ответственности) — каждый компонент должен нести только одну ответственность и она должна быть инкапсулирована в нем.

Придерживаться данных принципов не всегда просто. Но есть вещи которые могут действительно помочь в написании правильного кода для фронтенда:

  • Наличие определенной методологи в проекте
  • Соблюдение стандартов написания чистого кода

Методологии CSS

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

Что можно использовать? Есть неплохая обзорная статья на хабре, а вот доклад на эту тему.

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

При этом, не обязательно «слепо» следовать определенной методологии. Как вариант, вы может просто использовать часть БЭМ, а именно соглашение о наименовании классов CSS. Но, можно идти и дальше. Самое сложное добиться использования методологии в проекте над которым работает команда разработчиков.

Соблюдение стандартов написания чистого кода

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

  • Описание методологии в документации проекта — это даже может быть стартовая страница вашего стайлгайда
  • Линтинг CSS и JS — что использовать для этого я уже говорил во второй части, в разделе про инструментарий. Помимо линтинга при написании кода, можно также использовать линтинг при деплое, или при мердже пул-риквестов
  • Код-ревью — самое то, если хотите писать качественный код и помочь вашей команде постоянно совершенствовать в этом

Организация компонентов: «слоеный пирог».

Любой компонент должен придерживаться принципа разделения ответственности. И для того, чтобы реализовать это в проекте, зачастую, нам недостаточно одноуровневой (плоской) архитектуры. Поэтому нам нужны «слои» разделения ответственности:

  1. Базовый слой (base/root) — слой на котором сосредоточена ответственность за основные настройки и функции нашего проекта
  2. Блоки — основная структурная единица проекта
  3. Компоненты — слой для организации блоков
  4. Разметка — отдельный слой, по сути сетка, выполняет функцию только распределения компонентов в интерфейсе.
  5. Шаблоны — это вспомогательный слой, основная задача которого предоставить типовые примеры распределения компонентов в разметке
  6. Страницы — еще один вспомогательный слой для того, чтобы сделать шаблоны красивыми

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

Что поможет в организации компонентов?

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

Модульность

Модульность, пожалуй, ключевой фактор для правильной организации компонентов. Уже сегодня модули доступны нам как для JavaScript, так и в некоторой мере для CSS.

ES6 modules

ES6 modules — все просто и понятно. Инкапсулируем код компонента в отдельном файле в виде модуля. Экспортируем функционал по умолчанию и импортируем там, где нам нужно. К сожалению, пока использовать их нативно нельзя, но есть Webpack, SystemJS и прочее (об этом було в разделе про инструменты), что позволит вам писать модульно уже сейчас.

CSS modules

CSS modules — немного сложнее, так как не существует единого механизма реализации данного функционала. Но есть варианты. Здесь я вам рекомендовал бы отличный доклад по модульному CSS. Но вот несколько вариантов реалитзации:

Подведем итоги

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

Оставить комментарий

  • (не будет показан)