(WIP) Plans for Solid Devtools 2023

[thetarnav]

previous: Plans for the 2022

One year ago, the Solid team launched the Fellowships program to accelerate the development of the devtools. The program lasted for five months, during which I completed most of the goals outlined in the 2022 plan, as discussed in this link.

The initial features of the devtools focused more on the visualization of the real-time state of solid’s reactive graph. The devtools tracked and displayed the ownership structure (including components, and DOM elements), state of signals, memos, and stores declared inside inspected owner (component, effect, root, etc.) and a dependency graph, showing the data flow from signal sources, through memo derivations, to effects at the end.

These features, combined with the additional component locator feature, turned out to be a great tool when learning new codebases, and understanding how specific components behave by monitoring how their state changes over time.

Unfortunately, unless you had a bug which is easy to spot by observing the state changes, or incorrect dependencies, mentioned features didn’t have a significant impact on the way I debug issues with the app behavior.

This is my main target for the next year: debugging.

Runtime API

Inspired by the Analyzing reactivity features of mobx, similar API could be implemented in the debugger, giving the developer a programmable interface to get the current state about signals, effects, memos, stores, etc. including dependencies, dependents, ownership, values, context in a digestable way. Instead of trying to use the solid internals to get the same information. Similarly it could allow for tracking changes, causes of updates (with a source code location from error stack traces) in the same way.

I experimented a long time ago with a similar API in the logger package which was focused only on logging that information to the console. But the package didn’t get much love as I focused more on the extension. Also unfortunately, I wasn’t able to reuse much of the debugger implementation between the extension features, and the logger, which I’m hoping to change with the new API.

Recording updates (timeline)

The timeline of updates with causes.
It should display a list of changes to signals, stores, and computations as they happen over time. Timestamps, update causes, batched updates.
Such a timeline should probably be scoped to the focused owner/store or separated into different groups.

Performance metrics

…

Analyzing the state changes

…

Resources

…

Routing

…

Context

…

Integrations

• Solid Playground
• Firefox Extension
• Astro