Estoy trabajando en una biblioteca y el público objetivo es TypeScript; sin embargo, es algo que es útil para JavaScript e ignorarlos ignorará a muchas personas.
Gran parte del código que estoy escribiendo está comprobando si un valor que es NonNullable<T> es de hecho null porque los desarrolladores de JavaScript pueden dar null o undefined sin que se les diga que no pueden antes de tiempo.
Simplemente no estoy seguro de si se espera que agregue todo esto cuando dar null o undefined dará como resultado un error independientemente, a expensas de cada operación para mi público objetivo que necesita verificar null . Si fuera un par de veces, no pensaría mucho en ello, pero hay cadenas de métodos con la validación de los datos pasados.
La información sobre herramientas al pasar el cursor sobre el método dice claramente NonNullable<T> y esta biblioteca no tiene ningún parámetro opcional, por lo que si dice que hay un parámetro, necesita un valor.
Estoy aburrido de escribir las mismas comprobaciones, que constituyen aproximadamente el 40 % de mi código, lo que es aún peor teniendo en cuenta que algunos parámetros son funciones, por lo que debo comprobar si la función es null y, si no lo es, si el resultado de la la función es null .
value:NonNullable<T>; ... public setOr(fn:() => NonNullable<T>) { if(fn == null) throw Error("Expected function, not `null` or `undefined`") const value = fn() if(value == null) throw Error("Cannot accept `null` or `undefined`") this.value = value }dentro
value:NonNullable<T>; ... public setOr(fn:() => NonNullable<T>) { this.value = fn() //Will implicitly throw an error if `fn` is `null` or `undefined` }Estoy haciendo esto principalmente para mí, sin embargo, sería bueno que otros lo usaran y no quiero cometer un error, pero también quiero terminar esto.
Así que creo que depende del nivel de soporte de mecanografiado en el proyecto. Si hay muchos anys o está usando algunos js-libs, definitivamente puede pensar en agregar un typeguard para null|undefined y tal vez el tipo esperado.
Si no hay anys en todo el proyecto y todas las apis, libs que está utilizando también están escritas, no lo haría. Solo porque es por eso que todos usan mecanografiado. En mi opinión, también es mejor si el tipo que está llamando a su función maneja el valor nulo y no su función en sí.
Pero hay algunas excepciones en las que definitivamente debe verificar nulo | indefinido incluso si se supone que no debe hacerlo:
// accessing an array item: const a = ["a","b"] const x = a[2] // is undefined but typescript won't tell you that, if the // compiler option: noUncheckedIndexedAccess is set to false // accessing an Record const y:Record<string,string> = {} const z = y["any"]// is undefined but typescript won't tell you that aswell