- 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.
- 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.
Also, the transformed code (like all transformed babel) is most likely ugly and more verbose than using lodash's get, no?
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/baseG...
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.