архитектура приложения на vue js

Разработка архитектуры масштабного приложения Vue.js

При разработке нового приложения у веб-программиста возникают следующие проблемы:

Я разработал шаблон, который решает все эти проблемы и позволяет создать модульное, гибкое и масштабируемое приложение на Vue.js. Созданию этого шаблона и посвящена данная серия статей. Сегодня мы рассмотрим структуру приложения.

Я всегда стараюсь спроектировать front-end приложение в три уровня:

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

Папка src:

assets :

Содержит статические ресурсы и изображения.

environment :

plugins :

main.js :

Этот файл отвечает за загрузку Vue-приложения.

Папка app:

app-routes.js :

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

app-state.js :

Файл конфигурации настроек, связанных с управлением состоянием. Например, соответствующая конфигурация Vuex. Все состояния из модулей функций будут объединены и настроены в этом файле с помощью системы управления состояниями.

app.vue :

Корневой компонент, который содержит основное представление приложения.

Модуль функций

Структура папок приложения разделена на основе функций с помощью модулей функций. Корневой модуль функций содержит компоненты вместе с тестами и папкой shared.

Папка shared:

Одна папка shared размещается на уровне приложения. У каждого модуля функций также собственная папка shared. Первая папка содержит содержать общие элементы уровня приложения, а вторая – элементы уровня модуля.

components :

Эта папка включает в себя общие компоненты, которые разделены на различные модули функций или компонентов. Например, Header, Footer, Navigation и т. д.

config:

Содержит связанные с API конфигурации, константы конфигурации и т. д.

directives:

Папка уровня приложения будет содержать общие директивы уровня приложения, а папка уровня модуля – уровня модуля.

filters:

Общие фильтры уровня приложения находятся в общей папке уровня приложения, а фильтры уровня модуля – в папке уровня модуля.

services:

Папка содержит бизнес-логику, утилиты или вызовы http, которые не зависят от логики пользовательского интерфейса. Большинство людей называют их utils, helpers или services. Я назвал их services.

state:

Папка уровня приложения хранит состояние, которое будет совместно использоваться различными модулями функций. Папка уровня модуля содержит состояние модуля функций.

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

Заключение

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

Пожалуйста, оставьте ваши мнения по текущей теме материала. За комментарии, подписки, дизлайки, лайки, отклики низкий вам поклон!

Источник

Архитектура большого, масштабного энтерпрайз приложения на VueJs

При создании нового приложения разработчик часто сталкивается с такими нетривиальными вопросами:

У меня, во всяком случае, всегда возникали вопросы по этой теме, и после некоторых поисков решения, я подготовил шаблон, который поможет решить эти задачи и даст знания и нужный опыт для написания модульного, гибкого и масштабируемого приложения Vue.js. Я решил написать подборку статей об этом, и сегодня начну с первой части, в которой я расскажу о правильной структуре приложения на Vue.js.

Благодаря Vue CLI 3 первоначальная настройка проекта занимает минимум времени. Однако, как бы не был крут Vue Cli 3, начальная настройка не решает все вышеперечисленные проблемы.

Архитектуру своих приложений я всегда стараюсь разделить на 3 слоя:

Изучив материалы из готовых, доступных решений, я нашел множество способов структурирования файлов в проекте, например: папка-одного-типа (сущности), или папка-одной-функции (то есть, группировка сущностей по задаче, которую они решают). И я позаимствовал их идею, немного модифицировав её под собственные задачи. Я взял за основу схему структурирования, основанную на именовании папок, и структурированию файлов, решающих одну задачу, или тесно связанных с ней.

Пример этой структуры вы можете увидеть на картинке:

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

assets :
Содержит одну статику: файлы/изображения.

plugins :
В этой папке будут размещены плагины Vue.

main.js :
Этот файл отвечает за загрузку приложения Vue и его компонентов.

app-routes.js :
Этот файл будет отвечать за подключение всех маршрутов из функциональных модулей (разделяя приложение на модули, я предпочитаю называть их функциональными модулями). Он также будет иметь некоторые системные маршруты, необходимые для разработки и отладки.

