feat: add parent hierarchy to __svelte_meta objects at dev time
#16255
Conversation
This adds a `parent` property to the `__svelte_meta` properties that are added to elements at dev time. This property represents the closest non-element parent the element is related to. For example for `{#if ...}<div>foo</div>{/if}` the `parent` of the div would be the line/column of the if block.
The parent is recursive and goes upwards (through component boundaries) until the root component is reached, which has no parent.
part of #11389
🦋 Changeset detectedLatest commit: 23a4e7c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
|
|
how does that work? components are compiled in isolation so the dev runtime would have to calculate these for blocks outside of that component. If the runtime can calculate it, the devtool can do that 🤔 everything would have to be updated on hot updates too, think adding or removing block. could this information be obtained from/attached to comment nodes we already have instead? |
|
How would componentTag look for renamed things like if every element had all parents attached i hope data is deduplicated/just linked, otherwise that could be a lot extra on long lists that are deeply nested. |
|
Everything is compiled in isolation. The compiler wraps block/component creations with the info where they are within the file, and the runtime creates sort of a stack from it. You can only go upwards not downward - is HMR smart enough to keep children around when a component higher up the tree is reloaded? If not then this doesn't leak or get outdated. If it does we should be able to add logic to our HMR to handle it. What would attaching it to comments give us? Right now component tags are what the compiler will use under the hood I think. We should be able to adjust that to show the original name |
|
attaching it to comment nodes was just an idea of how it could be possible to put the information of locations where they actually are instead of adding it to all nodes they wrap. |
|
What exactly is your concern with the deeply nested example? |
|
time spent & memory consumed. right now svelte_meta is linear, one information about the source code location per node. with this, it becomes exponential and adding blocks at the root level or adding many deeply nested components can quickly escalate things. Why is the full info on each node? |
|
This is a shared stack, it's not recreated for every node. So the overhead is basically zero.
The reference to the parent (think about it as a reference, not as a value) is there because it's very convenient for anyone not wanting to build their own tree, you can just get a node and traverse upwards from there. |
This adds a
parentproperty to the__svelte_metaproperties that are added to elements at dev time. This property represents the closest non-element parent the element is related to. For example for{#if ...}<div>foo</div>{/if}theparentof the div would be the line/column of the if block. The parent is recursive and goes upwards (through component boundaries) until the root component is reached, which has no parent.part of #11389 - I believe the hierarchy structure along with the line/column/block type info will make things much easier for tooling wanting to represent hierarchies. This deliberately doesn't include any firing of events yet, that can happen later once we've figured out at which times we want/need it (my guess is we want it to fire it exactly when those parent relationships are established).
cc @jacob-8
Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.packages/svelte/src, add a changeset (npx changeset).Tests and linting
pnpm testand lint the project withpnpm lint