Svelte Toolbar

[dominikg]

Note

this post is a collection of ideas and goals and things will be refined based on the discussion that follows, nothing is set in stone yet.

svelte toolbar

As Rich mentioned briefly during his svelte summit talk we are working on a toolbar to improve DX and allow better insights into svelte applications.

Goals

available everywhere

regardless of how you use svelte, adding the toolbar should give you access to the tools in our ecosystem

• The toolbar itself is going to be part of the svelte package under a new subpath export svelte/toolbar.
• First party tools added automatically via svelte/toolbar or other packages within the org (eg bundler plugins)

customizable

While we are going to provide first party tools, we also want to provide an api to add third party tools and allow customization

add tools

• libraries or packages for svelte can ship with dedicated tools
• community can add useful generic tools
• you can add custom made ones for your app

configure

The toolbar itself and each tool has a configuration that can be modified by invoking a function provided on svelte/toolbar
The configuration is going to be stored locally so you can tailor it to your needs and it stays that way. Possible storage locations would be localstorage, indexeddb or .env.local files.

mode aware

Most tools are going to be available during dev, but some can also be used in a production build.

powerful

• access svelte build-time information from the svelte compiler
• access svelte runtime information
• integrate with dev server functionality

Planned tools

first release

svelte inspector

to be ported from vite-plugin-svelte , its functionality is going to remain the same, but instead of hardcoding how file editors are opened by a call to a vite middleware, it is going to leverage the devserver integration

toolbar config editor

visual editor for the toolbar config, with options to persist

future releases

reactivity graph viewer

$inspect is nice and surgical, but it would be even nicer if there was a way to visualize the reactivity graph and more easily follow dependencies through your app. Solid already has a tool for this and so should we

sveltekit route viewer

params, matchers, layout groups, the file system tree can become a bit messy. A dedicated ui with links to open the relevant files can help understand and work with your application structure.

component hierarchy viewer

The original svelte devtools browser extension had this view, and we can bring it back.

your idea here

please share ideas for tools you'd like to have/build and any apis they might need. now is the time to shape the foundation

the owl

The toolbar

The toolbar itself is going to provide basic common features to the tools and renders them with provided name&icon. Of course it is going to be a svelte component and to avoid colliding with your application it will be mounted on document.documentElement outside of body by default, which should avoid collisions with your app in most cases.

A tool

A tool needs to be registered with the toolbar and receives api & configuration. Optionally it can provide its own svelte component for ui. If the toolbar is going to add this component or the tools is responsible for mounting it is still up for discussion.

How to add it

Ideally, bundler plugins are going to inject the toolbar to avoid the need for putting code into your app yourself (like svelte-inspector is added today) and the tools just show up as configured.
But manually putting them in your root layout can work as well.
The hardest one is adding them for production, this might require a web extension and building with a special flag so it can aquire a reference to the toolbar api.

Feedback & Ideas wanted!

If you want to build a tool, what api do you prefer. Should a tool always be a svelte component or should it be more similar to a vite plugin with an initializer function and hooks?

Do you think tools should be aware of each other and able to collaborate?

What are the most important tools you want to use?

Would you prefer a web extension with ui separately in the devtools tab or is rendering in the apps window ok?

[brunnerh]

Should a tool always be a svelte component or should it be more similar to a vite plugin with an initializer function and hooks?

Would be nice to have both options. Though for components I suspect that there might be potential for issues around Svelte version mismatches.

Do you think tools should be aware of each other and able to collaborate?

That could be useful for higher modularity, having some async, event-based mechanism could work.

What are the most important tools you want to use?

Probably the inspector & component hierarchy viewer.

Would you prefer a web extension with ui separately in the devtools tab or is rendering in the apps window ok?

I have written custom debug tools that function as an collapsible toolbar but can also be detached to a separate window (via window.open). To me an approach like that would be flexible enough.

[benmccann]

Would you prefer a web extension with ui separately in the devtools tab or is rendering in the apps window ok?

It might be kind of cool if it could work either way. A web extension in the devtools tab is nice because it won't get in the way of you app's UI. Rendering into the app window is nice because it doesn't require anything extra to be installed. Perhaps that could work by default, but would only activate if the extension is not detected.