app-state.js :
Все настройки, связанные с управлением состоянием приложения будут осуществляться в этом файле. Например, конфигурация, настройка и подключение модулей, связанное с Vuex, будет выполнено здесь. Все состояния из различных функциональных модулей будут объединены здесь и сконфигурированы с системой управления состоянием.

app.vue :
Это корневой компонент, который будет содержать основной шаблон приложения (представление).

Функциональные модули

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

config :
Эта папка будет содержать настройки, связанная с API, например, константы, конфигурационные параметры и т.д.

директивы directives :
Эта папка будет содержать общие директивы. Корневая shared папка приложения будет содержать директивы общего пользования на уровне всего приложения, а shared папка конкретного модуля будет содержать только директивы общего использования конкретного модуля.

Сервисы services :
Большинство людей не понимают, что такое сервисы. Если говорить просто, то сервисы содержат бизнес-логику, хелперы или обработчики HTTP запросов, которые не зависят от логики представления пользовательского интерфейса (UI). Большинство людей называют их утилитами, хелперами или сервисами. Я называю из сервисами, мне кажется это описание наиболее подходящее.

Состояние state :
Shared папка приложения будет хранить информацию о состоянии, которое будет доступно для общего пользования разными функциональными модулями. Общая shared папка на уровне функционального модуля будет знать только о состояние конкретного функционального модуля, и управлять только им.

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

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

Резюме

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

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

Subscribe to Блог php программиста: статьи по PHP, JavaScript, MySql

Get the latest posts delivered right to your inbox

Источник

Проектирование архитектуры хранилища Vuex для больших приложений на Vue.js

Перевод статьи подготовлен в преддверии старта курса «Vue.js-разработчик».

В основе масштабного приложения на Vue.js лежит хранилище, в котором находятся все данные. Хранилище Vuex в приложении на Vue.js служит единым источником истины, который обеспечивает отличную производительность и реактивность из коробки. По мере того, как обрастает кодом ваше приложение, количество данных в хранилище Vuex также растет, и управлять ими становится труднее. Проектирование управления состоянием вашего приложения на основе лучших практик поможет решить большинство проблем, которые появляются по мере усложнения приложения.

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

Структурирование хранилища

Хранилище Vuex состоит из четырех компонентов:

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

Хорошей практикой является отказ от прямого доступа к объекту состояния и использование вместо него getter’а. Функцию getter можно легко смаппить в любой компонент Vue с помощью mapGetter, в качестве вычисляемых свойств.

Разделение хранилища на модули

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

Вот небольшой пример создания модуля хранилища и того, как объединить все модули в основном хранилище.

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

Автоматический импорт модулей хранилища

Как я уже говорил, если модули становятся все сложнее и больше, их нужно разделить на подмодули для уменьшения сложности. Когда количество модулей увеличивается, управлять этими модулями по отдельности становится действительно сложно, а в особенности импортировать каждый из них. У нас будет небольшой JS-файл в каталоге modules, который сделает эту работу за нас. Он поможет нам объединить вместе все модули.

Скрипт для автоматического экспорта

Теперь, когда наш скрипт для автоматического экспорта находится там, где нужно, мы можем начать импорт в основное хранилище и получить доступ ко всем модулям.

Сброс состояния модуля

Если вы когда-нибудь работали с приложениями на Vue + Vuex, которые обрабатывают большое количество данных, то, возможно, сталкивались со сценарием, когда нужно было сбросить состояние хранилища. Функция сброса довольно распространенная механика. В случае, когда в вашем приложении есть аутентификация пользователя, вы можете сбросить хранилище при выходе пользователя из приложения.

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

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

Глобальный сброс состояния модуля

Что делать, если нам нужно сбросить хранилище целиком? Вместе со всеми модулями? Если вы выполнили 4-й и 5-й пункт настройки автоматического импорта и мутации сброса состояния модуля для всех ваших модулей, мы можем использовать следующее действие в файле основного хранилища, чтобы сбросить все модули одновременно.

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

