Agreed that the actual implementation of hooks is _relatively_ "simple" internally. I strongly recommend Shawn Wang's talk/post "Getting Closure on Hooks" [0] a

Agreed that the actual implementation of hooks is _relatively_ "simple" internally. I strongly recommend Shawn Wang's talk/post "Getting Closure on Hooks" [0] as a good dive into the implementation approach. That said, `hooks` as an argument wasn't chosen for a couple reasons: - It doesn't work for custom hooks, which need to be written as separate functions - Function components still receive the legacy `context` object as their second parameter. (The long-term migration plan is that someday they will instead receive a potential `ref` object instead, and that will allow removing the `forwardRef` API.) Dan Abramov wrote an extensive post on why various alternative hook API designs were rejected [1], including the design criteria and constraints that they were looking for. [0] https://www.swyx.io/hooks/ https://www.swyx.io/hooks/ [1] https://overreacted.io/why-do-hooks-rely-on-call-order/ https://overreacted.io/why-do-hooks-rely-on-call-order/