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

Проблема

Фронтенд-разработка современных (веб- и нативных) приложений  —  сложная задача. Стремясь упростить ее, разработчики разбивают ее на более мелкие части, обычно называемые компонентами. Но большие приложения, помимо “компонентов”, могут содержат страницы, макеты, хуки, редьюсеры, экшены, атомы, молекулы, организмы и утилиты. Такого рода разделение полезно, но в нем все еще много шаблонного кода и рутинных задач.

Хотите создать небольшой компонент? Вам придется подготовить около 3–4 файлов: файл компонента, CSS-файл, индексный файл и (в некоторых случаях) тестовый файл. А теперь представьте, что вы делаете это вручную около 10 раз для проекта с 10 компонентами (что даже можно считать небольшим проектом). Еще больше трудностей возникает при добавлении дополнительных библиотек, таких как Redux. Нужно новое состояние? Создавайте новый файл (редьюсер) или даже два (плюс экшен)! Для тех, кто только начинает заниматься фронтенд-разработкой, эта проблема может показаться тривиальной. Но тот, кто создал несколько приложений, понимает, насколько повторяющейся, скучной и трудоемкой может быть подготовка всех этих файлов с одинаковым шаблонным кодом.

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

Решение

Lego-build  —  это CLI-инструмент, который помогает выполнять все скучные задачи фронтенд-разработки с помощью одной строки. Вместо того, чтобы создавать 3 файла вручную при разработке Nav-компонента, автоматизируйте этот процесс посредством простой команды:

lego-build component Nav

Lego-build не просто помогает создавать внешние компоненты  —  инструменты для этого уже существуют. Lego-build гораздо мощнее.

Философия

Большинство инструментов для генерации компонентов рассматривают все части приложения как компоненты. Однако Lego-build отличается гибкостью. Инструмент рассматривает фронтенд-приложение как здание, состоящее из отдельных блоков. Этими блоками могут быть различные элементы (уже перечисленные в начале статьи), такие как компоненты, страницы, макеты, React-хуки и так далее. Они могут быть папками (например, компоненты) и даже отдельными файлами (например, редьюсер).

Однако главная характеристика блока  —  это наличие шаблонного кода. Например, при создании пользовательских хуков в React вы всегда импортируете useState и возвращаете значение (массив или объект). Lego-build позволяет легко конфигурировать собственные блоки вместе с шаблонным кодом или “образцом”, которому нужно следовать. Гибкость этого инструмента позволяет использовать его в любом фронтенд-фреймворке. Ни один другой инструмент не сравнится с ним в плане гибкости.

Более подробную информацию о том, как настроить Lego-build в соответствии с вашим рабочим процессом, можно найти в документации. Вы также можете посмотреть, как другие разработчики используют Lego-build на странице сообщества.

Вдохновение (подробнее о решении проблемы)

React была первой современной библиотекой JavaScript, которую я изучил, и с тех пор ни разу не пожалел. С ее помощью я создал несколько веб-приложений (и несколько нативных приложений). Некоторые из этих приложений небольшие, с базовой функциональностью, несколькими компонентами и ограниченным управлением состояниями. Другие немного сложнее, с небольшим количеством компонентов, но значительным количеством состояний и логики для управления. Остальные состоят из многих компонентов (в данном случае 39, не считая страниц и компонентов приложения администратора) и достаточного количества логики для подключения к API бэкенда.

Мне понравилось использовать React, но он требовал огромного количества шаблонного кода, связанного с созданием больших приложений (особенно при использовании Redux). При создании полнофункциональных приложений я использую Laravel для API-разработки. Laravel  —  это MVC-фреймворк. Это означает, что в приложении есть три основных блока: модель, представление и контроллер. Laravel поставляется с CLI-инструментом под названием Artisan, который можно использовать для создания любого из трех основных блоков, а также имеет множество полезных команд, которые облегчают и ускоряют бэкенд-разработку. Я отчаянно нуждался в Artisan для React.

Именно эта потребность и привела к появлению Lego-build.

Зачем заново изобретать колесо? (Еще несколько деталей о решении проблемы)

Простой поиск в Google покажет, что уже существует несколько CLI-инструментов для упрощенной разработки React-компонентов. Мы уже упоминали, что Lego-build намного гибче этих инструментов, но поговорим о том, почему такая гибкость важна. Почему мы создали Lego-build вместо использования существующих инструментов?

В Laravel (по крайней мере, в версии 9) каждая модель хранится в каталоге apps/Models. Контроллеры, как и представления, также имеют собственную папку. Эта структура одинакова для каждого разработчика Laravel. Но библиотека React абсолютно другая: она принципиально не ориентирована на единообразную структуру. А это значит, что каждый разработчик структурирует проект по-своему. Одни помещают все компоненты в каталог src/components, а другие используют атомарный дизайн, разделяя компоненты на атомы и молекулы. Кто-то из разработчиков использует модульный CSS, кто-то  —  обычный CSS, а в проектах React Native нет файла CSS.

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

Гибкость Lego-build позволяет использовать его в других библиотеках и фреймворках, кроме React, хотя идея разрабатывалась с учетом потребностей React-разработчиков.


Здесь вы можете самостоятельно протестировать Lego-build.

npm i @ogteam/lego-build -g

Читайте также:

Читайте нас в TelegramVK и Дзен


Перевод статьи Lego-build: Lego-build, the why and what

Предыдущая статьяКак работает шлюз API на Golang: на примере одного симпатичного платья
Следующая статьяКак использовать JavaScript для сокращения HTML-кода