-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eliminate cache.writeData. #5923
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 @benjamn! The code changes look awesome as usual. I added one small Migration Guide mention in the TODO list.
0c231d1
to
6fdab9d
Compare
c37555b
to
6b2df25
Compare
Huh, stumbling upon this is exciting. We're doing a deep integration into client-side cache management and local state/resolvers and it was never truly clear to me why all the different cache modification APIs existed. |
4c88b4d
to
339aad4
Compare
6b2df25
to
4c88b4d
Compare
I referred to cache.writeData as a "foot-seeking missile" in PR #5909, because it's one of the easiest ways to turn your faulty assumptions about how the cache represents data internally into cache corruption. PR #5909 introduced an alternative api, cache.modify(id, modifiers), which aims to take the place of the more "surgical" uses of cache.writeData. However, as you can see, in almost every case where cache.writeData was used in our tests, an appropriate query was already sitting very close by, making cache.writeQuery just as easy to call. If you think your life is worse now that you have to pass a query to cache.writeQuery or a fragment to cache.writeFragment, please realize that cache.writeData was dynamically creating a fresh query or fragment behind the scenes, every time it was called, so it was actually doing a lot more work than the equivalent call to cache.writeQuery or cache.writeFragment.
339aad4
to
f77d6d2
Compare
f77d6d2
to
36559aa
Compare
Codecov Report
@@ Coverage Diff @@
## master #5923 +/- ##
==========================================
- Coverage 95.24% 95.20% -0.04%
==========================================
Files 89 88 -1
Lines 3703 3674 -29
Branches 909 903 -6
==========================================
- Hits 3527 3498 -29
Misses 154 154
Partials 22 22 Continue to review full report at Codecov.
|
We should be all set here @benjamn. I have several more local state section changes coming, but since they aren't specifically related to |
Neat! |
I was following the doc about local state management which still includes |
@duskmoon314 They have updated documentation for these changes in the v3.0 beta branch. |
this document still talks about |
Thanks @AndreiRailean - we're working on changes to the tutorial to address this. |
Thanks, @hwillson this is my first time with the I was not able to figure out why it's not working. I'm looking forward to the update in the tutorial. Thanks. |
Are there docs on the |
Link is dead. |
In PR #5909, I referred to
cache.writeData
as a "foot-seeking missile" because it's one of the easiest ways to turn your faulty assumptions about how the cache represents data internally into cache inconsistency and corruption.PR #5909 introduced an alternative api,
cache.modify(id, modifiers)
, which aims to take the place of the more "surgical" uses ofcache.writeData
. Somewhat to my surprise, in almost every case wherecache.writeData
was used in our tests, an appropriate query was already sitting very close by, makingcache.writeQuery
just as easy to call.If you think your life is worse now that you have to pass a query to
cache.writeQuery
or a fragment tocache.writeFragment
, please realize thatcache.writeData
was dynamically creating a fresh query or fragment behind the scenes, every time it was called, so it was actually doing a lot more work than the equivalent call tocache.writeQuery
orcache.writeFragment
.Left to do:
cache.writeData
.CHANGELOG.md
.cache.writeData
tocache.writeQuery
in the Migration Guide.