useKeyedGroups; bending the Rules of Hooks with "keys for hooks"

[Nathan-Fenner]

useKeyedGroups makes it possible for libraries and application writers to composably and declaratively consume custom hooks that depend on dynamic props in cases that are currently forbidden by the Rules of Hooks.

View formatted RFC

See React issue #15893 for a brief overview of how this differs from similar older proposals. This proposal ensures that custom hooks remain composable and independent from one another: it focuses on allowing developers to do more with the custom hooks that already exist, without needing to totally restructure their applications.

[gaearon]

Thanks for the RFC! This is really well-written.

We either have to split our one component into multiple, which may involve a restructuring of our application, or we have to come up with a brand-new (much, much more complicated) useMultipleEventSource custom hook.

In general, splitting a component into multiple is the idiomatic way to do a lot of things in React. It doesn't make everyone happy (e.g. #197) but it's the way it goes, and all features are built with the assumption that eventually you'll want/need to split it up.

The feature of "keyed Hooks" is something we considered early on and even (if I recall correctly) implemented. However, we've thought of it only as a compiler target (to support component inlining) and not a user-facing API. It is, in our opinion, a bit too complicated and advanced to be used widely, and not worth it if it's used rarely.

In our experience, by the time you want something like this and you also can't split a component up, there's a big risk that having those Hooks stay isolated wouldn't have worked out anyway. E.g. you might begin to want to control them together in some way, accumulate information between them, compose their implementation details, and so on. So we think the subset of cases that would be well-served by this abstraction is just to small to justify the complexity (both in implementation and API surface) that it brings. That's the reason we rejected it last time, and I don't think anything made this more compelling yet.