Как использовать значение промиса, для условия?

asd dsa, тогда комментарий выше справедлив, нужно либо async/await синтаксис использовать или внутри промиса инициализировать провайдер - когда он зарезолвится.

Как передать в компонент из vuex изменившиеся данные конкретного объекта store?

Евгений Журов, ага, точно, поправил в ответе.

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

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-...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как изменить primary цвет в Vuetify?

Если это primary цвет для всего приложения, то лучше его задать как опцию: https://codepen.io/kerf/pen/WNedXEz

Плохая вложенность компонентов или чего то не хватает для правильной работы v-model?

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

Плохая вложенность компонентов или чего то не хватает для правильной работы v-model?

Сергей Хлопов, не знаю специфики вашего компонента, но попробуйте так:

<template>
    <quill :value="text" :options="editorOption" @change="$emit('input', $event)"></quill>
</template>

export default {
        model: {
            prop: 'text',
            event: 'input',
        },
        props: {
            text: {
              type: String,
              default: ''
            },
        },
        data: function() {
            return {
                editorOption: {
                    placeholder: 'Описание категории...',
                    formats: [],
                    modules: {
                        toolbar: [
                            ['bold', 'italic', 'underline', 'strike'],
                            [{ 'list': 'ordered' }, { 'list': 'bullet' }],
                            ['link']
                        ]
                    }
                }
            }
        },
        components: {
            'quill': () => import(/* webpackChunkName: "/quill-editor" */ 'vue-quill-editor/src/editor')
        },
        methods: {
            clearEditor: function() {
                this.$emit('input', '');
            }
        }
    }

Адаптивный список в несколько столбцов?

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

VueJS: mutation-types и action-types?

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

Приложение на Vue с кастомизацией?

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

Приложение на Vue с кастомизацией?

Давайте скрины в вопрос. А сервер у вас один или образ под каждого клиента новый разворачивается?

Как заставить свойство вычисляться каждый раз при изменении полей?

p3trukh1n, я бы лучше взял какую-нить готовую реализацию датапикера для вью, ну или нужно обернуть qjuery picker во вью компонент и научиться получать из него при изменении.

Как заставить свойство вычисляться каждый раз при изменении полей?

p3trukh1n, смотрите, это же ваш пример, должно работать: https://codepen.io/kerf/pen/GaaGwQ Когда вы используете v-model происходит изменение объекта dates при изменении соответствующих полей и так как он реактивный и используется в шаблоне, то происходит ререндер шаблона и соответственно вызывается ваша функция getDifference.

Предать данные через props во vue.js?

BallooO0, просто открывайте гитхаб vuetify и изучайте исходники) Основная мысль в том, что вам по сути в каждом компоненте нужно знать какая тема сейчас используется, чтобы применить соответствующие стили. Делать через пропсы - придется в каждый компонент пробрасывать, что неудобно и багоопасно. Можно хранить текущую тему в vuex и в компоненте обращаться к ней как-то так: this.$store.state.themeName. Можно наследовать свои компоненты от какого-то базового, используя extend, и в базовом компоненте определить все что касается темы. Можно сделать плагин, который будет добавлять каждому экземпляру компонента поле ответственное за тему. Вариантов много.

Как получать актуальные данные с сервера в одном компоненте, если они меняются в другом?

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