VL
Real world example ж есть
Надо глянуть
Да и архитектуру можно самому придумать, если один делаешь
Главное шизу не поймать и потом не начать путаться
Size: a a a
2020 March 23
VL
Та я недавно на нём пишу. На первых порах я её словил, отлавливая ошибки прямо в компонентах. Позже увидел интерсепторы и такой: "Лол, так можно было?"
K✔
filter
Оказывается, в first тоже можно, я затупил
K✔
Привет, ребят. Может кто-нибудь скинуть статьи по нормальной архитектуре angular приложения? Я почитал про кодстайл в самом ангуляре, по rxjs. Но недавно узнал, что подписки в коде лучше не хранить. Вот хотелось бы эту тему подробнее разобрать
Я подписки храню в
или в
Потом через
SubscriptionSet<Map> {}или в
SubscriptionSet { [key: string]: Subscription}Потом через
for ... in прохожусь и отписываюсь, когда надоЕУ
Я подписки храню в
или в
Потом через
SubscriptionSet<Map> {}или в
SubscriptionSet { [key: string]: Subscription}Потом через
for ... in прохожусь и отписываюсь, когда надозачем, если можно юзать takeUntil(ngOnDestroy$) и отписаться разом в ngOnDestroy:
this.ngOnDestroy$.next()
this.ngOnDestroy$.next()
V
А можно ещё сделать декоратор, который при уничтожении компонента будет проходиться по объекту subscribe и отписываться
🧤K
зачем, если можно юзать takeUntil(ngOnDestroy$) и отписаться разом в ngOnDestroy:
this.ngOnDestroy$.next()
this.ngOnDestroy$.next()
Потому что у него это скорее всего в базовом компоненте и это нагляднее ) чем следить где забыл takeUntil
VM
можно все сделать и базовый класс и декоратор, и takeUntil, но так как это часто используемая штука, как-бы ее сделать короче (без нахлобучки), понятнее (без скрытого поведения), и проще чтоб каждый новый разработчик с первого взгляда понял что к чему, весь смысл программирования в этом
ЕУ
можно все сделать и базовый класс и декоратор, и takeUntil, но так как это часто используемая штука, как-бы ее сделать короче (без нахлобучки), понятнее (без скрытого поведения), и проще чтоб каждый новый разработчик с первого взгляда понял что к чему, весь смысл программирования в этом
никак. если разраб знаком с rxjs, он поймет и то, и другое, и третье. а если нет, то все равно будет спрашивать, гуглить или тупить
K✔
зачем, если можно юзать takeUntil(ngOnDestroy$) и отписаться разом в ngOnDestroy:
this.ngOnDestroy$.next()
this.ngOnDestroy$.next()
Без примера не очень понятно, но спасибо - гляну обяз
K✔
RxJs - вообще целый мир. Жаль, что нативной поддержки реактивности в ЖСе нема
ЕУ
Без примера не очень понятно, но спасибо - гляну обяз
observable.pipe(takeUntil(this.ngOnDestroy$)).subscribe()
K✔
observable.pipe(takeUntil(this.ngOnDestroy$)).subscribe()
От ет понятно! Спс
VM
никак. если разраб знаком с rxjs, он поймет и то, и другое, и третье. а если нет, то все равно будет спрашивать, гуглить или тупить
иногда читаешь текст все слова понятны но смысл в целом нет, так и в коде ), rxjs-ом можно навертеть такую бороду, что даже многолетние профи ничего не поймут
ЕУ
От ет понятно! Спс
зы. ngOnDestroy$
ngOnDestroy$ = new Subject()
ngOnDestroy$ = new Subject()
🧤K
иногда читаешь текст все слова понятны но смысл в целом нет, так и в коде ), rxjs-ом можно навертеть такую бороду, что даже многолетние профи ничего не поймут
Для такого пишут комментарии ))
VM
)) лучше изучать стайлгайды, английский язык) и учится писать читабельный код, комментарии - это крайний случай
K✔
)) лучше изучать стайлгайды, английский язык) и учится писать читабельный код, комментарии - это крайний случай
Согласен. Из комментариев достаточно JSDoc, и всё
VM
как в баскетболе, при потере мяча, виноват не тот кто не принял мяч, а тот кто его отдавал (если код не понимают, значит что-то не то написано)
OS
)) лучше изучать стайлгайды, английский язык) и учится писать читабельный код, комментарии - это крайний случай
комментарии не крайний случай, есть кейсы, где без них не обойтись.)