Что дальше?

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

Чтобы узнать больше о том, чем мы занимаемся в Locale.ai, прочтите здесь о неизведанных землях геопространственной аналитики.

Особую благодарность мы выражаем Крису Фритсу за его удивительный рассказ о 7 вещах, которые скрывают от вас консультанты Vue. Он подкинул нам несколько идей, которые мы использовали в этой статье.

Источник

Как структурировать крупномасштабное приложение Vue.js

Как лучше всего структурировать приложение Vue.js, чтобы оно масштабировалось и оставалось обслуживаемым и расширяемым по мере его роста? Этот вопрос я слышал неоднократно, и думаю, что один из ответов на него кроется в принципе предсказуемости. Когда речь идет о создании масштабируемого проекта, вы хотите, чтобы все в нем было максимально предсказуемо.

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

Почему это важно? Вы наверняка сталкивались с ситуацией, когда получали в наследство проект или были введены в него, а затем при выполнении первой задачи открывали кодовую базу и думали: «Я даже не знаю, с чего начать!».

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

Стоит отметить, что, хотя предсказуемость возможна, ни один проект никогда не станет предсказуемым на 100%. Каждый проект, новый или существующий, имеет хотя бы небольшую кривую обучения. Также следует знать, что предсказуемость не означает, что кодовая база или приложение будут быстро понятны в целом. Многие крупномасштабные приложения просто слишком сложны, чтобы это было возможно, и потребуется время, чтобы понять их целиком. Таким образом, предсказуемость — это не видение полной законченной картины, а скорее понимание структуры определенного фрагмента и возможность быстро понять, куда он встраивается. На самом деле, специфика хорошей кодовой базы такова, что ее можно понять по частям, и она не должна требовать от разработчиков необходимости думать обо всем сразу.

Как же добиться предсказуемости в кодовой базе? Ответ: стандарты, простые и понятные. Возможно, это не тот ответ, который вы ищете, но это правда. Лучший способ сделать что-либо предсказуемым — это следовать набору стандартов. Например, я могу почти со 100% уверенностью предсказать, что новые полноразмерные простыни, которые я купил только сегодня, подойдут к моей кровати, даже если я никогда раньше не заправлял ее ими. Почему? Потому что существует стандартная система определения размеров постельного белья.

Стандарты предсказуемости для сообщества

В связи с этим возникает вопрос, какие стандарты есть для сообщества Vue.js в целом? Я бы сказал, что существуют 4 источника.

Временные платформы, сгенерированные Vue CLI

Официальные библиотеки Vue.js (находятся в разделе Ecosystem > Official Projects на сайте Vue.js)

и более свободные, наиболее популярные компонентные фреймворки, такие как Vuetify или Quasar.

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

Официальные библиотеки и библиотеки компонентов

Для начала поговорим о стандартизации, которую обеспечивают официальные и популярные библиотеки компонентов. Хотя основной целью таких библиотек является предоставление функциональности, это также косвенно способствует применению общих стандартов. Если вы используете Vue Router, например, вы не только пользуетесь функциональностью самого пакета, но и в конечном итоге реализуете маршруты в одном проекте так же, как в другом, и точно так же, как их реализуют разработчики Vue.js по всему миру.

Библиотека Vuex фактически признает и рекламирует этот факт как главную особенность, называя себя «паттерн управления состоянием + библиотека».

Это может показаться очевидным, однако в этом есть смысл. Если в Vue.js существует популярное или рекомендуемое решение проблемы (и тем более, если это официальное решение), я бы крепко задумался, прежде чем использовать что-то другое. Мне, как и любому человеку, нравится создавать свои собственные компоненты, хранилища и т.д., но часто в долгосрочной перспективе действительно целесообразно использовать проверенные и верные решения не только из-за функциональности, тестового обеспечения и документации, которые они предлагают, но и из-за стандартизации, которую они привносят. (И разве в мире JavaScript мы все не можем применить немного больше стандартизации?).

