eslint-plugin-unicorn
v19.0.0 added unicorn/no-null by default.
The reasoning behind it:
Intent to stop using null
in my JS code
Some good Pros/Cons summary from that thread:
sindresorhus/meta#7 (comment)
The rule only restricts using null
as explicit values for variables or function arguments.
It's still valid to compare to null
as in:
if (localStorage.getItem('foo') === null) {}
- DOM API's
- Response from the backend or external service
While updating an existing repo to pass this rule, I realized that I can't remember an actual use case that would be greatly beneficial if I could set a value to null
and later compare to it.
And if I don't compare to null
anywhere, that means I could have easily not used null
all along.
Also I've noticed that when we don't have null
, reasoning about the code becomes a bit easier, it's one less potential value that a variable or argument can have.
In React components, usually we return null
to tell React not to render anything (that's what the React docs show and what everyone teaches online).
But it's perfectly fine to return false
, true
or ''
and React won't render anything as well:
https://reactjs.org/docs/jsx-in-depth.html#booleans-null-and-undefined-are-ignored
Returning undefined
doesn't work in this case, React errors about it.
So the best option is to return false
.
function MyComponent() {
if (isLoading) {
return false;
}
return (
<h1>Some content here</h1>
);
}
Usually we return null
to tell React to do nothing on a specific event handler.
In this case, return undefined
is actually preferable, as React won't even pass that prop down.
And that would be consistent with custom conditional props as well, where passing null
would actually pass it down.
function MyComponent() {
return (
<DialogCloseButton onClick={isOkInProgress ? undefined : onClose} />
);
}
Passing undefined
to JSON.stringify
2nd argument is like not passing any value, which is the same as passing null
per the MDN - JSON.stringify doc
JSON.stringify(someData, undefined, 2)
It feels like a lot of effort to make it work properly in a project.
Not so easy to enforce and requires some workarounds for edge cases.
I've decided not to persue this direction for now.
That is really good explanation. Thank you.
But in typescript world is not the case: