Closed myieye closed 3 months ago
Latest commit: d4439c57bf69e383a5e4044acfe0f3b360f2a5a3
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
[Click here if you're a maintainer who wants to add another changeset to this PR](https://github.com/myieye/svelte-ux/new/bugfix/contains-does-not-mean-its-a-child?filename=.changeset/gorgeous-pandas-joke.md&value=---%0A%22svelte-ux%22%3A%20patch%0A---%0A%0AFix%20.contains()%20does%20not%20mean%20it's%20a%20child%0A)
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
svelte-ux | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Jun 14, 2024 1:50pm |
@myieye This makes sense to me. Could you add an example of this use case (nested portal'd element) and run pnpm lint
to make prettier happy 😁. Thanks!
@techniq sorry, I jumped the gun on this one. But, I eventually nailed it down and added an example that breaks without my second commit. I also updated the PR description to explain exactly what was going wrong.
@myieye I really appreciate the detailed write up and digging in. I've got 2 small asks :)
{#if !destory}
around the whole example. Can this be scoped further down, or at least put the Recreate button in an {:else}
block of this statement?pnpm changeset
) so this creates a new version?Thanks for all the effort here!
@myieye Looks good! Ready to merge?
@techniq Yes 👍
Thanks @myieye. Publishing as 0.66.8
. Should be live in a minute or so
Three things were wrong here:
elem1.contains(elem2)
checks all descendants, so it doesn't imply that elem2 is a child of elem1onDestroy
was using the originaloptions
, which would be out of date if they had ever been changed (i.e. viaupdate()
)Due to a combination of these problems, when I navigate away from a route in my application I'm currently getting:
There are just so many little details that are wrong that it turns out there are a few ways to reproduce the bug, but what's crucial in my example is that: 1) The portal is initialized with
{target: undefined}
so that inonDestroy
it queries for the nearest target. 2) There's a portal target (e.g..PortalTarget
) within the same{#if}
as the portal content. Otherwise,.contains()
will return false. The reason is that everything within the{#if}
gets pulled out of the DOM, so root elements in the{#if}
don't have aparentElement
, but the elements within that detached subtree are still conntected to each other. 3) The portal content is not using that target i.e. it's not a direct child of it. It can simply be in its original parent (withenabled: false
) or be in a different target that's also within the same{#if}
. So, in the example you can trigger the error whether or not you've clicked "Move to target".