Skip to content
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

Closed
1 task done
vatro opened this issue Jun 18, 2022 · 2 comments
Closed
1 task done
Assignees
Labels
bug Something isn't working
Milestone

Comments

@vatro
Copy link
Owner

vatro commented Jun 18, 2022

e.g. in the Mesh component:

$: currentSceneActive = $svelthreeStores[sti].scenes[scene.userData.index_in_scenes]?.isActive

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:

  • examine destruction of dynamically generated components (SvelthreeGLTF.ts + X)
@vatro vatro added the bug Something isn't working label Jun 18, 2022
@vatro vatro added this to the 1.0.0-next.2 milestone Jun 18, 2022
@vatro vatro self-assigned this Jun 18, 2022
@vatro vatro changed the title SvelthreeGLTF.ts + X : Dynamically generated components are not being destroyed (at all? / properly?), reactive statements bound to $svelthreeStores[sti] cause errors SvelthreeGLTF.ts + x : dynamically generated components are not being destroyed (at all? / properly?), reactive statements bound to $svelthreeStores[sti] cause errors Jun 18, 2022
@vatro
Copy link
Owner Author

vatro commented Aug 9, 2022

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

Fix DOM-less components not being properly destroyed (sveltejs/svelte#7488)

TODO: check if + eventually close ... EDIT: -> nope, problem still there.

@vatro vatro pinned this issue Aug 10, 2022
@vatro vatro modified the milestones: 1.0.0-next.2, 1.0.0-next.1 Aug 29, 2022
@vatro vatro added this to In progress in svelthree 1.0.0-next.1 Aug 29, 2022
@vatro
Copy link
Owner Author

vatro commented Aug 29, 2022

Ok, I think that's the issue:

see https://stackoverflow.com/questions/68335375/ondestroy-not-working-when-component-target-is-removed?rq=1

If you create the component by hand, you also need to destroy it by hand. You need to call $destroy on its instance before removing the Dom element

component_reference.$destroy()

TODO:

  • Refactor onDestroy in all components which generate shadow DOM elements: add ability to iterate over manually user-created / svelthree-generated children and $destroy() them.
  • Refactor SvelthreeGLTF.ts accordingly

@vatro vatro changed the title SvelthreeGLTF.ts + x : dynamically generated components are not being destroyed (at all? / properly?), reactive statements bound to $svelthreeStores[sti] cause errors SvelthreeGLTF.ts + x : manually created components have to be destroyed by hand! Aug 29, 2022
vatro added a commit that referenced this issue Sep 2, 2022
…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()`.
@vatro vatro closed this as completed in 8e3e73e Sep 7, 2022
@vatro vatro moved this from In progress to Done in svelthree 1.0.0-next.1 Sep 7, 2022
@vatro vatro unpinned this issue Sep 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Development

No branches or pull requests

1 participant