Discussion on: 😰 Optional chaining trap !

[stereobooster]

It's very effective.

This is ambiguous terminology (at least in this context). You mean it is very compact output. Not effective in sense performance. Most likely performance of verbose code will be better (you always need to measure to be sure).

babel plugin for github.com/facebookincubator/idx does the same.

[Antoine Caron]

Will change that, thanks :D

[Stephan Meijer]

idx works indeed similar, but it does provide a little bit less over overhead.

optional-chaining, 443 bytes vs idx, 254 bytes. As the original is only 83 bytes, they both come with an overhead.

I should be happy that optional chaining has reached stage 3. As we are using the proposal for quite some time now. But instead, I'm worried. I see it being heavily overused in some places, because it's so easy to use.

function CommentButtons({ user }) {
  return (
    <div>
      <Button disabled={user?.can?.reply}>reply</Button>
      <Button disabled={user?.can?.delete}>delete</Button>
    </div>
  )
}

Easy right? Both buttons are disabled if lacking the proper permissions. This however compiles down to 731 bytes and a lot of ternary operators, while we could simply reduce this down to something like:

function CommentButtons({ user, can = user ? user.can : {} }) {
  return (
    <div>
      <Button disabled={can.reply}>reply</Button>
      <Button disabled={can.delete}>delete</Button>
    </div>
  )
}

If it's your own code base. It's safe to make some assumptions. For example, to say that if the user is set, that it's guaranteed to have a can property wich is an object.

[Devin Rhode]

When browsers finally start shiping support for optional chaining.... the amount of bytes sent over the wire can decrease quite a bit.... but that's going to take some time right?

[Victor Vincent]

{ user: { can = {} } }

[Stephan Meijer]

I'm aware of that syntax. But defaults don't work for null values. As grapql tends to return null for missing data, I don't use that syntax that much.

In a real world scenario, I would have moved the assignment out of the arguments.

[Victor Vincent]

Makes sense!

[Stephan Meijer]

I took some time to create that peformance test you're talking about. But no, it doesn't perform better. Mostly, because it will check way more then required.

We as developers know that if user is not an object, that it doesn't meet our requirements. Babel will however check against null and void 0. While we could just check if it's "truthy". So the transpiled code contains at least twice as much checks as required.

I just published a small post, inspired by this one. If you're only interested in the performance, you can check the outcome here: jsperf.com/costs-of-optional-chaining.

[stereobooster]

I meant performance of babel-compiled optional chaining vs baseGet. What author talked about in the post