This new JavaScript operator is an absolute game changer

[@zachhoward9336]

Good video mate. But you need to make the code bigger, you can barely read it on a phone

[@ItsTundeAlao]

Ohh right! I'll improve the zoom in the next vid. Glad you liked it 🤗

[@byailen]

Smells like go

[@ItsTundeAlao]

Which of the proposals do you prefer, and why?
1. const [error, data] ?= await mightFail();
2. const [error, data] = try await mightFail();
3. try [error, data] = await mightFail();
4. const [error, data] = await mightFail()?;

[@ventorious1145]

Definitely 1.
Two doesn't make sense.
Three is just wrong syntax.
Three is confusing since you can't validate the proper return type

[@emmyarty]

@@ventorious1145 two makes perfect sense. it's just a new unary operator, and JS already allows us to chain them. my only issue with it is that it shares the same keyword used in a control flow keyword while working very differently, it would need to use a different symbol or keyword as it's conceptually distinct even if it's related.

[@zergrush78319]

I like 2 because you don't have to assign it, you can use it in an expression, or in a function argument

[@IamTeaBag]

@@emmyarty Definitely agree with you. The '?' typically has to do with nullish values (nullish coalescing '??', optional chaining 'foo?.bar' etc). 1 and 4 would break that pattern. 2 makes sense because you are modifying the function's return value, just like 'await' does. It also doesn't force you to assign the return value, which could be handy when passing it somewhere else, like in a return statement or function argument. Or if it's a void function and you just want to allow it to fail silently.

[@byailen]

@@ItsTundeAlao I voted for 1st. But the second one is winning right now (: