Задумался над таким вопросом, принято ли на фронте (том же

Vue) применять паттерны проектирования/архитектуры из бэкенда? например налепить чистую/onion архитектуру на Vue приложение? Или же по сути Vuex+компонентный подход тот же диктует структуру приложения и ее архитектуру?

как по мне, все это довольно плохо ложится на фронт и на ФП в целом, но есть люди, которые очень усердно пытаются это перенести сюда с бэкенда но в целом, все уже давно придумано и вовсю используется - vuex и компонентный подход, как ты и сказал

Смотря какие. Нет просто "паттернов бека". Какие-то паттерны не применимы не потому что "фронт", а потому что JS с динамической типизацией, или потому что не ООП. В том же ангуларе отлично применяют и DI с IoC контейнером, и фабрики, и декораторы. Кто-то монады использует на фронте. На слои приложение также делится в идеале, и не считается нормой писать http запрос в методе компонента, смешивать слои

Хмм, good point

Однако же js - тоже не главная причина, вот на ноде бэкенды пишут, и серьезные Насчет слоев, тот факт что мы пишем все у vue компонентах, не означет что мы смешиваем слой презентации, домена и т.д.?

означает, если мы действительно ВСЕ пишем в компонентах

например патерн фабрика чем плох на фронте

Что здесь все и что не нужно писать в компонентах?) Кроме явных операций со стейтом, которые в vuex идут

А вот чисто спортивный интерес, какой кейс в котором нужна фабрика? Инстанс какого обьекта вам нужен?

инстанс object, для создания которого нужно много зависимостей

На ноде тоже не применяют "все паттерны" и принципы, которые встречаются в статически типизированных и ООП языках

если писать "взрослые" бэкенды, то мне кажется что это не для ноды

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

Про эту тему в соседних чатах уже немало крови пролито, думаю это выходит за рамки vue)

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

Mr. N

какое это отношение имеет к фронту?)

Mr. N

Это синтетический пример, можете назвать классы так чтобы они отображали реальный кейс? Плюс мы говорим о вью, который в data не всегда хорошо хранит инстансы классов (не обычные обьекты)

вью 3 кажется уже хорошо хранит, ибо через рефлекты работает

хранит, только смысл использовать классы от этого не появился

нельзя сказать что какой то поттерн плох на фронте, нужно задаться вопросом какую проблему решают паттерны, этой проблемы может и не быть на фронте или ее решают другими способами. Взять к примеру распространенный DI, зачем его юзают в php допустим. У тебя может быть класс который использует сторонний модуль, отсылающий http запросы. А как его протестировать? Нам же нельзя отсылать запросы в тестах и тд. Нужно его замокать, что сложно сделать если этот сторонний модуль жестко связанн с твоим классом, ты используешь DI через конструктор. А как мы решаем это проблему в js? Используем прототипную модель js и просто делаем манки патчинг

Однако же, явное прокидывание зависимостей лучше и проще в чтении чем потециальные танцы с прототипами и прочими аспектами самого js

Ну решается ето з помощью интерфейсов

В typescript есть интерфейсы

что делать микродозерам , кто TS не пользует ?

Что

использование интерфейсов не обязывает использовать DI, ты и с ними можешь жестко связать модуль, напихав this.logger = new Logger() прямо в классе