With update you're just changing one value with other, while unset is closer to the DELETE operation. In graph based DBs like DGraph, or No-SQL DBs like Mongo, is quite dangerous to just unset a property of something. Let's say accidentaly you set this with a PATCH:
{"user":"lukeshiru","friends":null}
And friends was an array containing all the friends of said user, suddenly we deleted all friends in a patch operation. Ideally actions like that should be in a different endpoint, not the same one you use for updates (not to mention this wouldn't even be possible if we don't use null at all).
But in that scenario, for example ... why would you set totalCost to null? The default should be { amount: 0, currency: "EUR" } or something like that. If you want to leave the default, you omit it, if you want to update it to the default then you just set it to {} (maybe even the wrapper function you have to deal with API interactions can do that for you), and when you want to set a value then you just set it { amount: 50 } or just the currency { currencty: "USD" } or both { amount: 50, currency: "USD" }.
My point when talking about this in the article was that when you need null, you actually need a Type | null, which can be easily replaced with Type | undefined or even just Type because maybe you didn't even needed that nullish in the first place.
Don't take my word for this, you can just google about languages with a single nullish value or without them, and see how they solve this issues ... that can be easily transferred to JS, using only undefined 😄
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.
With update you're just changing one value with other, while unset is closer to the
DELETEoperation. In graph based DBs like DGraph, or No-SQL DBs like Mongo, is quite dangerous to just unset a property of something. Let's say accidentaly you set this with a PATCH:And
friendswas an array containing all the friends of said user, suddenly we deleted all friends in a patch operation. Ideally actions like that should be in a different endpoint, not the same one you use for updates (not to mention this wouldn't even be possible if we don't usenullat all).What about
totalCost: {
amount: 50,
currency: “EUR”
}
Just creating a sub resource for totalCost to be able to delete it, is not really optimal.
Not to mention you may use it in an atomic batch of changes
But in that scenario, for example ... why would you set
totalCosttonull? The default should be{ amount: 0, currency: "EUR" }or something like that. If you want to leave the default, you omit it, if you want to update it to the default then you just set it to{}(maybe even the wrapper function you have to deal with API interactions can do that for you), and when you want to set a value then you just set it{ amount: 50 }or just the currency{ currencty: "USD" }or both{ amount: 50, currency: "USD" }.My point when talking about this in the article was that when you need
null, you actually need aType | null, which can be easily replaced withType | undefinedor even justTypebecause maybe you didn't even needed that nullish in the first place.Don't take my word for this, you can just google about languages with a single nullish value or without them, and see how they solve this issues ... that can be easily transferred to JS, using only
undefined😄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.