Deepcase Github

[Charlesetta Blare]

Its going to be really verbose in your bundles. The transformation made by babel in the state does not at all share the nullsafe access mechanism as lodash.get can do. Even if lodash is very/too heavy. It offers a more efficient nullsafe implementation while generating less code.

Ok but this time we can still look a few minutes to propose an implementation of a less trivial polyfill. This solution cannot really be applied in a world where the web developer turns into a Ko hunter.

As I see it, it will mostly be useful for things like options objects loaded from a JSON or YML file, where you have settings that may or may not be set, and often 1-3 levels deep. Or when loading documents from a MongoDB where you have set of properties and data that may or may not be there.

I'd really love this api:

someObject.lookup('some.really.long.property.path') - works essentially just like lodash.get or optional chaining. But what if you want to know why the lookup failed?

just print someObject.lastLookupMsg

As a failsafe, is the last lookup was successful.. this could be set to true (there is no meaningful message for successful lookups)

If the last lookup failed, it COULD just automatically console.log("Lookup failed: some.really.long is:", some.really.long, "some.really is:", some.really);

One issue is that passing an object lookup path as a string results in no syntax highlighting, you probably lose out on a bunch of other potential ide goodies, but from what I know they mostly don't apply to the main use case of check data from the user or from over the wire.

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:

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.

One comment against this that I've read, is that the Javascript engine can optimise inline code better. Using a function like lodash.get would invoke an extra function call (creating a new function scope) and run more complex logic for every statement that uses optional chaining. I'm not all that familiar with runtime optimisations myself, but it sounds plausible to me that checking if foo === null is a lot less expensive than calling a function like lodash.get.

Also, frequently repeated patterns (like === null) can get optimised and pretty heavily with gzip compression, so I doubt it would increase the download size by that much. Especially compared to the other hundreds of kilobytes of dependencies we usually have in our frontend bundles.

I know the Javascript engine can do a lot, but I find it hard to believe that it could optimise a while-loop with object assignments (like the lodash.get function) to be as performant as foo === null checks.

As you point out, the compression made by Gzip can compensate for the use of this plugin. However, I think that on a large web application, the entropy generated by these ternaries will still generate many KB.

In the lodash.get function, they use two other Lodash functions: castPath and toKey. The castPath function uses isKey and stringToPath. And so on. So in the end, for that one function you're importing all of this: github.com/lodash/lodash/blob/4.4....

Of course there are probably better, more concise options than the Lodash implementation, so I set up a quick test case with just the one function body as listed in your post: github.com/woubuc/optional-chainin...

I know this test case is far from perfect, and if you notice any mistakes I made, be sure to let me know so we can keep this accurate. But it shows that gzip compression really does optimise away most of the size of the repeated inline if statements, along with some optimisations that Babel itself does (see the bundles/babel.js file, it creates intermediate variables).

My opinion is along the lines of the general consensus: Optional chaining sure is compact... but VERY ugly if a polyfill is needed, along with an implicit acceptance of the risk of NULL / undefined data, which I am personally opposed to. As syntactic sugar goes, it makes things easier - but the ugliness of polyfills for JS gives me pause on adopting it now.

3a8082e126