Any recommendations on debugging signal-based code?

[dmaretskyi]

A common problem I'm facing is trying to debug why i given signal is being subscribed to?

Are there any general recommendations for such situations?

Something that would help me are debug utilities for example to list all signals that are observed in a given effect, or list all subscriptions of a given signals.

[rschristian]

You can see which signals a component is subscribed to using the Preact devtools, but I don't believe we have any tooling set up for checking signals/computed/effects themselves.

However, you can still piece this together if you needed to using the internal properties. This would be a good place to start, with the mangle values providing a way to map those properties.

const count = signal(0);
const count2 = computed(() => count.value + 1);

console.log(count.t) // can pull targets from this as you need.

I won't pretend this is super user friendly -- it's not. Generally you shouldn't need this though. Tracking signal subscriptions are pretty easy, as you're just following the variable?

[OnlyWick]

I tried to debug test unit of signals's core, Are there any best practices?
I add this command in scripts of root package.json.
"unit": "cross-env COVERAGE=true mocha --require ts-node/register packages/core/test/**.test.tsx -P tsconfig.json"

and I was configure launch.json.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch via NPM",
      "request": "launch",
      "runtimeArgs": [
        "unit",
      ],
      "sourceMaps": true,
      "runtimeExecutable": "pnpm",
      "skipFiles": [
         "<node_internals>/**"
      ],
      "type": "node"
    }
  ]
}

It can correctly enter the specified test-unit if it has breakpoint. However, the debug information is missing.

[rschristian]

Firstly, you don't want to be adding additional tools -- run the tests we have using the existing tooling. Adding additional scripts, with different tools, just increases the chances of inconsistencies.

Secondly, it looks like launch.json is a VS Code thing? Sorry, not a VS Code user myself. I'm also not sure what your image is supposed to be showing, as that looks like the correct output of a signal's properties?

[OnlyWick]

Yeah, It's vscode, I just want to debug test-unit for learning How signals work. Then how should I correctly debug a test file?

It's weird, execute this._value = v; but this has v property instead of _value property.

[rschristian]

This, along with all Preact repos, make heavy use of prop mangling. See mangle.json for translations.

[OnlyWick]

Got it! use webstorm for debug can directly solve this problem. Thank you for reply.

[myobie]

@rschristian thanks for pointer, but I wanted to ask how one can find all the computeds that use (subscribe to?) a signal? I can find all the effects of a signal by traversing signal.t, but since computed's are lazy (I think) it doesn't seem possible to find them. Is there an example somewhere of how this works or is this just not possible with the design of signal <-> computeds?

[rschristian]

No, I don't believe you're going to be able to easily pull a list of computeds. Is there a particular reason why you want to?

[myobie]

OK, thanks for the reply. I’m trying to visualize my app state (little DAG) to help with data modeling and debugging. I think I can capture every computed into a Map (when debugging, export my own computed() wrapper) and use that to traverse things, so I’ll see how that goes. 🫡