Как отрефакторить работу с ошибками?

Игорь,

this.$root.$emit("progress-dialog-show", "Подождите...")

А как можно понять что тут вызывается?
Откуда берется $root и $emit?

Как отрефакторить работу с ошибками?

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

Как отрефакторить работу с ошибками?

Игорь, благодарю вас за помощь) На php освоил чистый код, а вот Vue только начинаю. Ещё мало опыта и есть много вопросов) Так как привык на php следовать SOLID, то и тут это хочется использовать. Но пока не очень есть понимание как это все разносить. Компоненты более понятно было, а вот с обработкой ошибок затормозил. Но помогли) Попробую))

А по ответу зря) Мне помог ваш комментарий с пониманием. Про примеси тоже почитаю. Я так понимаю примеси это как трейт на php)

Как отрефакторить работу с ошибками?

Игорь, не плохое решение. А почему в ответы не пишите?)))

Как отрефакторить работу с ошибками?

Игорь, я сейчас использую формы так:

<b-form @submit.prevent="create">

            <b-form-group label="Название" label-for="createName">
              <b-form-input
                  id="createName"
                  type="text"
                  v-model="form.name"
                  aria-describedby="createNameError"
                  :state="errors.name ? false : null"
                  required>
              </b-form-input>
              <b-form-invalid-feedback id="createNameError">{{ errors.name }}</b-form-invalid-feedback>
            </b-form-group>

            <b-form-group label="Дата начала" label-for="createStartDate">
              <b-form-input
                  id="createStartDate"
                  type="date"
                  v-model="form.startDate"
                  aria-describedby="createStartDateError"
                  :state="errors.startDate ? false : null"
                  required>
              </b-form-input>
              <b-form-invalid-feedback id="createStartDateError">{{ errors.startDate  }}</b-form-invalid-feedback>
            </b-form-group>

            <b-form-group label="Дата окончаиня" label-for="createEndDate">
              <b-form-input
                  id="createEndDate"
                  type="date"
                  v-model="form.endDate"
                  aria-describedby="createEndDateError"
                  :state="errors.endDate ? false : null"
                  required>
              </b-form-input>
              <b-form-invalid-feedback id="createEndDateError">{{ errors.endDate  }}</b-form-invalid-feedback>
            </b-form-group>

            <b-button type="submit" variant="primary">Добавить</b-button>

          </b-form>

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

Как отрефакторить работу с ошибками?

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

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

Вот как раз этим же занимаюсь. Авторизацией)

А как вы рефакторите формы? Создаете свой компонент форм?

Как организовать архитектуру мероприятий?

Евгений Ромашкан, понял)

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

АХхах)

Как организовать архитектуру мероприятий?

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

Теперь понял, что монолит пока что не плохо. Согласен с этим. Буду просто разбивать по папкам. src/Usersrc/Event Либо так:

Event // Модуль-сервис мероприятий
            Entity сущности
                Disciplines //Дисциплины
                Events // мероприятия
                    Event
                    Registrations //регистрации
                        Competition//на соревнования
                        Battle//на батлы
                Geo /гео
                Organizations /организации
                Persons /персоны

У меня возникает такая ситуация. Как отделить регистрацию от мероприятия? Пока что она принимает объект Event. Использовать интерфейс EventInterface и его реализовать? Пока не могу сообразить как это можно сделать всё слабо связанным. Чтобы заменить или если будет интересно другим - подключаем эту библиотеку другим.

Сквозной функционал между сервисами это плохо т.к. плодит зависимости и влечёт каскадные изменения после каждой правки. Делаете сервисы так чтобы им не было важно, Teacher там, Member или Artist.

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

p.s. Хотите использовать что-то крутое и сделать ваш проект лучше и качественнее - пишите unit-тесты.

КОнечно! Без Unit тестов не начну) Функциональные делаю меньше, а юниты на старте 60-70% покрытия.

Правильно ли сделана связь?

Евгений Ромашкан, понял) спасибо)

Правильно ли сделана связь?

Евгений Ромашкан, я просто не знаю как лучше сделать именно связь. Упрощённо:

Dicsipline 
- id
- name

Event
- id
- name

EventDisipline
- id --> discipline_id
- event --> event_id

Registration 
id 
discipline_id --> event_disipline_id

Или

Dicsipline 
- id
- name

Event
- id
- name

EventDisipline
- id
- discipline_id --> discipline_id
- event --> event_id

Registration 
id 
discipline_id --> event_disipline_dicipline_id

Как хранить настройки регистрации?

Игорь,
1. а если таких полей будет много? У нас сущность будет большая...
2. Когда привязывать к пользователю настройки? Во время создания?

Как хранить настройки регистрации?

То что нужно) Давно использую ORM, а именно доктрину. Использую на Symfony. Тут вопрос больше не про то, как это сохранить, а про архитектуру. Можете показать что у вас в new Setting(); и new SubSettings()?

Как хранить настройки регистрации?

Шохрух Шаймардонов, благодарю за ответ по делу. Вот я и сам не знаю что лучше выбрать. Сейчас использую mysql. Планирую перейти на postgresql. nosql не рассматривал. Возможно имеет смысл и использовать что-то из этого. Ранее не приходилось решать подобные задачи, поэтому с вопросом пришёл на тостер. Всегда удавалось решать пару полями в базе данных, но тут хотелось бы гибкости и настроек будет больше чем два.

Можете подсказать где лучше почитать про эту тематику? Возможно где-то разбирают плюсы минусы разных вариантов. С удовольствием изучил бы подобную тематику.

Как хранить настройки регистрации?

Daria Motorina, поддерживаю. Тостер превращается в юморной сервис.

Как хранить настройки регистрации?

Artem Ivanov, Gip почему нужно обязательно высмеивать и почему это на тостере так ценится? Понимаю, что хранить в базе данных. Что хранить нужно в таблицах. Вопрос не об этом. Вопрос об архитектуре этих таблиц. Какие они должны быть?

Я так понимаю это должно выглядеть примерно так:

competition //таблица соревнований
competition_settings // таблица настроек
  - competition_id
  - reg_start
  - reg_end
 .... etc

Или же

competition //таблица соревнований
competition_settings// таблица настроек
-id
- name
- default
competition_setting_assignments // таблица настроек соревнований
  - competition_id
  - setting_id

Или вообще в json

competition //таблица соревнований
- id
- settings (json)

Как хранить настройки регистрации?

Это понятно. А в каком виде?

Правильно ли сделана связь?

Евгений Ромашкан, подскажите?

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

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

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

Правильно ли сделана связь?

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

А что именно там не так?

Ну, во первых - почему константы торчат наружу(public)?

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

А во вторых, что такое Event Discipline из вашего кода ну никак не ясно, как не ясно....

Event Discipline - это связующая таблица дисциплин с мероприятием. У каждого мероприятия может много дисциплин.
Дисциплины мероприятия имеют настройки:
1. Цены: стоимость участия, валюта, калькулятор
2. Статус (открыта, закрыта) и т.д.

В регистрации человек выбирает дисциплину мероприятия и по этой дисциплине рассчитывается цена из Event Dance. А название подтягивается из Dicipline

.. почему эту инфу не поместить в агрегат Discipline

Потому что Discipline это справочник названий, правил. А Event Discipline это дисциплина конкретного мероприятия со своими настройками:
1. Цены: стоимость участия, валюта, калькулятор
2. Статус (открыта, закрыта) и т.д.

Вот)) Если понятно что сказал....