SФ
Херня, а не вывод
Size: a a a
2018 November 01
SФ
И поэтому разрабы фреймворка предоставляют публичный апи для подкапотных дел ?)
Да, потому что ты можешь, если уже вдруг делаешь что-то сложное и не 90% обычных задач
SФ
Ты можешь вообще отрубить весь CD и сам написать логику ререндера
DO
И поэтому разрабы фреймворка предоставляют публичный апи для подкапотных дел ?)
Они это делают для гибкости. Если ты попал в сложную ситуацию, тебе не нужно форкать ангуляр и подпиливать его.
DG
И поэтому разрабы фреймворка предоставляют публичный апи для подкапотных дел ?)
это обычное дело) не подкапотное, суть в стиле написания кода
DO
это обычное дело) не подкапотное, суть в стиле написания кода
Как раз подкапотное, это low level api
SФ
это обычное дело) не подкапотное, суть в стиле написания кода
Так лучше не писать
SФ
Совсем
SФ
Но иногда нужно, в исключительных случаях
SФ
А если вдруг стало нужно, то стоит задуматься над архитектурой приложения
SФ
А том уже ручками дергать CD
DG
да, например смарт компонент с онпушем ты как работать будешь?
SФ
да, например смарт компонент с онпушем ты как работать будешь?
behaviorsubject
SФ
и async
DG
такое себе усложнение
IF
-Джеквери ГАВНО. -Ну почему же, для определенных задач нормальны инструмент. - Я сказал ГАВНО!!11 мучайтесь, пишите на ванилле, но главное без джекуериDG
ангуляр должен подписаться на данные, следить за ними и ручками дергать markForCheck когда ты в компоненте делаешь next(whatever) вместо того чтоб просто самому вызвать markForCheck
SФ
ангуляр должен подписаться на данные, следить за ними и ручками дергать markForCheck когда ты в компоненте делаешь next(whatever) вместо того чтоб просто самому вызвать markForCheck
Нет, не next, а он подписан на async
DG
а данные ты там как обновлять будешь?
SФ
Так что это зависит от того, что ты там используешь в шаблоне