VueJS: минусы компонентной структуры?

Question

[thehighhomie]

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

src
    components
        icon
        layout
        main
        modal
        shared
        ui

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

main
    Header
        index.vue
        Menu.vue
    Sidebar
        index.vue

Каждая папка - это неймспейс для компонента.
Пример с парой компонентов:

<MainHeader />
<MainSidebar />

Вложенные компоненты у дочерних компонентов каждого неймспейса, имеют префикс компонента, в котором они лежат.
К примеру компонент Menu.vue, который лежит в папке Header, будет иметь name: ‘MainHeaderMenu’ и вот так при описании:

<MainHeaderMenu :list=”menuList” />

С такой структурой мне довольно легко ориентироваться в коде, я сразу вижу по префиксу из какого неймспейса компонент, да и структурировано все, как по мне, с такой структурой можно сотни компонентов добавлять.

Единственное, что меня очень сильно раздражает, так это то описывать компоненты с неймспейсом UI:
<UIButton />, <UISelect />, <UIMenu />. Мне очень неудобно читать компонент, когда у него стоит префикс UI, не знаю почему, но прям глаз ломает. Что-то другое не получается придумать.

В общем подскажите пожалуйста по структуре, может какие вещи я еще не предусмотрел и Ваш комментарий мне поможет.

Comments

[Игорь]

Интересно послушать специалистов.

Прификсы в коде можно использовать через черточку

Вот так

<head-title>

Исходя и того что я уже видел, то можно придерживаться следующей логике:

Существует концептуально неизменная структура.

Head
Body
Footer

Было бы глупо везде и всюду добавлять префиксы head, body, title.

Другое дело в папке components
может быть следующая структура

директория Head
В которой могут находиться дочерние компоненты принадлежащие основному компоненту Head

HeadTitle
HeadItem
HeadSubTitle
HeadBody
HeadGroup
HeadGroupItem

Так реализована во фреймворке V bootstrap

Component Card
BCard
BCardTitle
BCardBody
BCardText
BCardFooter

если конечно я правильно понял вопрос.

[Игорь]

По поводу минусов, наверное чрезмерная декомпозиция не даст существенного профита.

стоит учитывать ещё тот момент, что если component не предназначен для многоразового использования нет смысла оформлять его как компонент.

[Сергей delphinpro]

Мне очень неудобно читать компонент, когда у него стоит префикс UI, не знаю почему, но прям глаз ломает.

Ага, тоже есть такое. Видимо из-за прописных букв, сливается. Поэтому не использую сокращение UI

<UiButton />, <UiSelect />, <UiMenu />
<BaseButton />, <BaseSelect />, <BaseMenu />

Answer 1

[Evgeny Kulakov]

Несколько общих соображений:

1. Если проект развивается, и вы не переписываете что-то уже готовое, то на начальном этапе нет смысла сильно заморачиваться со структурой. Просто делайте своевременно рефакторинг и приводите структуру к более удобному виду по мере развития.
2. По опыту более удобно все-таки иметь более плоскую структуру папок, иначе со временем по ним очень тяжело делать навигацию.
3. В вашем варианте вы получите много одинаковых файлов index и menu например. Как правило в редакторе открыта куча файлов, для названия остается мало места и у вас будет множество вкладок index.vue в итоге. Т.е. лучше делать название файла более информативным типа:

header\
HeaderLayout.vue (или Header.vue или HeaderBase.vue ) - базовый компонент, который так или иначе использует другие.
HeaderMenu.vue
HeaderTitle.vue
и т.д.

Лично я обычно имя компонента делаю равным имени файла.
4. Если не смотрели, стоит прочитать style guide по vue: https://vuejs.org/v2/style-guide/
5. Тесно связанные файлы и папки лучше держать ближе к друг другу для упрощения поиска.
6. Для базовых компонентов, чтобы отличать их от компонентов фреймворка например, можете сделать свой префикс типа app-button, app-selector и т.д.

Comments

[Сергей delphinpro]

Третий пункт — боль. С одной стороны всё верно — во вкладках неудобно ориентироваться. С другой внутренний эстет не дает покоя, когда вижу импорты

import MainHeader from '@/components/Main/Header/MainHeader';

Так оно как-то лучше выглядит
import MainHeader from '@/components/Main/Header';

