[✨] self-referencing QRLs (was: Allow binding `this` to the store in useStore)

[wmertens]

Is your feature request related to a problem?

It would be nice to have have functions in stores be bound to the store object.

Describe the solution you'd like

I think a bind option to useStore would be nice. It could even be true by default because the majority use case for functions in the store is using the store object itself.

This can be used orthogonally with deep and reactive.

import { component$, useStore, $, useTask$ } from '@builder.io/qwik';

export default component$(() => {
  const store = useStore({
    count: 1,
    inc: $(function () {console.log('I have a this:', !!this);this.count++})
  }, {bind: true})

  return <p>Count: {store.count} <button onClick$={store.inc}>one up</button></p>;
});

Describe alternatives you've considered

letting the deserializer do it, but then the function is only bound when it's deserialized.

Additional context

This allows making zustand-like APIs.

UPDATE

See this comment to see how to do it manually, but it would be nice if the optimizer did it.

[justoverclockl]

pr opened, hope it helps:

QwikDev/qwik#5088

[mhevery]

I assume this workaround is too wordy

import { component$, useStore, $, useTask$ } from '@builder.io/qwik';

export default component$(() => {
  const store = useStore({
    count: 1,
    inc: null!
  })
  store.inc = $(function () {store.count++})

  return <p>Count: {store.count} <button onClick$={store.inc}>one up</button></p>;
});

Wondering if something like this would work:

import { component$, useStore, $, useTask$ } from '@builder.io/qwik';

export default component$(() => {
  const store = useStore({
    count: 1,
    inc: storeMethod$(function () {store.count++})
  })

  return <p>Count: {store.count} <button onClick$={store.inc}>one up</button></p>;
});

The semantics of method$ would be such that it would ensure that store.inc would pre-bind it to the store.

[wmertens]

@mhevery the first version is not allowed because then you're updating a store during a render function, right?

The second option looks like it could work, but it would still cause an error with the serialization, because it's referring to the store while creating it, no? Or does the extra QRL fix that?

In any case, if that worked, I think this would work too:

const store = useStore({ count: 0, inc: $(() => store.inc++) })

Note that the workaround is this:

import { component$, useStore, $, useTask$ } from '@builder.io/qwik';

export default component$(() => {
  const store = useStore({
    count: 1,
    inc: $(function () {this.count++})
  })
  useTask$(({})=>{
    const prevInc = store.inc
    store.inc = $(() => prevInc.call(store))
  })

  return <p>Count: {store.count} <button onClick$={store.inc}>one up</button></p>;
});

This works but it means an extra task and an extra QRL for each bound function.

[wmertens]

I found how to do it!

https://qwik.builder.io/playground/#v=1.1.5&buildMode=production&f=Q0o0xobG2BKNjgIQwWpdilMQJDjS8vOBoVENbhlYgYuuWqAcUFQP0liwhVuoAdIE0gYs9q0UDHXAvMy8ZCsFkKkgQ%2BG69MCKtLVrNYGKwATEsmqwuA5IVy3QZLh6LpQE7QyxAaK4FhiY4FYOonKvBmm3A%2FoHWFnC20CjaX8op30A

import { component$, $, useStore } from '@builder.io/qwik';

export default component$(() => {
  const foo = {store: null}
  foo.store = useStore({
    count: 1,
    inc: $(()=> {foo.store.count++})
  })
  const {count, inc} = foo.store

  return <p>Count: {count} <button onClick$={inc}>one up</button></p>;
});

Would the optimizer be able to take

const store = useStore({ count: 0, inc: $(() => store.inc++) })

and convert it to

const __ref = {}
ref.store = useStore({ count: 0, inc: $(() => __ref.store.inc++) })
const store = __ref.store

?

[mhevery]

We don't want to teach optimizers such tricks, as it would lead to weird corner cases. How should the optimizer know when it is safe to convert this to __ref? I can imagine lot's of ways to break it, which will result in bugs being filed. The simpler, the better.

[wmertens]

@mhevery this would only apply when it's encountering a self-reference during conversion. this is not used.

const store = useStore({ count: 0, inc: $(() => store.inc++) })

is valid JS

but the conversion does

const store = useStore({ count: 0, inc: qrl(() => ..., [store]) })

which is not valid due to reference before initialization. Replacing const with var makes it valid JS but the QRL function will be getting [undefined] so it won't help.

By making a temporary object as a stable ref, the conversion becomes

const __ref = {};
__ref.store = useStore({
    count: 1,
    inc: /*#__PURE__*/ qrl(()=>import("./s_wp3wbze0ge0.js"), "s_wP3wBzE0Ge0", [
        __ref
    ])
});
const store = __ref.store

which is correct JS and the serializer is happy too.

[wmertens]

The optimizer would be applying a transform that makes it accept valid JS code that it couldn't accept before.

[mhevery]

This would work

const store = useStore({ count: 0, inc: $(() => store.inc++) })

But this would not

import {inc} from '...';

const store = useStore({ count: 0, inc: inc)

The optimizer would not know that inc is a function that needs to be bound.

Teaching Optimizer tricks is potentially dangerous as it creates corner cases where things will not work the way you want.

Sorry if I sound too negative, but I have learned my lessons from Angular days about such things, and I am not overly cautions.

[wmertens]

@mhevery I understand and share your caution, but I think that in this particular case it's fine, because the binding isn't happening invisibly, it's part of the scope. The second example you give won't be bound by anything, not in regular JS and not after optimizing.

I think that this is a corner case where the optimizer encounters valid JS and due to its regular transform, it breaks the JS.

By adding a temporary ref when needed (or even every time), the optimizer generates code that is equivalent to what was there before. The temporary ref is only visible to the optimizer and the QRL encapsulation.

I believe this allows writing useful JS in an intuitive way.

Note that the useStore here is in no way involved, it's purely about capturing the valid interaction between const store = ... and ()=>store.count++

[wmertens]

In fact, this same technique allows you to define recursive QRL functions:

import { component$, $ } from '@builder.io/qwik';

const fibModuleScope = n => n > 1 ? (fibModuleScope(n-1)+fibModuleScope(n-2)) : 1

export default component$(() => {
  const __ref = {} as any
  __ref.fib$ = $(async n => n > 1 ? ((await __ref.fib$(n-1))+(await __ref.fib$(n-2))) : 1)
  const {fib$} = __ref

  return <p>Fib 5 {fibModuleScope(5)}<br/> Fib$ 5 {fib$(5)} </p>;
});

https://qwik.builder.io/playground/#v=1.1.5&f=Q0o0xuaW2BKNjgL%2BdAPxYFpmkm9%2BSmlOKrgOA3o1D%2BTTPAU7BUMFewUNVGmNPF1DTW0MMSNNTQUrBUPikiLE2vh4YIEHtK26FljGgCo0oAxYTA9ougpQQkUDUvagOkcDUk0gVIJdpKmNTRzoKrCzNOGWVoNkaoGGg9VxoeQLt8wkBVOwCmS%2FmWrW2iQV6dspAKVVoPIqIFFgXIzmnqGbewA

You can't just wrap fibModuleScope with $() but by adding a temporary __ref you can.

[mhevery]

Workaround:
working example

import { component$, $, useStore } from '@builder.io/qwik';

interface State {
  count: number;
  increment(): Promise<void>;
}

export default component$(() => {
  const state = useStore<State>({
    count: 0,
    increment: $(function (this: State) {
      this.count++;
    }),
  });
  return (
    <button onClick$={() => state.increment()}>Count: {state.count}</button>
  );
});

[wmertens]

@mhevery is that workaround better than using an extra object for containing the scope?