My main concern is that jrsinclair focuses on everything through a "functional filter". I mean, they like functional programming and that's fine, of course.
But if you think about it, is this problem related to functional programming at all? I don't think so. It's simply the well-known, more general problem of "shared understanding and vocabulary in the code of a project". It's not about using flow or pipe or map. It's far more general than that. The same problem arises when you use any construct, any approach, even a single function or expression, that is unfamiliar to the rest of the team.
Sorry, but this is not a good article in many ways, Amrish.
If we focus on the concepts, on what is composition in general, the article is not good at all. Composition, as a programming thing is a very common word and is used for a bunch of different concepts. In your article, you refer to "composition" with no additional qualification, but you really mean "function composition". So you would do well to use the complete "function composition" expression at the very least in the title, but also almost everywhere in your whole text.
So, ok, it's "function composition" you're referring to. The next problem is that what you present as "function composition" is not that really.
The explanation you give is simply calling a bunch of functions in a way where you feed the output of one function to the next function and the output of that to the next and so on. You simply present an example like...
add2(multiplyBy3(reduceBy2(divideBy2(num))))
This is not really function composition. Function composition is actually that next step you take: creating *another function* from the ones you have and *then* using that function. So, function composition happens here:
const calculate = compose(add2, multiplyBy3, reduce...);
Similarly, your two "real life" examples which should explain so easily what function composition is fail to do so completely because they don't point out that composition at all.
Take the clothes example. You simply apply one calculation (discount) and then apply the next one (tax). There is no composition there. You simply have done one calculation and then another calculation. Now, the example could work, but you need to explain it properly. That is, you need to present the discount as an operation, the tax as a second operation and then introduce a "composed calculation" you could call final price or whatever (see further below for the code), which is composed from the percentages. Something *like* this (but please do not copy this verbatim):
"The first calculation is applying a discount of 50%. Then you have to apply a second calculation which applies 10% taxes. These two separate calculations can be merged into a single calculation if we compose them by simply applying a percentage of 55% to the original value. This single new operation is said to be the composition of the other two operations."
The second example describes a process where there isn't really a linear flow over a specific input. The process involves different pieces, different inputs and, more importantly, the various operations in the process are *not* separate. The process is the full thing; you can't really "compose" it in any other way or with any other operations. You can't blow air before closing the mould. The operation of "moulding glass into shape" is not a standalone operation. It is not a good example.
Finally, while this may seem a minor problem compared to the above, in the actual code examples you show, the naming is not good to help the reader understand the concept of the composed function.
That's because you don't give it a name. You simply call it "joinedFns" or "composedFns" which are really bad names. On the one hand the do not express the idea of what they actually do. On the other, why is the name in plural? It is, once composed, a single function; if anything it would be called "composedFn", not "composedFns".
But no, don't call it that. Instead give it a proper name. Even better, write proper examples where all names are significant. Take the shirt example and use that. Instead of "add2" or "multiplyBy2" write something like...
const applyDiscount = (originalPrice) => originalPrice * 0.5;
const addTaxes = (amount) => amount * 1.1;
// ... compose function ...
const calculateFinalPrice = compose([ applyDiscount, addTaxes ]);
const shirtPrice = 50;
const finalPrice = calculateFinalPrice(shirtPrice);
Hey, maybe you can even show *both* ways to show the difference. In one code block you write...
const applyDiscount = (originalPrice) => originalPrice * 0.5;
const addTaxes = (amount) => amount * 1.1;
const shirtPrice = 50;
const discountedPrice = applyDiscount(shirtPrice);
const finalPrice = addTaxes(discountedPrice);
console.log(finalPrice);
And then in the next block you reuse the same applyDiscount and addTaxes functions and write:
const calculateFinalPrice = compose([ applyDiscount, addTaxes ]);
const shirtPrice = 50;
const finalPrice = calculateFinalPrice(shirtPrice);
console.log(finalPrice);
This way you show that the result is the same, but that now you're doing that thing there with the functions, composing them into a new single function. And so readers will more easily understand where the difference is, and that "function composition" is precisely that thing you do with the functions.
First question I got, it asked for a "valid CSS selector" with a certain specificity.
I tried for a while. I couldn't figure what was wrong. There was a fairly long and obtuse parsing error below the input box. I tried different selectors all with the wanted specificity.
It turns out that I didn't have to write just the selector; it needed a full rule, even if empty.
The thing is this...
#someId p.class
...is a valid CSS selector. Meanwhile, this...
#someId p.class { }
...is a CSS rule (or sometimes ruleset). You can see https://developer.mozilla.org/en-US/docs/Web/CSS/Syntax for a more visual explanation.
In a gentler manner:
Please, don't post this. Sometimes you "update dependencies" and then post here. Other times you haven't made any changes at all for months and still post here again.
I mean, it's nice that you maintain your project. You can be proud of it, and I'm sure it's useful for some people. And yet, spamming sites like this doesn't really benefit you. For every person whose attention you might get, you'll probably piss off two or three more. Really, it's not worth it for anyone. Please.
I sincerely don't get the obsession about "X lines of code".
I mean, once I joined a project where the first thing they told me to explain the size/reach of the project was that it was about 5 MLoCs. They said it with a sense of achievement, like "This is a lot; we've done something big here". It later turned out that their numbers were quite old and the project was about 8 MLoCs. But what nobody said... what they didn't even want to acknowledge is that the code was a horrible mess where copy&pasting had gone rampant and unsupervised for years.
If the code had been cleaned and well kept, the actual significant size may have been probably something like 1 or 2 MLoCs, at most. Yes, a big project, but still quite the difference.
But then again... "something in 10 lines of JS"... is like, hey, whatever, just put it all in a single line if that's your goal. I mean, the code is almost as horrible at 10 lines as it is at 1 line, so if your goal is the number of lines of code...
I know, I know, "this is fun code". But, really, what is even fun about this code? Does it at least show or teach some "fun tricks" or anything clever, interesting, peculiar? Not really. It's just about writing some bad code in a specific number of lines.
The "10 lines" is so random and pointless that it even resorts to removing some newlines but not others to make it fit exactly 10. It feels silly.
So, to anyone reading this kind of article, I'd like to say: Please, ignore anyone who talks about the number of lines of their code. By itself, whether small or big that number means shit nothing. Instead, focus on writing good, clear, expressive code. And then, the fact that they mention the number as something relevant most probably means the quality of the code is pretty bad.
Sorry, but this is not a good article in many ways, Amrish. If we focus on the concepts, on what is composition in general, the article is not good at all. Composition, as a programming thing is a very common word and is used for a bunch of different concepts. In your article, you refer to "composition" with no additional qualification, but you really mean "function composition". So you would do well to use the complete "function composition" expression at the very least in the title, but also almost everywhere in your whole text. So, ok, it's "function composition" you're referring to. The next problem is that what you present as "function composition" is not that really. The explanation you give is simply calling a bunch of functions in a way where you feed the output of one function to the next function and the output of that to the next and so on. You simply present an example like... add2(multiplyBy3(reduceBy2(divideBy2(num)))) This is not really function composition. Function composition is actually that next step you take: creating *another function* from the ones you have and *then* using that function. So, function composition happens here: const calculate = compose(add2, multiplyBy3, reduce...); Similarly, your two "real life" examples which should explain so easily what function composition is fail to do so completely because they don't point out that composition at all. Take the clothes example. You simply apply one calculation (discount) and then apply the next one (tax). There is no composition there. You simply have done one calculation and then another calculation. Now, the example could work, but you need to explain it properly. That is, you need to present the discount as an operation, the tax as a second operation and then introduce a "composed calculation" you could call final price or whatever (see further below for the code), which is composed from the percentages. Something *like* this (but please do not copy this verbatim): "The first calculation is applying a discount of 50%. Then you have to apply a second calculation which applies 10% taxes. These two separate calculations can be merged into a single calculation if we compose them by simply applying a percentage of 55% to the original value. This single new operation is said to be the composition of the other two operations." The second example describes a process where there isn't really a linear flow over a specific input. The process involves different pieces, different inputs and, more importantly, the various operations in the process are *not* separate. The process is the full thing; you can't really "compose" it in any other way or with any other operations. You can't blow air before closing the mould. The operation of "moulding glass into shape" is not a standalone operation. It is not a good example. Finally, while this may seem a minor problem compared to the above, in the actual code examples you show, the naming is not good to help the reader understand the concept of the composed function. That's because you don't give it a name. You simply call it "joinedFns" or "composedFns" which are really bad names. On the one hand the do not express the idea of what they actually do. On the other, why is the name in plural? It is, once composed, a single function; if anything it would be called "composedFn", not "composedFns". But no, don't call it that. Instead give it a proper name. Even better, write proper examples where all names are significant. Take the shirt example and use that. Instead of "add2" or "multiplyBy2" write something like... const applyDiscount = (originalPrice) => originalPrice * 0.5; const addTaxes = (amount) => amount * 1.1; // ... compose function ... const calculateFinalPrice = compose([ applyDiscount, addTaxes ]); const shirtPrice = 50; const finalPrice = calculateFinalPrice(shirtPrice); Hey, maybe you can even show *both* ways to show the difference. In one code block you write... const applyDiscount = (originalPrice) => originalPrice * 0.5; const addTaxes = (amount) => amount * 1.1; const shirtPrice = 50; const discountedPrice = applyDiscount(shirtPrice); const finalPrice = addTaxes(discountedPrice); console.log(finalPrice); And then in the next block you reuse the same applyDiscount and addTaxes functions and write: const calculateFinalPrice = compose([ applyDiscount, addTaxes ]); const shirtPrice = 50; const finalPrice = calculateFinalPrice(shirtPrice); console.log(finalPrice); This way you show that the result is the same, but that now you're doing that thing there with the functions, composing them into a new single function. And so readers will more easily understand where the difference is, and that "function composition" is precisely that thing you do with the functions.First question I got, it asked for a "valid CSS selector" with a certain specificity. I tried for a while. I couldn't figure what was wrong. There was a fairly long and obtuse parsing error below the input box. I tried different selectors all with the wanted specificity. It turns out that I didn't have to write just the selector; it needed a full rule, even if empty. The thing is this... #someId p.class ...is a valid CSS selector. Meanwhile, this... #someId p.class { } ...is a CSS rule (or sometimes ruleset). You can see https://developer.mozilla.org/en-US/docs/Web/CSS/Syntax for a more visual explanation.