пока приходится писать лишнее, и надеяться, что когда-нибудь проблему решат на уровне поддержки в IDE.
В шторме, например уже сейчас есть опция отображения каталога при наличии нескольких одинаковых имен файлов в открытых вкладках.
Но префикс отображается только если есть более одного условного index.vue
А если он один, сиди гадай, что там за индекс, пока не ткнешь.

[Evgeny Kulakov]

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

views\
  orders\
    OrderLayout.vue
    OrderSummary.vue
    OrderSummaryRow.vue
    ...etc.
  otherpage\
    ...etc.

[thehighhomie]

Сергей delphinpro, так вы плюсуете мою структуру или что-то лучше предложить можете?

[thehighhomie]

Evgeny Kulakov, спасибо) но мне не очень нравится такой подход

[Дмитрий]

Не знаю, какой "редактор" вы используете, но тот же Шторм показывает в имени вкладки родительскую директорию при совпадении иен открытых файлов.

[Сергей delphinpro]

thehighhomie, я полностью согласен в этом вопросе с Evgeny Kulakov

[Сергей delphinpro]

Дмитрий, Я про шторм и говорил. Хорошо было бы иметь возможность переименовывать вкладки как угодно без переименования файлов, и чтобы имена сохранялись при закрытии. Плюс поддержка Vue — отображать на вкладке имя компонента, а не файла. Черкануть что ли в трекер идею..

[Evgeny Kulakov]

thehighhomie, в чем его недостаток?) Еще касательно стилей - если выпишите приложение, именно приложение, а не какую-то библиотеку, то выносить стили в какую-то отдельную папку, типа как в схеме для nuxt в смежном ответе тот еще геморой, будете постоянно лазить в эту папку и искать файл со стилем. Куда удобнее хранить все в одном файле или максимально близко к файлу компонента. Также обычно, если используется какая-то готовая либа, то своих стилей совсем немного, в итоге они хранятся прямо в компоненте и есть отдельные общие свои стили для всего приложения.

[thehighhomie]

Evgeny Kulakov, гораздо удобнее в папку со стилями выносить код, который похож на библиотеку, хелперы, что-то общее. что касается именно компонента, то разделять компонент по файлам плохая идея, когда вы используете SFC. смысл тогда вообще от vue?) пользовались бы реактом) хотя там тоже вроде можно это настроить

[Evgeny Kulakov]

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

[thehighhomie]

Evgeny Kulakov, ну я хочу что-то более универсальное, чтобы во всех проектах использовать не заморачиваясь. у меня 3 приложения, редактор (где одна вьюха) и 2 сайта.

[thehighhomie]

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

[Evgeny Kulakov]

thehighhomie, про серебряную пули слышали? Ее нет) Гит не дам) вот скрин. И представьте, если я начну все по папкам распихивать.

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

[thehighhomie]

Evgeny Kulakov, в том то и дело, что у вас структура сложная) ее нужно разделить еще лучше, это вам наверное удобно, вы привыкли. а если новые люди придут?)

[Evgeny Kulakov]

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

[thehighhomie]

Evgeny Kulakov, у меня компоненты получают имя с префиксом неймспейса, я же писал в вопросе.

[Игорь]

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

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

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

Evgeny Kulakov, поэтому давайте переделываете, да побыстрей.

Шучу.

[Evgeny Kulakov]

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

order\
  Order.vue
  OrderHeader.vue
  OrderHeaderTabs.vue
  OrderContent.vue
  OrderContentSomeFeature.vue

или

order\
  index.vue
  header\
    index.vue
    tabs\
      index.vue
  content\
     index.vue
     somefeature\
       index.vue

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

[thehighhomie]

Evgeny Kulakov,

order\
index.vue
header\
index.vue
tabs\
index.vue
content\
index.vue
somefeature\
index.vue

я по другому строю структуру.

пример с Order:

Order\
    index.vue
    Content.vue 
    Header.vue
    HeaderTabs.vue

имена получаются у этих компонентов такие:

index.vue             name: 'Order'
Content.vue         name: 'OrderContent'
Header.vue          name: 'OrderHeader'
HeaderTabs.vue   name: 'OrderHeaderTabs'

я делаю структуру так, чтобы вложенных подпапок небыло, и да, это возможно)

[Игорь]

Evgeny Kulakov, Ну второй пример притянут за уши.

