As I replied to other guy. The response should be consistent, if you skip this value, tada! an error should be thrown. Because you won’t know if the value is missing (eg: it has, but api fails to give it) or the value is not defined.
Other languages which don’t have it because they are more strict, where it’s bad when you try to use an undefined variable. JS was born as a mess, but growing up as a flexible language, that’s why we have undefined and null to use together
If the API fails, you should handle that in other ways (response headers and proper error handling), if the API responded with the wrong body, that will be a problem either if you use null or undefined, so I still don't see much value for null in this scenario. If a value can either come or not, then you can define it as optional (meaning Type | undefined), and in the front end you can just do value ?? "default value" or if (value === undefined) { throw // ... } or whatever 😄
You should take a look at optional chaining and nullish coalescing, saying "it's bad when you try to use an undefined variable" feels like you might not be aware of this operators, but long story short, it's no longer bad. You can even "call" undefined 🎉
nullorundefined, so I still don't see much value fornullin this scenario. If a value can either come or not, then you can define it as optional (meaningType | undefined), and in the front end you can just dovalue ?? "default value"orif (value === undefined) { throw // ... }or whatever 😄undefined🎉