After enabling <StrictMode> in a React app, an analytics 'page_view' event sent from a mount effect starts firing twice in development. How do you decide whether that is a real defect, and what do you change?

## The triage question When StrictMode makes something happen twice, there is exactly one useful question to ask: **would a genuine unmount and remount cause the same thing?** React remounts components for real all the time — route changes, tab switches, a parent whose `key` changed, a subtree that unmounts and returns. If the answer is yes, StrictMode has not created a development artefact; it has given you an early preview of a production bug. Run that test on a mount-effect analytics beacon and the answer is yes. Navigate to the page, leave, come back, and the event fires again. If that is wrong, it was already wrong before StrictMode was switched on. ## Separating the cases The useful split is by *what causes* the event. **Interaction-caused.** "User clicked Subscribe", "user submitted the form", "user dismissed the banner". These have no business in an effect. Effects synchronize a component with an external system; they fire on mount and on dependency change, neither of which is the thing you want to record. Move the call into the handler: ```jsx function Subscribe() { function handleClick() { track('subscribe_clicked'); // once per click, forever subscribe(); } return <button onClick={handleClick}>Subscribe</button>; } ``` This is the single largest category, and moving the call is a strict improvement independent of StrictMode: it is more accurate (a mount is not a click), and it stops depending on render timing. **View-caused.** "This screen was displayed." Here a mount really is the trigger, so the duplication must be handled somewhere that outlives the component instance. Options, roughly in order of preference: - Fire it from navigation rather than from a component. A router-level listener records one view per navigation event, which is what the metric actually means, and is immune to any component churn under it. - Give the request an idempotency or event key the collector deduplicates on. This is the only option that also protects you from retries, double clicks and network replays. - Keep a module-scoped record of "already sent for this view identity" — module scope survives remounts, unlike a ref — with a deliberate policy for when it resets. **Idempotent-anyway.** Some duplicated operations are genuinely harmless: setting a document title, writing the same value to storage, a `PUT` of identical content. Here the second run changes nothing observable. It is still worth checking that the effect has a cleanup, but there is no defect to fix in the payload itself. ## What not to do The two tempting shortcuts both fail the remount test. A `useRef` guard resets when the component instance is recreated, so the duplicate returns in production. Removing `<StrictMode>` removes the report and keeps the behaviour. Both convert a loud development signal into a quiet production one, which is the wrong direction. A third shortcut worth naming: "it only happens in development, ship it." That is true of the *doubling in your console* and false of the *underlying duplication*, and conflating the two is what the interviewer is listening for. ## The wider habit After you have fixed the analytics case, the same triage applies to everything StrictMode reports across the app. Sort each finding into: needs cleanup (subscriptions, timers, listeners, observers), belongs in an event handler (user-caused writes), needs external deduplication (non-idempotent mount work), or genuinely harmless. That classification, not the individual patch, is the senior-level answer — it turns the StrictMode rollout into a bounded, reviewable cleanup rather than an open-ended annoyance. ## Verifying the fix Check it the way the bug arrived: mount, unmount, mount again — navigate away and back with the network panel open — and confirm exactly one event per intended occurrence. If the fix only holds because of StrictMode's specific timing, it is not a fix. And confirm on the collector side, since duplicate suppression there is the layer that survives everything, including the retries you do not control.