Due to the unique way Solid operates and manages "components," certain functionalities may be restricted, unavailable, or only accessible in a development environment.
In production, Solid discards unnecessary elements to streamline its performance.
The issue lies in the fact that Solid does not have individual "component instances" like Svelte or React. Instead, it functions as a network of signals and reactions.
What defines a component? Simply put, it's a function that generates DOM elements, establishes signals and computations within the network, and eventually gets disposed of after use. In production, a component is essentially just another function (or hook).
Despite this, the signal graph remains somewhat traceable, albeit with limitations in a production setting.
You can observe all the computations (such as createEffect, createMemo, etc.) and the signals they are currently monitoring. Perhaps even some contextual information.
Traditional props – reactive objects passed from parent to child – are essentially getters contained within an object transferred to a function; they do not stand alone within the reactive graph.
Accessing these signals is still possible, but only if utilized in specific effects – meaning a node in the creative graph must reference them.
Think of it like this:
If you're developing a library intended for production use, I recommend explicitly providing necessary data through arguments/props rather than delving into the internal mechanisms.
On the other hand, if you aim to visualize the reactive graph during development, check out the source code of this debugger: https://github.com/thetarnav/solid-devtools/tree/main/packages/debugger