I'm not honestly certain whether your comment is sincere or sarcastic. But I think the question evokes some interesting questions for FP methodology so I'll try to answer it sincerely. (And if your comment was sarcastic, then, well... you got me.)
As I tried to make clear in my article, I'm actually an ever-increasing fan of functional programming. And I think there's a ton value to be had in learning it and striving to make your code more FP-compliant (even if JS is NOT inherently a "functional programming language").
So from that perspective, there's absolutely some value to be had in creating those HOCs that wrap all of those nasty side effects and, in turn, leverage the pure functions. My "official" response to that approach is... do it - until it's annoying to do it.
You see, it's all fine-and-good to strive for pure functions. And, in general, I encourage the thought process that leads you to look at every function and think, "But... how can I make this pure???" But there are limits...
This is probably a subject for a separate blog, but if you've been programming for long enough, you might understand what I mean by "limits". When you start trying to think in FP terms, you will probably find that that there are some - or even, many - of your functions that can easily-and-swiftly be converted into pure functions. (In React, another way to think of these functions is as controlled components.) But there's probably a batch of other components that are not so easily converted.
I can tell you from experience that, when you start going down a theoretical rabbit hole (like: the "rabbit hole" of pure functions), it's extremely easy to follow that rabbit hole too damn far. In other words, there are some functions that, due to their very nature, are just damn-near-impossible to convert into pure functions.
When you find such functions, you often need to decide whether you want to A. redesign the whole damn app (which is almost never a good idea), or B. accept the fact that "purity" is a question for theorists - and, at some point, you still need to deliver working code on a manageable deadline.
A good, anecdotal example of this is: any function/component that uses session values. In theory, any function that leverages session values is, by definition, impure. In practice, even if you worship at the altar of pure functions, there are just some times when session values are absolutely positively necessary. So if you're writing the Holy Grail of FP, and you find yourself needing a session value, how do you handle it???
One answer may be to create HOCs. And that might be a viable solution. But I would ask you this: Does your HOC just split into two what might have previously been a simple, concise component?? Even if that "simple, concise" component would've originally leveraged session values (thus, making it "impure"), you may not have solved any problem by chopping it into a (impure) HOC and a (pure) component.
So in conclusion, all I'm trying to say is that your proposal might be a solid approach. But if you are breaking apart all of your "impure" components into HOC and "pure" components, you may find that you're just creating more work for yourself - all for the sake checking off some theoretical box that claims you write pure functions.
What do you think about wrapping the component with an HOC that does all the side effects so that the component remains a pure function?
I'm not honestly certain whether your comment is sincere or sarcastic. But I think the question evokes some interesting questions for FP methodology so I'll try to answer it sincerely. (And if your comment was sarcastic, then, well... you got me.)
As I tried to make clear in my article, I'm actually an ever-increasing fan of functional programming. And I think there's a ton value to be had in learning it and striving to make your code more FP-compliant (even if JS is NOT inherently a "functional programming language").
So from that perspective, there's absolutely some value to be had in creating those HOCs that wrap all of those nasty side effects and, in turn, leverage the pure functions. My "official" response to that approach is... do it - until it's annoying to do it.
You see, it's all fine-and-good to strive for pure functions. And, in general, I encourage the thought process that leads you to look at every function and think, "But... how can I make this pure???" But there are limits...
This is probably a subject for a separate blog, but if you've been programming for long enough, you might understand what I mean by "limits". When you start trying to think in FP terms, you will probably find that that there are some - or even, many - of your functions that can easily-and-swiftly be converted into pure functions. (In React, another way to think of these functions is as controlled components.) But there's probably a batch of other components that are not so easily converted.
I can tell you from experience that, when you start going down a theoretical rabbit hole (like: the "rabbit hole" of pure functions), it's extremely easy to follow that rabbit hole too damn far. In other words, there are some functions that, due to their very nature, are just damn-near-impossible to convert into pure functions.
When you find such functions, you often need to decide whether you want to A. redesign the whole damn app (which is almost never a good idea), or B. accept the fact that "purity" is a question for theorists - and, at some point, you still need to deliver working code on a manageable deadline.
A good, anecdotal example of this is: any function/component that uses session values. In theory, any function that leverages session values is, by definition, impure. In practice, even if you worship at the altar of pure functions, there are just some times when session values are absolutely positively necessary. So if you're writing the Holy Grail of FP, and you find yourself needing a session value, how do you handle it???
One answer may be to create HOCs. And that might be a viable solution. But I would ask you this: Does your HOC just split into two what might have previously been a simple, concise component?? Even if that "simple, concise" component would've originally leveraged session values (thus, making it "impure"), you may not have solved any problem by chopping it into a (impure) HOC and a (pure) component.
So in conclusion, all I'm trying to say is that your proposal might be a solid approach. But if you are breaking apart all of your "impure" components into HOC and "pure" components, you may find that you're just creating more work for yourself - all for the sake checking off some theoretical box that claims you write pure functions.
Question was indeed sincere.