Svelte: Fix docs rendering

[JReinhold]

Issue: #19205

This PR fixes a number of issues:

1. Only the last story in a docs file would be rendered when using the Svelte renderer. unblocks Disable play functions in docs mode, unless you set parameters.docs.autoplay #19659
2. Changing controls would remount Svelte components instead of keeping them and their state
3. A memory leak in the Vue3 renderer that uses a similar architecture.

Previously the Svelte renderer would destroy any previous component rendered whenever a new component was to be rendered. In docs with inline rendering this would cause each story to destroy each other immediately, leaving the last one remaining.

This PR (inspired by the vue3 renderer) instead keeps a map of all the parent DOM elements in use and only destroys them if the component to be rendered has a matching DOM element.

[tmeasday]

As discussed with @ndelangen, a more bulletproof solution would be to have an unmount hook for renderers that is called whenever the user navigates away from a story, essentially telling the renderer "please release this component". Instead of the current situation where the following story is responsible for unmounting any existing stories.

Umm.... we do 🤷

storybook/code/lib/types/src/modules/store.ts

Lines 38 to 42 in 816930c

	export type TeardownRenderToRoot = () => Store_MaybePromise<void>;
	export type RenderToRoot<TFramework extends AnyFramework, TStorybookRoot = HTMLElement> = (
	context: Store_RenderContext<TFramework>,
	element: TStorybookRoot
	) => Store_MaybePromise<void | TeardownRenderToRoot>;

storybook/code/lib/preview-web/src/render/StoryRender.ts

Lines 218 to 219 in 816930c

	const teardown = await this.renderToScreen(renderContext, canvasElement);
	this.teardownRender = teardown || (() => {});

storybook/code/renderers/react/src/render.tsx

Line 163 in 816930c

return () => unmountElement(domElement);

(Sorry those code references are from this branch #19623 where I renamed renderToDOM to renderToRoot, but you get the idea).

[JReinhold]

Good to know!
I'll try that out.

[JReinhold]

I've reworked the implementation to

1. use the teardown hook to teardown stories when appropriate
2. fix the issue where any changes to props (via controls) would remount the whole component. Now it keeps the component state when changing controls.

2 should probably have some tests, but I think we should do that in a follow-up PR to unblock #19659 now. The tests would need a stateful component which none of our default components are - I think we should introduce that either way.

I'm pretty sure I can do the same remount fix for the Vue3 renderer in combination with the workarounds mentioned in vuejs/core#4874.

[tmeasday]

Nice job @JReinhold! Actually we already have a test for 2 -- it is just disabled for Svelte ATM:

storybook/code/lib/store/template/stories/rendering.stories.ts

Line 38 in 95da68c

['vue3', 'svelte', 'web-components', 'html', 'preact'].includes(globalThis.storybookRenderer)

As you can see I used focus as a stand-in for state ;) We could have also used the form component and filled it in a little bit.

[JReinhold]

CI is blocking me on this.
E2E tests are failing because they are running on sandboxes that don't include the changes I've made to sandboxes in this PR.
(The Svelte examples weren't actually reactive, so the only reason the worked before was because we remounted them. now that we're not remounting, the sandboxes needs to be reactive.)

However I can't generate new repros for the repros repository, because CI is failing with ENOSPC: no space left on device. 🫠

[JReinhold]

my tests keeps failing because my changes to repros get overwritten by the scheduled repro generator, and thus the sandboxes wont update.

I think this is ready to merge when it has been reviewed @tmeasday . the tests passes locally, and the failing tests are exactly what I'd expect to see based on the changes I've made here.

[tmeasday]

Svelte part looks great, maybe we should drop the vue part until we take another look at it?

[JReinhold]

Svelte part looks great, maybe we should drop the vue part until we take another look at it?

Fine by me, this is a very minor fix anyway, that is incorporated in #19737 .