Race condition on updating store in store.select(...) subscription

[shanovskyi-b]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

When you subscribe via store.select to prop1 and use store.update for prop2 in the prop1 subscription it reverts prop2 state.

Expected behavior

Store update works fine in the store.select subscription.

Minimal reproduction of the problem with instructions

STEPS TO REPRODUCE:

• create a store with two properties;
• subscribe to the first property and call store.update for the second property in it;
• update the first property and see results;

What happens:

• prop1 update is called ✔️
• prop1 subscribe is called that calls prop2 update ✔️
• prop2 subscribe is called with new prop2 value ✔️
• prop2 subscribe is called again with previous prop2 value (the one that was before new) 🟥

MINIMAL DEMO:
https://stackblitz.com/edit/akita-todos-app-y1bwtu?file=src/app/test/test.component.ts

What is the motivation / use case for changing the behavior?

It's quite common to make some data loading based on some UI filter's state, the easiest way to do that is in the subscription to filter's state property.
Inside of this subscription it's quite useful to set a loading flag, clean up the existing data and finally make call for the new data.

Because of the bug, the loading flag is not set, the data is not cleaned.

The workaround is to use setTimeout in the subscription but i believe it shouldn't work like that,

Environment

"@angular/core": "^10.2.4",
"@datorama/akita": "^5.2.1",
"@datorama/akita-ngdevtools": "^5.0.3",

Also reproduced on:
"@angular/core": "^9.1.11",
"@datorama/akita": "^5.0.5",
"@datorama/akita-ngdevtools": "^5.0.3",


Browser:
- [X] Chrome (desktop) version 89.0.4389.114
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: v12.13.1
- Platform:  Windows

[staciedev]

Thank you @shanovskyi-b for submitting this. It's really sad to be unable to update a property like that.

I've made some research on the issue and found out this behavior can be reproduced with pure RxJS, using a BehaviorSubject instead of Akita Store. So it seems to be an RxJS bug, still reproduced with latest v7.1.0.

Nevertheless it may be worth trying to implement a workaround in Akita, because state properties depending on each other seem to be a very common solution.

I would gladly work on a PR, but I'm not sure what is the best approach here. Really need to know most active contributors' opinion!

[shanovskyi-b]

Hey @staciedev, thanks for your response.

Could you add a bit more info about the RxJs bug you have mentioned? (probably there's some rxjs github issue or just some minimal reproduction)

I've tried to play around updating the BehaviourSubject values in it's own subscription (which is probably happening in the Akita store), but wasn't able to reproduce it

[nzav]

Here's a demo app that reproduces the issue using just BehaviorSubject. Definitely just the way RxJs handles task scheduling.

@NetanelBasal might be a good idea to mention this side-effect somewhere in the docs, maybe in Best Practised section. Seems like Akita makes it tempting to use "subscribe to one part of the state and modify another part as the result" architecture.

[NetanelBasal]

@nzav would love to see a PR

[staciedev]

@shanovskyi-b
Here is a fork of your example :) https://stackblitz.com/edit/akita-todos-app-2irvjf?file=src/app/test/test.component.ts
I haven't looked for RxJS open issues yet but I'm going to to it.

[NetanelBasal]

There are similar closed issues where I described that it's not related to Akita. As @staciedev said, it's how Rx works.