
Idx: Easily access deeply nested nullable fields in JavaScript - dikaiosune
https://facebook.github.io/react-native/blog/2017/03/13/idx-the-existential-function.html
======
morley
As much as Coffeescript gets maligned, its best feature (that hasn't been
replicated, not even here) was the existential operator:

    
    
      friends = user?.friends?[0]?.friends
    

It would even work properly with functions:

    
    
      friends = getFriends?()
    

Which compiles to:

    
    
      friends = typeof getFriends === "function" ? getFriends() : void 0;
    

`idx` is not quite the existential operator, but it seems cleaner then
`_.get`'s string representation of your path.

~~~
evv
The existential operator has been introduced as an ECMAScript proposal[1], so
it will probably be included in future versions of JavaScript. The `idx`
function is just a temporary workaround.

When it gets added to the language, we can codemod away all usage of `idx` to
use the question-mark syntax.

[1] [https://github.com/claudepache/es-optional-
chaining](https://github.com/claudepache/es-optional-chaining)

------
vmasto
I don't quite get this, maybe someone can help. There's already a proposal for
adding the existential operator in ECMAScript, if you're going to require
babel transpilation why not simply write a babel plugin for the existential
operator and use that?

If the argument is "because the proposal is immature and could be withdrawn"
then the counter argument is that you have basically extended the language
already by providing a built in "idx" global much like, say, parseFloat, with
the difference that your function does not have any chance of actually being
in the spec at any point, unlike the existential operator, thus you're
basically masquerading the fact that using idx and the current proposal is the
exact same thing just with different syntax.

~~~
yungsters
At Facebook, we use Flow for type safety. We didn't want to have to introduce
support for the existential operator until all of the details were more
finalized.

Until then, we needed to have something that required minimal work (e.g.
changes to the parser) that could tie us over until the language had proper
support.

Also, we've been using this before the existential operator was formally
proposed. (I should've probably got off my lazy butt to publish this sooner,
but oh well.)

The plan is indeed to codemod this to the existential operator when it becomes
available.

------
davej
Relevant discussion of the existential operator on ESDiscuss:
[https://esdiscuss.org/topic/existential-operator-null-
propag...](https://esdiscuss.org/topic/existential-operator-null-propagation-
operator)

------
jessaustin
As usual, coffeescript had it first.

------
modalduality
For context, this is a special case of Haskell's monads, which was also
adopted by languages like Swift.

~~~
aaron-santos
Reminiscent of Clojure's get-in function as well. [1]

[1] [https://clojuredocs.org/clojure.core/get-
in](https://clojuredocs.org/clojure.core/get-in)

~~~
emidln
This is more like a clojure macro in that it runs via a compiler extension to
avoid the runtime call overhead of something like get-in.

Seeing how verbose and painful it looks, it's also an interesting commentary
on macros in JS.

------
arrty88
How does this differ from lodash's get method?

~~~
jankassens
\- Flow understands the semantics of it.

\- The path can only be given as a static function literal and there is no
function call overhead at runtime because of the bundled babel transform that
transforms the code to a bunch of ternary operators.

~~~
arrty88
Is the FN call overhead really that horrible in lodash? I didn't see any side
by side comps.

Also, the transformed code (like all transformed babel) is most likely ugly
and more verbose than using lodash's get, no?

~~~
15155
> Is the FN call overhead really that horrible in lodash?

The overall size overhead is what is horrible.

> Also, the transformed code (like all transformed babel) is most likely ugly
> and more verbose than using lodash's get, no?

Yes, but it also performs at what is probably as-close-to-optimal as possible.
The resulting ternaries are extremely easy to work with for even the most
basic of JS compilers. Source maps work well - I don't see this as a downside
at all.

~~~
jdd
Naw, Lodash is modular. You can cherry-pick its modules. It's less than 716
bytes (with lodash-webpack-plugin).

