думаю логичнее если бы все можно было из параметров в тело конструктора перенести.

тут в апендиксе есть пример

думаю логичнее если бы все можно было из параметров в тело конструктора перенести.

это уже личные предпочтения каждого. я например за чистый di без контейнеров

Просто в сервис вынес методы для работы с бэком, через di передал Http. А как работать с этим сервисом без di вообще не могу понять.

Просто в сервис вынес методы для работы с бэком, через di передал Http. А как работать с этим сервисом без di вообще не могу понять.

вручную удовлетворять зависимости

@malborov сорри, но я что то не понял, как DI удовлетворяются вручную. В примере на странице это делается через метод injector.get но откуда его взять?

Удовлетворить зависимости можно: через di, через ioc контейнер

Через di: в конструкторе сервиса перечисляются зависимости и ангулар их удовлетворяет при создании сервиса

Если сервис создается вручную, то зависимости необходимо передать вручную

Через ioc контейнер (в данном случае injector ангулара): получить контейнер в конструкторе сервиса и запросить у него необходимые сервисы. В случае ангулара передать injector можно через di

@malborov сорри, но я что то не понял, как DI удовлетворяются вручную. В примере на странице это делается через метод injector.get но откуда его взять?

В примере injector получается через di

Спасибо, попробую что нибудь сделать

Пожалуйста

Добрый день, можно ли задать вопрос

Лол

Ночь ведь

Брад Грин бы расстроился )

У нас тут мат запрещен тоже?

Как правильно использовать внутри service(http.get) params.set(возможно append(?)) для массива вида localhost/test?array[0].parameter1="значение" & array[0].parameter2="значение" и тд.

есть компонент, который в своем шаблоне должен выводить своих наследников, задумка такая @Component({ selector: 'dt-filter', template: <div [ngSwitch]="column.filter"> <dt-filter-select *ngSwitchCase="'select'" [filters]="'filters'"></dt-filter-select> <!-- other components --> </div> }) export class DTFilter { @Input() filters: any; } @Component({ selector: 'dt-filter-select', template: 'this is select!' }) export class DTFilterSelect extends DTFilter { } // all other filter types ... @NgModule({ imports: [CommonModule], exports: [ DTFilter ], declarations: [ DTFilter, DTFilterSelect, /* other classes */] }) export class DTFilterModule { } но полифилы ругаются, что в фунции __extendsFn базовый класс undefined - что я делаю не так? или это в принципе невозможно сделать таким путем?

хмм, если классы запихнуть в один файл, то работает, странно

вопрос снят

немаленький такой вопрос

черт, @Input не наследуется

черт, @Input не наследуется

т.е.? в дочернем классе родительское поле без декоратора?

поля вообще нет, насколько я вижу

поля вообще нет, насколько я вижу

а если убрать декоратор, то есть?

поля вообще нет, насколько я вижу

https://medium.com/@ttemplier/angular2-decorators-and-class-inheritance-905921dbd1b7#.1arjzf1gu

тери про наследование декораторов

если коротко, то наследование не поддерживается, но это можно обойти

О поддержка инстант вью

Ага, классная штука

Как у себя это реализовать?

Никак

:(

Печально

Павел доки на след неделе обещал

точняк, видел же эту статью пару дней назад, дырявая голова

И снова вечер добрый. Я добавил ссылку на планкер, что бы может кто то сможет показать как правильно инжектить зависимости не через параметры конструктора? Совсем не выходит у меня. В вопросе написано в каком файле надо править если решитесь. https://toster.ru/q/375838

И снова вечер добрый. Я добавил ссылку на планкер, что бы может кто то сможет показать как правильно инжектить зависимости не через параметры конструктора? Совсем не выходит у меня. В вопросе написано в каком файле надо править если решитесь. https://toster.ru/q/375838

зачем наследовать компонент от сервиса?

+ brouserModule не надо импортить в каждом модуле, только в корневом. в остальных достаточно commonModule

просто писал быстро что бы пример накидать. Смысл рабочей задачи в том что на страницах есть много одинаковых задач, я решил их функционал отнаследовать от родительского класса, но споткнулся на том что все ломается на зависимостях типа Http в родительском классе

команда ангула проделала большую работу в плане di

А по поводу инжекта в теле конструктора? Пробовал через ReflectiveInjector не помогло

не вижу смысла этим di принебрегать

а пробовали инджектить сам сервис в конструкторе компонента? ангулар сам удовлетворит зависимости сервиса

За di им отдельное спасибо, но именно он и ломает красоту ООП. Зачем же его в JS тогда добавлять? Можно было бы и на прототипах то же самое сделать.

Как сделать автодополнение?

За di им отдельное спасибо, но именно он и ломает красоту ООП. Зачем же его в JS тогда добавлять? Можно было бы и на прототипах то же самое сделать.

Может нужно сначала почитать зачем вообще di?

За di им отдельное спасибо, но именно он и ломает красоту ООП. Зачем же его в JS тогда добавлять? Можно было бы и на прототипах то же самое сделать.

для меня как для бэкендщика появление di в js это огромный прорыв. использвоние прототипирования там где нужен di это ад

Да, я тоже не знаю как реализовать этот di руками. Но спасибо, поддержали как смогли)

