Description
It would be interesting to have different test setup for qwik. To see how it performs using alternative methods.
Current setup ( not typed as QRL)
https://github.com/krausest/js-framework-benchmark/blob/master/frameworks/keyed/qwik/src/components/app/index.tsx#L90-L96
But are defined as QRL $()
https://github.com/krausest/js-framework-benchmark/blob/master/frameworks/keyed/qwik/src/components/app/index.tsx#L171-L198
Uses QRLs in the onClick$={()=> $(…)}
Which returns a Promise
There are several alternatives that could be interesting to test and compare against.
Ref docs
https://qwik.dev/docs/components/tasks/#track-as-a-function
Instead using a Signal in the onClick$={()=> reset.value = true}
And tracking the signal in a useTask$ / useVisibleTask$ and defining the functions inside of the useTask instead of using $() normal sync functions ie
useTask(({track}) => {
track(reset)
const reset= (count: number) => {
state.data = buildData(count);
selectedItem.value = null;
redraw.value++;
reset.value = false
}),
// … rest of the functions
If(reset.value){
reset(count)
}
// … rest
If
Potential other methods using useComputed$ useOn…
Other alternatives
Declaring functions out of scope of the component, using signal if needed where positional args can’t be passed to functions in use Tasks scope
Not sure if this would improve or be worst but that’s the point ^_^
What I noticed is in the other tests they use normal functions not functions that return a Promise and I think there might be some improvement, maybe not .