We certainly could do that, but it would violate the business needs.
We can use custom null objects to mean no-value, but why? Just to reach a metric of not using null?
Another way is to represent Options or Maybes or Eithers as tagged unions, but if you have null at your disposal, and mind you, it is part of the json spec, so even languages without null or with just one nullish value, can still leverage absence (aka undefined), and null when speaking json.
It certainly makes interacting with your api easier and more standard :)
How you interpret these values while deserialising json, or when you play the object dance in domain model, or how to store and represent in your persistence model; those are private implementation details.
We might not be understanding each other, if the API needsnull to work, then use it when interacting with it. The article doesn't say "you should never ever use null", the point of the article is that we shouldn't default to it and use undefined instead. Instead of having null and undefined all over the code, you should use just undefined in your code, and if the API is limited to using null, then just use null in the functions or methods that interact with it.
I have a disclaimer at the bottom of every article in this series because folks generally understand "you don't need" as "you should never use", and that's not the point. This series is about re-evaluating our defaults.
Some comments have been hidden by the post's author - find out more
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.
We certainly could do that, but it would violate the business needs.
We can use custom null objects to mean no-value, but why? Just to reach a metric of not using null?
Another way is to represent Options or Maybes or Eithers as tagged unions, but if you have null at your disposal, and mind you, it is part of the json spec, so even languages without null or with just one nullish value, can still leverage absence (aka undefined), and null when speaking json.
It certainly makes interacting with your api easier and more standard :)
How you interpret these values while deserialising json, or when you play the object dance in domain model, or how to store and represent in your persistence model; those are private implementation details.
We might not be understanding each other, if the API needs
nullto work, then use it when interacting with it. The article doesn't say "you should never ever usenull", the point of the article is that we shouldn't default to it and useundefinedinstead. Instead of havingnullandundefinedall over the code, you should use justundefinedin your code, and if the API is limited to usingnull, then just usenullin the functions or methods that interact with it.I have a disclaimer at the bottom of every article in this series because folks generally understand "you don't need" as "you should never use", and that's not the point. This series is about re-evaluating our defaults.