#typescript
#typescript
Вопрос:
(Я парень старой школы C / C , только изучающий typescript.)
У меня есть такой код:
class myClass {
v: string | null = null
setVtoNonNull() { this.v = "hi" }
method() {
if (!this.v)
this.setVtoNonNull()
// now at this point v is definitely not null
// how do I tell typescript that?
const s: string = this.v // <<<< typescript gives error here
}
}
В method
, как мне сообщить typescript, что после setVtoNonNull()
вызова локальная переменная v
не равна null? Я знаю, что могу использовать v!
везде, где я использую v
, после ее установки (но это раздражает, если я использую v
много), или я мог бы сделать этот ужасный взлом:
v = v!
но это будет стоить циклов во время выполнения только для обеспечения чистоты во время компиляции. Есть ли директива компилятора или что-то, что я могу использовать?
Комментарии:
1. Требуются ли здесь побочные эффекты в методе? Если вы возвращаете значение, укажите возвращаемый тип как simply
string
, затем переназначите на сайте вызова, это может сработать.2. Анализ потока управления TypeScript / вывод типа почти никогда не пересекает границу функции. Смотрите github.com/Microsoft/TypeScript/issues/20901 , github.com/Microsoft/TypeScript/pull/10357 , и github.com/Microsoft/TypeScript/issues/9998
3. Я думаю, другой способ — добавить ненужный
if (v) { ... }
блок вокруг кода, где я знаю, что он ненулевой. Typescript выяснит, что это означает, что в теле этого значения не может быть nullif
, верно?4. Верно, но ненулевое утверждение
const s: string = this.v!
более явно, чемif
при условии always true IMO
Ответ №1:
Я бы сделал что-то вроде этого:
class myClass {
v: string | null = null;
setVtoNonNull(): string {
if (!this.v) {
this.v = "hi";
}
return this.v;
}
method() {
const s: string = this.setVtoNonNull();
}
}
Ответ №2:
Такого рода поражение — цель Typescript. В любом случае, поскольку TypeScript будет определять тип переменной, я предлагаю вам использовать что-то вроде этого
class myClass {
v: any = null
// ... rest of your conde
}
Комментарии:
1. Я не голосовал против, но я не понимаю, к чему вы здесь клоните. Как было бы лучше вообще игнорировать безопасность типов и использовать
any
?