ESLint rule for Best practice: Moving signal reads to useTask$ or useComputed$

[DmitryEfimenko]

What is it about?

Create Qwik ESLint rule to enforce best practices

What's the motivation for this proposal?

Problems you are trying to solve:

• Optimize performance of Qwik app

Goals you are trying to achieve:

• Ensure code written by devs is optimized for performance

Any other context or information you want to share:

Documentation best practices have the following section: Moving signal reads to useTask$ or useComputed$.

It would be good if there was a Qwik ESLint rule enforcing this best practice.

---

Proposed Solution / Feature

What do you propose?

Create a Qwik linting rule that highlights usages of derived state, which is defined at the component level rather than with the usage of useTask$ or useComputed$

Code examples

This should throw linting error/warning:

export default component$(() => {
  const count = useSignal(1);
  const doubleCount = count.value * 2;
  return (
    <div>{doubleCount}</div>
  );
});

This should also throw linting error/warning:

export default component$(() => {
  const state = useStore({ count: 0, name: 'Qwik' });
  const doubleCount = state.count * 2;
  return (
    <div>{doubleCount}</div>
  );
});

Side note: in case of useSignal, the type of count is Signal<number>. However, in case of useStore, the type of state is simply the state object shape - so: { count: number; name: string }. This type does not indicate in any way that state is reactive. This certainly brings a bit of traction to the dev experience - it adds cognitive load to the dev having to remember this. It also might or might not play a part in the complexity of writing the ESLint rule - not sure about that one.

---

Links / References

https://qwik.dev/docs/guides/best-practices/#moving-signal-reads-to-usetask-or-usecomputed

[JerryWu1234]

I think it's good point.
It would be good if someone could list all the cases here.