I think this article should be retitled Why I avoid get-like functions in TS because every point relies on you having a type system in place. The lodash get function lends itself to a dynamically typed environment, and plays really well with functional programming paradigms in JS, like curried functions, partial functions, and composition, all supported by lodash as well.
For example, one of the better places I've seen it used was in an API that took in json objects from a variety of sources that were all formatted very differently. Using lodash's functional toolkit, we were able to compose a function that could reconcile all the different formats and have them ready for our production environment. Without a function that can pick properties from an object and set good defaults, you can't compose the workflow.
Without a function that can pick properties from an object and set good defaults, you can't compose the workflow.
That doesn't mean that the function has to be dynamic in nature and not statically analyzable, and that applies to what you said in the paragraph above as well.
The dynamic approach will likely be shorter, sure, but it's a trade-off. You are trading a preferred code structure for fewer compile time guarantees.
If that's a trade-off a team is comfortable doing or it makes sense for a given problem regardless for whatever reason, then by all means.
I think this article should be retitled
Why I avoid get-like functions in TSbecause every point relies on you having a type system in place. The lodashgetfunction lends itself to a dynamically typed environment, and plays really well with functional programming paradigms in JS, like curried functions, partial functions, and composition, all supported by lodash as well.For example, one of the better places I've seen it used was in an API that took in json objects from a variety of sources that were all formatted very differently. Using lodash's functional toolkit, we were able to compose a function that could reconcile all the different formats and have them ready for our production environment. Without a function that can pick properties from an object and set good defaults, you can't compose the workflow.
That doesn't mean that the function has to be dynamic in nature and not statically analyzable, and that applies to what you said in the paragraph above as well.
The dynamic approach will likely be shorter, sure, but it's a trade-off. You are trading a preferred code structure for fewer compile time guarantees.
If that's a trade-off a team is comfortable doing or it makes sense for a given problem regardless for whatever reason, then by all means.
True, that’s a great point. Thanks for writing this!