fix(angular-query-experimental): run mutation callback in injection context #7360
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 8d537b7. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 1 targetSent with 💌 from NxCloud. |
| // check if injection contexts persist in a different task | ||
| await new Promise<void>((resolve) => queueMicrotask(() => resolve())) |
There was a problem hiding this comment.
Without this, the test will pass with the previous implementation. That is because the callback of effect which causes the exception will run in a different task.
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8d537b7:
|
…ontext Previously, the injectMutation callback was run in injection context only if accessed in the same task as the component initialization (i.e. before the `effect` callback run). By running the effect run in injection context, it is ensured that the callback will always run in injection context, and any `inject` calls will not fail. Note there is a separate issue here, and it's that the callback is always run twice - once synchronously when initialization the mutation, and secondly as the first callback of the `effect`. This is something that can potentially be improved. No breaking changes, any code that worked before should still work.
ShacharHarshuv
force-pushed
the
inject-mutation-callback-should-run-in-injection-context
branch
from
82597e8 to
f34b811
Compare
|
Resolved conflicts. |
|
The tests failures don't seem to be related to my change, as they fail in the react adapter. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7360 +/- ##
==========================================
- Coverage 41.42% 0 -41.43%
==========================================
Files 184 0 -184
Lines 7331 0 -7331
Branches 1531 0 -1531
==========================================
- Hits 3037 0 -3037
+ Misses 3889 0 -3889
+ Partials 405 0 -405
|
|
Can this be merged? |
|
@arnoud-dv I believe this one's good to be merged, wdyt? |
|
Hi I just ran the test from this PR on my laptop and it passes with the current implementation. Can you create a test or a repro that demonstrates the issue? |
|
Nice catch @arnoud-dv ! Thank you for checking this out. @ShacharHarshuv I added a test in kfrancois@eb05ac2#diff-aa4e4fa79cbfdc8cb15c0cfb49c3b858294ec82865c5e2cdbf0ba98e2927dfe4R459-R502 which I verified fails with the current implementation. If you think this can be useful, feel free to take that change along in this PR |
|
@arnoud-dv Apparently the error wasn't caught by the test, thanks for noticing. I took @kfrancois's approach of using an "errorSpy" and manually catching the error. Now the test will fail as expected without my change. |
…lback-should-run-in-injection-context
Previously, the
injectMutationcallback ran in injection context only if accessed in the same context as the component initialization (i.e. before theeffectcallback run). By wrapping the effect callback in injection context, it is ensured that the callback will always run in injection context, and anyinjectcalls will not fail.Note there is a separate issue here, and it's that the callback is always run twice - once synchronously when initialization the mutation (when you create the
MutationObserver), and secondly as the first callback of theeffect. This is something that can potentially be improved to prevent redundant code run.Another related issue - I would argue that if any signal dependencies of the mutation changed, you don't necessarily want to immediately run the callback again. You probably want to be "lazy" and run it again only when the mutation object is accessed. With the current implementation, that callback might unnecessarily run when there are a lot of dependency changes, but no mutation is used. (For example, imagine there is an "opened todo item" state, and a delete button on it. The user might switched the opened todo item state frequently without actually using the delete mutation).
No breaking changes, any code that worked before should still work.