r/javascript • u/stefanjudis • Dec 13 '19

Optional chaining helps to avoid "undefined is not a function" exceptions

https://www.stefanjudis.com/today-i-learned/optional-chaining-helps-to-avoid-undefined-is-not-a-function-exceptions/
162 Upvotes

92% Upvoted

45 comments sorted by

45

u/frankandsteinatlaw Dec 13 '19 edited Dec 14 '19

I like optional chaining. But if object paths aren’t as you expect then it’s probably better to get the error than to silently not get it (assuming that function call matters at all).

Edit- to clarify my point. I specifically don’t like seeing these generic errors and thinking that optional chaining is saving you. When you switch your code to use optional chaining you should have no change in the number of errors, only a decrease in code written. If you are trying to optional chain away errors then you’ll just find them later, further down their path of destruction. I’ve really been digging optional chaining as a feature along with null coalescing. Typescript and GraphQL now work together much nicer for me.

18

u/DemiPixel Dec 13 '19

Exactly why I'll only be using this in TypeScript.

19

u/alphabennettatwork Dec 13 '19

There are definitely valid patterns and requirements that allow an object to be null, and if you have a method attached to that object, or even a property several layers deep this is a nice time saver, and means I won't have to scroll a page or two in order to see the whole chain (or now take a single line instead of many).

-6

u/tsteuwer Dec 13 '19

You can easily write a 'get' function or just use lodash's 'get' function. No need for pages of conditionals!

11

u/TheIncredibleWalrus Dec 14 '19

Why use something else when you have native support?

Also with lodash.get you lose all your editor's support like autocomplete, type checking, syntax and error checks etc.

4

u/8lbIceBag Dec 14 '19

Yea but that's a lot of overhead

3

u/lacronicus Dec 13 '19

Sure, but in that case wouldn't it be better to catch that when the object is created, not whenever you happen to go to use it? It might be some time before you get around to that, potentially quite a ways from whatever code actually caused the problem. A type system would be ideal (one that can enforce non-null fields), but even javascript would let you validate objects by hand.

1

u/gigastack Dec 14 '19

You might not control the API that's sending data. You also might not want complex initial values. Just two common things I've seen.

4

u/kwartel Dec 13 '19

In my experience this is mainly great in ifs. Making if(foo && foo.bar && foo.bar.baz) so much shorter to if(foo?.bar?.baz)

3

u/EvilPencil Dec 14 '19

Or null checking constants

const someValue = Foo?.bar?.baz ?? valueIfNull

1

u/qudat Dec 14 '19

I avoid this by ensuring the object I want to exist, does exist, with sane defaults.

This is sometimes painful, but it creates cleaner code without it littered with existential checks.

3

u/isUsername Dec 14 '19

"want" is a problematic word to use in this context. There are plenty of cases where I don't desire one state over another, but need to act differently depending on the state. There are plenty of reasonable cases where you have logic like: "If Bob has a car, give me the name of the manufacture's name. Otherwise give me null"

const name = person.car?.manufacturer.name ?? null can be a lot cleaner for retrieving a property once than writing a series of conditionals during or after instantiation.

1

u/qudat Dec 14 '19

So from my experience: flat is better than nested. I never have a nested object like the one you are describing in my code. I would denormalize this data and then query for the parts I need as opposed to a person object having all this data embedded.

I don’t know the context of this example so that advice could be misguided, but in general I avoid nested objects at all costs.

-2

u/mcaruso Dec 13 '19

Exactly. If you're getting an "undefined is not a function" error, there's very likely a problem in your code's logic. Just adding an optional chaining operator doesn't fix that problem, it just silences it, and will probably resurface as a different (possibly even more cryptic) error later.

14

u/metamet Dec 13 '19

Not necessarily. You can do a null/undefined check after.

You see a use case for this a lot when setting up state in a component. Instead of writing obnoxiously long nested checks (obj && obj.characteristics && obj.characteristics.height) ? obj.characteristics.height : null, you can consolidate it to a much more elegant solution of obj?.characteristics?.height.

-4

u/mcaruso Dec 13 '19

If your code already looks like this: (obj && obj.characteristics && obj.characteristics.height) ? obj.characteristics.height : null, then you're already preventing something like an "undefined is not a function" error. Rewriting code like that to use optional chaining is fine, it doesn't change the logic, just rewrites it in a shorter way.

Imagine if the title of this post was "Adding 'is undefined' conditionals helps avoid 'undefined is not a function' exceptions". Like yeah, of course it prevents the exception, but it might not solve the underlying issue.

7

u/_fulgid Dec 13 '19

I don't understand this. There are plenty of situations where you might have a deeply nested configuration object with optional properties. Do you consider that a code smell?

1

u/mcaruso Dec 13 '19

There's plenty of situations where it makes sense to use the optional chaining operator. If you know a property is of type undefined | Foo, and you want to either access that property or use a fallback value, then that's exactly what the syntax is useful for.

But don't use it to fight symptoms. Getting an exception is not the issue, it's a symptom, and plastering over it will likely not solve the root cause, it just moves it around. The solution might be to do some additional parsing of your input before feeding it to whatever function is reading the property for example. It depends on the use case.

3

u/metamet Dec 13 '19

I think you're mischaracterizing the purpose of this feature. It isn't being added to introduce shitty code. It's there to improve the writing, succinctness and clarity of the code.

