Svelte 5: Provide metadata/events needed for devtools et al

[dummdidumm]

Describe the problem

Svelte 4 emits some events in dev mode around elements being inserted etc and provides location info on the elements that map back to the original code.

Svelte 5 currently doesn't have any of it. To support devtools et al, it needs to be added back, ideally in a less on-the-fly way compared to before.

Describe the proposed solution

No good idea yet - first we need to collect requirements from tooling:

• Svelte devtools @ignatiusmb
• Svelte inspector @dominikg
• others who use it, like Kitbook @jacob-8

Importance

nice to have

[jacob-8]

ideally in a less on-the-fly way compared to before

Yes, that's a good way to put it. :) For reference, Kitbook's scaled down version of what Svelte DevTools had to do on-the-fly is here and then I added this to move elements up into a parent component if they come from a node_modules component. The incentive for moving elements up the chain is that I had some situations where a local component has no dom elements of its own but only node_modules components with dom elements. I still have no option to enable targeting components which have no local elements as only the elements carry the file location reference and not components. There's no need to try to read through that code, just wanted to say it'd be a real boost to have something simpler made available.

Requested

Here's my list of what's needed for building a component tree w/ each local component knowing which DOM elements it owns.

• [ ] on component mount emit an event like SvelteRegisterComponent that includes:

  • [ ] file location - important for being able to jump to the source code for those components without DOM elements. They can still easily be selected with a simple tree viewer:
  • [ ] props
  • [ ] capture_state function (and optionally capture_props_state would be nice but it can be calculated on-the-fly)
  • [ ] set_state function
  • [ ] unique component identifier that can be added to dom elements such that we can know exactly which instance of a local component they belong to (in Svelte 4 it required listening to SvelteRegisterBlock's block to match to the correct component's component.$$.fragment and doing some wizardy for the pending await block.)
  • [ ] parentComponent - the unique component identifier for a component's parent component to be able to build a tree
• [ ] on component destroy emit something like SvelteUnregisterComponent
• [ ] each dom element has metadata:
  • [ ] actual source file location information (Svelte 4 places into __svelte_meta)
  • [ ] perceived source file location - so if file location is from node_modules then this would be file information for which local component is responsible for bring this element into the app, it is the perceived parent component
  • if I import Button.svelte into +page.svelte and I hover over the button, I want to jump to +page.svelte. With some backflips, I'm currently doing this now, but if +page.svelte has no elements of it's own, its source file location information is not currently available.
  • As to snippetted/slotted elements I lean towards them pointing to the actual file they are written in, not the file they are mounted in
  • [ ] unique component identifier to local component instance that matches the one emitted by it's perceived parent component (not actual component in the case of node_modules components)
• [ ] Emit SvelteDOMInsert and SvelteDOMRemove events with the elements which will include that metadata. If the unique component identifier is not practical to keep in the DOM then just including it in these events is sufficient.

Note that the above list means all mounted components from node_modules will have 0 children elements registered to them. That's fine, but please still emit the SvelteRegisterComponent event for them so we can capture and set state if desired.

I don't need the SvelteRegisterBlock anymore if we have the above list.

What I've written down will eliminate all of my code's backflips and will require just listening to the appropriate events. However, you may be envisioning something more low-level like having the SvelteKit plugin maintain current component-elements tree state which libraries can then just request from the dev server and receive updates from via server broadcasted events. I'm good with whatever approach is taken.