Да, я бы выбрал верхний.

[Игорь]

thehighhomie, Мне не понятно, а зачем индексные файлы в компонентах?
Моё субъективное мнение, подсказывает, что имя компонента должно соответствовать названию папки, её содержащей.

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

[thehighhomie]

Игорь, представьте, что папка с именем компонента - это приложение, а index.vue - это точка входа приложения)))

я все-таки набросал быстренько переключение темы, со своей структурой, посмотрите, может вы прозреете))

https://codesandbox.io/s/vue-template-vdozv

[thehighhomie]

Evgeny Kulakov, может вы не поняли изначально, какая именно структура.

https://codesandbox.io/s/vue-template-vdozv

я тут немного набросал. есть и пример с двумя компонентами в папке, это компонент Header

[thehighhomie]

Игорь, я кстати не смог в песочнице реализовать доступ к переменным стилей из компонентов, по этому цветом обычным вхерачил значения)) ну и не ставил либы для стилей, тоже почему-то не работало в песочнице, но сам посыл ясен)

[Evgeny Kulakov]

thehighhomie, да, я вас понял. Но как говорил, c кучей index файлов не совсем удобно работать. В моем варианте:

main/
  Main.vue
  MainContent.vue
  MainHeader.vue
  MainHeaderMenu.vue
  MainSideBar.vue

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

settings/
  Settings.vue
  SettingsCategories.vue
  activeproducts/
    ActiveProducts.vue
    ActiveProductsEdit.vue
  minorder/
    MinOrder.vue
    MinOrderTable.vue
  kpi/
    KPISettings.vue

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

- близость тесносвязанных компонентов/сущностей
- легкость опознавания компонентов - адекватный нэйминг файлов
- соблюдение компромисса вложенности - не надо все в одну папку, не надо 100500 вложенных папок с одним компонентом
- не загонять себя в рамки придуманной структуры - подстраиваться под проект и его потребности
- style-guide от vue с объяснением почему так делать не рекомендуется: https://vuejs.org/v2/style-guide/#Tightly-coupled-...

[Игорь]

Evgeny Kulakov, Вот тут я присоединяюсь к коллеге.

- близость тесно связанных компонентов/сущностей
- легкость опознавания компонентов - адекватный нэйминг файлов
- соблюдение компромисса вложенности - не надо все в одну папку, не надо 100500 вложенных папок с одним компонентом

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

Опять же, я отталкиваюсь не только от своих предпочтений.

[thehighhomie]

Evgeny Kulakov, спасибо за комментарии)

[thehighhomie]

Игорь, спасибо за комментарии)

[kDallas1203]

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

[Игорь]

kDallas1203, В шторме, плагины, в поиске вбейте
/vendor:"Fabio Gianini"

Ну или ссылка

[kDallas1203]

Игорь, спасибо)

[Игорь]

thehighhomie, Продолжая тему, позарез понадобился слайдер с горизонтальной прокруткой
Оформил в виде компонента

<v-row>
      <v-col>
        <slide-group>
          <slider-item image="https://img.icons8.com/small/64/000000/soda-cup.png"  />
          <slider-item image="https://img.icons8.com/wired/64/000000/salad.png"  />
          <slider-item image="https://img.icons8.com/ios-glyphs/60/000000/cheeseburger.png"  />
          <slider-item image="https://img.icons8.com/carbon-copy/100/000000/french-fries.png"  />
          <slider-item image="https://img.icons8.com/doodle/48/000000/strawberry-2.png"  />
        </slide-group>
      </v-col>
    </v-row>

Answer 2

[Akkarine]

Почитайте nuxt.js - там best practices включают и иерархию файлов.

Comments

[HeTpe3B]

Там pages, layout, components только. Вопрос-то, как устроить иерархию в папке components, и nuxt на этот счёт, вроде, рекомендаций не даёт?

[Игорь]

HeTpe3B, Коллега, внимание сюда

Для нужд компании купили профессиональный шаблон, для NUXT

Там следующая схема.

Схема

