`useEffect` gets called twice

[calebeby]

In almost all of our stories which use useEffect, we are using it inside of a function embedded in JSX like this:

{() => {
  useEffect(() => {
    // ...
  }, []);
}}

Storybook changed the number of times the function in JSX is called. Now useEffect gets called twice, even when we meant for it to be called once.

This is a problem for stories which might attach event listeners inside useEffect: we only want those listeners to get attached once, but they would get called multiple times.

We can fix this by moving the useEffect into a decorator:

(story) => {
  useEffect(() => {
    // ...
  }, []);
  return story();
},

To see an example of this change, see #1918

[spaceninja]

Still valid, but the description no longer matches the code — updating so nobody closes it as stale.

The MDX pattern is gone. #2405 migrated all 84 .stories.mdx files to CSF3, so the {() => { useEffect(...) }} shape this issue opens with no longer exists anywhere.

The underlying problem does not appear to be gone. Eight story files still use useEffect, now imported from storybook/preview-api, and only three of them use the decorator form this issue proposed:

Uses a decorator	Calls useEffect inside render
page.stories.js, sky-nav.stories.js, draft-email-textarea.stories.js	cloud-cover.stories.js, input.stories.js, comment.stories.js, subscribe.stories.js, comment-form.stories.js

page.stories.js is a good example of the fix landing exactly as proposed here — the useEffect sits in a decorator that returns story().

The clearest remaining case is comment.stories.js, which calls useEffect(() => initCommentReplyForms()) in three stories with no dependency array, so it re-runs on every render. That is precisely the "listeners attached more than once" risk this issue was opened about.

Two things worth doing here rather than assuming:

1. Confirm whether Storybook 10 still double-invokes in the render position. The behaviour that prompted this was a Storybook 6.x change, and we are five majors on with React 19 — it may have changed in either direction.
2. If it does, move the remaining five to decorators. If it does not, the dependency-array omission in comment.stories.js is still worth fixing on its own merits.

Related: #2405, #2428.

[spaceninja]

Closing this. The premise no longer holds on Storybook 10, and the fix proposed here would now be a regression rather than a no-op.

Picking up the two open questions from my previous comment.

1. Storybook 10 does not double-invoke in the render position

It treats render and decorators identically. prepareStory builds a single stable wrapper:

undecoratedStoryFn = (context) => context.originalStoryFn(context.args, context)

and hands it to applyHooks(applyDecorators)(undecoratedStoryFn, decorators), which runs it through the same hookify MOUNT/UPDATE machinery as every decorator. Hook lists are keyed by function identity in a WeakMap, and because that wrapper is created once per prepared story its identity is stable — so a render-position effect gets a MOUNT on first render and an UPDATE on every render after, exactly like a decorator.

Rather than trust a read of a minified bundle, I exercised the real installed applyHooks / defaultDecorateStory / useEffect in jsdom and counted create and destroy calls across three renders:

Position	[] deps	no dep array
render	1 create, 0 destroys	3 creates, 2 destroys
decorator	1 create, 0 destroys	3 creates, 2 destroys

Position makes no difference. The dependency array is the only thing that matters. Moving the remaining five stories to decorators would be a pure no-op, so the fix this issue proposes has nothing left to fix. The MDX {() => { useEffect(...) }} shape that actually caused the original double-invocation stopped existing in #2405.

2. The missing dependency arrays are load-bearing, not a defect

This is the part worth recording, because it inverts the recommendation. I was wrong to suggest in my last comment that the omission in comment.stories.js was worth fixing on its own merits — adding [] there would break the story.

@storybook/html renders string-returning stories like this:

canvasElement.innerHTML = element;

Every Twig template returns a string, so the entire DOM is destroyed and rebuilt on every render, including on an arg-control change. Meanwhile Storybook only calls hooks.clean() from cleanupStory, on teardown — never on an arg change. An arg change is therefore an UPDATE, and an effect with [] deps does not re-run.

Put together: with [], the second and every later render produces fresh DOM that never gets initialized. Toggling Allow replies on a comment story would leave a reply button with no JS attached to it; toggling an arg on the Input story would leave a textarea that no longer grows. Omitting the dependency array is what reattaches the component JS to the new nodes, and the effects that need teardown already return a cleanup — useEffect(() => initCommentReplyForms()) propagates the destroy function that initCommentReplyForms returns, and Storybook runs it before creating the replacement.

This is the opposite of the React intuition. React preserves DOM across renders, so a missing dependency array is wasted work; here the DOM is thrown away, so re-running is the only thing keeping the stories functional.

Outcome

Nothing to change. The eight story files using useEffect are all correct as written, in both positions, and the inconsistency between them is cosmetic rather than behavioural.

One residual worth flagging for whoever touches these next: none of this is written down in the story files themselves, which is why this issue survived four years and nearly got "fixed" into a regression twice. If these come up again, the reasoning belongs in a comment next to the effects rather than in an issue thread.

Related: #2405, #2428.