С момента своего возникновения веб-приложения прошли долгий путь. Мы знаем, какую важную роль играет в вебе JavaScript и какие безграничные возможности есть у нас при выборе фреймворков и технологий. Каждый фреймворк имеет свои достоинства и недостатки, но почти во всех используются какие-то основные методологии. Такие инструменты как create-react-app, next.js, vue-cli и другие действительно полезны для начального формирования проекта и его структуры, но в остальном вы вольны создавать приложение в соответствии со своими предпочтениями и требованиями проекта.
В статье собран список принципов, которые будут полезны при создании веб-приложений с помощью React и Vue. Они помогут вам задать нужное направление и упорядочить разработку. Большинство этих принципов применимо к созданию любого ПО, но всё же список предназначен именно для веб-приложений.
Не всем компонентам нужно подключение к хранилищам, серверному API или каким-то иным сервисам. Когда делаешь компоненты «безразличными к источнику данных», очень сильно повышаются возможности по их многократному использованию.
Storybook – прекрасный инструмент для взаимодействия с дизайнерами и обсуждения функциональности. Он служит «руководством по стилю» для вашего приложения.
Модель ветвления:
Инструмент для линтинга коммит-сообщений — commitlint
В самом начале любого проекта обычно легко держать все изменения в памяти. По мере роста проекта changelog может быть главным «хранилищем», где будут описаны заметные изменения кодовой базы. Пройдут месяцы и даже годы, а он все еще будет актуален для вас.
Да, сюда можно добавить ещё много пунктов, в зависимости от сферы вашего проекта и используемых технологий. Перечисленного будет достаточно для радикального улучшения многих фронтенд-приложений. Почти каждый принцип можно применять постепенно и в зависимости от приоритетов, которые определите вы и ваша команда. Так что не нужно думать о том, как применить всё и сразу :)
В статье собран список принципов, которые будут полезны при создании веб-приложений с помощью React и Vue. Они помогут вам задать нужное направление и упорядочить разработку. Большинство этих принципов применимо к созданию любого ПО, но всё же список предназначен именно для веб-приложений.
1. Разрабатывайте компоненты, а не экраны
- Старайтесь инкапсулировать всю логику компонента, чтобы его можно было легко отобразить где угодно, например, на разных экранах и в разных разделах.
- Все CRUD-операции обращаются за необходимыми данными к контроллерам/поставщикам. Эти данные потом передаются компонентам, которые с ними связаны. Один из распространенных подходов заключается в использовании redux/vuex: данные сохраняются в хранилище и рассматриваются как истинные, а контейнеры извлекают нужную информацию.
2. Разделяйте уровни представления и бизнес-логику/управление
Не всем компонентам нужно подключение к хранилищам, серверному API или каким-то иным сервисам. Когда делаешь компоненты «безразличными к источнику данных», очень сильно повышаются возможности по их многократному использованию.
3. Применяйте стандартный способ извлечения данных
- Этот принцип замечательно иллюстрирует rest-hooks, который поощряет создание простой и понятной структуры вызовов API.
- Для некоторых проектов достаточно использования вызовов с явным извлечением данных. Но если вы работаете с многочисленными источниками и взаимосвязями, то вам поможет абстрагирование серверного API.
4. Используйте общую стратегию ввода информации пользователями
- Сюда относятся формы, выбор меток, проверки и валидации, ошибочные состояния.
- Есть подходящие решения уже из коробки: библиотеки с компонентами пользовательского интерфейса предлагает antd.
- Если вы создаёте приложение без использования UI-библиотеки, то постарайтесь стандартизировать элементы ради улучшения пользовательского опыта.
5. Пишите автоматизированные тесты
- Компоненты лучше тестировать с помощью интеграционных тестов, например, Cypress.
- Необходимо тщательно проверять бизнес-логику с помощью модульных тестов.
- e2e полезно для smoke-тестирования больших пользовательских сценариев. Это поможет выявить регрессии между клиентами и API.
6. Используйте Storybook для создания компонентов многократного использования
Storybook – прекрасный инструмент для взаимодействия с дизайнерами и обсуждения функциональности. Он служит «руководством по стилю» для вашего приложения.
7. Используйте линтеры и средства форматирования
- Примеры линтеров: ESLint, stylelint.
- Большинство инструментов для быстрого старта, например, create-react-app, заранее установят для вас линтеры. Но если вы работаете со старой кодовой базой, то линтеры могут быть бесполезны.
- Они помогают в поиске багов, но также могут применяться для формирования стиля кода, который пишет команда. Это снижает когнитивную нагрузку при работе над фичами, которые вы получили от своих коллег.
- Плагин sonarJS eslint поможет улучшить качество кода за счёт проверки его логической структуры.
- prettier — это прекрасный инструмент форматирования. Достаточно настроить его один раз и забыть. Очень полезно при работе в команде.
8. Избегайте глобальных стилей
- Переопределения и сбросы могут быть глобальными.
- Создать изолированные стили можно с помощью CSS-модулей или CSS-in-JS.
- Локальные стили часто улучшают ситуацию с многократным использованием компонентов.
9. Используйте структурированное версионирование
Модель ветвления:
- Например, gitflow — «модель ветвления для Git, созданная Винсентом Дриссеном».
- Для командной работы необходимо наличие структуры в вашем версионировании. Но это будет полезно и при самостоятельной работе.
Инструмент для линтинга коммит-сообщений — commitlint
- Полезен при создании списка изменений и поиске багов в ходе работы над проектом.
- Правила по написанию коммит-сообщений в Angular часто подходят и для других проектов. А commitlint поможет соблюдать эти правила, когда будете писать свои сообщения.
10. Поддерживайте changelog
В самом начале любого проекта обычно легко держать все изменения в памяти. По мере роста проекта changelog может быть главным «хранилищем», где будут описаны заметные изменения кодовой базы. Пройдут месяцы и даже годы, а он все еще будет актуален для вас.
Список можно продолжать бесконечно
Да, сюда можно добавить ещё много пунктов, в зависимости от сферы вашего проекта и используемых технологий. Перечисленного будет достаточно для радикального улучшения многих фронтенд-приложений. Почти каждый принцип можно применять постепенно и в зависимости от приоритетов, которые определите вы и ваша команда. Так что не нужно думать о том, как применить всё и сразу :)
atomic1989
советы полезны, только скорее с точки зрения поставщика компонентов. С точки зрения архитектуры приложения мало информации(Модули, асинхронная подгрузка скриптов).
A11oW Автор
Соглашусь, что список можно дополнить. Но кажется что он достаточно универсален как для компонентов, так и для приложений. Мы используем каждый пункт из списка в приложении, даже changelog =) (он генерируется автоматически)