Breaking The React Wall

- Ben

I’ve written before about using useImperativeHandle to hoist functionality up a layer of React componentry. It helps to better encapsulate any state that component defines, without needing to expose it directly to the consumer.

You can use this same feature to “exit” React! If your top level component exposes a ref, you can access that with a ref callback! The simplest implementation, where our top level component is named App, looks like:

const App = React.forwardRef(function (props, ref) {
  const [msg, setMsg] = useState(props.defaultText || "Hi there!");
    useImperativeHandle(ref, () => ({
      update(newMsg) { setMsg(newMsg) }
    }), [setMsg]);
  return <div>{msg}</div>;
});

const renderRoot = ReactDOM.createRoot(document.querySelector('#react-root');
function refFunc(refAttr: RefAttributes | null) {
    // attach it directly to the window for our example
    window.refHandle = refAttr;
}
renderRoot.render(<App ref={refFunc} />);

Then running window.refHandle.update("Hello World"); in the console updates the text within App! If you try it in your console window on this page, the text in the box below will change!

It’s a very simple example, but it shows that we can get React to update directly, within it’s lifecycle but outside of the React context, while staying within React’s guidelines. I’ve seen it talked about very little! If it seems trivial here, it could turn a lot of React paradigms on their heads. Most React libraries feel like they try to fit the web into React’s paradigm, instead of augmenting their webpages with something as powerful as React. Even more powerful than how frameworks like Next.JS do it today, we can allow React to do what it’s best at (reacting to changes) and give us an escape hatch to also interact with other elements in the browser. Just like that, React can easily be made to create “islands of interactivity”

In more complicated “App” components, using an imperative handle means we don’t need to worry about calling “render” again. The functions we expose act inside the React lifecycle, even though we’re calling them from outside. The same thing could be achieved by placing functions on any element with in the ref, but by able to “come out the top” like this, we can place react DOM render roots anywhere we want, or isolate our consumer from React entirely by wrapping our component in a Custom Element.

It’s important that we aren’t just copying out a reference to a setState function or something like that. While that technically works, it breaks a lot of assumptions React and most developers would make about your code. It’s a good way to cause a mess! Comparatively, using an imperative handle is something React gives us, and it exposes functionality in a way that we can easily see what’s going on. Data still flows one way, callbacks are the primary method of interacting upstream, and React can dynamically update the handle if we need. The ref gives us a way to encapsulate some imperative logic as well!

Focusing an element is the classic example of when we might need or want to use some imperative logic, referencing the DOM directly in React. Dialogs also use this technique to call show and close. Checkbox even uses imperative logic to set its indeterminate state.

We can create a more seamless experience within React by mimicking these types of interactions, ones already available to us on the DOM. Developers can utilize their knowledge of the platform their on, or learn about it, while also using and learning our enhancements and new components. We aren’t limited by what web browsers give us, and we can use React in its full power to write updates to screen, based on one way data bindings.

PS: You can see the script used in your dev tools, or at https://benkenawell.com/scripts/breaking-react-wall.js. It looks a little different than the above script because it’s in React 19, strictly javascript, doesn’t use JSX, and I’m vendoring react and react-dom.