A Proposal for Making Components Visible in the Developer Tools

[shancarter]

For debugging it's often quite nice to be able to inspect the state (data) of a component in the web inspector. While something like this is certainly nice, I had a weird idea for a low-dollar alternative. If svelte had a debug mode it could add a comment node for each component,

and then could bind the current component object to a property of that comment node, allowing you to highlight it in the inspector and interact with it in the console.

Might be dumb, dunno.

[Rich-Harris]

I can see that making sense in dev mode. Though now I'm wondering what would be involved in creating a svelte-devtools package...

[PaulBGD]

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/devtools.panels
more general guide: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Extending_the_developer_tools

[shancarter]

Yeah, probably worth doing it the right way from the start.

[Rich-Harris]

It occurred to me while working on #811 that custom elements may give us an inexpensive solution to this problem:

In this example we're not explicitly creating any custom elements — the only difference is that we're compiling with the customElement: true option. Because of that, the components are also custom elements, and the inspector will use the name they're defined with when displaying tags. And we can easily inspect/set data by selecting elements and either using accessors or the component API.

So you can imagine e.g. compiling to custom elements while developing, then turning it off for production. Given that custom elements are (presumably) going to become more and more commonplace, it arguably makes sense to invest in this workflow rather than investing in separate devtools as other frameworks have.

The one major caveat is that styles don't work exactly the same, because shadow DOM has true encapsulation. That might be a dealbreaker. Not sure.

[shancarter]

I would be a big fan of any official support of custom elements. I would probably use this option for production. But explicitly having to define the tag name feels a little verbose. I agree that this is better than installing some questionable devtool extension. Going down this road does open up a bunch of cans of worms, but I whole-heartedly support it. :) I've found that using styles within the shadow dom to be a little bit of a nightmare. But with an open shadow dom you could just style them with the custom element tag selector in global CSS instead of the svelte-id and it should work mostly the same, no? Or just NOT use shadow dom at all but still use custom elements.

…

On Sun, Sep 3, 2017 at 6:38 AM Rich Harris ***@***.***> wrote: It occurred to me while working on #811 <#811> that custom elements may give us an inexpensive solution to this problem: [image: screen shot 2017-09-03 at 9 33 00 am] <https://user-images.githubusercontent.com/1162160/30003441-f11bfbf2-908a-11e7-8493-b6a070241a58.png> In this example we're not explicitly creating any custom elements — the only difference is that we're compiling with the customElement: true option. Because of that, the components are *also* custom elements, and the inspector will use the name they're defined with when displaying tags. And we can easily inspect/set data by selecting elements and either using accessors or the component API. So you can imagine e.g. compiling to custom elements while developing, then turning it off for production. Given that custom elements are (presumably) going to become more and more commonplace, it arguably makes sense to invest in this workflow rather than investing in separate devtools as other frameworks have. The one major caveat is that styles don't work exactly the same, because shadow DOM has true encapsulation. That might be a dealbreaker. Not sure. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#695 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZiNI0lUSSHm1DWJrqzEdEpUW10_453ks5seqvHgaJpZM4OQcFy> .

[ekhaled]

Don't know how relevant this is right now....
While working on svelte-hot-loader I had to add comment markers to the DOM when a component is mounted, just so that we can re-mount in the same location after a hot-update.

I saw this issue, and realised it was trivial to add what is being proposed.

The caveats for now are:

1. You have to be using webpack with HMR plugin
2. You have to be using svelte-hot-loader

Although in the future I might make this available for Rollup (if there is demand).

[equinusocio]

What about something like Vue and React Dev Tools extension?
https://chrome.google.com/webstore/detail/vuejs-devtools/ljjemllljcmogpfapbkkighbhhppjdbg

https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en

[maciej-trebacz]

Lack of Vue-like dev tools extension is probably the only thing that keeps be from committing to using Svelte in bigger projects. Any idea if/when this will be worked on?

[pngwn]

Closing this in favour of #2931 as it contains more recent information and the author of that thread has made some progress on some kind of browser based developer tooling.