🚀🚀
поэтому ес модули абузить смысла нет)
Size: a a a
2020 August 22
🚀🚀
makoven
А, кстати, идея! Подсовываешь симлинк типа ./auth_service.ts с нужной реализацией. Который указывает, например, на ../services/auth/jwt.ts
либо в init файле
import {authFx} from './authService'
import {jwtAuth} from './authImpl/jwt'
authFx.use(jwtAuth)🚀🚀
то есть одну и ту же задачу можно решить как с di, так и с другими подходами, поэтому вопрос тут не в том, похожа методика на di или нет)
🚀🚀
цель — установить связи (зависимости) между секциями приложения, изначально друг о друге не знающих
m
цель — установить связи (зависимости) между секциями приложения, изначально друг о друге не знающих
Так через декораторы и обертки над классами можно прокидывать целые сервисы, которые могут быть устрокны на порядки сложнее сущностей эффектора
🚀🚀
makoven
Так через декораторы и обертки над классами можно прокидывать целые сервисы, которые могут быть устрокны на порядки сложнее сущностей эффектора
как измерить порядки
🚀🚀
и почему передача зависимости в клиент это необходимое условие для сложных приложений. это случайно не причина?)
ЕГ
service dependency можно представить как какой-либо юнит эффектора, через который модуль получает информацию от подключённого к нему источника
То есть
В данном случае эвент, импортируемый, подключен к стору
$store.on(event, fn) это уже service dependency? В данном случае эвент, импортируемый, подключен к стору
m
как измерить порядки
Это возвращаясь к флейму объекты vs классы) Может быть один интерфейс, с пачкой функций и полей внутри. И много его реализаций, которые можно переключать по желанию
🚀🚀
То есть
В данном случае эвент, импортируемый, подключен к стору
$store.on(event, fn) это уже service dependency? В данном случае эвент, импортируемый, подключен к стору
$store зависит от event, да)
ЕГ
$store зависит от event, да)
Это уже больше одного способа у нас
1) как подключенный юнит
2) форк
3) на уровне файлов
Круто, не правда ли)
1) как подключенный юнит
2) форк
3) на уровне файлов
Круто, не правда ли)
🚀🚀
makoven
Это возвращаясь к флейму объекты vs классы) Может быть один интерфейс, с пачкой функций и полей внутри. И много его реализаций, которые можно переключать по желанию
как по твоему бы выглядел механизм, делающий то же самое, но без интерфейса?
m
и почему передача зависимости в клиент это необходимое условие для сложных приложений. это случайно не причина?)
Не знаю. Кому-то нравится. Для моего ума слишком сложно)
🚀🚀
Это уже больше одного способа у нас
1) как подключенный юнит
2) форк
3) на уровне файлов
Круто, не правда ли)
1) как подключенный юнит
2) форк
3) на уровне файлов
Круто, не правда ли)
если честно то не оч
ЕГ
если честно то не оч
Почему?
🚀🚀
ну это явление, которому необходимо объяснение
m
как по твоему бы выглядел механизм, делающий то же самое, но без интерфейса?
Никак. Классы для того и созданы. Ну или как в си. Структура, и в комплекте с ней пачка функций с префиксами)
🚀🚀
makoven
Никак. Классы для того и созданы. Ну или как в си. Структура, и в комплекте с ней пачка функций с префиксами)
но такой механизм существует
🚀🚀
я иначе бы не спрашивал)
m
я иначе бы не спрашивал)
Расскажи-расскажи