|-- nuxt-now-ui-kit-pro
    |-- .editorconfig
    |-- .gitignore
    |-- README.md
    |-- nuxt.config.js
    |-- package.json
    |-- yarn.lock
    |-- assets
    |   |-- README.md
    |   |-- fonts
    |   |   |-- nucleo-license.md
    |   |   |-- nucleo-outline.eot
    |   |   |-- nucleo-outline.ttf
    |   |   |-- nucleo-outline.woff
    |   |   |-- nucleo-outline.woff2
    |   |-- sass
    |       |-- demo.scss
    |       |-- now-ui-kit.scss
    |       |-- now-ui-kit
    |           |-- _alerts.scss
    |           |-- _badges.scss
    |           |-- _buttons.scss
    |           |-- _cards.scss
    |           |-- _carousel.scss
    |           |-- _checkboxes-radio.scss
    |           |-- _dropdown-extend.scss
    |           |-- _dropdown.scss
    |           |-- _example-pages.scss
    |           |-- _footers.scss
    |           |-- _images.scss
    |           |-- _info-areas.scss
    |           |-- _inputs.scss
    |           |-- _media.scss
    |           |-- _misc.scss
    |           |-- _mixins.scss
    |           |-- _modals-extend.scss
    |           |-- _modals.scss
    |           |-- _navbar-extend.scss
    |           |-- _navbar.scss
    |           |-- _nucleo-outline.scss
    |           |-- _pagination.scss
    |           |-- _pills-extend.scss
    |           |-- _pills.scss
    |           |-- _popups.scss
    |           |-- _progress.scss
    |           |-- _responsive.scss
    |           |-- _sections-extend.scss
    |           |-- _sections.scss
    |           |-- _social-buttons.scss
    |           |-- _tables.scss
    |           |-- _tabs.scss
    |           |-- _typography.scss
    |           |-- _variables.scss
    |           |-- cards
    |           |   |-- _card-background.scss
    |           |   |-- _card-blog.scss
    |           |   |-- _card-contact.scss
    |           |   |-- _card-extend.scss
    |           |   |-- _card-fashion.scss
    |           |   |-- _card-form-horizontal.scss
    |           |   |-- _card-no-shadow.scss
    |           |   |-- _card-plain.scss
    |           |   |-- _card-pricing.scss
    |           |   |-- _card-product.scss
    |           |   |-- _card-profile.scss
    |           |   |-- _card-raised.scss
    |           |   |-- _card-signup.scss
    |           |   |-- _card-testimonials.scss
    |           |-- element-ui-plugins
    |           |   |-- _carousel.scss
    |           |   |-- _date_picker.scss
    |           |   |-- _input.scss
    |           |   |-- _select.scss
    |           |   |-- _tables.scss
    |           |   |-- _tags.scss
    |           |   |-- _tooltip.scss
    |           |-- mixins
    |           |   |-- _badges.scss
    |           |   |-- _buttons.scss
    |           |   |-- _cards.scss
    |           |   |-- _datepicker.scss
    |           |   |-- _dropdown.scss
    |           |   |-- _inputs.scss
    |           |   |-- _modals.scss
    |           |   |-- _navbar.scss
    |           |   |-- _pages.scss
    |           |   |-- _popovers.scss
    |           |   |-- _social-buttons.scss
    |           |   |-- _tags.scss
    |           |   |-- _transparency.scss
    |           |   |-- _vendor-prefixes.scss
    |           |-- plugins
    |           |   |-- _plugin-bootstrap-select.scss
    |           |   |-- _plugin-bootstrap-switch.scss
    |           |   |-- _plugin-datepicker.scss
    |           |   |-- _plugin-datetimepicker.scss
    |           |   |-- _plugin-fileupload.scss
    |           |   |-- _plugin-isometricGrids.scss
    |           |   |-- _plugin-nouislider.scss
    |           |   |-- _plugin-perfect-scrollbar.scss
    |           |   |-- _plugin-tagsinput.scss
    |           |-- sections
    |               |-- _blogs.scss
    |               |-- _contactus.scss
    |               |-- _features.scss
    |               |-- _headers.scss
    |               |-- _pricing.scss
    |               |-- _projects.scss
    |               |-- _social-subscribe-lines.scss
    |               |-- _team.scss
    |               |-- _testimonials.scss
    |-- components
    |   |-- Alert.vue
    |   |-- Badge.vue
    |   |-- Button.vue
    |   |-- Dropdown.vue
    |   |-- InfoSection.vue
    |   |-- Logo.vue
    |   |-- Modal.vue
    |   |-- Pagination.vue
    |   |-- Progress.vue
    |   |-- README.md
    |   |-- Slider.vue
    |   |-- Switch.vue
    |   |-- Table.vue
    |   |-- index.js
    |   |-- Cards
    |   |   |-- Card.vue
    |   |   |-- StatsCard.vue
    |   |-- Collapse
    |   |   |-- Collapse.vue
    |   |   |-- CollapseItem.vue
    |   |-- Comments
    |   |   |-- Comment.vue
    |   |-- Inputs
    |   |   |-- Checkbox.vue
    |   |   |-- IconCheckbox.vue
    |   |   |-- Radio.vue
    |   |   |-- formGroupInput.vue
    |   |-- Navbar
    |   |   |-- NavLink.vue
    |   |   |-- Navbar.vue
    |   |   |-- NavbarToggleButton.vue
    |   |-- NotificationPlugin
    |   |   |-- Notification.vue
    |   |   |-- Notifications.vue
    |   |   |-- index.js
    |   |-- Tabs
    |   |   |-- Tab.vue
    |   |   |-- Tabs.vue
    |   |-- layout
    |       |-- MainFooter.vue
    |       |-- MainNavbar.vue
    |       |-- StarterFooter.vue
    |       |-- StarterNavbar.vue
    |-- constants
    |   |-- index.js
    |-- directives
    |   |-- click-ouside.js
    |-- layouts
    |   |-- README.md
    |   |-- default-no-footer.vue
    |   |-- default.vue
    |   |-- gray-footer.vue
    |   |-- white-nav.vue
    |-- middleware
    |   |-- README.md
    |-- pages
    |   |-- README.md
    |   |-- about.vue
    |   |-- blog-post.vue
    |   |-- blog-posts.vue
    |   |-- components.vue
    |   |-- contact.vue
    |   |-- ecommerce.vue
    |   |-- index.vue
    |   |-- landing.vue
    |   |-- login.vue
    |   |-- pricing.vue
    |   |-- product.vue
    |   |-- profile.vue
    |   |-- sections.vue
    |   |-- signup.vue
    |   |-- components
    |   |   |-- BasicElementsSection.vue
    |   |   |-- Cards.vue
    |   |   |-- CarouselSection.vue
    |   |   |-- Footers.vue
    |   |   |-- ImagesSection.vue
    |   |   |-- JavascriptComponents.vue
    |   |   |-- Navigation.vue
    |   |   |-- Notifications.vue
    |   |   |-- NucleoIconsSection.vue
    |   |   |-- Pills.vue
    |   |   |-- PreFooters.vue
    |   |   |-- ProgressPagination.vue
    |   |   |-- Tabs.vue
    |   |   |-- TypographyTables.vue
    |   |   |-- Cards
    |   |   |   |-- BlogCards.vue
    |   |   |   |-- FullbackgroundCards.vue
    |   |   |   |-- PlainCards.vue
    |   |   |   |-- PricingCards.vue
    |   |   |   |-- ProfileCards.vue
    |   |   |-- TypographyTables
    |   |       |-- ShoppingTable.vue
    |   |-- sections
    |   |   |-- Blogs.vue
    |   |   |-- Contact.vue
    |   |   |-- Features.vue
    |   |   |-- Headers.vue
    |   |   |-- Pricing.vue
    |   |   |-- Projects.vue
    |   |   |-- Teams.vue
    |   |   |-- Testimonials.vue
    |   |-- starter
    |       |-- StarterPage.vue
    |-- plugins
    |   |-- README.md
    |   |-- element-ui.js
    |   |-- globalComponents.js
    |   |-- globalDirectives.js
    |   |-- globalMixins.js
    |   |-- now-ui-kit.js
    |-- static
    |   |-- README.md
    |   |-- favicon.ico
    |   |-- icon.png
    |   |-- sw.js
    |   |-- img
    |-- store
        |-- README.md

