DEV Community

loading...

Discussion on: 😲🤯The most outstanding new feature in Javascript you need to know about: Optional Chaining

Collapse
chrisachard profile image
Chris Achard

YES! I've been super excited waiting for this in javascript since ruby added it in 2.3.

It's certainly a lot better than writing:

const x = this.props.data && this.props.data.myObject && .....

:)

Thanks for the pointer to the babel plugin!

Collapse
lampewebdev profile image
Michael "lampe" Lazarski Author

Exactly!

It is just way easier to write :)

No problem.

In general proposal usually, have babel plugins. It just sometimes hard to find them or you have to directly search for them :)

Collapse
qm3ster profile image
Mihail Malo

Is there any issue in Ruby with people overusing this feature and it becoming unclear what is nullable and what isn't?

Collapse
chrisachard profile image
Chris Achard

I think it can if you overdo it, yes (there are a few blogposts about that if you search for them) - but in general, for patterns like checking if a prop exists, etc, I think it's a good thing.

There might be an argument for: "if you need to do that regularly, then maybe you need a different abstraction or way of doing things"... but I haven't thought too much about that, so I'm not sure.

Thread Thread
lampewebdev profile image
Michael "lampe" Lazarski Author

I would say that the objects you are getting are not well designed.

If you need to check that often that it will be a problem.

I mean you can overdo everything, adding 200 npm packages even if they just do small things would also be a bad pattern. In the end, it is in your fingertips to decide.

Thread Thread
chrisachard profile image
Chris Achard

Right, yep - if you're constantly checking the same thing for null or not, then maybe you need to abstract that to give you a better framework/way to access it.

Thread Thread
lampewebdev profile image
Michael "lampe" Lazarski Author

Like always thinking is the key here 😉

Thread Thread
qm3ster profile image
Mihail Malo

IMO it lends itself to patterns like:

useWidth(this.props.data?.myObject?.width||100)
alsoUseWidth(this.props.data?.myObject?.width||222)

Not only are you doing extra branching, but by having defaults at the usage site instead of defaults site you could have inconsistencies.

Instead, on construction of the this, you could have

this.data=_.merge(defaultData, incomingData)

and then access all the properties unconditionally.
(You could also only merge in properties that already exist in defaultData tree, and perform validation at this stage, creating a very predictable this)