Getting the wrong value from the store when updating this property from another query subscription of the same store

[EricPoul]

I believe it's not an issue but I wanted to ask if you faced the same flow as I'll describe. I guess, I saw the same while using akita.

Here is a small reproduction:
https://stackblitz.com/edit/angular-ivy-bvaokh?file=src/app/app.component.ts
(you need to change two lines of code with each other(28 and 29) to get the right flow)

The problem is that depending on which query I subscribe to first, I can find a bug in getting a value of the query. If I subscribe to filters first then I'll get loading always as false on the screen(even though actions in the store are fine). If I subscribe to loading first then I will see that the loading property is changing to true and then to false and it's the right flow. The reason why I'm not using async pipe here is that it'll subscribe always after init so filters will be subscribed first and it's a wrong flow.

As I understand, it's just because of how js works(I'll try to describe a flow). When we subscribe to filters and loading queries we write down callback that will be performed on store changes. Once the store is changed, in the call stack are put 2 our callbacks with the state that is in the store now(loading now is false). Because filters query is subscribed first its callback is performed first and inside it, we're updating the store property loading and it's now true. So that, loading query subscription is triggered with the current store(loading now is true). Once this's done, the first callback of loading query subscription will be performed since it was waiting for filters query subscription callback(and all synchronous code that was performed inside this callback) to be done. This callback has the store state that was when we updated filters(loading is false) and because of it our property loading has the value false.

Overall, it's just how synchronous code and call stack work(If I get it right).

I wanted to ask you @NetanelBasal what you think about it. I don't know whether it can be handled by lib without breaking changes or not and we just need to pay attention to the order of subscriptions in cases when we have 2 queries from one store and in the one query subscription we update the store property which the second one relies on.

[NetanelBasal]

Stale emission - https://github.com/ngneat/elf/blob/master/packages/store/src/lib/stale.spec.ts

[EricPoul]

So you're aware of it. Just wanted to know that you know😄
Yep, auditTime is a remedy too.

[EricPoul]

Maybe it's a good idea to add this to the docs? It'll be more explicit

[NetanelBasal]

Yes, it's Rx behavior. Unfortunately, we can't do anything as far as I know.

[NetanelBasal]

I didn't add it to the docs because it's hard to explain. That's why I wrote it in a spec file, lol. Any suggestions?

[EricPoul]

I've written it so hard and that's a fortune that you know what I was talking about😄
It's really hard to explain but I could try to simplify my essay to be undirected to the stackblitz example.