Как стать автором
Обновить

Комментарии 24

Отличная архитектура со статик сервисами.

Подход когда мы дёргаем метод чтобы получить значение поля как раз не является стандартным во вью из-за постоянных пересчётов. Всё же правильнее будет создать новый computed с уже посчитанными полями.

С классами внутри состояния компонента будут две проблемы: неожиданные потери реактивности, два источника правды (состояние компонента и состояние всех классов).

Если уж идти полностью по пути классов то фабрика тут кажется будет смотреться куда удачнее.

`this.users = await User.getList()`

Где getById сразу вернёт объекты UserModel.

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

С подобной архитектурой реализован не один проект, проблем с реактивностью и состоянием не наблюдалось. По сути, этот подход ничего не меняет в плане обработки и хранения данных, больше именно про удобство.
<user :user="user" />
и не надо никаких классов и конвертаций. В конце концов компоненты для того и существуют.

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

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

Какие именно проблемы с this вам встречались

Вы просто до конца реализуйте этот пример
static delete (collage) {
// ЛОГИКА УДАЛЕНИЯ КОЛЛАЖА
}
соединение имени происходит внутри компонента. Это сразу дает следующие приемущества в сравнении с вашим примером — не надо использовать дополнительный класс и мапить в него, в будущем изменения можно вносить централизованно (например добавить линк на пользователей или добавить иконку / стили).


Функционал получения ФИО может понадобиться не только при выводе пользователя на экран в конкретном виде (что и делает ваш вариант), но и в других компонентах и в 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) })
      })
  }
Про DRY можно поспорить, но это скорее всего бессмыслено.

Что касается примера. Оба this в данном случае указывают на класс сервиса (даже не на экземпляр). JS гибкий язык, можно конечно вызвать метод с контекстом компонента (чего не было в примере выше), но это еще то извращение. Хотя внедрять api и vuex еще бОльшее извращение (но тут на любителя извращений)

Думаю использование mixin-ов — наиболее близкий путь к вашей идее если судить по имплементации. Хотя саму идею сервисов можно реализовать иначе. А делать как вы не стоит — оно или не будет работать или это будет ужасный код.
Супер статья. Очень доступно объяснено что за что отвечает. Всегда интересуют паттерны, как можно по адекватному разделять код со стороны клиента, потому что зачастую вместо масштабируемого проекта получается просто каша. Вот только разделение сущностей, как мне кажется, требует серьезного опыта.
Автор текста не знает что ООП было уже более чем зрелой и вовсю использовавшейся парадигмой примерно лет за 30 до появления jQuery?
Имелось в виду не зарождение самого ООП, а его использование. По-настоящему и глубоко ООП и сейчас применяют нечасто, а в указанное время встречались проекты, где команды знали про ООП и даже использовали классы, но не с целью ООП, а как хранилища для тысяч строк кода.
По-настоящему, если человек не знает ООП, то использовать он его не сможет.
О сможет писать классы, наследование делать, даже какие-то паттерны осмысленно использовать, но это не обязательно будет ООП.
ООП это дофига делов, это как христианство — вроде уже почти 2000 лет существуют его идеи, но до сих пор большинство «христиан» его так и не поняли. Не поняли главную идею. У них мозги иначе устроены, они требуют от Боженьки всяких благ, как язычники, думают что он им обязан их предоставлять.
Есть одно важное принципиальное отличие ООП архитектуры от процедурного стиля.
В ООП не существует управляющего алгоритма, оно основано на возникающем поведении совокупности взаимодействующих объектов. То есть мы описываем поведение объектов, а они уже начинают передавать друг другу сообщения. И в целом система начинает работать, причем сложность работы такой системы может быть на порядки выше того что способен понять человеческий разум. Мы не программируем алгоритм системы, а инкапсулируем алгоритмы исключительно в объектах. Между собой же они общаются самостоятельно. Как-то так…
Разделение бизнес-логики и компонентов давным давно принято делать с помощью Vuex (или самописного стора на Vue 3).
Схема предельно простая — компонент на клик по кнопке (или на другое действие) дергает стор, стор дергает апишку (которая как раз и есть вынесенный отдельно «сервис»), стор исполняет всю бизнес логику и создает ошибку если что-то пошло не так, компонент ее если что ловит и показывает пользователю информацию о ней.
Модели же с помощью typescript живут как отдельные классы/интерфейсы и используются просто как обертки для типов.
А создание сервисов, фабрик и прочего — удел java бэкендеров, откуда это и пошло. Хватит придумывать архитектурные велосипеды, все уже придумано)

Да, но vuex, на мой взгляд, какой-то громоздкий.

Но возможно я просто избалован сервисами на ангуларе.

Думаю, для туду-листов архитектурные решения не особо важны, а для сколько-нибудь больших проектов без vuex уже почти никак, если не хотите плодить лапшу.

С ангуларом знаком очень посредственно, но на вью рекомендую использовать его всю экосистему :)

Ну а куда деваться?

Он конечно громоздкий, но хорошо работает

Отдельный плюс - крутой дебаггер через расширение:)

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

А я недавно узнал про Vue ORM и мне кажется он решает кучу проблем. Сам пока не щупал, но выглядит круто

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

Решение, конечно предложено тривиальное, но рабочее. Статические сервисы не самый плохой вариант:)

На языке который слабо предназначен для исполнения хоть чуть чуть более сложной логики, в интерпретаторе который не сильно то предназначен для исполнения серьезного объема кода вы пытаетесь писать код словно на с++, делфи или с#. Я не понимаю вам что мало тормозов в вебе? Эти бесконечно жрущие и тормозные поделки. Вот за что спасибо майнерам так это за то что сделали новое железо менее доступным, может хоть чуть чуть начнут оптимизировать по в отсутсвие новых игрушек.

В старые времена...

Лолшто? Вы видимо из параллельной вселенной, ибо в нашей всё то, что вы написали после этих слов -- полный бред. После фразы про ООП не смог дольше читать.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.