Комментарии 25
Отличная архитектура со статик сервисами.
Подход когда мы дёргаем метод чтобы получить значение поля как раз не является стандартным во вью из-за постоянных пересчётов. Всё же правильнее будет создать новый computed с уже посчитанными полями.
С классами внутри состояния компонента будут две проблемы: неожиданные потери реактивности, два источника правды (состояние компонента и состояние всех классов).
Если уж идти полностью по пути классов то фабрика тут кажется будет смотреться куда удачнее.
`this.users = await User.getList()`
Где getById сразу вернёт объекты UserModel.
С подобной архитектурой реализован не один проект, проблем с реактивностью и состоянием не наблюдалось. По сути, этот подход ничего не меняет в плане обработки и хранения данных, больше именно про удобство.
<user :user="user" />и не надо никаких классов и конвертаций. В конце концов компоненты для того и существуют.
ну и в глаза бросились статичные методы сервиса (а как же this из оригинала, что с ним делать). И getList который так то вернет promise и все сломается. Ну да еще мапить лучше без мутаций, ну да ладно, это мелочи
Какие именно проблемы с 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) })
})
}
Что касается примера. Оба this в данном случае указывают на класс сервиса (даже не на экземпляр). JS гибкий язык, можно конечно вызвать метод с контекстом компонента (чего не было в примере выше), но это еще то извращение. Хотя внедрять api и vuex еще бОльшее извращение (но тут на любителя извращений)
Думаю использование mixin-ов — наиболее близкий путь к вашей идее если судить по имплементации. Хотя саму идею сервисов можно реализовать иначе. А делать как вы не стоит — оно или не будет работать или это будет ужасный код.
Вроде речь шла про разделение бизнес логики и фреймворков, и тут же появляется vuex в статическом методе, который ничего не должен знать про используемый фреймворк )
О сможет писать классы, наследование делать, даже какие-то паттерны осмысленно использовать, но это не обязательно будет ООП.
ООП это дофига делов, это как христианство — вроде уже почти 2000 лет существуют его идеи, но до сих пор большинство «христиан» его так и не поняли. Не поняли главную идею. У них мозги иначе устроены, они требуют от Боженьки всяких благ, как язычники, думают что он им обязан их предоставлять.
Есть одно важное принципиальное отличие ООП архитектуры от процедурного стиля.
В ООП не существует управляющего алгоритма, оно основано на возникающем поведении совокупности взаимодействующих объектов. То есть мы описываем поведение объектов, а они уже начинают передавать друг другу сообщения. И в целом система начинает работать, причем сложность работы такой системы может быть на порядки выше того что способен понять человеческий разум. Мы не программируем алгоритм системы, а инкапсулируем алгоритмы исключительно в объектах. Между собой же они общаются самостоятельно. Как-то так…
Схема предельно простая — компонент на клик по кнопке (или на другое действие) дергает стор, стор дергает апишку (которая как раз и есть вынесенный отдельно «сервис»), стор исполняет всю бизнес логику и создает ошибку если что-то пошло не так, компонент ее если что ловит и показывает пользователю информацию о ней.
Модели же с помощью typescript живут как отдельные классы/интерфейсы и используются просто как обертки для типов.
А создание сервисов, фабрик и прочего — удел java бэкендеров, откуда это и пошло. Хватит придумывать архитектурные велосипеды, все уже придумано)
Да, но vuex, на мой взгляд, какой-то громоздкий.
Но возможно я просто избалован сервисами на ангуларе.
А я недавно узнал про Vue ORM и мне кажется он решает кучу проблем. Сам пока не щупал, но выглядит круто
Решение, конечно предложено тривиальное, но рабочее. Статические сервисы не самый плохой вариант:)
На языке который слабо предназначен для исполнения хоть чуть чуть более сложной логики, в интерпретаторе который не сильно то предназначен для исполнения серьезного объема кода вы пытаетесь писать код словно на с++, делфи или с#. Я не понимаю вам что мало тормозов в вебе? Эти бесконечно жрущие и тормозные поделки. Вот за что спасибо майнерам так это за то что сделали новое железо менее доступным, может хоть чуть чуть начнут оптимизировать по в отсутсвие новых игрушек.
В старые времена...
Лолшто? Вы видимо из параллельной вселенной, ибо в нашей всё то, что вы написали после этих слов -- полный бред. После фразы про ООП не смог дольше читать.
Vue.js и слоистая архитектура: вынесение бизнес-логики в сервисы