fix(store): reduce change detection cycles with pending tasks #2280
Conversation
162bdd5 to
a893a2f
Compare
|
View your CI Pipeline Execution ↗ for commit 0cb3dab.
☁️ Nx Cloud last updated this comment at |
@ngxs/devtools-plugin
@ngxs/hmr-plugin
@ngxs/form-plugin
@ngxs/router-plugin
@ngxs/storage-plugin
@ngxs/store
@ngxs/websocket-plugin
commit: |
BundleMonFiles updated (1)
Unchanged files (5)
Total files change +1.69KB +1.29% Groups updated (1)
Final result: ❌ View report in BundleMon website ➡️ |
BundleMon (NGXS Plugins)Unchanged files (9)
No change in files bundle size Unchanged groups (1)
Final result: ✅ View report in BundleMon website ➡️ |
BundleMon (Integration Projects)Files added (1)
Files removed (3)
Total files change -139.27KB -67.72% Final result: ✅ View report in BundleMon website ➡️ |
a893a2f to
1b533f6
Compare
There was a problem hiding this comment.
What is the logic change?...
As far as I can see, it was previously creating a task for every action dispatched, but now it creates one and keeps track of the actions dispatched while that pending task is active.
It keeps that pending task active until the last dispatched action completes (the tracked actions go down to zero).
I left comments in the code describing the change but haven’t added the commit message yet. |
12e517f to
477e98e
Compare
477e98e to
b5c2a56
Compare
An `INFINITE_CHANGE_DETECTION` error has been logged to the error service multiple times, occurring randomly depending on the number of actions dispatched in a row. This happens because a pending task is added every time an action is dispatched. Removing a pending task via the public API forces a scheduled tick, ensuring that stability is asynchronous and delayed until there has been at least an opportunity to run app synchronization. This change reduces the number of change detection cycles. For example, if 10 synchronous actions are dispatched in a row, it may previously trigger 10 change detection cycles, as tasks would be removed 10 times. We listen to the actions stream, and every time a context with a `dispatched` status is generated, we add a pending task only once and keep it until the action is completed. If multiple actions are dispatched at the same time, we debounce them and use `buffer` to collect them into a single list.
b5c2a56 to
0cb3dab
Compare
|
Code Climate has analyzed commit 0cb3dab and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 95.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 95.3% (0.0% change). View more on Code Climate. |
An
INFINITE_CHANGE_DETECTIONerror has been logged to the error service multiple times,occurring randomly depending on the number of actions dispatched in a row. This happens
because a pending task is added every time an action is dispatched. Removing a pending task
via the public API forces a scheduled tick, ensuring that stability is asynchronous and
delayed until there has been at least an opportunity to run app synchronization.
This change reduces the number of change detection cycles. For example, if 10 synchronous
actions are dispatched in a row, it may previously trigger 10 change detection cycles, as
tasks would be removed 10 times.
We listen to the actions stream, and every time a context with a
dispatchedstatus isgenerated, we add a pending task only once and keep it until the action is completed.
If multiple actions are dispatched at the same time, we debounce them and use
bufferto collect them into a single list.