Plans for the devtools 2022

[thetarnav]

As of today, I'm mainly focused on the runtime reactivity of Solid, so my plans are mainly concerned with it as well. Features related to the router and SolidStart may poke my mind from time to time, and I want to include them in my plans eventually. But providing support for the base primitives that all of us are interacting with most of the time of the development.

Those consist foremost of:

• Signals
• Computations
• Components — Props, DOM elements, re-renders
• Structure of the reactivity graph
• Context API
• Dependency graph
• The timeline and causality of signal/computation updates
• Stores
• Resources
• Suspense Boundaries

All of the above require developing individual solutions in terms of UI, the debugger, babel transforms, and even additions to solid itself.

While working on that, the general UI design, UX, and accessibility are additional parts that deserve attention. I have been working on some Figma mockups, but those are very brief.

Publishing the extension to the Chrome Extension Store and figuring out a proper CI for the next releases, as well as ensuring version compatibility between the extension and runtime (#14) should also be done at this point—I want to have people trying out the extension, even if the features/ui are incomplete.
The extension is now available in Chrome Web Store

---

The following plan was prepared for the rough duration of the SolidJS Fellowships program.

---

Up to this point only Signals, Computations, and the Reactivity Structure have gotten my attention, and there is still much to do. So my focus currently is on finishing those three.

• For example, Signals need to be properly serialized and displayed in the devtools panel in an intractable way—viewing properties of js objects/arrays. (Signal value serialization #69)

• There needs to be a way to overwrite their value as well.

• Computations need to store information about what has caused the last rerun.
  Same with Signals, just the other way around.

• The Structure View needs virtualization to stay performant wheel viewing the reactivity graph of larger applications.

As the next target, I'll probably be focusing on Context API, the Dependency Graph, Component Props, and Stores.

Context API should be pretty straightforward, as the whole API is generally very simple.

• The context state should be encapsulated in a graph node, just as computations or components are. (Context support #131)

• Additionally, every node down the tree should have an indication about available contexts, and the ability to jump to them.

• The Dependency Graph would require creating a separate view where you can trace possible update chains. Using D3 or just raw SVGs. It would also give users a different way to navigate the reactivity graph.
  It's also a very promising feature looking at the direction solid is heading—removing the need for createComputed by focusing on derivation primitives instead. The more derivation, the longer the dependency chain we are able to track and visualize.

• Component Props will require a babel plugin or modifications to the solid implementation of createComponent. It should give you insights about not only the values but also if the props are static/dynamic, which of them are getters and which are just values. (debugger: track component props #56)

• Displaying values of props that are getters (Improve displaying values of getters #109)

• Stores are pretty self-explanatory, but also challenging as solid doesn't provide any dev API for observing the changes without reading all of the properties and creating signals for all of them. I'm working on a solution with babel and an object-observer package.
  Observing nested values in stores and displaying updates to them in the inspector: done in (Feature: observe stores #157 )

Next up are Resources, Suspense, Components Tree, and a timeline of updates.

• Resources would need their loading state. Suspense and Error Boundaries similarly—some indication of the current state.
  The Suspense Context should have a special indication compared to user context use.
  Effects are paused under suspended branch—it would be a valuable insight to show if possible.

• The Component Tree view would be similar to the Structure view. But it would only show the components, (Suspense, Context, For, and other Control Flow components as well) and how they fit in the DOM tree of the page. (Components tree view #77)

• The Update Timeline is interesting, and would probably require some changes to solid.
  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.
  Additionally, I was thinking of a "Recording" mode, where the user could record all of the updates and the state of the reactive graph for a given time. And then navigate through those updates to see every change to the reactive graph.
  The MobX Devtools extension should have a lot of good solutions in this space.

[outbackStack]

Thanks @thetarnav for working on this!

Signal is the most important one so I agree with working on that first for the extension. I'm happy to be a tester for this and provide feedbacks.

It sounds like a lot of work but one step at a time will go a long way :-)