AM
Size: a a a
2018 February 02
AV
Сегодня пытался что-то подобное задвинуть когда терли про IoC в ванила JS - http://plnkr.co/edit/dWb1zFfZyHcPwZs22k3L
AV
Кто что думает по поводу такой реализации/использования? тут ключевой момент в том, что в качестве ключа при регистрации зависимостей мы используем не строку, а *абстрактный* (привет из плюсов) ES6 класс, который на самом деле в JS является construction function
AV
Еще удобно, что находясь в классе App видно все его зависимости, правда конфигурируется через класс-декоратор ( @Injectable([ILogger]) ) ну и хрен с ним. За то это позволяет явно видеть интерфейсы зависимостей. Ну и в IDE удобно делать ‘Go to definition’ и проваливаться прямо в файл с интерфейсом
AV
плюс в IDE есть человеческий рефакторинг названий у зависимостей
AV
Минусы какие видите?
AV
как вариант минуc: лишний прототип в цепочке прототипов
AV
еще минус, но я пока не понял нужно ли это в IoC: реализация не может реализовать несколько интерфейсов, так как интерфейс это ES6 класс.
ЕЩ
еще минус, но я пока не понял нужно ли это в IoC: реализация не может реализовать несколько интерфейсов, так как интерфейс это ES6 класс.
У тебя все равно инжектиться какой-то объект, никакого комплишена у тебя не будет без javadoc, а если так, то какая разница на строчках это или на ссылках?
AV
нормального комплишина не будет, но пара плюсов в этом есть, описал выше
AV
Надо в фюность выложить, там точно засрут
AM
AV
написал щас засрут
NM
Минусы какие видите?
Неплохо, но с вариантом строк мы делаем так
ioc.get('config')
и нам не нужно делать require типа, например в policy, где параметрами конструктора являются (req, res, next), таким образом меньше за собой нужно тащить, если ты захочешь ее тестировать.
ioc.get('config')
и нам не нужно делать require типа, например в policy, где параметрами конструктора являются (req, res, next), таким образом меньше за собой нужно тащить, если ты захочешь ее тестировать.
AV
Неплохо, но с вариантом строк мы делаем так
ioc.get('config')
и нам не нужно делать require типа, например в policy, где параметрами конструктора являются (req, res, next), таким образом меньше за собой нужно тащить, если ты захочешь ее тестировать.
ioc.get('config')
и нам не нужно делать require типа, например в policy, где параметрами конструктора являются (req, res, next), таким образом меньше за собой нужно тащить, если ты захочешь ее тестировать.
Спасибо, в моем случае вместо строки нужно было бы добавить импорт с абстрастным классом Config: ioc.get(Config)
ЕЩ
>
опять же зачем? тебе нужно сделать противоествественные для JS вещи, а именно описать интерфейс и его реализовать, но на самом деле в JS тебе от этого интерфейса ни жарко ни холодно, потому что нет строгой системы типов которая обяжет тебя следовать правилам типизации. Т.е. ты проделаешь лишнюю работу выделяя абстракции — а вопрос только один — зачем?
Config: ioc.get(Config): опять же зачем? тебе нужно сделать противоествественные для JS вещи, а именно описать интерфейс и его реализовать, но на самом деле в JS тебе от этого интерфейса ни жарко ни холодно, потому что нет строгой системы типов которая обяжет тебя следовать правилам типизации. Т.е. ты проделаешь лишнюю работу выделяя абстракции — а вопрос только один — зачем?
ЕЩ
Процитирую слова моего бывшего коллеги:
Усложнять — легко, упрощать — сложноЕЩ
Если тебе нужна строгая типизация — ты выбрал не тот инструмент. Гвозди можно и микроскопом забивать, но нужно ли это?!
VI
Процитирую слова моего бывшего коллеги:
Усложнять — легко, упрощать — сложно👍
AV
>
опять же зачем? тебе нужно сделать противоествественные для JS вещи, а именно описать интерфейс и его реализовать, но на самом деле в JS тебе от этого интерфейса ни жарко ни холодно, потому что нет строгой системы типов которая обяжет тебя следовать правилам типизации. Т.е. ты проделаешь лишнюю работу выделяя абстракции — а вопрос только один — зачем?
Config: ioc.get(Config): опять же зачем? тебе нужно сделать противоествественные для JS вещи, а именно описать интерфейс и его реализовать, но на самом деле в JS тебе от этого интерфейса ни жарко ни холодно, потому что нет строгой системы типов которая обяжет тебя следовать правилам типизации. Т.е. ты проделаешь лишнюю работу выделяя абстракции — а вопрос только один — зачем?
Почему тогда TS так популярен?
Это пример использования IoC на ванильном JS. Но вот если добавить сюда Flow, то заживём...
У Flow есть строгая система типов
Это пример использования IoC на ванильном JS. Но вот если добавить сюда Flow, то заживём...
У Flow есть строгая система типов