3 ms·

> Just because it's using functions doesn't mean it's functional. I never said it was. I said that hooks are a way of abstracting functionality that can't be e

> Just because it's using functions doesn't mean it's functional. I never said it was. I said that hooks are a way of abstracting functionality that can't be easily represented as pure functions. > they make it difficult to reason about which functions are pure and which are impure. Hooks have to have 'use' at the start of their name to be recognized by React. It should be instantly obvious which functions are pure and which aren't as long as you don't wrongly namespace your pure functions with 'use'.

mplanchard 6y ago
Thanks for replying! I did not downvote your comment, and I don’t think it deserves it. I do disagree with it though. > hooks are a way of abstracting functionality that can't be easily represented as pure functions. Yes, this is true, but in what is (IMO) a much less semantically clear manner than classes or a monadic interface. If a HookMonad or something similar were passed into components as an optional argument, I’d have very few complaints about hooks. > Hooks have to have 'use' at the start of their name to be recognized by React. Is this architecturally true or just conventionally true? It seems like this would just be determined by what they name the functions, which needs to be enforced by convention, but I suppose JS is dynamic enough that they could actually require the names conform to some standard. Either way, it doesn’t prevent people from importing them with other names, and even if it did, digging through a large function searching for “use” function calls seems much less obvious than the presence of an optional function parameter or the fact that a component is a class.