Ну вот я бы никому не советовал так делать )

Ну да, обычно всё же юзают в AppComponent, но человеку не нравится яркий пример, описанный в angular2-webpack-starter

ну я как вижу, чаще юзают сервисы

алексей придет и точно посоветует сервисы)

Ну да, обычно всё же юзают в AppComponent, но человеку не нравится яркий пример, описанный в angular2-webpack-starter

Он вообще задает правильный вопрос. Поскольку ответ зависит от архитектуры приложения. Я советую такие данные и работу с ними выносить в отдельный сервис - если это умные компоненты. А если это глупые у нас - просто рендер - тогда да - родительский компонент. Есть еще истекающий и 1го - это общий стор и ngrx например

При прямой передаче (шаринге) данных сложность может очень быстро вырастать. И тогда начинается хелл из input-output. Но опять же - все зависит от самой архитектуры приложения.

Да, ты прав

а бота вроде завели сюда

а бота вроде завели сюда

Ты про FAQ-бота?

алексей придет и точно посоветует сервисы)

Вообще нет :) Если что-то более или менее серьезное то лучше Redux, Mobx. Сервисы прямая дорога в ад

Вообще нет :) Если что-то более или менее серьезное то лучше Redux, Mobx. Сервисы прямая дорога в ад

Снова я мимо)

Вообще нет :) Если что-то более или менее серьезное то лучше Redux, Mobx. Сервисы прямая дорога в ад

Для редакс-приложений есть свой персональный ад

Ну и сразу использовать такие принципы без нужды - прямая к нему дорога

это обычный паттерн... God Object

это обычный паттерн... God Object

И да, это обычный сервис в angular2

И да, это обычный сервис в angular2

Никто не мешает разделять

Господа, есть вопрос по rxjs в связке c ts

кто сможет помочь?

кто сможет помочь?

Можно тут, можно @typescript_ru - если по типам порос

Есть еще @frp_ru - если что-то серъезное по части rx

А что нормальной документации по материал2 нету ? Или я не там смотрю

С примерами

А что нормальной документации по материал2 нету ? Или я не там смотрю

Он еще в альфе, там не до документации

Он еще в альфе, там не до документации

Опередил ?

И ещё хз сколько будет в альфе болтаться.

Фреймворк от гугл, нормального материал дизайна нет

Класс

Не материалом ангуляр красен.

Класс

Посмотри когда он появился для первого, нормальный.

О, только вчера для себя этот подкаст открыл

А ты где? Не вижу тебя в Di

ребят, есть 1 вопрос по паблишингу модуля для ng2. собираю написанный модуль тайпскриптовым компилером в target- es5. заливаю в npm - все ок. можно юзать в других проектах. в одном из компонентов модуля нужно добавить стили. инлайново писать не хочется, делаю scss-ку. теперь уже простеший компайл tsc-й не подходит. вебпаком собирать не хочу, ибо если у модуля есть зависимости от CommonModul-я ангуларовского, вебпак раскручивает это дело в толстый бандл. собственно вопрос: что делать со стилями и как это удобно варить. только инлайн? ии вообще какие здесь могут быть подходы. есть вариант при билде scss-ку собрать в css и в npm и сss-ку залить с билдом от tsc. но выходит как-то криво

https://www.npmjs.com/package/webpack-node-externals ответ наверное нашел. вопрос оставлю. мб кому-нибудь пригодится

подскажет кто рабочий скроллбар?

или может кто объяснит, по туторилу всю ставлю, но в некоторых вылетает ошибка

или может кто объяснит, по туторилу всю ставлю, но в некоторых вылетает ошибка

Скинь ссылку на туториал

https://github.com/jkuri/ng2-slimscroll

https://github.com/jkuri/ng2-slimscroll

Вечером посмотрю. Отпишусь. Пока кто-то может посмотрит.

хорошо, спасибо

Ребят, а подкиньте, плиз, какой-нибудь воркшоп или статью или что-нибудь еще где подробно рассмотрена работа с асинхронностью в angular2 ) а то где бы не смотрел, не читал, везде - в сервисе получили Observable, в компоненте подписались, все, конец магии ))

Ребят, а подкиньте, плиз, какой-нибудь воркшоп или статью или что-нибудь еще где подробно рассмотрена работа с асинхронностью в angular2 ) а то где бы не смотрел, не читал, везде - в сервисе получили Observable, в компоненте подписались, все, конец магии ))

А что именно интересует? Как работать с Observable? Как это все проектировать и комбинировать?

как проектировать и комбинировать

как проектировать и комбинировать

Как доберусь домой скину ссылок.

спасибо )

