that is fairly didactical article, I like how you introduce and develop the subject. There is indeed a lot of functional patterns we can already put in use in our code without needing a pure functional language. It is also quite exciting to see companies that are using fp-ts in earnest. Two years ago, I wish there would have been more example code of how to put all this to good usage. They came a long way since then in terms of docs and examples.
I could not however find the reasoning behind those assertions:
Hooks as a functional way to manage state dependencies.
How are hooks functional? Is it because they are functions? But they are effectful functions (with no indication that they are so, except the prefix use). The first time they run and the second time they run with the same argument they do not do the same thing, by design. That design is also why there are the rule for hooks to follow. I confess I haven't used hooks so I maybe wrong. But a year or so, that was the conclusion I reached. That may have changed.
Function components instead of class components
that's a bit linked to the previous point. A pure function need not be a class. But if you need a class, and you replace that by a function component, that means your function component is not pure. You can't replace something impure by something pure. Then the previous point applies again.
The bottom line is that functional programming is not about the syntax, i.e. it is not just about using functions (who doesn't?). The essential pattern is expressing computations as the composition of pure functions. Hooks, in that matter, are a bit confusing because they compose (when applied in order, and within a React context) but they do not compose like pure functions do. That's better than not composing, but still, I would not call using hooks applying functional programming principles.
But that does not really matter though. The more important point is that I am going to check Meeshkan, PBT being something I have a strong interest in :-) Automatic testing for any app -> that is exactly what I call a problem worth solving.
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.
Hello Carolyn,
that is fairly didactical article, I like how you introduce and develop the subject. There is indeed a lot of functional patterns we can already put in use in our code without needing a pure functional language. It is also quite exciting to see companies that are using fp-ts in earnest. Two years ago, I wish there would have been more example code of how to put all this to good usage. They came a long way since then in terms of docs and examples.
I could not however find the reasoning behind those assertions:
use). The first time they run and the second time they run with the same argument they do not do the same thing, by design. That design is also why there are the rule for hooks to follow. I confess I haven't used hooks so I maybe wrong. But a year or so, that was the conclusion I reached. That may have changed.The bottom line is that functional programming is not about the syntax, i.e. it is not just about using functions (who doesn't?). The essential pattern is expressing computations as the composition of pure functions. Hooks, in that matter, are a bit confusing because they compose (when applied in order, and within a React context) but they do not compose like pure functions do. That's better than not composing, but still, I would not call using hooks applying functional programming principles.
But that does not really matter though. The more important point is that I am going to check Meeshkan, PBT being something I have a strong interest in :-) Automatic testing for any app -> that is exactly what I call a problem worth solving.