kk
I
Фактически кода даже больше становится, используешь декораторы ради иллюзии di, а потом еще сам засовываешь зависимости в модули
Это иллюзия первого дня. По мере нарастания функционала кода почти не становится больше.
Size: a a a
2021 January 28
kk
И DI тут именно в инъекциях разного разряда, как в C#. Все сервис имеют разный цикл жизни, инектируются они имопортами только потому что в js/ts нет нормальной системы namespace
I
Это иллюзия первого дня. По мере нарастания функционала кода почти не становится больше.
Так ты можешь просто контейнер использовать вместо этих нагромождений нестовских и точнл также передавать зависимости и кода будет меньше просто потому что не будешь использовать синтаксис с декораторами
kk
То есть от такого DI всё равно больше пользы чем от простого import, export
kk
I
Так ты можешь просто контейнер использовать вместо этих нагромождений нестовских и точнл также передавать зависимости и кода будет меньше просто потому что не будешь использовать синтаксис с декораторами
Это не столь удобно и наглядно.
I
И DI тут именно в инъекциях разного разряда, как в C#. Все сервис имеют разный цикл жизни, инектируются они имопортами только потому что в js/ts нет нормальной системы namespace
Ну ок, вот про жизненный цикл это первый более менее аргумент, действительно потенциально полезная штука при определённом подходе
DD
Ребята собрались и сделали платформу из лучших практик. Решили некоторые архитектурные вопросы. Вот и весь нест
kk
I
Ну ок, вот про жизненный цикл это первый более менее аргумент, действительно потенциально полезная штука при определённом подходе
Ты не писал на C#?
I
Ты не писал на C#?
Нет, только спринг
kk
Тогда понятно.
ДМ
I
Вот тут рассказывают про di который фактически есть, но это же не правда. Ты с нестом точно так же будешь все импортировать, буквально ручками отправлять зависимости куда надо, кода меньше не становится, нет инжектинга как в спринге напимер, так какой смысл то тогда рассказывать про di
подожди, да ты импортируешь сущность, но ты можешь сделать так:
{ provide: OneEntity, useClass: AnotherEntity } - и подменять их по условию, например для прода один логер, для дево другой. Без di тебе бы пришлось везде менять импорты, а тут нет
{ provide: OneEntity, useClass: AnotherEntity } - и подменять их по условию, например для прода один логер, для дево другой. Без di тебе бы пришлось везде менять импорты, а тут нет
ДМ
ну как один из примеров расширяемости
I
Это не столь удобно и наглядно.
Это спорные преимущества
kk
I
Это спорные преимущества
Чем больше людей, тем важнее наглядность.
I
Чем больше людей, тем важнее наглядность.
Так это решается договоренностями, а не фреймворками
D
Мне кажется, или тут сравнивают импорты и DI? Хм...
🏡K
I
Фактически кода даже больше становится, используешь декораторы ради иллюзии di, а потом еще сам засовываешь зависимости в модули
Тут мало кто декомпозирует сильно, в основном монолиты пилят, и если смотреть как на монолит, то да может нест и не нужен, так как все его абстракции можно сделать с нуля за неделю, просто Камиль это уже сделал и почему бы не юзать его, чем городить в каждой конторе свой нест, проще взять готовое и людей проще обучать и искать, когда есть архитектура уже можно тратить время на декомпозипование и тестирование, двигаться в сторону лаконичного и надёжного кода, а твой самописный нест ты всю жизнь будешь улучшать, с нестом мы просто снимаем этот головняк со своих плеч
kk
Тут то как раз фреймворк своими рельсами ставит жёсткие условия, а не просто предоставляет набор функциональности как coffer
I
Окей, я хочу потом продолжить этот разговор, но сейчас мне надо ливнуть
I
I
Я просто еще раз хочу подчеркнуть что у меня реальные вопросы, я ничего не вбрасываю, не тролю и нормально хочу подискутировать и понять заблуждаюсь я или же мои претензии обоснованы
Еще раз напоминаю