Intent to stop using 'null' in my JS code
github.com
github.com
Arguing that all `null`s should be replaced with `undefined`s in JS code also kind of implies to me that JSON should replace the `null` keyword with `undefined`, which just sounds crazy to me. Why store "undefined" values in serialized data? If it's not defined, don't define it... `null` allows you to convey that "this value may exist, but currently doesn't".
People should avoid using undefined, not avoid using null.
"this value was intentionally set to 'null'
in contrast to undefined:
'this value is undefined (e.g. was never [correctly] set)'
Though this doesn't apply to dealing with unsanitized json parsing.
// @ts-check
Plenty, though it depends a bit on what you count as JS standard library.
An object’s prototype may be null, so things like Object.getPrototypeOf(), Object.setPrototypeOf(), Object.create() and .__proto__ all deal with null.
Anything that is accessing a named property that exists on a class will yield null for no value, never undefined.
This is seen in DOM methods; things like Node.firstChild and Node.parentNode spring to mind as potentially null, and in each case it would be semantically quite wrong for them to be undefined—they are defined, as “no value”.
conceptually I think so, but I am not sure how much it actually helps with the language ergonomic.
in hindsight I think undefined should have been more powerful, eg setting a property to unrefined should effectively remove the property from an object (which would also affect the prototype chain)
Absolutely not.
Null means it knows what you’re asking for, and there’s no value.
Undefined means it doesn’t know what you’re asking for. (This includes function calls that don’t return a value, since you’re asking for a value that wasn’t produced—again different from null, which is explicitly producing a value.)
Node.firstChild being null for a node with no children is absolutely correct. Undefined would be incorrect.
Seeking past the end of an array finds elements that have not been defined, so undefined is correct and null would be incorrect.
For your Node.firstChild example, one could say that if a node has no children, then it's firstChild is not defined as it doesn't exist, and so undefined makes sense. You can construct similar plausible arguments for other usages of null, though you cannot do the inverse.
An undefined property would be one like Node.helloWorld, which doesn't not exist at all on the object.
“Hey node, what’s your first child?” “I don’t have a first child.”
Node.firstChild producing undefined is this conversation:
“Hey node, what’s your first child?” “Huh? What’s a first child? I have no idea what you’re talking about.”
A failing of JS lang that so many of these discussions have to keep happening.
For example, take Array.prototype.find(). Would be nice to have null here as a default return value. But what about Arrays containing null as a value? What about the case of null || false? What about the case of false || null?
There were a lot of design discussions to come up with those APIs...but I agree with you that technically, undefined should not exist. I'd rather have a syntax error being thrown than having to deal with undefined.
As undefined is specified as a hackaround as a global property, ... most of the implications are just a workaround, too.
Only in Javascript though. In Typescript this would be clear from the fact that the type has the property.
Of course Typescript is not Javascript, but nobody should use plain JS anymore.
It would be better to just error out and not allow the uninitialized usage at all, but unfortunately that's not possible in Javascript.
For instance, if I'm fetching some data I usually want to initialize the data variable as null for a couple of reasons.
1) null is not truthy, empty arrays and objects are
2) It shows that the variable is supposed to be filled, unlike undefined
When I'm using hooks in React this is very common.
You must give an initial value, and at some point in the future you will update it.
By setting the value as null initially I can easily check whether the variable has been filled or not. This is most important for initially rendering the UI.
> By setting the value as null initially I can easily check whether the variable has been filled or not
I don't think there's anything wrong with this but it does mean your variable can be in two states~, one where "it shows it should be filled" and one where the value is present and can be used.
You can use null for this if you want and most programmers will understand these states. You can also choose to make this even more explicit by creating a type that expresses this.
example in Kotlin but you get the idea (applies to any variable in any language)
sealed class ThatVariableYouCareAbout {
object ShouldBeFilled: ThatVariableYouCareAbout()
data class HasBeenFilled(val x: String): ThatVariableYouCareAbout()
}
// usage
fun test(thatVar: ThatVariableYouCareAbout) {
if(thatVar is ShouldBeFilled) {
//
} else if(thatVar is HasBeenFilled) {
}
}
All that being said, null is generally understood to have this meaning~ and I have/do use it but with an understanding that it's of lazyness/not wanting to be overly verbose (language consideration).
The case you are describing is very familiar to me (rendering UI with initial states through a framework like react) and having an explicit type for the initial state is the ideal, or at least the most explicit, solution.
Option works for 2-state variables like this
https://en.m.wikipedia.org/wiki/Option_type
If you are using TypeScript (TFA mentions it), fp-ts provides a good functional programming layer. Although if you aren't already familiar with functional programming it's going to be hard as the documentation is rather lacking.
I would go even further that even if the semantics are a little clunky (wrap/unwrap) any programming language can implement Option.
If the FP community wants to say that impure languages have been "doing FP" for decades then great! The religious war is over! We can happily have mixed paradigm languages and move on. But that's not what I'm seeing.
As an aside, TypeScript is very unsafe by default, and still relatively unsafe with strict mode enabled. Stringent fp-ts usage bypasses these issues.
Is it? I have been using Typescript more and more these last few years, and lately haven't really experienced any issues where it's type system failed me.
To clarify, I'm not trying to argue against your point, genuinely curious to learn if fp-ts can really improve my code quality in production.
Beyond that there's functions that throw/reject doing so outside the type system, something solved by Either/Option/similar types in fp-ts.
The biggest benefit of fp-ts though is that it makes you think functionally. If you're dead set against that, then there are plenty of other libraries that give you types/wrappers like these without having to use pipe/flow (two functions you'll want to use before anything else in fp-ts).
document.getElementById("asdf") // returns null;
document.getElementsByTagName("asdf") // returns [];
document.getEleemntsByTagName("asdf")[0] // returns undefined
document.getElementsByTagName("body")[0].getAttribute("asdf") // returns null
//
document.getElementsByTagName("input") // assuming not empty for the next several lines
document.getElementsByTagName("input")[0] // Element object
document.getEleemntsByTagName("input")[0].value // returns "" as valus is implicitly an empty string if not supplied
document.getElementsByTagName("div")[0].value // returns undefined even though the element is present but expresses an inference to an unsupported property
Here are the rules I use:
* undefined is a value where a value is never before assigned. Yes, you can do stupid things in opposition to the default such as arbitrarily assigning undefined or even redefining undefined to an assignment, but those footguns are not be accident.
* null is a value that is explicitly assigned.
If you program with those assumptions in mind you are safe 99% of the time given default language constructs, which doesn't account for the intentionally bad decisions other people make. This also helps with troubleshooting because when an error is encountered due to a null or undefined value the assignment distinction helps to diagnose the problem.
As you said,
undefined == I just don’t know what the value is
null == I know that there isn’t supposed to be a value here.
In 10 years I’ve never come across a situation where I found that distinction useful.
Null should mean in most cases that the data you wanted to access was invalid, but you can expect it to exist there in other circumstances.
Neither are a guarantee in JS, and you can find counterexamples for the counterexamples of the counterexamples, but that's the intention behind each.
For everything else, use false to “explicitly assign it”, you don’t need a third type.
Then you still have null, you’re just spelling it funny while confusing all the other developers who have to deal with your code and making it incompatible with language constructs like the nullish coalescing operator.
If the concept you are trying to express is “null”, then please use null to represent that instead of bringing in a poor substitute like an overloaded false.
Found? string
Not found? undefined
You were telling people to use false and that’s what I was responding to. That’s why I quoted that part in my comment.
> document.getElementsByTagName
For what it's worth I usually wrap these functions to e.g. throw an error if they don't find any items as that's what you usually want to happen but forget to write checks for. It's rare I'll use getElementById and expect it not to find something.
Lots of undefined + null values crop up from situations like this where you want to fail when something you expect to be there isn't found e.g. file handling, dictionaries, web requests.
It's a no-brainer to use TypeScript as well if you want robustness from these kinds of bugs, where returning undefined or a value is more practical because TypeScript will force you to check for undefined. I don't understand why anyone would willingly give up to type checks like these as it's obvious to me you can't compete with automated checking.
const w = (fn, _) => function(...args){
return (_ = fn(...args)) === null ? undefined : _;
};
document.getElementById = w(document.getElementById.bind(document));Returning undefined for null, as well as changing dom functions is a great way to ensure unintended side effects will creep into your code.
foo
//Uncaught ReferenceError: foo is not defined
o = { foo: undefined }
o.foo
//undefined
o.hasOwnProperty('foo')
//true
a = []
a[0]
//undefined
foo
#NameError (undefined local variable or method `foo' for main:Object)
defined?(foo)
#=> nil
o = Object.new
o.foo
#NoMethodError (undefined method `foo' for #<Object:0x000055f2f4e56e78>)
a = []
a[0]
#=> nil
def foo(value)
end
foo
#ArgumentError (wrong number of arguments (given 0, expected 1))
def bar(value:)
end
bar
#ArgumentError (missing keyword: :value)
I think reimplementation is a great way to uncover how things work, Ruby "fix" for property access
http://sergeykish.com/ruby-like-javascript-undefined.rb
Anyone knows how to relax arity?
For example, a couple years ago GraphQL specifically added support for the difference between undefined and null, and it was a good change. An optional field on an input type can be left off (in which case it is undefined) or it can be explicitly set to null. For a mutation, these have very different meanings: undefined means "don't update the property" while null means "update the property to null (which usually means 'delete')". These are very different things.
This thread, https://github.com/graphql/graphql-js/issues/133, is a good overview.
That is pretty humorous, null means make it undefined, so I guess false will need to mean make it null, and true can mean make it false?
The general problem is trying to get enough metadata directly into the language to manipulate it's own programs with such metadata. Of course this never works it just goes to an edge case so absurd that absurd syntax stays reserved for things with meta operations so they can work on most things yet not themselves or each other.
Let's say I have an object that represents an object in the DB, and one of the properties on that object represents an relationship to another entity which may not always be there. Then setting null on the object would mean set the corresponding DB column to null. How is that a discrepancy?
The problem with JS isn't that it doesn't really need null, it's that it doesn't really need undefined, but now that undefined is there it's impossible to rip it out. Most other languages that have null also have a separate concept of "doesn't exist": accessing a non-existent property would throw an exception, not return null, and for example you could tell the difference between whether a Map has a value at all vs has a null value by calling the equivalent of map.containsKey. Point is it is often necessary to tell the difference between "object doesn't have a property" vs. "property is null", and for better or worse (I think mostly worse) JS uses undefined to distinguish between those cases.
A new patch must follow, etc. Homoiconic languages and channel protocols are crafted to avoid this kind of meta rat races with their own representation.
null is actually the null object, so if an object is not expected the use of null is wrong, a key should exist but it's value is undefined. AFAIR even most DOM operations are correct in this distinction.
undefined as a value does not mess with Object.keys or hasOwnKey.. it truly is what it claims to be and is truly distinct from a never existing value in JS.
JSON is buggy, but we knew that. Trying to get metadata on the data channel instead of the opposite is buggy, but we knew that too.
Better things exist to implement a proper interface today, i.e. one can use Symbol to distinguish current runtime metadata that truly can not collide with the data.
A> Using X to mean `delete` is using up X such that you can't work on items that use X.
B> I checked and no one really uses X.
A> now you use X!
B> I checked and no one really uses Y, I'll use Y for X where X would have really meant X.
..
It doesn't mean null is good, it is simply available. A good meta has entirely different properties than null and those properties get you out of that treadmill.
But otherwise I just leave undefined to play the role of "this optional argument wasn't defined" and null for everything else. I like null because You have to specifically set something as null. I can run into undefined through typos and such. I dont think you can accidentally hit null.
P.s. This reminds me of the one time in Python I thought, "Damn I wish I had both undefined and None". I needed to know if a user was omitting an optional argument or passing an explicit None into it. Ie. This data is optional and the data might be "None". I ended up using kwargs which weakened my function as it nolonger described all the possible arguments.
> But otherwise I just leave undefined to play the role of "this optional argument wasn't defined"
And the reply is saying that's how JSON uses it too. Anything set to undefined will not be serialized, as if it were optional and not defined.
Sorry I was wandering all over.
Null is:
>> JSON.stringify({"foo": undefined});
"{}"
>> JSON.stringify({"foo": null});
"{\"foo\":null}"Again: In the vast majority of cases. I'm sure you'll find your exceptions.
The second form makes it explicit.
On the first case, the parser that's getting the data may want to calculate a sensible value. On the second one, it's clear the value is known.
Consider partial object updates. "null" means "explicitly set a field to null", whereas undefined means "don't change the value of the field". The distinction is meaningful.
Sounds like kindof like an Optional<Optional<Value>>. An optional is just a container of at most one element, so you could emulate that with a singleton list, having None mean not specified, [value] be value, and [None] be explicit lack of value.
Maybe.
You have to know differences between those when coding in js/ts/flow. Ie. no 4. has implications when iterating ie. Object.keys({ foo: undefined }).length === 1.
Education around those - yes, but blacklisting null? Sounds a bit silly, however I agree that most developers overuse null when they actually mean undefined.
One example in code where null vs undefined can be used is sql.update(table, where, { foo: null, bar: 1 }) - meaning update foo to null vs sql.update(table, where, { foo: undefined, bar: 1 }) - where undefined means, don't do anything with that column. This helps a lot because it's much more verbose to conditionally construct object with a property or without it, however it's easy to set it defined/undefined.
So ‘class undefinedDivideByZero extends InvalidType’. Then just check if a value is an instance of InvalidType. Then you can create much more specific invalid types.
If you have to account for 3 anyway, might as well account for N, and then create more information rich types.
Is there a name for this pattern?
try{
}
catch(SQLException ex) { }
catch(MathException ex) { }
What I'm looking for is a name for a pattern where a function returns (typeof ExpectedType | typeof InvalidType). Say it's a pipelined compiler and you want all the passes to continue even with InvalidTypes, and then at the end of the pipeline the result is a structure of the correct shape, but there may be some "holes" filled with InvalidTypes.
So one way to say it is exception types without the Try/Catch.
You're thinking of "try ... catch", but that's not what I'm talking about. What I'm talking about, and what I wrote, was "exceptions", i.e., objects that signify you're dealing with an exceptional case.
> Nulls and undefined are about types.
Anything that can be checked with instanceof, as I'm alluding to and as described in the first comment, or cross-checked by comparing a tag against constant, as in the case of node types in the DOM, is "about types".
What you describe as "just check[ing] if a value is an instance of InvalidType" is a straightforward restatement of how to represent an exception and handle it. Give it extra fields with further details, etc. This is widely used, it's just not widely used in in the NodeJS world, but that has more to do with the dubious influence that people like OP have, and all the programmers who try to emulate his style.
So far just context dependent. If the target is csv, generally just “”. If JSON, one of the existing types. If DSL, a discrete term from a custom grammar.
> but readability is poor when every error must be handled many times instead of implicitly returning to callers.
I should clarify that I'm only using these types for parsing and transformation pipelines and not as a general replacement for exception handling—in other words only in places where you'd have to already worry about undefineds, nulls, and NaNs.
If you use TypeScript and TSLint, there's also a rule for that: https://palantir.github.io/tslint/rules/no-null-keyword
If there is an interface: `interface ISomething { x?: string };` and obj of this interface to have `obj.x = undefined` instead of `delete obj.x`.
Writing methods: `function x(param0, param1?, param2?) {}` to be used as `x(1, undefined, '2');` instead of creating the func as `function x(param0, option: { param1?, param2? })` and using as `x(1, { param2: '2' })`.
Returning undefined from a function: `function x(): undefined { return undefined; }`, instead of `function x(): void { return; }`.
Mixing the meanings of `undefined` and `null`, can bring a lot of troubles for JS devs when they use `Object.keys` or using `arguments` in function. IMHO If we keep that `undefined` means missing while `null` means no value, then we will have better JS code, using: `'x' in obj` instead of `obj.x === undefined` or `typeof obj.x === 'undefined'`, `delete obj.x` instead of `obj.x = undefined`, `obj.x = null` and then `obj.x === null` instead of `obj.x == null`.
> If there is an interface: `interface ISomething { x?: string };` and obj of this interface to have `obj.x = undefined` instead of `delete obj.x`.
In typescript additional properties are not a problem. Since it is using structural typing. In most cases spread and restructuring are better options for merging/overwriting and deleting. It is safer and easier to reason about.
> Writing methods: `function x(param0, param1?, param2?) {}` to be used as `x(1, undefined, '2');` instead of creating the func as `function x(param0, option: { param1?, param2? })` and using as `x(1, { param2: '2' })`.
I am not fan of creating functions taking options objects as argument. In many cases is better to create specialized functions
It’s somewhat reassuring to see these comments here because at the time, I couldn’t deny that my solution isn’t ideal. At the same time, I know that favouring a less explicit approach to describing empty values is inevitably even more confusing - there has to be some way to indicate why something is empty. It’s still hard to program with a solution you know isn’t ideal... I really wanted a better answer or to find a better way forward with the reviewer, but in JS land it seems like an unfortunate but viable way to work.
All you need to do is use a condition like `v == null` or `v == undefined`. I like the first one more because it's shorter, but both are equivalent to `v === null || v === undefined`
And you can ignore the distinction then.
But I'd just love to tear it down and start again.
For something that's supposed to be a universal programming language, it's got so much stuff like this that makes it so unfriendly to newbies.
Emscripten can produce js as well as wasm, so you can build both and deliver according to support.
what's another one?
That's just one example of things in JavaScript that are poorly named for people to guess what they do.
Now, explaining Ruby's collect/detect/inject/select/reject, that's a whole different matter...
Automatically creating a variable (with global scope) if you attempt to use a variable that doesn't exist.
Semicolons are optional, except when they aren't.
== and === (at minimum they should be reversed)
I just tested this as I think you're describing & it didn't create a global var. Could you give an example?
*Edit - recursive rather than no-op, to make it do something that people might abuse.
> we cannot remove null from JavaScript, but we can pretend it doesn't exist
Even if it does become general convention to not use null, as a developer, you cannot depend on that convention and skip null checks in favor of undefined, because null is deeply engrained into the language itself.
So... we can't really pretend that it doesn't exist
So if anything, you should not set something as undefined, but you can update something as null.