поле как nullable по умолчанию т.к. не видит присвоений к нему, пример:
@Input() transaction: Transaction;
Соответственно приходится обозначать все подобные поля так:
@Input() transaction!: Transaction;
явно указывая что оно не null - как по вашему правильнее? Продолжить явно указывать в подобных местах или поправить конфиг ts’a?
По мне тут есть недочет ангуляра т.к. все инпуты опциональны. А так так они опциональны я бы не советовал использовать !, а проверять значение перед использованием, но это мое мнение и подход который я стараюсь использовать, если есть что поинтереснее буду тоже признателен
Использовать везде в таких местах conditional access тоже кажется не очень правильным. Здесь член команды Angular дает достаточно пространный ответ на этот вопрос: To fix it, you’d have to either set title to a string value or change its type, for instance: @Component({...}) class AppComponent { @Input() title: string = ‘’; }
Ну я бы сказал что конкретно этот пример с title я бы лучше оставил string | undefined, так логичнее если тайтл опционален, если конечно пустой тайтл не отображается
Ну тут не очень понятно, если я проброшу в инпут компонента не тот тип или null я получу ошибку в темплейте, это же контролируется на уровне получения данных - «получил null не бросай в компонент». Или Angular здесь все-таки пропагандирует весь null handling внутри компонента? Просто в любом случае есть истории когда в инпут никогда не придёт null, а даже если может придти - почему не указать это как дополнительный тип, а не воспринимать отсутствие присвоения как ошибку, выглядит как ограничение разработчика - ты же знаешь куда может придти null, а куда нет.
Я не уловил причем тут null, может речь все же про undefined, т.к. любое проперти по умолчанию undefined, если оно не инициализируется при объявлении или в конструкторе?
My bad. Ну да, undefined.
Если есть любая вероятность что придет Null надо это отрабатывать, но обычно это может случиться осознано либо бэк такой тип вернул и это тоже осознано
они сами не знают че "пропагандируют" :) а ваще для настоящего кайфа это попробовать поработать с реактом в ts strict режиме, вот где веселуха самая
а там useState по дефолту возвращает тип T|undefined
С undefined сложнее, т.к. мы не можем гарантировать что в этот компонент будут передаваться какие то данные вообще и тут либо давать дефолтные значения либо обрабатывать undrfined
Ок, обработку undefined делаем, например наш компонент категорически не может работать без какого-то input свойства и мы бросаем эксепшн. Это все равно нас не избавит от необходимости делать везде где мы используем свойство - conditional access, либо альтернативы.
Да вроде нет Пишешь useState<boolean>(false) и возвращает булеан Не знаю как в стрикт моде, у меня во всех проектах так
ну так попробуй :)
Если эксепшн то можно наверное и исключить undefined из типа
Но опять таки если есть условно ngIf на проверку undefined далее мы уже работаем с ожидаемым типом
Обсуждают сегодня