За di им отдельное спасибо, но именно он и ломает красоту ООП. Зачем же его в JS тогда добавлять? Можно было бы и на прототипах то же самое сделать.

// и как сделать так что бы ничего передавать не надо было вообще? (Это важнее) Есть такой принцип - явное лучше неявного. Так вот, как раз конструктор di явный. Ты знаешь что можешь использовать в своем классе, поэтому тебе нужно повторить конструктор, а не использовать super()

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

Я вообще форкнул этот проект что бы написать на нем один файл и одну правку.

https://angular.io/docs/ts/latest/guide/dependency-injection.html по di для начала

Я вообще форкнул этот проект что бы написать на нем один файл и одну правку.

в планкере есть дефолтные проекты на ангуларе, не надо шлак форкать

в планкере есть дефолтные проекты на ангуларе, не надо шлак форкать

Можно ссылку

Ты, кстати, когда из отпуска выйдешь?

https://plnkr.co/edit/c65mTCZ1oYDGE1G0QMlM

Спасибо

возле new стрелочка и можно выбирать

Ты, кстати, когда из отпуска выйдешь?

в пн точно, но может и в пт появлюсь

https://angular.io/docs/ts/latest/guide/dependency-injection.html по di для начала

по di ангулара чуть подробнее от паскаля

http://blog.thoughtram.io/angular/2015/05/18/dependency-injection-in-angular-2.html

http://blog.thoughtram.io/angular/2015/05/18/dependency-injection-in-angular-2.html

По всем этм ссылкам уже прошелся. Спасибо.

У меня не верно работает только вот эта часть let injector = ReflectiveInjector.resolveAndCreate([ Router ]); this.router = injector.get(Router); Потому что я вынес ее в тело из параметров. Как это лечится не понятно

зачем переопределять injector?

зачем переопределять injector?

эм, переопределять? Ну потмоу что вызов в классе типа @Injector('router') Router; Результата не дал

я про let решил похоливарить...

лучше в другой раз

я про let решил похоливарить...

Это в pro.js группу это уже не Angular 2

@Ai_boy а ты не можешь подсказать как можно заинжектить зависимости не через параметры конструктора?

Зачем тебе это?

Что стандартными средствами мешает объявить?

@Ai_boy а ты не можешь подсказать как можно заинжектить зависимости не через параметры конструктора?

Если нужно заинджектить в ES5 стиле то делать это нужно так ng.core.Component({ selector: 'cmp' }). View({ template: '{{greeting}} world!' }). Class({ constructor: [Service, function(service) { this.greeting = service.greeting(); }] })

@Ai_boy а ты не можешь подсказать как можно заинжектить зависимости не через параметры конструктора?

Если для тестирования - то просто создаешь instance и передаешь в параметр new Component(new Service())

Родительский класс. В нем методы которые используются во всех страницах. От родителя наследуются классы для создания страниц. Все замечательно, только зависимость в di все портит. Router не прокатывает.

Если нужно заинджектить в ES5 стиле то делать это нужно так ng.core.Component({ selector: 'cmp' }). View({ template: '{{greeting}} world!' }). Class({ constructor: [Service, function(service) { this.greeting = service.greeting(); }] })

А в ts? что нибудь подобное есть? Уже писал let injector = ReflectiveInjector.resolveAndCreate([ Router ]); this.router = injector.get(Router); что нибдь типа этого

ТОлько вот это не работает

Родительский класс. В нем методы которые используются во всех страницах. От родителя наследуются классы для создания страниц. Все замечательно, только зависимость в di все портит. Router не прокатывает.

Ага - тоесть если правильно понял у тебя есть базовый класс где инжектится роутер и ты от него наследуешься и нужно передать этот Router

Ага - тоесть если правильно понял у тебя есть базовый класс где инжектится роутер и ты от него наследуешься и нужно передать этот Router

Да. Нужно в наследников передать методы этого класса, в ожном из них мы можем менять текущий путь. Просто хочелось бы что бы наследники без особой надобности не перезаписывали эти методы.

Да. Нужно в наследников передать методы этого класса, в ожном из них мы можем менять текущий путь. Просто хочелось бы что бы наследники без особой надобности не перезаписывали эти методы.

можешь пример проблемы накидать в plnkr? скинуть ссылку?

https://toster.ru/q/375838 Тут и описание и все. Править если что только в двух указанных файлах. Остальное было тупо форкнуто.

В классе наследнике напиши constructor(private _http: Http) { super(_http); }

Там в ответах тоже уже написали

Да, это работает) Видимо так и оставлю. Просто не хотелось везде таскать с собой зависимость в виде Router

Спасибо @Ai_boy

если коротко, то наследование не поддерживается, но это можно обойти

Увы нельзя - в том что способе что в статье написали - отваливаеться AOT шаблонов. На данный момент наследования декораторов нет. Никаких. Никак и на это не стоит базироваться.

Пока решения не придумали совет только 1 копипастить декораторы @Input, @Output, @Component и т.п.

Пока решения не придумали совет только 1 копипастить декораторы @Input, @Output, @Component и т.п.

Где то обсуждалось?

Где то обсуждалось?

Isssue есть и да. Обсуждалось

Чуть попозже найду и скинуть в чат