How would you integrate a third-party library that creates and owns its own DOM — a charting library, a map, a rich-text editor — into a React function component?

## The division of labour A chart, a map, or an editor is an imperative object: you construct it against a DOM element, it fills that element with markup it manages itself, you call methods to change it, and you call a destructor when you are done. React is declarative: it wants to own a tree of nodes and diff them against a description you return. The two models can coexist only if you draw a boundary, and the boundary is one DOM node. React owns the container element and nothing below it. The library owns everything inside. Every rule below follows from that sentence. ## The skeleton ```js function MapView({ center, zoom }) { const containerRef = useRef(null); const mapRef = useRef(null); useEffect(() => { const map = L.map(containerRef.current).setView(center, zoom); mapRef.current = map; return () => { map.remove(); mapRef.current = null; }; }, []); return <div ref={containerRef} style={{ height: 400 }} />; } ``` Four moving parts: a container ref so the effect can find *this* instance's node; an effect that runs after the commit, when the node is attached; an instance ref so other effects and handlers can reach the object; and a cleanup that undoes exactly what setup did. ## Why a ref for the instance, not state The instance is not rendered data. Nothing in the returned JSX depends on it, so writing it to state would schedule a re-render that changes no output. Refs are also readable and writable synchronously across renders, which is what the cleanup and the prop-sync effects need. State would additionally be a render-ordering hazard: you would have to render at least once with `null` before any other effect could use it. ## The dependency array Empty deps express "this is a lifecycle, not a reaction": create when the component mounts, destroy when it unmounts. Construction options read inside that effect are captured at mount, which is correct for options the library only honours at construction time — but it does mean later changes to them are ignored, so anything the user can change afterwards must be fed through an imperative setter in its own effect. If an option genuinely can only be set at construction and genuinely has to change, do not smuggle it into the deps: give the wrapper a `key` derived from it, so React unmounts the old component and mounts a new one, running your existing teardown and setup instead of a bespoke rebuild path. ## The container stays empty Render no children inside the container. React diffs the children of the nodes it created against its own model of them, and library-inserted nodes are not in that model, so a React update can remove or reorder the wrong things. If the component needs a heading, a spinner or a toolbar, render those as **siblings** of the container. If React content truly must live inside library-owned markup — a popup body, a cell renderer — use `createPortal` targeting a node the library created and gave you. A robust variant is to have the effect create its own child node, append it to the container, hand *that* to the library, and remove it in cleanup. React then only ever owns an empty outer div, and teardown is guaranteed to leave that div genuinely empty even if the library's destructor is sloppy. ## Cleanup is the whole contract The cleanup must reverse everything the setup did: destroy the instance, drop the reference, and remove anything the library appended outside the container (some libraries attach tooltips or overlays to `document.body`). Two things depend on this being complete. In development, StrictMode runs setup, cleanup, then setup again on mount, which turns incomplete teardown into an immediately visible duplicate. In production, any real remount — a route the user navigates back to, a changed `key`, a conditional branch flipping — does the same thing, and an instance that outlives its component keeps its listeners, timers and observers alive, holding its detached DOM in memory. ## Server rendering Effects do not run on the server, so the initialization is client-only for free: the server emits an empty container, and the library fills it after hydration. What is not free is the library's *module*: if it touches `window` at import time, import it dynamically inside the effect rather than at the top of the file, and ignore the resolved module if the effect has already been cleaned up. ## The checklist a reviewer applies Container rendered by React and empty; ref, not a document query; construction inside an effect; instance in a ref; empty deps for the lifecycle effect; cleanup mirroring setup exactly; props applied through setters; no React children under library-owned DOM.