Experiment: JS-driven story loop with Promise handshake

[EmilioBejasa]

Summary

• JS owns the entire story sequence — no events from native, no deprecated sync methods
• StoryRenderer calls createPreparedStoryMapping() once on mount, then iterates all stories in a for...of loop
• After each story is rendered, JS calls await StorybookRegistry.notifyStoryReady(storyId) — a standard Promise call that resolves only after the test thread takes the screenshot
• allStoriesDone() signals the test thread to exit and unmount the surface

How it works

JS: for (story of allStories)
      await renderDone   ← useEffect fires after React commits the story
      await notifyStoryReady(storyId)   ← blocks until native resolves Promise
                                  ↑
Test: awaitStoryReady() → screenshot → resolveCurrentStory() → Promise.resolve()

The renderResolverRef pattern bridges React's async render to the for...of loop: the loop awaits a Promise whose resolve is stored in a ref and called from useEffect([storyContent, error]) — the only reliable signal that React has committed the render.

Why useEffect is necessary

setCurrentStoryId() schedules a render asynchronously. Calling notifyStoryReady() immediately after would race against React's scheduler and potentially screenshot the wrong state. useEffect fires after commit, guaranteeing the view is painted before native is notified.

Advantages over sync-story-blocking branch

• Works with new arch (newArchEnabled=true) — uses standard @ReactMethod Promise
• No deprecated APIs
• Native thread is purely reactive; JS controls ordering

Test plan

• Create draft PR to see if CI passes
• Verify story order matches between JS iteration and screenshots

🤖 Generated with Claude Code