-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SvelthreeGLTF.ts
+ x : manually created components have to be destroyed by hand!
#100
Comments
SvelthreeGLTF.ts
+ X : Dynamically generated components are not being destroyed (at all? / properly?), reactive statements bound to $svelthreeStores[sti]
cause errorsSvelthreeGLTF.ts
+ x : dynamically generated components are not being destroyed (at all? / properly?), reactive statements bound to $svelthreeStores[sti]
cause errors
I just stumbled upon this issue: sveltejs/svelte#7488 which should be fixed in Svelte 3.49.0 and which may also solve the problem with dynamically generated components described above, see: https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md#3490
TODO: check if + eventually close ... EDIT: -> nope, problem still there. |
Ok, I think that's the issue:
TODO:
|
SvelthreeGLTF.ts
+ x : dynamically generated components are not being destroyed (at all? / properly?), reactive statements bound to $svelthreeStores[sti]
cause errorsSvelthreeGLTF.ts
+ x : manually created components have to be destroyed by hand!
…d `SvelthreeComponentShadowDOMChild` (#100) We want to distinguish between components which are generating shadow DOM elements as children only and the `Canvas` component which is generating the `ShadowRoot` element and also sort those components which are not generating any shadow DOM elements. Also: `Canvas` has a different named getter for retrieving the shadow root element: `get_shadow_root_el()`.
e.g. in the
Mesh
component:svelthree/src/components/Mesh.svelte
Line 785 in d986052
I've stumbled upon this when changing test-scenes (pages) in the SvelteKit test-app. The error was thrown only when switching from the
gltf-to-comp-1
test-scene to any other.gltf-to-comp-1
test-scene generates svelthree-components from a loaded GLTF file.If we e.g. change the line above to
$: currentSceneActive = $svelthreeStores[sti]
?.scenes[scene.userData.index_in_scenes]?.isActive
the error is not being thrown.
Why?
It seems like that somewhere during the destruction process, the
svelthreeStores
store is gone / nullified?, but generated components are still alive and react to that change by triggering corresponding reactive statements. Adding?
to all$svelthreeStores[sti]
related statements doesn't feel like a real fix.TODO:
SvelthreeGLTF.ts
+ X)The text was updated successfully, but these errors were encountered: