The typescript coding guidelines state:
Use undefined. Do not use null.
https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined
Standardizing on one helps prevent bugs (due to comparisons between the two; or due to === undefined checks, when the value is really null). Using the two to represent different semantics usually leads to more confusing code. In addition since Java can't distinguish between the two any undefineds are converted to nulls after a write and a read.
Should we therefore:
- Update all Conjure generated typescript typings to be '| undefined' only (instead of
| undefined | null)?
- Update the generated Conjure clients to automatically convert any nulls to undefined on deserialization?
This would be an API break, so would have to be opt in --- ideally opt-in on the client side (maybe we have Conjure publish two versions of the typescript typings, a v1 and a v2?). The goal would be to reduce bugs from null vs undefined mismatches, and just have a single way of representing optional values.
The typescript coding guidelines state:
Use undefined. Do not use null.https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined
Standardizing on one helps prevent bugs (due to comparisons between the two; or due to === undefined checks, when the value is really null). Using the two to represent different semantics usually leads to more confusing code. In addition since Java can't distinguish between the two any undefineds are converted to nulls after a write and a read.
Should we therefore:
| undefined | null)?This would be an API break, so would have to be opt in --- ideally opt-in on the client side (maybe we have Conjure publish two versions of the typescript typings, a v1 and a v2?). The goal would be to reduce bugs from null vs undefined mismatches, and just have a single way of representing optional values.