Привет, как правильно задизайнить такую штуку: Есть компонент который выводит данные, но теперь задача сделать чтобы данные с определенным типом (data.type === '...') отображались иначе. Я наследовал просто компонент от стандартного, но там есть подписка на ngOninit ngOnInit(){ this.someSerivce.subscribe(items => { ... } Так вот в наследнике я просто переопределил метод ngOnInit(){ this.someSerivce .filter(...type==) .subscribe(items => { ... } то есть беру из подписки только те айтемы которые с определенным типом и получается что в базовый класс мне придется тоже внести изменения только там фильтр выставить обратный этому типу. То есть чтобы получать все кроме вот этого особенного типа. На сколько это верно? ведь если мне потребуется выделить еще какой то тип то мне придется снова внести измненеие в базовый класс. Как лучше поступить?

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

Привет, как правильно задизайнить такую штуку: Есть компонент который выводит данные, но теперь задача сделать чтобы данные с определенным типом (data.type === '...') отображались иначе. Я наследовал просто компонент от стандартного, но там есть подписка на ngOninit ngOnInit(){ this.someSerivce.subscribe(items => { ... } Так вот в наследнике я просто переопределил метод ngOnInit(){ this.someSerivce .filter(...type==) .subscribe(items => { ... } то есть беру из подписки только те айтемы которые с определенным типом и получается что в базовый класс мне придется тоже внести изменения только там фильтр выставить обратный этому типу. То есть чтобы получать все кроме вот этого особенного типа. На сколько это верно? ведь если мне потребуется выделить еще какой то тип то мне придется снова внести измненеие в базовый класс. Как лучше поступить?

Может внести @input type и не заниматься наследованием?

Да type вот внес

Привет, как правильно задизайнить такую штуку: Есть компонент который выводит данные, но теперь задача сделать чтобы данные с определенным типом (data.type === '...') отображались иначе. Я наследовал просто компонент от стандартного, но там есть подписка на ngOninit ngOnInit(){ this.someSerivce.subscribe(items => { ... } Так вот в наследнике я просто переопределил метод ngOnInit(){ this.someSerivce .filter(...type==) .subscribe(items => { ... } то есть беру из подписки только те айтемы которые с определенным типом и получается что в базовый класс мне придется тоже внести изменения только там фильтр выставить обратный этому типу. То есть чтобы получать все кроме вот этого особенного типа. На сколько это верно? ведь если мне потребуется выделить еще какой то тип то мне придется снова внести измненеие в базовый класс. Как лучше поступить?

ngOnInit - в наследнике перезапишит метод родителя. Не нужно ничего в базовом менять

Ну базовым получается остается тот который был изначально

или тогдп получается уже 3 класс

базовый абстрактный

обычный наследник

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

так?

или можно сделать input навреное , тоже налседоваться но вот это ветвление просто выше уровнем вынести

Ну базовым получается остается тот который был изначально

Мне кажеться тут какаято каша. У вас есть класс B он наследуеться от A В.ngOnInit перезапишет A.ngOnInit и все. Как только вы создатите обьект экзепляр класса B в нем будет метод B.ngOnInit - A.ngOnInit не вызовется

Я понимаю что ngOnInit перезапишет но они то рядом все равно лежат <simple-component> <super-type-component>

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

обычный тип

обычный тип

Да. Все верно. В чем проблема?

ну в том что в паренте останется в ngOnInit подписка на все данные(включая и обычный тип)

вот я к чему

к тому что наследуясь я должен паренту фильтр еще внести на вывод всего роме определенного типа

но вот если да с @input type то выше вынести если только урвонем ветвление

тогда да, так получается саый верный способ?

ну в том что в паренте останется в ngOnInit подписка на все данные(включая и обычный тип)

Это же ООП - там свой инстанс

но вот если да с @input type то выше вынести если только урвонем ветвление

У тебя поведение этих компонентов отличается или шаблоны?

ну шаблоны, но парентовые жлементы должны вместе вывоидиться с чайлд

То есть и те и другие должны выводиться, просто элементы с определенынм типом должны шаблоном отличаться и в паренте куда по подписки они попадут если изменения не внести они не перестанут ведь выводится

вот я к чему

но вот если да с @input type то выше вынести если только урвонем ветвление

Либо @input type - либо можете использовать OOP class A { ngOnInit () { this.someSerivce .filter(filterFunction) .subscribe(items => {}) } filterFunction() { return true; } } class B extends A { filterFunction() { return type === } }

ГУД!

@Ai_boy @matochu Спасибо!

и все же

когда появится class C

я в парент внесу изменнеие :D

на фильтр функцию

потому что придется не вывводить тип C

я бы вынес в сервис типы, которые надо игнорировать class A { ngOnInit() { obs.filter(this.MyService.ignoreTypes()).subscribe(...) } } class B extends A { ngOnInit() { this.MyService.put('type'); obs.filter(...).subscribe(...) } }

и даже тут придется внести изменения

ignoreTypes будет возвращать функцию

и даже тут придется внести изменения

где?

АААА)

точно

я бы вынес в сервис типы, которые надо игнорировать class A { ngOnInit() { obs.filter(this.MyService.ignoreTypes()).subscribe(...) } } class B extends A { ngOnInit() { this.MyService.put('type'); obs.filter(...).subscribe(...) } }

Тут все равно вопрос в шаблоне и особенностях самих компонент

Хотя вынести ветвление выше уровнем введя @input это тоже не совсем OOP

ведь всегда будут изменения в каком то еместе

при том рутовом

Можно просто сделать отдельный компонент для работы с типами <super-type-component type="some_type"> - и там уже будет одно поведение и один шаблон

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

я бы вынес в сервис типы, которые надо игнорировать class A { ngOnInit() { obs.filter(this.MyService.ignoreTypes()).subscribe(...) } } class B extends A { ngOnInit() { this.MyService.put('type'); obs.filter(...).subscribe(...) } }

Тут даже без наследования можно

Хотя вынести ветвление выше уровнем введя @input это тоже не совсем OOP

Зачем тебе ООП? Если ты меняешь поведение или шаблон оно нужно, иначе нет. Ты просто вносишь параметр отбора с один компонент.

ой) точно этоже только в шаблоне