На самом деле чем больше опыта, тем больше осознание что DI тут какой-то ущербный :( В статье например не сказано что все зависимости по сути синглтоны (пусть и в пределах модуля), даже фабрика и та создает синглтоны (кмк несколько неочевидно), хотя это по-моему упоминается в документации. Если синглтон не нужен приходиться явно добавлять сервис в компонент и писать @Self() — очень раздражает и легко ошибиться (особенно когда компоненты наследуются). Надеюсь что когда-нибудь они добавят providedIn: 'component' или что-то подобное ...
Ничего не сказано и об иерархии, которая иногда создает проблемы при переопределении провайдеров, про невозможность собрать все провайдеры из всех модулей и т.д.
Просто пишите код так, как задумано принципами фреймворка, и вы не попадете в неприятности с OnPush
Ровно до тех пор не заходите уведомить другие дочерние компоненты родительского компонента о том что "надо бы перерендерится". Проблема в том что при onpush компонент обновиться только если изменятся @Input() (см ниже) или если он сам вызовет markForCheck(), способа сказать angular-у "перерендерь меня полностью со всеми подкомпонентами" до сих пор не существует :( Самый простой и очевидный способ решить проблему через @Input(), но, как указано в статье, надо помнить о том что нельзя просто взять изменить свойство, надо создавать новый объект, в некоторых случаях это неудобно.
Кроме этого в статье упущен еще один важный момент: если вы изменяете @Input() программно, вы обязаны вызвать markForCheck()иначе angular не поймет что надо обновить компонент. На практике это значит что если вы хотите чтобы ваш компонент работал во всех случаях, то в каждый сеттер каждого @Input() надо пихать проверку действительно ли значение изменилось и вызывать markForCheck() когда это произошло (ну или проверять в ngDoCheck()).
Самый полезный, по моему мнению, способ использования фабрики в tree shakable сервисах выглядит так:
Пример кмк не очень удачный (как и плюсы), если нужен app-wide синглтон, то есть рекомендованный providedIn: 'root'.
Это работает точно так же, как и следующий пример:@NgModule({providers: [SomeService]})
Вот только в этом случае tree shakable невозможен (из статьи это немного неочевидно, да и вообще оно deprecated). И работает кстати тоже не совсем так как ожидаешь, при @Injectable({providedIn: SomeModule})SomeModule не сможет использовать этот сервис внутри себя из-за cyclic dependency))) Приходится создавать отдельный пустой модуль для сервисов и импортировать его в SomeModule. Неудобно :(
@Injectable({providedIn: SomeModule})
И тут мы еще получаем одну неочевидную проблему с приоритетом (кто последний тот и папа), что затрудняет переопределение провайдеров определенных в импортируемых модулях (иногда оно нужно).
Поэтому в 99% providedIn: 'root' предпочтительнее.
Это очень мощный инструмент для создания гибких и переиспользуемых компонентов.
Всё-таки правильнее будет сказать "ущербный" или, если более политкорректно, "подходящий для совсем простых случаев", самый большой косяк в нем это что он наследует контекст того места где определен (т.е. AppComponent), что например не позволяет сделать вот так:
Прикол тут в том что визуально все как бы нормально, но на самом деле если посмотреть внутрь angular-а то можно заметить что optionы регистрируются вselecte, но тут этого не происходит по очевидной причине (другой контекст) и рождаются всякие баги https://github.com/angular/angular/issues/26273 (впрочем <select> сам по себе тоже довольно сильно баганый...).
Я решил указать экспортный, потому что предельная сумма до постановки на учет валютного контроля по такому типу контракта выше остальных типов (до 6 млн ₽ вы можете быть спокойны).
Зарегистрировать можно и раньше не дожидаясь 3/6млн, единственное на что влияет регистрация это на коммисию при переносе контракта в другой банк, а вот если не сделать это вовремя то можно попасть на штраф (40к вроде был).
Ну и еще не все банки требуют дополнительных сумм в CoS из пункта (2). Модулю например достаточно только суммы.
Последний раз инженерный калькулятор у меня был лет 20 назад наверное, поэтому не помню было ли оно так, ну а сейчас весьма неожиданно что контрол который выглядит как обычная кнопка на самом деле чекбокс… Тем более в прошлой версии корень был отдельной кнопкой без всякого переключения. Мне кажется лучше бы они сделали если не чекбокс, то хотя бы селект, но лучше конечно просто еще один ряд кнопок.
Т.е. его надо каждый раз переключать в обычный режим?
В "обычном" режиме у него весьма забавный приоритет операторов (1 + 2 *2 = 6), а в "инженерном", где он нормальный, больше нет квадратного корня. Так что куда не переключайся он всё равно будет унылым :(
либо есть возможность иначе связать родительскую форму с внутренней.
Никак.
Либо не стоит использовать реактивную форму внутри
Это зависит от того что вам надо, возможно, в вашем случае можно заменить родительный контрол на FormGroup (которая сейчас внутри), это решит проблемы с touched, но в сложных формах, когда это невозможно — только костылить пытаясь заставить это всё работать....
Существует ли стандартный подход для поддержки метода markAsTouched в таком компоненте?
Touched событий у формы в принципе нету… Но как всегда есть костыль — можно проверять touched внутри DoCheck и обновлять внутреннюю форму. Правда в этом случае есть проблемы с тем как получить ссылку на внешний FormControl, легче и лучше всего это сделать через @Input() formControl (правда оно не будет работать с formControlName, но зато максимально прозрачно и без костылей...)
Copy relative path — перенесли в вложенное подменю — очень неудобно (два клика вместо одного), особенно что хоткей на него (сopy relative path) повесить нельзя
Сломали замену относительных путей на полные в ts файлах, при этом в баге пишут что типа так и должно быть, несмотря на то что оно всегда работало (минимум год). Печально :(
В вебе (angular+ts) без гугла, к сожалению, уже никак нельзя — основная причина в том что это сильно быстрее и проще чем дебажить. Я был бы даже рад залезть в код, поглядеть в чем проблема, возможно, pr родить, однако, исходников библиотек в проекте просто нету, есть только рожденный компилятором js. Из-за чего, когда сильно нужно, приходится клонировать репо отдельно и смотреть там. При этом, кстати, еще ~ пару лет назад можно было использовать исходники, но потом сообщество ts внезапно решило что исходный ts в пакетах это зло и пакеты должны содержать только js и d.ts (информацию о типах)...
ЗЫ: Кстати, возможно как-то можно подтянуть исходники?
Ну так и я вроде сослался на прямой ответ минфина на вопрос
По моим ссылкам пишут что это было единственное такое письмо, а по второй есть письмо от конца 18 года.
Продаёт по 1$ по 100 штук в день. Вы каждую продажу будете считать?
Вполне возможно (не изучал тему), еще бредовее выглядит онлайн касса (для апрвока на патенте для 62 оквэда пока можно не применять), но куда деваться? ...
Оно не так работает. Налоговая сначала потребует пояснений, если они её не устроят то потребует доплатить (и/или еще могут придти с проверкой), а дальше если вы не согласны то суд и куча убитого времени. При этом никто не гарантирует что суд встанет на вашу сторону… А с валютой надо вообще осторожным быть, там неадекватные штрафы на каждый чих.
На самом деле чем больше опыта, тем больше осознание что DI тут какой-то ущербный :( В статье например не сказано что все зависимости по сути синглтоны (пусть и в пределах модуля), даже фабрика и та создает синглтоны (кмк несколько неочевидно), хотя это по-моему упоминается в документации. Если синглтон не нужен приходиться явно добавлять сервис в компонент и писать
@Self()— очень раздражает и легко ошибиться (особенно когда компоненты наследуются). Надеюсь что когда-нибудь они добавятprovidedIn: 'component'или что-то подобное ...Ничего не сказано и об иерархии, которая иногда создает проблемы при переопределении провайдеров, про невозможность собрать все провайдеры из всех модулей и т.д.
Ровно до тех пор не заходите уведомить другие дочерние компоненты родительского компонента о том что "надо бы перерендерится". Проблема в том что при
onpushкомпонент обновиться только если изменятся@Input()(см ниже) или если он сам вызоветmarkForCheck(), способа сказать angular-у "перерендерь меня полностью со всеми подкомпонентами" до сих пор не существует :( Самый простой и очевидный способ решить проблему через@Input(), но, как указано в статье, надо помнить о том что нельзя просто взять изменить свойство, надо создавать новый объект, в некоторых случаях это неудобно.Кроме этого в статье упущен еще один важный момент: если вы изменяете
@Input()программно, вы обязаны вызватьmarkForCheck()иначе angular не поймет что надо обновить компонент. На практике это значит что если вы хотите чтобы ваш компонент работал во всех случаях, то в каждый сеттер каждого@Input()надо пихать проверку действительно ли значение изменилось и вызыватьmarkForCheck()когда это произошло (ну или проверять вngDoCheck()).Пример кмк не очень удачный (как и плюсы), если нужен app-wide синглтон, то есть рекомендованный
providedIn: 'root'.Вот только в этом случае tree shakable невозможен (из статьи это немного неочевидно, да и вообще оно deprecated). И работает кстати тоже не совсем так как ожидаешь, при
@Injectable({providedIn: SomeModule})SomeModuleне сможет использовать этот сервис внутри себя из-за cyclic dependency))) Приходится создавать отдельный пустой модуль для сервисов и импортировать его вSomeModule. Неудобно :(И тут мы еще получаем одну неочевидную проблему с приоритетом (кто последний тот и папа), что затрудняет переопределение провайдеров определенных в импортируемых модулях (иногда оно нужно).
Поэтому в 99%
providedIn: 'root'предпочтительнее.Всё-таки правильнее будет сказать "ущербный" или, если более политкорректно, "подходящий для совсем простых случаев", самый большой косяк в нем это что он наследует контекст того места где определен (т.е.
AppComponent), что например не позволяет сделать вот так:Прикол тут в том что визуально все как бы нормально, но на самом деле если посмотреть внутрь angular-а то можно заметить что
optionы регистрируются вselecte, но тут этого не происходит по очевидной причине (другой контекст) и рождаются всякие баги https://github.com/angular/angular/issues/26273 (впрочем<select>сам по себе тоже довольно сильно баганый...).А еще нет никакого способа задать содержимое по умолчанию, что довольно часто нужно (см https://github.com/angular/angular/issues/12530).
Поэтому по сути годится только для иконок :(
Зарегистрировать можно и раньше не дожидаясь 3/6млн, единственное на что влияет регистрация это на коммисию при переносе контракта в другой банк, а вот если не сделать это вовремя то можно попасть на штраф (40к вроде был).
Ну и еще не все банки требуют дополнительных сумм в CoS из пункта (2). Модулю например достаточно только суммы.
Оно скорее аналог
JsonSerializableНаверное, но кмк в этом случае было бы лучше писать не
1 + 2 * 2 = 6как сейчас, а1 + 2 = 3 * 2 = 6Последний раз инженерный калькулятор у меня был лет 20 назад наверное, поэтому не помню было ли оно так, ну а сейчас весьма неожиданно что контрол который выглядит как обычная кнопка на самом деле чекбокс… Тем более в прошлой версии корень был отдельной кнопкой без всякого переключения. Мне кажется лучше бы они сделали если не чекбокс, то хотя бы селект, но лучше конечно просто еще один ряд кнопок.
Нашел :) Фиг догадаешься… для тех кто тоже ищет он под "2nd"
В "обычном" режиме у него весьма забавный приоритет операторов (1 + 2 *2 = 6), а в "инженерном", где он нормальный, больше нет квадратного корня. Так что куда не переключайся он всё равно будет унылым :(
Oно не работает c
NG_VALIDATORS...Делиться смысла нет, каждая налоговая может трактовать всё по своему и на мнение другой налоговой им побоку, так что придется самому спрашивать :)
Ну а если серьезно, то
Никак.
Это зависит от того что вам надо, возможно, в вашем случае можно заменить родительный контрол на
FormGroup(которая сейчас внутри), это решит проблемы сtouched, но в сложных формах, когда это невозможно — только костылить пытаясь заставить это всё работать....Всё нормально, расслабьтесь, это ангуляр, тут подобных костылей на каждом шагу по десятку...
Touched событий у формы в принципе нету… Но как всегда есть костыль — можно проверять
touchedвнутриDoCheckи обновлять внутреннюю форму. Правда в этом случае есть проблемы с тем как получить ссылку на внешнийFormControl, легче и лучше всего это сделать через@Input() formControl(правда оно не будет работать сformControlName, но зато максимально прозрачно и без костылей...)Запускать оно стало быстрее, но вместе с тем:
В вебе (angular+ts) без гугла, к сожалению, уже никак нельзя — основная причина в том что это сильно быстрее и проще чем дебажить. Я был бы даже рад залезть в код, поглядеть в чем проблема, возможно, pr родить, однако, исходников библиотек в проекте просто нету, есть только рожденный компилятором js. Из-за чего, когда сильно нужно, приходится клонировать репо отдельно и смотреть там. При этом, кстати, еще ~ пару лет назад можно было использовать исходники, но потом сообщество ts внезапно решило что исходный ts в пакетах это зло и пакеты должны содержать только js и
d.ts(информацию о типах)...ЗЫ: Кстати, возможно как-то можно подтянуть исходники?
Вообще кстати можно у самой (местной) налоговой спросить — по идее самый лучший вариант :)
По моим ссылкам пишут что это было единственное такое письмо, а по второй есть письмо от конца 18 года.
Вполне возможно (не изучал тему), еще бредовее выглядит онлайн касса (для апрвока на патенте для 62 оквэда пока можно не применять), но куда деваться? ...
Странно, а бухгалтера про агентский договор (случай апворка) по другому пишут:
Оно не так работает. Налоговая сначала потребует пояснений, если они её не устроят то потребует доплатить (и/или еще могут придти с проверкой), а дальше если вы не согласны то суд и куча убитого времени. При этом никто не гарантирует что суд встанет на вашу сторону… А с валютой надо вообще осторожным быть, там неадекватные штрафы на каждый чих.