Respuestas:
Todos los campos en JavaScript (y en TypeScript) pueden tener el valor nullo undefined.
Puede hacer que el campo sea opcional, que es diferente de anulable.
interface Employee1 {
name: string;
salary: number;
}
var a: Employee1 = { name: 'Bob', salary: 40000 }; // OK
var b: Employee1 = { name: 'Bob' }; // Not OK, you must have 'salary'
var c: Employee1 = { name: 'Bob', salary: undefined }; // OK
var d: Employee1 = { name: null, salary: undefined }; // OK
// OK
class SomeEmployeeA implements Employee1 {
public name = 'Bob';
public salary = 40000;
}
// Not OK: Must have 'salary'
class SomeEmployeeB implements Employee1 {
public name: string;
}
Comparar con:
interface Employee2 {
name: string;
salary?: number;
}
var a: Employee2 = { name: 'Bob', salary: 40000 }; // OK
var b: Employee2 = { name: 'Bob' }; // OK
var c: Employee2 = { name: 'Bob', salary: undefined }; // OK
var d: Employee2 = { name: null, salary: 'bob' }; // Not OK, salary must be a number
// OK, but doesn't make too much sense
class SomeEmployeeA implements Employee2 {
public name = 'Bob';
}
"strict" : false
salary:number|null;Si lo hace salary?:number; salary = null;, obtendrá un error. Sin embargo, salary = undefined;funcionará bien en este caso. Solución: use Union, es decir, '|'
El tipo de unión es, en mi opinión, la mejor opción en este caso:
interface Employee{
id: number;
name: string;
salary: number | null;
}
// Both cases are valid
let employe1: Employee = { id: 1, name: 'John', salary: 100 };
let employe2: Employee = { id: 1, name: 'John', salary: null };
EDIT: Para que esto funcione como se esperaba, se debe permitir que el strictNullChecksen tsconfig.
Para ser más parecido a C # , defina el Nullabletipo de esta manera:
type Nullable<T> = T | null;
interface Employee{
id: number;
name: string;
salary: Nullable<number>;
}
Prima:
Para hacer que se Nullablecomporte como un tipo de Typecript incorporado, defínalo en un global.d.tsarchivo de definición en la carpeta de origen raíz. Este camino funcionó para mí:/src/global.d.ts
emp: Partial<Employee>, podemos hacer emp.ido emp.nameetc, pero si tenemos emp: Nullable<Employee>, no podemos haceremp.id
Simplemente agregue un signo de interrogación ?al campo opcional.
interface Employee{
id: number;
name: string;
salary?: number;
}
Simplemente puede implementar un tipo definido por el usuario como el siguiente:
type Nullable<T> = T | undefined | null;
var foo: Nullable<number> = 10; // ok
var bar: Nullable<number> = true; // type 'true' is not assignable to type 'Nullable<number>'
var baz: Nullable<number> = null; // ok
var arr1: Nullable<Array<number>> = [1,2]; // ok
var obj: Nullable<Object> = {}; // ok
// Type 'number[]' is not assignable to type 'string[]'.
// Type 'number' is not assignable to type 'string'
var arr2: Nullable<Array<string>> = [1,2];
Tuve esta misma pregunta hace un tiempo ... todos los tipos en ts son anulables, porque void es un subtipo de todos los tipos (a diferencia, por ejemplo, scala).
vea si este diagrama de flujo ayuda - https://github.com/bcherny/language-types-comparison#typescript
voidser 'subtipo de todos los tipos' ( tipo inferior ), consulte este hilo . Además, el gráfico que proporcionó para scala también es incorrecto. Nothingen scala es, de hecho, el tipo de fondo. Typecript, atm, no tiene tipo de fondo mientras que scala sí .
El tipo anulable puede invocar un error de tiempo de ejecución. Así que creo que es bueno usar una opción de compilador --strictNullChecksy declarar number | nullcomo tipo. También en el caso de la función anidada, aunque el tipo de entrada es nulo, el compilador no puede saber qué podría romper, por lo que recomiendo su uso !(signo de exclamación).
function broken(name: string | null): string {
function postfix(epithet: string) {
return name.charAt(0) + '. the ' + epithet; // error, 'name' is possibly null
}
name = name || "Bob";
return postfix("great");
}
function fixed(name: string | null): string {
function postfix(epithet: string) {
return name!.charAt(0) + '. the ' + epithet; // ok
}
name = name || "Bob";
return postfix("great");
}
Referencia. https://www.typescriptlang.org/docs/handbook/advanced-types.html#type-guards-and-type-assertions
typescript@nextahora.)