Vue.js и слоистая архитектура: вынесение бизнес-логики в сервисы

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

Функционал получения ФИО может понадобиться не только при выводе пользователя на экран в конкретном виде (что и делает ваш вариант), но и в других компонентах и в JavaScript-коде. При этом в вашем случае придется дублировать функционал получения ФИО. Если же использовать предложенную архитектуру, то и в шаблонах и в JavaScript-коде всегда будет объект пользователя со всем необходимым функционалом.

Если пользователь выводится одинаково более чем в одном месте, то надо создавать такой <user :user=«user» /> чтобы соблюсти правило DRY. Но в самом компоненте все равно надо брать ФИО из центрального источника (та же модель пользователя), чтобы это можно было использовать повсеместно, а не только в этом компоненте.

Вы просто до конца реализуйте этот пример
static delete (collage) {
// ЛОГИКА УДАЛЕНИЯ КОЛЛАЖА
}

Как вариант:

static delete (collage) {
    this.api.deleteCollage(collage)
      .then(() => {
        this.vuex.dispatch('common/setCollages', { items: collages.items.filter(userCollage => userCollage.id !== collage.id) })
      })
  }

Vue.js и слоистая архитектура: вынесение бизнес-логики в сервисы

Спасибо)

Vue.js и слоистая архитектура: вынесение бизнес-логики в сервисы

Состояние/стор/хранилище создано для хранения данных, а не кода — во втором случае его использование выглядит не очень оправданным. Логических сущностей, которым не нужно хранение данных в состоянии, может быть много. Тогда состояние будет просто хранить код без операций с данными состояния?

Vue.js и слоистая архитектура: вынесение бизнес-логики в сервисы

Не совсем понятно, чем <user :user=«user» /> отличается от предложенного решения. Переменная user может быть и простым объектом и объектом класса при передаче в компонент.
Какие именно проблемы с this вам встречались и каком «оригинале» речь? Статический класс аналогичен файлу, возвращающему функции. this в нем используется для работы со статическими же свойствами и методами.

Vue.js и слоистая архитектура: вынесение бизнес-логики в сервисы

В статье лишь описан пример, и для формирования ФИО чаще используется computed, да, но это не меняет идеи вынесения функционала в сущность, а не разделения по компонентам.

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

Vue.js и слоистая архитектура: вынесение бизнес-логики в сервисы

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

Как мы использовали GraphQL в разработке на примере интернет-каталога

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

Как мы использовали GraphQL в разработке на примере интернет-каталога

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

Как мы использовали GraphQL в разработке на примере интернет-каталога

Добрый день! Первоначальная скорость обработки запросов нас тоже не устраивала, поэтому мы постарались их ускорить. Указанный параметр 2 секунды — это максимальное время (на практике, как правило, все быстрее). Технологии в этом проекте были выбраны владельцем продукта.