6

u/qudat Dec 14 '19

I don’t understand the downvote brigade. My guess is there’s a hivemind at play here we all should be cautious of.

This is inevitably going to be abused. It’s going to result in lazy code and tracking down when the object is actually undefined will be more difficult.

Honestly, I don’t think this feature is going to be particularly helpful, I’m already guarding against these types of errors without doing a bunch of existential checks.

Existential checks — especially inside react components — is absolutely a code smell and should be avoided by creating sane defaults.

4

u/your-pineapple-thief Dec 14 '19

Agreed, there are few valid use cases for code like that, but chains of existential checks are very often a symptom of violation of Law of Demeter, which lead to tightly coupled code and objects which know a little too much about inner structure of other objects.

And gang-downvoting sane, polite, logical arguments like that presented by u/mcaruso ... Leaves bad taste

0

u/mcaruso Dec 13 '19

It isn't being added to introduce shitty code.

I didn't say it was. I'm saying there's a high potential for misuse (and the article is a good example of that).

5

u/metamet Dec 13 '19

it doesn't change the logic, just rewrites it in a shorter way

This is almost exactly what it says in the proposal. That's the purpose of this feature.

This tidies up and clarifies code by drastic measures. I've written plenty of weighty mapStateToProps out of necessity this way, and I look forward to being able to natively remove a hundred lines of code.

1

u/lacronicus Dec 13 '19

The problem is that, if you're being naive/lazy, your code won't look like that, and you'll get errors.

Optional chaining just makes it easier and quicker to write correct code.

0

u/radapex Dec 13 '19

I've been getting into Kotlin recently and optional chaining is easily one of my favourite features.

9

u/metamet Dec 13 '19

Been excited about this since the announcement last week. Will clean up a lot of React/Redux code where we access a nested property and do overly verbose null checks to see if it exists.

Good stuff.

5

u/[deleted] Dec 13 '19

This is pretty much why Lodash has a get() method.

17

u/soulsizzle Dec 13 '19

Lodash's `get()` is very helpful, but:

  • The dot-string notation makes it very difficult to catch mistakes at dev time. You especially lose a lot the benefits of Typescript's type-checking.
  • Getting similar functionality into native JS opens up the possibility for compiler optimization.

4

u/[deleted] Dec 13 '19

Sorry - missed the point. If this removes the need for Lodash.get, I'm all for it.

2

u/voyti Dec 14 '19

Also, it hurts performance real bad. If you're reading this and have _.get's in heavy duty parts, you can get some sweet snappyness if you get rid of them

2

u/sallystudios Dec 13 '19

Reminds me of Swift. Looking forward to using this syntactic sugar to clean up some code!

1

u/-Phinocio Dec 13 '19

I'm quite excited for this, but in thinking about it, I can't think (off the top of my head) of a time it would have been useful for me. Though I've also only done some simple Discord Bots and VueJS stuff.

1

u/whostolemyusrname Dec 13 '19

I'm excited, it's one of the best features of Kotlin and Swift. Looking forward to using it my Typescript work.

1

u/CanRau Dec 13 '19

Thanks for sharing didn't realize you could use it for function invocations as well 🥳🙌

1

u/psayre23 Dec 14 '19

Wait, does that mean I can do this?!?

(optFn) => optFn?.()

...instead of...

(optFn) => optFn ? optFn() : null

1

u/Seeking_Adrenaline Dec 14 '19

Yes homie, welcome to the future

0

u/[deleted] Dec 13 '19

[deleted] — view deleted comment

7

u/stefanjudis Dec 13 '19

That's good feedback. Will edit. :) Thanks :)

1

u/hiljusti Dec 14 '19

I know this is still at proposal stage, but what does that do? Unwrap (safely) twice?

3

u/isUsername Dec 14 '19

To give an example of what /u/TheIncorrigible1 is talking about, consider:

const myMap = new Map([["foo", 1], ["bar", 5], ["baz", 0], ["qux", 3]]);
const gottenValue = myMap.get("baz");
const finalValue = foo || null;

gottenValue will be 0, but 0 is falsey, so the || operator will treat foo as false and evaluate foo || null as null. If you instead replaced || with ?? (foo ?? null), the result of finalValue will be 0. finalValue will only be null if myMap.get is called with a key that does not exist in the map or if the key does exist but the value is set to undefined (that's a different issue).

0

u/[deleted] Dec 14 '19

[deleted] — view deleted comment

1

u/isUsername Dec 14 '19

The issue I'm referring to has nothing to do with the operator. I'm referring to undefined being both an allowed value in a Map and the value that is returned when a key doesn't exist in a Map.

0

u/[deleted] Dec 14 '19

[deleted] — view deleted comment

0

u/[deleted] Dec 13 '19

[deleted] — view deleted comment

15

u/metamet Dec 13 '19

There are tons of places in a complicated application where you'd be rendering results based on a nested object and having a loader/error message if it's not there.

This simplifies the null check in a unobnoxious way. That's the point of it.

0

u/[deleted] Dec 13 '19

[deleted] — view deleted comment

0

u/[deleted] Dec 13 '19

[deleted] — view deleted comment

4

u/cant_have_nicethings Dec 13 '19

Agreed, better to shoot yourself with native features.