3 ms·
> You can certainly replace most hooks with static return values. "most" is not good enough. The idea of PFP is precisely that there is no exception, otherwise
by valenterry 3y ago
> You can certainly replace most hooks with static return values.
"most" is not good enough. The idea of PFP is precisely that there is no exception, otherwise all guarantees are void. If I cannot rely on an expression to be referential transparent, then it means I have to look into to find out - and with that, the advantage of PFP goes through the window.
> The order of hooks matter in the same way that the order of IO binds or the order of Futures/Promises awaits.
The difference is that if you create an effect in a PFP style (like in Haskell), the effect itself doesn't do anything. You can now combine that effect with another effect in some way, e.g. by sequencing, which means first effect A and then afterwards effect B is executed. Yes. But what you get back is, again, an effect that doesn't do anything. So what you need to do is to build a datastructure of effects.
Do you do that with hooks? I don't think so. With hooks, you call one, then call another, and yeah, the result depends on the order just like with an effect monad like IO. But the difference is that once the line of code that calls the hook is executed, something happens and the world has changed. This is not true when you can the line of code that builds the datastructure for the effect execution.
You would have handle hooks like promises for this to work in a PFP way. But maybe I misunderstand and you can clarify it with a code example?
Otherwise, I just think it's about terminology. I agree that there is a relation between the two things, but we shouldn't give it the same name, because it is still not the same concept.
- WorldMaker 3y agoHooks definitely build a complex data structure. They don't actually run immediately/imperatively. Even `useEffect(callback, undefined)` (no defined dependencies) which gives the illusion that it runs "immediately" on every render is still an illusion of sorts and there's a complex scheduler apparatus feeding on the data structures under the hood that useEffect builds. The data structures that Hooks build in React gets built in a strangely bound, somewhat liminal `this` space so it effectively "disappears" in JS. That's certainly not how I would have built it. You are right that I probably would have used something more like JS Promises, given the choice. But I didn't build React's Hook systems, I'm just an outside critic. I'm very happy to agree that use of `this` bound things is about as impure functionally as you get in JS. (That said, it is a very JS solution that predates React and gets to old debates of whether or not JS is truly "OO". Prototypical OO is a gray space between OO and functional paradigms.) Hooks are never imperative, even in the most complex multi-hook components. They use and build data structures. Those data structures are mostly hidden from view and hard to inspect, but they exist.
- valenterry 3y ago> Hooks definitely build a complex data structure But you don't. It is react that builds the datastructure in the background, not you that builds and controls it. Hooks might be declarative, but this is actually orthogonal to being pfp or not. All of that is totally fine btw., there is no need for everything to follow a pfp style. It's a tradeoff. But we shouldn't call something pfp that isn't, even if it is closely related.