5 ms·

Idx: Easily access deeply nested nullable fields in JavaScript

42 points by dikaiosune 10y ago

modalduality 10y ago
For context, this is a special case of Haskell's monads, which was also adopted by languages like Swift.
- aaron-santos 10y ago
  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 10y ago
    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.
- lacker 10y ago
  I wonder if there are other useful monads that would be useful to add to JavaScript.
  - belovedeagle 10y ago
    JavaScript already has monads, whether or not they are recognized as such. What JavaScript needs is either Haskell's syntactic sugar for monads, or, much much better, lisp-style (as opposed to cpp or m4) macros which can be used to implement that sugar directly. The macros could even be run during a one-time "compile" step on the server before being served; or not, if the cost of expanding them is less than the cost of sending expanded code over the network.
arrty88 10y ago
How does this differ from lodash's get method?
- jankassens 10y ago
  - 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 10y ago
    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?
    - glibgil 10y ago
      The function call overhead is in browsers and in node, but it is low. Inlining is a top priority for all JavaScript implementations. However, I wonder why lodash doesn't use a lambda. Parsing that path seems silly. It could just be a try on a lambda https://github.com/lodash/lodash/blob/master/.internal/baseGet.js https://github.com/lodash/lodash/blob/master/.internal/baseG...
    - 15155 10y ago
      > 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.
      - deleted 10y ago
        [deleted]
jessaustin 10y ago
As usual, coffeescript had it first.
morley 10y ago
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.
- lgas 10y ago
  FWIW, the existential operator is not unique to CoffeeScript, e.g. I'm fairly certain Cobra had it before CoffeeScript was created.
- evv 10y ago
  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
davej 10y ago
Relevant discussion of the existential operator on ESDiscuss: https://esdiscuss.org/topic/existential-operator-null-propagation-operator https://esdiscuss.org/topic/existential-operator-null-propag...
vmasto 10y ago
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.
- hzoo 10y ago
  I haven't heard of this either. I guess they just wanted something that worked with minimal effort. Making the plugin and writing/coming up with spec tests takes time but albeit a better effort for the community overall. Maybe we can get more contributors for this effort now? I made an issue for parser support, and after that we can create a babel plugin though https://github.com/babel/babylon/issues/328 https://github.com/babel/babylon/issues/328.
- yungsters 10y ago
  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.

42 points by dikaiosune 10y ago

modalduality 10y ago

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

aaron-santos 10y ago
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 10y ago
  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.
lacker 10y ago
I wonder if there are other useful monads that would be useful to add to JavaScript.
- belovedeagle 10y ago
  JavaScript already has monads, whether or not they are recognized as such. What JavaScript needs is either Haskell's syntactic sugar for monads, or, much much better, lisp-style (as opposed to cpp or m4) macros which can be used to implement that sugar directly. The macros could even be run during a one-time "compile" step on the server before being served; or not, if the cost of expanding them is less than the cost of sending expanded code over the network.

arrty88 10y ago

How does this differ from lodash's get method?

jankassens 10y ago
- 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 10y ago
  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?
  - glibgil 10y ago
    The function call overhead is in browsers and in node, but it is low. Inlining is a top priority for all JavaScript implementations. However, I wonder why lodash doesn't use a lambda. Parsing that path seems silly. It could just be a try on a lambda https://github.com/lodash/lodash/blob/master/.internal/baseGet.js https://github.com/lodash/lodash/blob/master/.internal/baseG...
  - 15155 10y ago
    > 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.
    - deleted 10y ago
      [deleted]

jessaustin 10y ago

As usual, coffeescript had it first.

morley 10y ago

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.

lgas 10y ago
FWIW, the existential operator is not unique to CoffeeScript, e.g. I'm fairly certain Cobra had it before CoffeeScript was created.
evv 10y ago
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

davej 10y ago

Relevant discussion of the existential operator on ESDiscuss: https://esdiscuss.org/topic/existential-operator-null-propagation-operator https://esdiscuss.org/topic/existential-operator-null-propag...

vmasto 10y ago

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.

hzoo 10y ago
I haven't heard of this either. I guess they just wanted something that worked with minimal effort. Making the plugin and writing/coming up with spec tests takes time but albeit a better effort for the community overall. Maybe we can get more contributors for this effort now? I made an issue for parser support, and after that we can create a babel plugin though https://github.com/babel/babylon/issues/328 https://github.com/babel/babylon/issues/328.
yungsters 10y ago
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.