In development, a React component that creates a map with `L.map(node)` inside an effect ends up with two maps stacked in its container, or the library throws that the container is already initialized. What is React doing, and what is the correct fix?

## What React is doing When the app is wrapped in `<StrictMode>`, React in development mounts a component, runs its effects, immediately runs all of their cleanups, and then runs the effects again. Nothing about production changes; this is a deliberate probe of one property: **can this effect be torn down and set up again without leaving damage behind?** React needs that property to be true because real applications tear effects down and set them up again all the time. So the duplicate map is not a StrictMode bug that got past you. It is StrictMode reporting a bug you already had. ## Why the symptom looks like a framework problem The report is always some version of "it works without StrictMode". That is true and irrelevant. The identical sequence happens in production whenever a component genuinely remounts: the user navigates away and back, a `key` on the wrapper changes, a conditional branch flips, a parent re-creates the subtree. In all of those cases setup runs again after cleanup — and if cleanup was incomplete, production accumulates orphaned instances instead of showing you one obvious duplicate in development. ## Diagnosing which half is wrong Ask what the setup created and check the cleanup line by line against it. Typical omissions: - the destructor is never called at all, because the developer assumed removing the container div was enough; - the destructor is called but the instance ref is left pointing at a dead object, so later effects operate on a corpse; - the library appended something outside the container — a tooltip layer, an overlay, a portal root on `document.body` — that the destructor does not remove; - setup also registered a window listener, `ResizeObserver`, or `requestAnimationFrame` loop that cleanup forgets; - the library mutated the container and its destructor leaves that markup in place, so the second `L.map(node)` sees an element it already owns. ## The fix Make cleanup an exact mirror of setup: ```js useEffect(() => { const map = L.map(containerRef.current).setView(center, zoom); mapRef.current = map; return () => { map.remove(); mapRef.current = null; }; }, []); ``` Note that the cleanup closes over the local `map`, not over `mapRef.current`. That matters: it tears down the instance *this* setup created, even if something has already replaced the ref's contents. When the library's destructor is not trustworthy, or when it refuses to initialize twice on the same element, stop reusing the element. Let the effect create its own host node inside the React-owned container and remove it in cleanup. Every setup then receives a brand-new, pristine element, and the container is guaranteed empty afterwards regardless of what the library left behind. ## Why the guard is the wrong fix The reflex fix is a sentinel: ```js if (initializedRef.current) return; // don't do this initializedRef.current = true; ``` This suppresses the second *setup* while leaving the *cleanup* in place. In the StrictMode sequence the cleanup still destroys the first instance, and the guard then blocks the replacement — so you trade two maps for none, usually noticed later as a blank panel. If you also reset the flag in cleanup, the guard does nothing at all, which at least tells you it was never the fix. And any variant that keeps the flag alive across a remount (a module-level flag, a flag on a ref preserved by state-reuse features) breaks the component permanently after its first teardown. Deleting `<StrictMode>` is the same mistake with a wider blast radius: it silences this detector and every other one, for the whole app. ## Idempotence is the real requirement The property to aim for is that setup followed by cleanup returns the world to where it started, and that running the pair repeatedly is indistinguishable from running it once. Write cleanup at the same time as setup, in the same effect, and read them together as a pair. Applied consistently, StrictMode stops producing surprises: you get the double mount, nothing visibly changes, and that silence is the signal that the wrapper will survive a real remount too. ## A quick checklist Destructor called; instance ref nulled; nodes appended outside the container removed; listeners, observers and animation frames unregistered; the second setup receives a container in the same state as the first; and the cleanup references the instance from its own closure rather than whatever the ref currently holds.