[Игорь]

Это как раз то о чём я писал в комментарии выше.

[Игорь]

HeTpe3B, Вопрос, в чём, в том как удобно или в плане производительности?

Как мне кажется, на производительность это не как не влияет, всё ровно, ваш ровный код будет выполняться сборка, и код превратиться в кашу.

Влияет его количество, динамический или статический инклюд

[HeTpe3B]

Игорь, благодарю за схему

[Михаил]

Игорь, Плохое наименование компонентов, одна из причин они имеют название из одного слова, что может привести к неожиданным последствиям когда в html появится такой тэг

[thehighhomie]

Игорь, вот это дичь вы купили

[thehighhomie]

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

[thehighhomie]

HeTpe3B правильно написал, мне именно компонентная структура важна, а гайд nuxt'a по модулям это тоже не вариант, я считаю, что это лишнее.

вчера мне подсказали про feature slices, вроде норм тема, но вместе с atomic design, а atimic design мне тоже не нравится, вот я и в поиске решения, которое меня устроит, но что-то я ни как не найду его...

[Akkarine]

thehighhomie, Мне кажется у вас терзания на уровне "пробелы и табы". В таком случае надо просто взять какой-то стандарт или установить свой и больше не возвращаться к этому вопросу, если не появятся какие-то весомые аргументы :)

