lint plugin should complain when writing track(() => storeOrSignal)

[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.

[mhevery]

I think you are saying that track(() => signal) and track(signal) should behave equivalently.

My issue is that it is confusing:

track(() => store.a.b); // creates subscription on a of store and  another subscription on b of a
track(store.a.b); will only subscribe to nothing; (but if `b` is value or store, then it will subscribe to the store/ or signal NOT to the value

I believe this behavior is a foot gun, and i would rather just not allow the shortcut as it will have surprising behavior.

[wmertens]

correction, I wasn't proposing that track(store.a.b) would do anything.

Instead track(() => store.a.b) would actually subscribe to store.a and all keys of store.a.b if b is an object.

Anyway, this is still a bit haphazard, so making it a lint rule seems better.

[shairez]

After another RFC meeting we decided to go with the lint rule for this.

waiting for a champion to lead this.