track(() => storeOrSignal) should track the store or signal

[wmertens]

What is it about?

No response

What's the motivation for this proposal?

Problems you are trying to solve:

• people write track(() => signal) instead of track(signal) and this doesn't do anything
• same for stores
• reduce surprise

---

Proposed Solution / Feature

What do you propose?

when the track is given a callback, and the callback returns a signal/store, then that signal or store should be subscribed to.

Note that unlike track(signal) where it returns signal.value, track(() => signal should return signal, for backwards compatibility.

Code examples

useTask$(({track}) => {
  track(() => myStore)
  // stuff
})

---

Links / References

No response

[shairez]

Thanks @wmertens !

We've just reviewed this and these were the conclusions;

1. for cases where a store prop is a signal, or a signal value is another signal, this assumption break because Qwik cannot guess if you want to continue to subscribe to the signals or just stop after one.

2. On the other hand, having a lint rule that warns developers from the wrong way to use the track() is a much better solution because it prevents Qwik from over subscribing while still provide a better DX.

WDYT?

[wmertens]

@shairez no, when you return a Signal it should subscribe to the Signal. When you return a Store it should subscribe to the Store, meaning it will get called when the store is mutated (store.foo=1) but not when the children are mutated (store.foo.bar=1).

It should not descend into children. If you return store.sig, you're returning a signal, not a store.