[Игорь]

thehighhomie, Понимаете какое дело, я же купил на официальном сайте nuxt.
И коробку ещё не открывал.

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

А теперь объясните мне, каким это образом вы будите менять цветовую схему, если такая задача потребуется?

Спасибо.

[Игорь]

nuxt-now-ui-kit-pro
Плиз, пользуйтесь.

[Игорь]

Вот ещё пример, где сили лежат вне components
Не настаиваю, как вариант можно и в компонентах стиль задавать.

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

[thehighhomie]

Игорь, очень просто))

в компоненте добавить еще один блок стилей без scoupe и будет вам счастье)

<style lang="stylus">
.theme
  &-dark
    .main-footer
      background-color theme-color('dark', 'lighten-1')
      border-top 1px solid theme-color('dark', 'darken-3')
  &-light
    .main-footer
      background-color theme-color('light', 'base')
      border-top 1px solid theme-color('light', 'darken-3')
</style>

по сути результат один и тот же, что у вас, что в моем примере, только если компонент изменили или удалили, то не нужно идти в папку стилей, все при себе, как раз это показывает всю прелесть SFC!

[Игорь]

thehighhomie, Ок.
Не получилось бы так, что перемешаются кони и люди.

Ладно, ок, но вам всё ровно нужно создавать файл с общими стилями.
И инклюдить в конфигурационном файле.
Не так ли?

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

[thehighhomie]

Игорь,

Не получилось бы так, что перемешаются кони и люди.

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

Ладно, ок, но вам всё ровно нужно создавать файл с общими стилями.

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

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

в общем, что косается именно компонента - находится в компоненте. все общее уходит в папку стилей. и это уже будет больше похоже на стайл SFC)

в общем если хотите покажу вечером

[Игорь]

thehighhomie, Спасибо, не стоит, в принципе, я понимаю, о чем речь.

[thehighhomie]

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

[Игорь]

По поводу плоской структуры.
В плоской структуре есть свои минусы и они как мне кажется достаточно весомые.
Можно быстро исчерпать все нормальные и логичные наименования

Например.

У вас есть 2 компонента.

List и Card

В плоской структуре это выглядит следующим образом

Card.vue
CardGroup.vue
CardItem.vue
CardTitle.vue
CardHead.vue
CardFooter.vue
List.vue
ListGroup.vue
ListItem.vue
ListTitle.vue
ListHead.vue
ListFooter.vue

В иерархической структуре это выглядит так

List
---List.vue
---ListGroup.vue
---ListItem.vue
---ListTitle.vue
---ListHead.vue
---ListFooter.vue

Card
---Card.vue
---CardGroup.vue
---CardItem.vue
---CardTitle.vue
---CardHead.vue
---CardFooter.vue

[Игорь]

[thehighhomie]

Игорь, ну плоскую структуру я не использую)) особенно фишки из документации типа TheSidebar, BaseButton и т.д.)

[Игорь]

Игорь, Ну это я не вам.
Я заметил в комментарии коллегу, у которого структура плоская.

[thehighhomie]

Игорь, проглючило меня)

Answer 3

[Николай]

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

Comments

[thehighhomie]

недостатком таковой является путаница в случаях когда компоненты/модули пересекаются в дереве, к примеру когда 2 ветки используют один и тот же компонент

это как? можете пример показать? я не пойму в чем проблема.

Я больше предпочитаю структуру ориентированную на зоны ответственности.

можете тоже пример показать, или ссылку на репо?