When we are building applications, we generally end up chaining the result of one function into another function, for example the following is not ...
For further actions, you may consider blocking this person and/or reporting abuse
Tiny note; the pipe function behavior is not entirely as described here:
With the current implementation, parameter 2 (or 3, or 4, ...) could also be a Function[].
For example, the following is valid, while it shouldn't be according to the above error:
I had some fun setting up my first CodeSandbox to demo this with 1 additional test (open the sandbox page separately, because the dev.to embed doesn't allow the tests to be shown...)
The reason is that the concat trick
const parameters = fns.reduce((output, value) => output.concat(value), []);will flatten just any value it gets, not only the first one.I'd say this behavior is desirable. It could be useful! But it's not as described.
I updated the check because actually the jsdoc expects just an array of functions to be in the
fnsvariable and so I updated the code accordingly, open to feedback but I think this is cleaner either way. I also added your extra test with some modifications to the article.Looks good to me! Now it's consistent.
The spread operator can also be used when calling pipe, like
pipe(...[f1, f2], ...[f3, f4], f5), so if you know for sure there will be an array (or arrays) of functions to input, that's still possible this way.Exactly. Appreciate the input though! 👍
Exactly which still matches the initial intention anyway and keeps things more consistent too.
pipe(()=>1, ()=>2, "nope");The phrasing suggests that the first argument must be an array of functions, which is not so. Should be something like: "All arguments must be functions"
Side note 1. Typical error reporting is typically phrased about arguments, not parameters, such as in TypeError
Side note 2. Please consider using TypeError which reflects the situations more precisely.
I am aware of the common
TypeErrorusage and I am also aware of the phrasing being slightly off but it is being used as a spread parameter and would always be an array when the parameters are provided which I why I ended up choosing this wording but I will update the text to be a little clear never the less. Thanks for the comment!Your wording causes me to suspect you are not clear on difference between parameters and arguments.
Arguments will be provided.
See stackoverflow.com/questions/156767...
Again, "All arguments must be functions" or something of that sort would be more correct.
No since the function does accept an array of functions or all arguments can be functions. The wording is correct thusly.
Pass a
Function[]and then all parameters as individual ‘Functions` and it works both ways, heed the wording.Furthermore parameters and arguments are the same thing in English and have been used interchangeably between people in every role I’ve ever had, thus such elitism over terminology helps no one. The point of the article is to be educational and introduce people to a new concept and it does that. The tests are there, the implementation works exactly as it should and the terminology is accurate. Such pedantry is unwelcome and wholly unnecessary from your side in this case 🤷♂️
Correct! My mistake. First element of
fnscan be array of functions. You see? Easy. "My mistake". No shame in this. Everybody does mistakes. I did miss the functionality ofconst parameters = fns.reduce((output, value) => output.concat(value), []);.... and as sad as it is, all of them were wrong. How much evidence you need to be convinced that this is incorrect?
@paramin jsdocInstead of correcting your colleagues, you are ignoring opportunity to learn. Stop for a minute and think about this.
Being correct and using terminology consistent with MDN in an article that people are supposed to learn from does help ... a lot.
Being incorrect and defending that definitely does not help.
Doesn't mean it should ignore terminology.
Not covering
fns[0]being an array, which is not a very good example to learn from or reference in an argument.Not true. How can I convince you otherwise?
My aim is for programmers in general to be more professional. I think it will be a better world. Articles that people are supposed to learn from are the place to use correct terminology.
Learn from Kabir: "Uptil now, I thought that arguments and parameters were the same. But I just looked them up on the web again and understand the difference now. Shall correct it."
Your argument about arguments vs parameters is whatever. I know the difference, I learned it years ago as did most developers but the difference between you and I is that I accept language evolves and is used differently to how it is “standardised” every day. People are not technical books nor are they pedants about it like you seem to be. If people want to say one thing or another, so long as it is understood clearly by all parties, I couldn’t care less what terms they use and neither do most reasonable people.
“ Being correct and using terminology consistent with MDN” - sure thing, tell you what, I’ll just copy paste everything from there next time 😂
“Not covering fns[0] being an array, which is not a very good example to learn from or reference in an argument.“ - Firstly the code is covered on all branches and lines so I don’t care plus even if it wasn’t at 100% I’d be fine with 80%+, even in TDD the aim isn’t 100% coverage, you should know that being such a proficient reader of technical documents. Secondly I could add an example for illustration but I chose not to although I may change that stance in a future update if I do one.
“My aim is for programmers in general to be more professional. I think it will be a better world. Articles that people are supposed to learn from are the place to use correct terminology.“ - correct to you coming from a formal and standardised world but that’s not the world we live in and to be accessible to the most people possible, simple and understandable language used on the ground will always be preferable to me.
I’m finished with this conversation, I appreciate the comment but I’m finished talking about such pedantic things.
very good! I've been doing similar techniques for a long time, just putting the functions in an array. One technique I do sometimes is to do something similar to a. reduce and the output of a previous function is input of a new one. I'm glad to see developers with this same line of thinking.
Glad you liked the article and nice to hear that you’ve been trying this style for some time, I find it super helpful in many situations also! Thanks for stopping by and leaving a comment 👏