Why use this over extracting components?

[kevinpastor]

Why should this library be used instead of simply refactoring component into smaller and more reusable ones, that the React Compiler will probably have a better time optimizing them? Is there any benefit other that prop drilling that can often be solved by refactoring or the use of contexts?

I am not arguing in any way on the architecture of the library, the project itself or on the well written documentation, but more on the need that this library is trying to fill in.

Here is your example of nested hooks, quickly refactored in a way that would allow you to reuse the Post component as well as the Cat component.

import { useState, useTransition } from 'react'

type Category = {
  id: number
  name: string
  posts: { id: number; title: string }[]
}

const data: Category[] = [
  {
    id: 1,
    name: 'Tech',
    posts: [{ id: 11, title: 'Next-gen CSS' }],
  },
  {
    id: 2,
    name: 'Life',
    posts: [
      { id: 21, title: 'Minimalism' },
      { id: 22, title: 'Travel hacks' },
    ],
  },
]

function Post({ post, startTransition, setLikes }) {
  const [liked, setItemLiked] = useState(false)

  const toggleLike = () => {
    setItemLiked((prev) => {
      const next = !prev
      startTransition(() => {
        setLikes((c) => c + (next ? 1 : -1))
      })
      return next
    })
  }

  return (
    <li>
      {post.title} <button onClick={toggleLike}>{liked ? '❤️ Liked' : '🖤 Like'}</button>
    </li>
  )
}

function Cat({ cat }) {
  const [expanded, setExpanded] = useState(false)
  const [likes, setLikes] = useState(0)
  const [isPending, startTransition] = useTransition()

  return (
    <li>
      <button onClick={() => setExpanded(!expanded)}>
        {expanded ? '▾' : '▸'} {cat.name} {likes === 0 ? '🖤' : '❤️'.repeat(likes)} ({likes} like{likes === 1 ? '' : 's'}
        ){isPending && ' (updating...)'}
      </button>

      {expanded && (
        <ul>
          {cat.posts.map((post) => (
            <Post key={post.id} post={post} startTransition={startTransition} setLikes={setLikes} />
          ))}
        </ul>
      )}
    </li>
  )
}

export function NestedExample() {
  return (
    <ul>
      {data.map((cat) => (
        <Cat key={cat.id} cat={cat} />
      ))}
    </ul>
  )
}

[IamSAL]

Following

[brandonmcconnell]

Hey, Kevin.

This package specifically exists to allow developers to include nested state where they see fit. I am not officially suggesting this practice. In fact, in many cases, it makes the most sense to break a component out into multiple components for reusability, as you pointed out.

With that said, there are use cases where a package like this would be valuable— you may want to use a hook conditionally simply to wrap a very small piece of DOM state, like a single element, or to include state when iterating over an array that doesn't need to be reused. These are great use cases for RenderHooks or a similar package.

I wasn't surprised to find, after developing RenderHooks, that there are several other packages in the same problem space striving to solve the problem of nested component syntax. For this reason, the Meta team has been actively inquiring about the reasoning behind such packages to see if there are any affordances that can be made within React core to solve this issue in a better way.

You're not wrong to voice your concerns about the React compiler; they are valid. In most cases, the React compiler will have no issue compiling code that uses RenderHooks. However, RenderHooks will may prove problematic in certain circumstances, especially when rendering different content conditionally or when nested recursively.

For this reason, I am actively working on an overhaul of this package as a build tool plugin that will work regardless of your bundler and simplify the syntax greatly.

Before — ❌ extra syntax, render props, not compatible with React Compiler

const SimpleCounters = () => (
  <ul>
    {items.map((item) => (
      <$ key={item.id}>
        {() => {
          const [name, setName] = React.useState(item.name);
          // more logic ...
          return <button onClick={() => setName(newName)}>{newName}</button>;
        }}
      </$>
    ))}
  </ul>
);

After — ✅ simpler syntax (traditionally invalid, but corrected at build time), fully compatible with React Compiler

const SimpleCounters = () => (
  <ul>
    {items.map((item) => {
      const [name, setName] = useState(item.name);
      // more logic ...
      return <button key={item.id} onClick={() => setName(newName)}>{newName}</button>;
    })}
  </ul>
);

[kevinpastor]

I do understand that showcasing concrete examples is hard because it will, most of the time, not be able to express the limitations and restrictions a project has. I still personally prefer to refactor a component in order to be able to extract another one. That said, I do think some people will might prefer the ergonomics the library provides.

About the build tool plugin, I have mixed feelings. On the one hand, I feel like this could cause some confusion for someone joining a project where the Rules of React are not respected while not causing any issues. On the other hand, I can compare this to the React Compiler which comes in and tries to work around the quirks of React. That said, it would feel safer to me to use a feature like this if it was coming from the React team itself, through the React Compiler for example (not question your ability to implement something like this in any way).

All in all, I think it is nice to see projects like these explore how the ergonomics of React can be improved upon. Kudos on your work!