Когда дело доходит до выбора использования этих более стандартизированных решений, важно помнить, что именно вы создаете. Вы создаете масштабируемый компонент многократного использования? Тогда, возможно, стандартная библиотека не для вас, потому что новая стандартная библиотека — это как раз то, что вы пытаетесь создать. Однако, вероятно, большинство из нас строит не это. Скорее всего, вы создаете приложение, и в этом случае лучше использовать стандартные (или хотя бы полустандартные) компоненты, которые уже существуют в качестве строительных блоков.

Основы стандартной файловой структуры

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

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

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

Рекомендуемые правила для компонентов

Теперь, обращаясь к каталогу компонента, стайлгайд Vue дает нам несколько дополнительных советов, чтобы сделать нашу файловую структуру более предсказуемой. Среди прочего, стайлгайд рекомендует следующее при определении компонентов:

По возможности каждый компонент должен быть определен в собственном выделенном файле (SFC).

Однофайловые компоненты должны быть оформлены в формате PascalCase

Все базовые компоненты должны начинаться с одного и того же префикса (например, Base или App).

Вы можете рассматривать базовые компоненты как общие для всего приложения многократно используемые компоненты, например, кнопки или модалы.

Это группирует их вместе и заявляет об их глобальном, многоразовом характере.

Названия компонентов всегда должны быть многословными, чтобы не конфликтовать с существующими или будущими элементами HTML. Не создавайте компонент Table или Button.

Компоненты одного экземпляра должны начинаться с префикса The.

Например, верхний или нижний колонтитул сайта

Это группирует их вместе и объявляет их одноразовыми.

Тесно связанные дочерние компоненты должны иметь префикс с именем родительского компонента.

Это группирует их вместе и объявляет их связанными.

Имена компонентов должны начинаться со слов самого верхнего уровня (обычно общего) и заканчиваться самыми конкретными.

Это группирует связанные компоненты вместе в структуре файла

Потерпите, если это не совсем понятно, через минуту появится изображение, которое поможет вам.

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

Некоторые рекомендуемые личные/командные стандарты предсказуемости

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

Каталог одноуровневых компонентов

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

Быстро и легко перейти от поиска компонента в Vue devtools к поиску файла в кодовой базе (имя файла и имя компонента совпадают).

Используйте функцию быстрого поиска или перехода по файлам в вашей IDE для фильтрации файлов на основе их наиболее общих атрибутов вплоть до более конкретных

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

Возможность видеть все компоненты сразу в одном списке

Избавиться от избыточности ключевых слов в именах файлов и в каталоге (это если вы следуете рекомендациям стайлгайда (а так и должно быть) и используете вложенные каталоги) (т.е. post/PostList.vue, post/PostFeature.vue и т.д.)

Избавьтесь от соблазна использовать короткие имена компонентов из одного слова, что проще сделать с вложенными каталогами (т.е. post/List.vue, post/Feature.vue ) и нарушает рекомендации стайлгайда.

Исключить перемещение по файловой структуре в каталогах и обратно в поисках компонента

Упростить импорт компонентов (всегда будет import SomeComponent из «@/SomeComponent»).

Как же выглядит плоская структура, которая следует стайлгайду? Вот хороший пример.

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

Стандартизированное соглашение об именовании маршрутов/страниц

Еще одна методика — это стандартизированный способ именования маршрутов и компонентов страниц. В типичном CRUD-приложении у вас есть следующие различные страницы для каждого ресурса:

список всех ресурсов

представление отдельного ресурса

форма для создания ресурса

и форма для редактирования ресурса.

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

Поскольку у меня уже есть опыт работы с PHP-фреймворком Laravel, при определении имен маршрутов и их путей предсказуемым образом я интуитивно опирался на стандарты, которые были заложены в Laravel. Это облегчило моей команде, обладающей опытом работы с Laravel, более быструю и привычную работу с Vue. Используя в качестве примера ресурс «пользователь», я рекомендую следующее соглашение об именовании, предписанное Laravel и адаптированное для Vue:

