I think the complexity people see comes from a lose definition of those two (undefined and null). They do not represent the same thing. An empty array is different from an undefined array, and it is also different from an array with a null value in one position. In those cases, those definitions get more clear. And I think the best approach is just to use what the values mean.
So, I would use undefined whenever a variable has not been assigned yet, or when a method or function does not return anything (exactly how the language behaves on runtime).
On the other hand, null is used when you explicitly say that variable points to no value. You know that variable exists, but you have nothing to assign to it.
I would say undefined is more a "source code" thing, and null more of a runtime thing.
Angular manages state in a very complex and imperative way, in my opinion, which makes checking values harder. But I would use undefined for undefined values and null when I've passed the point where I would assign a value and I had nothing. If it is a collection, I would just initialize it without values.
But I don't think there is a silver bullet answer. Each case should be dealt diferently.
Adding to this answer, in JS/TS if you have to initialize a collection with empty object, it is often too early. Most JS runtime internally implement different optimization based on kind of the object. If you create an empty array, and later populated it with elements, you get a less optimized array than if you populate it on initialization. Refer to V8 blog for more details.
Thank you very much! That's an excellent answer and I agree pretty much with everything you say.
I think much of my particular problems are caused by my data being saved to a document oriented schemaless database (first localStorage and now IndexedDB) and the process of it evolving over time made me lose confidence what's actually in there. Probably makes most sense to solve this problem first and then to revisit the null/undefined problem as you mention.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the complexity people see comes from a lose definition of those two (
undefinedandnull). They do not represent the same thing. An empty array is different from an undefined array, and it is also different from an array with a null value in one position. In those cases, those definitions get more clear. And I think the best approach is just to use what the values mean.So, I would use
undefinedwhenever a variable has not been assigned yet, or when a method or function does not return anything (exactly how the language behaves on runtime).On the other hand,
nullis used when you explicitly say that variable points to no value. You know that variable exists, but you have nothing to assign to it.I would say
undefinedis more a "source code" thing, andnullmore of a runtime thing.Angular manages state in a very complex and imperative way, in my opinion, which makes checking values harder. But I would use
undefinedfor undefined values andnullwhen I've passed the point where I would assign a value and I had nothing. If it is a collection, I would just initialize it without values.But I don't think there is a silver bullet answer. Each case should be dealt diferently.
Adding to this answer, in JS/TS if you have to initialize a collection with empty object, it is often too early. Most JS runtime internally implement different optimization based on kind of the object. If you create an empty array, and later populated it with elements, you get a less optimized array than if you populate it on initialization. Refer to V8 blog for more details.
Thank you very much! That's an excellent answer and I agree pretty much with everything you say.
I think much of my particular problems are caused by my data being saved to a document oriented schemaless database (first localStorage and now IndexedDB) and the process of it evolving over time made me lose confidence what's actually in there. Probably makes most sense to solve this problem first and then to revisit the null/undefined problem as you mention.