4 ms·
From a user’s perspective, they’re not, they’re functions. That’s my point: they introduce a new concept, foreign to the language you’re writing in. There’s no
by rmccue 3y ago
From a user’s perspective, they’re not, they’re functions. That’s my point: they introduce a new concept, foreign to the language you’re writing in.
There’s not necessarily bad reasons for this, but the cognitive overhead of this is relatively high compared to existing language functionality.
- scotty79 3y agoThey are no more just functions than require() was a function. They use subset of function syntax to provide unique functionality. That's all. JS was full of such things already. Functions that are hooks (in traditional sense of the word) into some platform provided functionality. setTimeout(), fetch api, promise chains, jquery. You could say that all of those are just functions but you still need to learn what each does separately to get behavior you want. JS is not Lisp where a function means just one thing used always the same way with same restrictions. JS uses functions to construct idioms that introduce functionalities foreign to the core language. React hooks are just one such idiom. You may still argue that introducing yet another idiom is unnecessary burden. I personally like them very much. Component classes were imho very bad conceptual fit for react with a lot of intricate lifecycle methods and special fields. Hooks allow to simplify the core of it to just render that just runs every time it's necessary into which you are bringing in additional functionalities as needed.
- lispm 3y ago> JS is not Lisp where a function means just one thing used Lisp uses dynamic binding for that. (defun do-something () (funcall *something-to-call*)) (let ((*something-to-call* 'turn-the-light-on)) (do-something)) The behavior depends on the dynamic binding, which provides the context...