IK
а какие есть замены inversifyJS ( IoC/DI) без декораторов?
Инверсифай можно и без декораторов :)
Size: a a a
2020 September 13
V
ммм?
V
как
inject?V
Инверсифай можно и без декораторов :)
я понимаю что декоратор это обертка, но с inject не получилось
DB
Я ещё добавлю пять копеек. Мне кажется что js комьюнити слишком привязалось к декораторам для реализации DI когда это прям совсем не обязательно. Я вот для души ковырял asp.net.core 3 так там внедрение зависимостей реализовано просто и понятно без дополнительного «мета слоя» как выразился Илья.
Так это я к чему - можно учиться у более «взрослых» систем где это уже прошли. Но js миру свойственно продолжать идти по граблям
Так это я к чему - можно учиться у более «взрослых» систем где это уже прошли. Но js миру свойственно продолжать идти по граблям
IK
я понимаю что декоратор это обертка, но с inject не получилось
я давно не тыкал, но пару лет назад работало, сейчас не подскажу
Б
Я ещё добавлю пять копеек. Мне кажется что js комьюнити слишком привязалось к декораторам для реализации DI когда это прям совсем не обязательно. Я вот для души ковырял asp.net.core 3 так там внедрение зависимостей реализовано просто и понятно без дополнительного «мета слоя» как выразился Илья.
Так это я к чему - можно учиться у более «взрослых» систем где это уже прошли. Но js миру свойственно продолжать идти по граблям
Так это я к чему - можно учиться у более «взрослых» систем где это уже прошли. Но js миру свойственно продолжать идти по граблям
И я вот не понимаю зачем нужен этот синтаксис декораторов и почему бы не юзать простую композицию функций. Вот возьмем первый пример на nestjs
вот что мешало записать это без декораторов
просто используя hight order functions ?
import { Controller, Get } from '@nestjs/common';
@Controller('cats')
export class CatsController {
@Get()
findAll(): string {
return 'This action returns all cats';
}
}вот что мешало записать это без декораторов
import { Controller, Get } from '@nestjs/common';
export const CatsController = Controller('cats', class {
findAll = Get(()=>{
return 'This action returns all cats';
})
})просто используя hight order functions ?
DB
И я вот не понимаю зачем нужен этот синтаксис декораторов и почему бы не юзать простую композицию функций. Вот возьмем первый пример на nestjs
вот что мешало записать это без декораторов
просто используя hight order functions ?
import { Controller, Get } from '@nestjs/common';
@Controller('cats')
export class CatsController {
@Get()
findAll(): string {
return 'This action returns all cats';
}
}вот что мешало записать это без декораторов
import { Controller, Get } from '@nestjs/common';
export const CatsController = Controller('cats', class {
findAll = Get(()=>{
return 'This action returns all cats';
})
})просто используя hight order functions ?
А если заменить на hof пример в котором по крайней мере 3-4 декоратора над методом? Будет похоже на callback hell
IK
А если заменить на hof пример в котором по крайней мере 3-4 декоратора над методом? Будет похоже на callback hell
в лиспах все в скобках, и все живы )
IK
И я вот не понимаю зачем нужен этот синтаксис декораторов и почему бы не юзать простую композицию функций. Вот возьмем первый пример на nestjs
вот что мешало записать это без декораторов
просто используя hight order functions ?
import { Controller, Get } from '@nestjs/common';
@Controller('cats')
export class CatsController {
@Get()
findAll(): string {
return 'This action returns all cats';
}
}вот что мешало записать это без декораторов
import { Controller, Get } from '@nestjs/common';
export const CatsController = Controller('cats', class {
findAll = Get(()=>{
return 'This action returns all cats';
})
})просто используя hight order functions ?
тут основная проблема с тем что декораторы на самом деле это штука двойного назначения
IK
@Get()
findAll(): string {
return 'This action returns all cats';
}
не равноценно
findAll = Get(()=>{
return 'This action returns all cats';
})IK
потому что первое выполнит декоратор один раз, а второе будет создавать каждый раз новый инстанс
IK
ну и в принципе findAll хотелось бы в прототипе по очевидным причинам
IK
Тут скорее нужен аналог функции decorate из mobx
IK
Другими словами мы используем декораторы как способ изменения поведения сущностей так и (как в несте) как способ прикрепить метаданные
Б
Другими словами мы используем декораторы как способ изменения поведения сущностей так и (как в несте) как способ прикрепить метаданные
Ну будет происходить прикрепление метаданных при создание нового инстанса класса каждый раз. Разве есть какие-то фундаментальные недостатки которые с этим связаны и нужно обязательно через декораторы?
IK
Ну будет происходить прикрепление метаданных при создание нового инстанса класса каждый раз. Разве есть какие-то фундаментальные недостатки которые с этим связаны и нужно обязательно через декораторы?
Фундаментальный недостаток в том что мы по сути своей просто чтобы добавить информацию к полю вставляем какой-то ещё вызов функции и по сути поле перестает быть членом класса
AЬ
И я вот не понимаю зачем нужен этот синтаксис декораторов и почему бы не юзать простую композицию функций. Вот возьмем первый пример на nestjs
вот что мешало записать это без декораторов
просто используя hight order functions ?
import { Controller, Get } from '@nestjs/common';
@Controller('cats')
export class CatsController {
@Get()
findAll(): string {
return 'This action returns all cats';
}
}вот что мешало записать это без декораторов
import { Controller, Get } from '@nestjs/common';
export const CatsController = Controller('cats', class {
findAll = Get(()=>{
return 'This action returns all cats';
})
})просто используя hight order functions ?
Порт из джавы и спринга. Нест и ангуляр очень много идей оттуда заимствуют
AЬ
Там это прижилось, считается неплохой практикой декларативного программирования и несут в жс, потому что хотят в том же стиле, с ипользованияем уже знакомых идей на жс также писать.
Ну это скорее почему в ангуляр проникли.
А нест создавался частично под ангулярщиков
Ну это скорее почему в ангуляр проникли.
А нест создавался частично под ангулярщиков