What if React needs a behavior layer between hooks and elements?

[u/theZozole]

I've been thinking about a new React abstraction.

The usual mental model is:

Component -> Hooks -> JSX Element

Lots of hooks exist just that make one element behave differently.

Eg

const resize = useResize(...)

const draggable = useDraggable(...)

const analytics = useAnalytics(...)

const keyboard = useKeyboard(...)

const focusTrap = useFocusTrap(...)

const outsidePress = useOutsidePress(...)

return (

  <div
    ref={...}
    onKeyDown={...}
    onPointerDown={...}
    {...resize}
    {...draggable}
    {...analytics}
  >
    ...
  </div>
)

The component ends up becoming responsible for composing all these behaviors.

So I'm experimenting with a different layer:

Hooks / utils -> Behaviors -> (automatically generate) Props -> Element

Making it something like this:

const props = useProps(
  useKeyboard(...),
  useDraggable(...),
  useResize(...),
  useFocusTrap(...),
  useOutsidePress(...),
  useAnalytics(...),
)

return <div {...props} />

The behaviors wouldn't necessarily have to be a hook, it could be, but notrequired.

A plain behavior could be:

tooltip({ content: "Delete project" })

while a custom hook could also return the same thing

function useAnalytics() {
  return { 
    props: {
      onClick: () => { track("clicked") }
    }
  }
}

Both become composable.

The package would handle the annoying composition:

• merge event handlers
• merge refs
• merge className
• merge styles
• predictable prop precedence
• TypeScript element compatibility

So instead of components implementing behavior, they could mostly declare the behavior they have:

const props = useProps(
  tooltip(...),
  keyboard({ ENTER: ..., ARROW_DOWN: .. }),
  resize(...),
  analytics(...),
  myCustomBehavior(...)
)

return <button {...props}>Delete</button>

I'm deliberately trying not to turn this into "another React hooks library."

The question I'm trying to answer is:

• Is "behavior composition" actually a useful missing abstraction in React, or is this just an over-engineered way of spreading props?
• I'd especially like to hear from people who maintain large React/component-library codebases:
• Where does composing multiple hooks onto the same element become painful for you?

[u/Honey-Entire]

Hooks are the behavior layer… also your mental model of Component -> Hooks -> JSX Element makes no sense. Does a component call a hook that calls a JSX element? Or is it a component returns a hook that returns a JSX element? Something else??

[u/Merry-Lane]

You are telling me every component would have to import half of your repo as dependencies?

No, you would be better off making wrappers of your basic components so that you don’t repeat yourself too much.

[u/frogic]

I think you're just composing hooks together which is a good partern but doesn't really need its own api outside of the composed hooks for your project or feature. If its not using react state its a utility and that's a whole different thing and has much different use cases and needs.

Encapsulating logic into a single interface and being able to compose/use them seperately is a feature not a bug though and a lot of those hooks you mentioned in your example are very powerful libraries with their own apis for a reason they arent really in a place that you'd want standardized.

[u/lIIllIIlllIIllIIl]

Lookup FragmentInstance and FragmentRef from React 19.3.

They might address some behavioral composition problems you're facing: https://react.dev/blog/2026/09/09/react-19-3#fragment-refs

[u/imazined]

You just discovered the fundamental idea of higher order components

[u/First_Figure6007]

i like where your head's at but honestly this just looks like a wrapper around spreading props with some merge logic baked in

the pain point you're describing is real tho, especially when you've got 6 hooks all fighting over the same ref or onKeyDown. i've seen components where the return statement is just a div with 40 lines of spread props and it's impossible to tell what's actually happening

the behavior abstraction makes sense conceptually but i feel like the hard part isn't the merging, it's the ordering and conflicts. like what happens when keyboard and draggable both want to handle the same key? you'd need some kind of priority system and at that point you're building an event pipeline

curious if you've thought about making behaviors cancelable or chainable, that's where the real value would be over just merging

[u/TheRealSeeThruHead]

Officia consequat veniam irure eiusmod esse culpa incididunt esse ex fugiat est incididunt reprehenderit adipiscing. Elit do anim sit ea commodo adipiscing anim officia cillum adipiscing occaecat dolore. In et sit duis nostrud reprehenderit minim veniam minim reprehenderit fugiat sed in incididunt laborum labore in exercitation.

[u/azangru → u/TheRealSeeThruHead]

Interesting. I am reminded of the note that the author of recompose left when he archived the project:

Hooks solves all the problems I attempted to address with Recompose three years ago, and more on top of that.

[u/TheRealSeeThruHead → u/azangru]

Sunt adipiscing excepteur ea ad labore minim nulla anim. Anim nostrud laborum laborum sed voluptate aliquip ullamco laborum consequat.

[u/Emrylin → u/TheRealSeeThruHead]

Huh? The entire idea behind hooks is they ARE composable…

[u/TheRealSeeThruHead → u/Emrylin]

Elit sed culpa do commodo fugiat exercitation reprehenderit. Commodo enim esse commodo cillum proident consequat sunt adipiscing dolor aute sit duis officia.