Path

Route and Component Name

What it Does

List all the users

Form to create the user

Display the users details

Form to edit the user

Несмотря на соблазн назвать маршрут в более традиционном для Laravel стиле, например users.index вместо UsersIndex, я заметил, что использование стиля PascalCase работает так же хорошо и имеет дополнительное преимущество в виде соответствия имени компонента.

Для большей согласованности и гибкости необходимо всегда ссылаться на маршруты по их имени при использовании их в ссылках маршрутизатора и при программном обращении к ним. Например

Также стоит отметить, что не все маршруты будут точно соответствовать этому шаблону, поскольку некоторые из них будут более «CRUDdy», чем другие. Для таких случаев я рекомендую продолжать использовать PascalCase в названии для обеспечения согласованности.

Более комплексная файловая структура

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

Я также добавил один файл globals.js.

Итак, что стоит за этими стандартами файловой структуры? Очень рад, что вы спросили!

docs

Назначение этого файла очевидно, но важнее то, что он уже включен и при каждом открытии кодовой базы сразу предстает перед взором вашей команды. Более вероятно, что определенные аспекты проекта будут задокументированы, если разработчику никогда не придется покидать свою IDE. Я также обнаружил (и это было приятной неожиданностью), что написание документации сначала, прежде чем приступить к кодированию многократно используемого класса или компонента, обычно помогает мне лучше спроектировать интерфейс или API этого кода. Дерзайте, попробуйте!

Кроме того, помимо каталога docs, я обнаружил, что полезно помещать README.md в корень каждого стандартизированного каталога, объясняя назначение каталога и любые правила для того, что должно быть в него включено. Это особенно полезно для тех стандартов, которые не являются общими для всего сообщества.

helpers

Это общая директория во многих фреймворках для базовых функций ввода-вывода, которые можно использовать многократно в рамках всего проекта. Их обычно легко тестировать и, как правило, они используются не один раз. Мне нравится начинать с одного файла index.js, а затем, по мере роста числа хелперов, разбивать их на более сгруппированные файлы, такие как https.js, cache.js, time.js и т. д. Все в этом каталоге можно просто импортировать и использовать по требованию, а если какая-то функция в итоге вообще не будет использоваться, ее можно легко вытряхнуть из производственного пакета.

layouts

Я позаимствовал это соглашение из Nuxt, а также из Laravel. Это может быть удобно для определения не только компонентов страницы, но и компонентов макета, которые могут быть повторно использованы на нескольких страницах. Вместо того чтобы определять содержимое страницы, как следует из названия, эти компоненты определяют общий макет. Например, будет ли эта страница одноколоночной или двухколоночной? Имеет ли она левую или правую боковую панель? Включает ли макет типичные верхний и нижний колонтитулы или он совершенно пустой, возможно, с абсолютно центрированным содержимым страницы? Обычно существует всего 2 или 3 таких компонента макета, но, тем не менее, они могут быть удобной абстракцией.

mixins

Этот каталог предназначен для организации всех ваших Vue.js миксинов. Я думаю, важно по-прежнему добавлять слово Mixin в конец имени каждого файла (например, ResourceTableMixin.js ) для удобства поиска в переключателе файлов. Хотя у меня еще не было возможности поработать над более масштабным проектом Vue 3, я предполагаю, что это быстро изменится на каталог composables в пользу извлечения реактивных данных/методов с помощью Composition API, а не с помощью миксинов. Или, по крайней мере, каталог composables может быть добавлен в мою стандартную файловую структуру в дополнение к каталогу mixins.

plugins

globals.js

Это единственный стандартный файл, который я действительно когда-либо добавляю. Его цель — внести ограниченное количество глобальных переменных в приложение Vue а для SPA, которые являются только клиентской стороной, обычно это окно.

Вот комментарий, который обычно располагается в верхней части этого файла.

В Vue 2 это можно было сделать таким образом:

В Vue 3 это выглядит следующим образом:

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

Резюме по теме предсказуемости

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

Источник