Як структурувати проект Vue.js

Ідеальна структура папок Vue.js та архітектура компонентів із розумними та німими компонентами

Vue.js - це більше, ніж ажіотаж, це чудовий фронтменд. Почати з нього досить просто і створити веб-додаток. Vue.js часто описується як рамки для невеликих додатків і навіть іноді як альтернатива jQuery через його невеликий розмір! Я особисто думаю, що він також може підходити для великих проектів, і в цьому випадку важливо добре його структурувати, з точки зору архітектури компонентів.

Перш ніж запустити свій перший великий проект Vue.js, я провів кілька досліджень, щоб знайти ідеальну структуру папок, архітектуру компонентів та умови іменування. Я ознайомився з документацією Vue.js, кількома статтями та багатьма проектами з відкритим кодом GitHub.

Мені потрібно було знайти відповіді на кілька запитань. Ось що ви знайдете в цій публікації:

  • Як ви структуруєте файли та папки всередині проекту Vue.js?
  • Як ви пишете інтелектуальні та німі компоненти та де їх розміщуєте? Це концепція, що виходить від React.
  • Які стиль кодування Vue.js та кращі практики?

Я також буду документувати джерело, на яке я надихнувся, та інші посилання, щоб краще зрозуміти.

Структура папки Vue.js

Ось вміст папки src. Рекомендую розпочати проект із Vue CLI. Я особисто використовував шаблон Webpack за замовчуванням.

.
├── app.css
├── App.vue
├── активи
│ └── ...
├── компоненти
│ └── ...
├── main.js
├── міксин
│ └── ...
├── маршрутизатор
│ └── index.js
├── магазин
│ ├── index.js
│ ├── модулі
│ │ └── ...
│ └── mutation-types.js
├── переклади
│ └── index.js
├── утиліти
│ └── ...
└── поглядів
    └── ...

Кілька деталей про кожну з цих папок:

  • активи - куди ви розміщуєте будь-які активи, які імпортуються у ваші компоненти
  • компоненти - Усі компоненти проектів, які не є основними поглядами
  • mixins - Міксини - це частини коду JavaScript, який повторно використовується в різних компонентах. У mixin ви можете помістити методи будь-якого компонента з Vue.js, вони будуть об'єднані з методами компонента, який його використовує.
  • маршрутизатор - Усі маршрути ваших проектів (у моєму випадку я їх маю в index.js). В основному у Vue.js все є складовою. Але не все - це сторінка. На сторінці є такий маршрут, як "/ приладова панель", "/ налаштування" або "/ пошук". Якщо компонент має маршрут, він спрямовується.
  • зберігати (необов'язково) - константи Vuex у mutation-type.js, модулі Vuex у модулях підпапки (які потім завантажуються у index.js).
  • переклади (необов’язково) - Локальні файли, я використовую Vue-i18n, і він працює досить добре.
  • утиліти (необов'язково) - Функції, які я використовую в деяких компонентах, таких як тестування величин регулярного виразів, константи або фільтри.
  • перегляди - Щоб зробити проект швидшим для читання, я відокремлюю компоненти, які спрямовуються, і поміщаю їх у цю папку. Передані для мене компоненти - це більше, ніж компонент, оскільки вони представляють сторінки, і вони мають маршрути, я розміщую їх у "переглядах", то коли ви перевіряєте сторінку, переходите до цієї папки.

Зрештою, ви можете додати інші папки залежно від ваших потреб, наприклад, фільтри чи константи, API.

Деякі ресурси мене надихнули

  • https://vuex.vuejs.org/en/structure.html
  • https://github.com/vuejs/vue-hackernews-2.0/tree/master/src
  • https://github.com/mchandleraz/realworld-vue/tree/master/src

Розумні та німі компоненти з Vue.js

Розумні та німі компоненти - це концепція, про яку я дізнався від React. Розумні компоненти також називають контейнерами, вони - ті, хто керує змінами стану, вони відповідають за те, як все працює. Навпаки, німі компоненти, які ще називають презентаційними, керують лише зовнішнім виглядом.

Якщо ви знайомі з шаблоном MVC, ви можете порівняти компоненти дампа з представленням та інтелектуальні компоненти з контролером!

Розумні та німі компоненти React зазвичай розміщуються в різних папках, тоді як у Vue.js ви поміщаєте їх у одну папку: компоненти. Для розмежування у Vue.js ви використовуєте конвенцію про іменування. Скажімо, у вас є німий компонент картки, тоді ви повинні використовувати одне з цих імен:

  • BaseCard
  • AppCard
  • VCard

Якщо у вас є інтелектуальний компонент, який використовує BaseCard і додає до нього деякі методи, ви можете, наприклад, назвати його, залежно від вашого проекту:

  • ProfileCard
  • ItemCard
  • Картки новин

Якщо ваш розумний компонент - це не лише «розумніша» BaseCard із методами, просто використовуйте будь-яке ім’я, яке відповідає вашому компоненту і не починаючи, наприклад, від Base (або App, або V):

  • Інформаційна панель
  • Результати пошуку
  • Профіль користувача

Ця умова іменування походить від офіційного керівництва стилем Vue.js, що також містить угоди про іменування!

Названня конвенцій

Ось кілька конвенцій, що виходять із офіційного стилю керівництва Vue.js, що вам потрібно добре структурувати ваш проект:

  • Імена компонентів завжди повинні бути багатословними, за винятком кореневих компонентів програми. Наприклад, використовуйте “UserCard” або “ProfileCard” замість “Card”.
  • Кожен компонент повинен бути у власному файлі.
  • Імена файлів з однофайловими компонентами повинні бути завжди PascalCase або завжди шашликовими. Використовуйте “UserCard.vue” або “user-card.vue”.
  • Компоненти, які використовуються лише один раз на сторінці, повинні починатися з префіксу "The", щоб позначити, що може бути лише один. Наприклад, для навбар або нижнього колонтитулу слід використовувати "TheNavbar.vue" або "TheFooter.vue".
  • Дочірні компоненти повинні містити прізвище свого батька як префікс. Наприклад, якщо ви хочете, щоб компонент "Photo", який використовується в "UserCard", назвете його "UserCardPhoto". Це для кращої читабельності, оскільки файли в папці зазвичай впорядковуються в алфавітному порядку.
  • Завжди використовуйте повне ім'я замість абревіатури в назві компонентів. Наприклад, не використовуйте "UDSettings", а замість цього "UserDashboardSettings".

Офіційний стиль керівництва Vue.js

Незалежно від того, ви є просунутим чи початківцем у Vue.js, ви повинні прочитати цей стильний посібник Vue.js, він містить безліч порад, а також іменування умов. Він містить безліч прикладів того, що потрібно робити, а не робити.

Якщо вам сподобалась ця публікація, натисніть клавішу нижче кнопки кілька разів, щоб показати свою підтримку! Також сміливо коментуйте та дайте будь-які відгуки. Не забувайте йти за мною!

Хочете побачити більше подібних статей? Підтримайте мене на Patreon