Docs - add 'Cached data' concept page #1036
Conversation
|
Deploy preview for redux-starter-kit-docs ready! Built with commit 2828b7d https://deploy-preview-1036--redux-starter-kit-docs.netlify.app |
|
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 2828b7d:
|
docs/usage/rtk-query/cached-data.md
Outdated
|
|
||
| ## Definitions | ||
|
|
||
| - _tags_ - Items used to identify the data present in the cache. An individual `tag` has a `type`, represented as a `string` name, and an optional `id`, represented as a `string` or `number`. |
There was a problem hiding this comment.
This in combination with the paragraph can be read as "if two endpoints have the same tags and one has been fetched, the other won't be".
Can we make it more clear that tags are just for refetching?
There was a problem hiding this comment.
I've relocated the definitions from the 'Mutation' page into this 'Cached data' page with some minor tweaks/additions, and added a 'note' section to the 'Providing cache data' section to better clarify the intent & behaviour of tags with a more explicit explanation
docs/usage/rtk-query/cached-data.md
Outdated
| }) | ||
| ``` | ||
|
|
||
| Note that for the example above, the `id` is used where possible on a successful result. In the case of an error, no result is supplied, and we still consider that it has provided the general `'Post'` tag type rather than any specific instance of that tag. |
There was a problem hiding this comment.
Hmm. I'm not 100% sure if providing the general ['Post'] tag makes any sense here. That would invalidate only if an endpoint would invalidate all posts by invalidatesTags: ['Post'].
I'd rather have a LIST id in both results as well.
There was a problem hiding this comment.
PS: reading further I why it is still missing here though
There was a problem hiding this comment.
Yeah the goal was to try to introduce it as a general concept piece by piece first rather than immediately going into 'This is how you should be using it'.
I've added another 'tip' block in the 'Providing cache data' section linking to the 'Advanced Invalidation' section which hopefully is clear enough.
Shrugsy
changed the title
|
Ahh damn conflicts. The joys of concurrent PRs 😅 @Shrugsy if you have the resources could you please fix those up and maybe also add TS to the examples here? |
No problem, I'll get it fixed up when I have some time |
- Add miscellaneous content to the 'Cached Data' docs page - Fix outdated links to renamed `provides`/invalidates` docblock summaries - Expand `providesTags` docblock summary
- Add tag invalidation examples & table
Co-authored-by: Lenz Weber <mail@lenzw.de>
- Relocate cache invalidation sections from `Mutations` page to `Cached Data`
- Fix incorrect 'invalidation' examples in 'Invalidation Behavior' table
Shrugsy
force-pushed
the
docs/add-cache-concept-page
branch
from
23e241c to
2828b7d
Compare
|
@phryneas I've rebased on top of |
|
Thank you! |
Adds a 'Cached data' docs page. Intended to cover as much of the caching concept in a single page as is reasonable.
Moves the 'invalidation' stuff from the 'Mutation' page onto this 'Cached data' page, as IMO adding more details about invalidation would have cluttered and distracted too much on the 'Mutation' page.
Note regarding the 'Invalidation behavior' table:
The colour for the 'diagonal' line in the upper left table cell for 'invalidation behaviour' is hard coded in.
I couldn't find a great way to have a diagonal line in the cell like that using css and use a css variable for the colour (--ifm-table-border-color is what we would have wanted).
Since the best method I found uses an inline svg in a
background: url(...)string, I couldn't see a way to use the css variable for the colour.However, hard-coding the colour from the light-mode border doesn't look extremely out of place in dark mode IMO