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).
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.
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:
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.
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?
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.
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.
Will change that, thanks :D
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.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:
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 acan
property wich is anobject
.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?
{ user: { can = {} } }
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.
Makes sense!
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 anobject
, that it doesn't meet our requirements. Babel will however check againstnull
andvoid 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.
I meant performance of babel-compiled optional chaining vs baseGet. What author talked about in the post