I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
Thanks for the post, I have had similar thoughts about this topic but it seemed like I was in the minority in feeling that way about these functions. I think it is seen and taught as the "modern ES6 way", but as you mentioned these are functions added for convenience/functional programming and not the new default for looping. I think the appeal is that it looks cleaner and the code can be shorter, but I'm a fan of easy to understand code as opposed to one-liners.
In addition to your examples, I have also seen some roundabout ways of using these functions when there is a simpler and more performant way.
A result set pulled from the database or API then immediately has a filter run on it. I think this is better suited for the database to do the filtering, I cannot think of a good use case for doing this unless it was not possible in SQL or in the API.
Converting a non-array iterable into an array for the sole purpose of using the map function on it. It seems like a wasted step when a regular loop will work on it.
Chaining/running all three (map, filter, and reduce) on the same array. I cannot remember the exact use case, so it may have been valid, but I'm confident there was a simpler and faster way to achieve the same result.
It has definitely been at the forefront of my mind for a while. I think whent he hivemind collectively says something is good or bad in the front-end community, it tends to spiral out of control and the true meaning of things is lost.
The ability to write shorthand (and harder to understand) code that looks like it is being submitted as a competition entry into a code golfing contest definitely seems to be associated with these methods. Admittedly, you can't deny it's not shorter, but I prefer verbosity whenever I can because I cannot stand it when developers try and be clever to save a few extra characters or lines.
A result set pulled from the database or API then immediately has a filter run on it. I think this is better suited for the database to do the filtering, I cannot think of a good use case for doing this unless it was not possible in SQL or in the API.
100%. I have seen this a lot as well. With the advent of GraphQL, filtering data like this is even easier now as well. Whenever I can use GraphQL queries, I always make sure my resolvers support additional parameters for filtering the data server-side instead of on the client.
Converting a non-array iterable into an array for the sole purpose of using the map function on it. It seems like a wasted step when a regular loop will work on it.
Oh, man, this makes me sweat profusely. I've seen this before.
Chaining/running all three (map, filter, and reduce) on the same array. I cannot remember the exact use case, so it may have been valid, but I'm confident there was a simpler and faster way to achieve the same result.
This chaining is known as the holy trinity in the functional programming community, chaining for some is like a religion they go to sleep at night and they have dreams about chaining their inefficient non-side effect producing functions while the performance drains from their apps.
[1,2,3,4].map(add2).filter(isDivBy(3)).reduce(+) doesn’t do anything until you ask for it.
Another example: x := [a,b,c].map(g).map(f) does nothing, but calling x[2] will return f(g(2)) (doing the calculation and caching it when called)
This allows you to work with things like infinite (or practically infinite) without the cost of running your calculations on infinite things.
It also allows the compiler/interpreter to optimize the f(g(x)) into a new function f•g(x). Example: f(x)=x+2; g(x)=x / 4; h(x) = (x/4)+2 Then f(g(x))==h(x) (coincidentally, this is why encrypting something multiple times is technically equal to doing it once with a different function)
Now that’s not to say if you know h ahead of time that you shouldn’t just write h. BUT, if you have a bunch of functions that do f, it’s often easier to reason about if you extract the logic that’s different and define g, g’, g'', g''', etc and just pass them in.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the post, I have had similar thoughts about this topic but it seemed like I was in the minority in feeling that way about these functions. I think it is seen and taught as the "modern ES6 way", but as you mentioned these are functions added for convenience/functional programming and not the new default for looping. I think the appeal is that it looks cleaner and the code can be shorter, but I'm a fan of easy to understand code as opposed to one-liners.
In addition to your examples, I have also seen some roundabout ways of using these functions when there is a simpler and more performant way.
map,filter, andreduce) on the same array. I cannot remember the exact use case, so it may have been valid, but I'm confident there was a simpler and faster way to achieve the same result.It has definitely been at the forefront of my mind for a while. I think whent he hivemind collectively says something is good or bad in the front-end community, it tends to spiral out of control and the true meaning of things is lost.
The ability to write shorthand (and harder to understand) code that looks like it is being submitted as a competition entry into a code golfing contest definitely seems to be associated with these methods. Admittedly, you can't deny it's not shorter, but I prefer verbosity whenever I can because I cannot stand it when developers try and be clever to save a few extra characters or lines.
100%. I have seen this a lot as well. With the advent of GraphQL, filtering data like this is even easier now as well. Whenever I can use GraphQL queries, I always make sure my resolvers support additional parameters for filtering the data server-side instead of on the client.
Oh, man, this makes me sweat profusely. I've seen this before.
This chaining is known as the holy trinity in the functional programming community, chaining for some is like a religion they go to sleep at night and they have dreams about chaining their inefficient non-side effect producing functions while the performance drains from their apps.
In lazily evaluated languages,
[1,2,3,4].map(add2).filter(isDivBy(3)).reduce(+)doesn’t do anything until you ask for it.Another example:
x := [a,b,c].map(g).map(f)does nothing, but callingx[2]will returnf(g(2))(doing the calculation and caching it when called)This allows you to work with things like infinite (or practically infinite) without the cost of running your calculations on infinite things.
It also allows the compiler/interpreter to optimize the
f(g(x))into a new functionf•g(x). Example:f(x)=x+2;g(x)=x / 4;h(x) = (x/4)+2Thenf(g(x))==h(x)(coincidentally, this is why encrypting something multiple times is technically equal to doing it once with a different function)Now that’s not to say if you know h ahead of time that you shouldn’t just write h. BUT, if you have a bunch of functions that do f, it’s often easier to reason about if you extract the logic that’s different and define g, g’, g'', g''', etc and just pass them in.