Fix canvas Repeater live data binding by wiring iframe to builder store

[Copilot]

Collection-bound Repeater blocks could resolve through deploy/render paths but remained empty in the editor canvas because canvas-side async data hooks were not reading the same builder props store. This caused getBlockAsyncProps to remain effectively unavailable in the iframe render tree.

• Canvas store propagation

  • Wrapped the canvas iframe subtree in JotaiProvider with builderStore so hooks inside canvas blocks resolve chaiBuilderPropsAtom (including getBlockAsyncProps) from the same source updated by the editor watchers.
  • Kept existing layout/typography provider behavior intact by aliasing and nesting the prior balancer provider.

• Stable async provider fallback

  • Replaced inline getBlockAsyncProps fallback in useAsyncProps with a module-level constant stub.
  • Prevents fallback function identity churn and aligns provider resolution behavior when real editor props become available.

• Regression coverage

  • Added a focused StaticCanvas test that mounts the component under a different parent Jotai store and verifies canvas-rendered blocks still resolve chaiBuilderPropsAtom from builderStore.

<JotaiProvider store={builderStore}>
  <BalancerProvider>
    <Canvas>
      <StaticBlocksRenderer />
    </Canvas>
  </BalancerProvider>
</JotaiProvider>

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
sdk	Error		Jul 6, 2026 5:46am