task(docs): Updates docs to include result description meta param [#1904] #1934
Conversation
|
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 939e8ac:
|
|
The CI looks grumpy, but it seems appropriate to fail deploys from unsolicited PRs. Please let me know if there are additional tests I can run to validate docs changes |
|
The docs builds have been finicky ever since we switched to Yarn v3, although it seems to be more something to do with Netlify caching somehow. Usually a "Clear Cache and Rebuild" command on the Netlify dashboard resolves it. |
|
✔️ Deploy Preview for redux-starter-kit-docs ready! 🔨 Explore the source changes: 939e8ac 🔍 Inspect the deploy log: https://app.netlify.com/sites/redux-starter-kit-docs/deploys/61e64d0dcccf0a86af07e2b5 😎 Browse the preview: https://deploy-preview-1934--redux-starter-kit-docs.netlify.app |
| @@ -398,6 +398,7 @@ When using the function notation, both the `providesTags` and `invalidatesTags` | |||
| - result: `ResultType` | `undefined` - The result returned by a successful query. The type corresponds with `ResultType` as [supplied to the built endpoint](#typing-query-and-mutation-endpoints). In the error case for a query, this will be `undefined`. | |||
| - error: `ErrorType` | `undefined` - The error returned by an errored query. The type corresponds with `Error` as [supplied to the `baseQuery` for the api](#typing-a-basequery). In the success case for a query, this will be `undefined`. | |||
| - arg: `QueryArg` - The argument supplied to the `query` property when the query itself is called. The type corresponds with `QueryArg` as [supplied to the built endpoint](#typing-query-and-mutation-endpoints). | |||
| - meta: `MetaType` | `undefined` - The optional `meta` value returned by `baseQuery` | |||
There was a problem hiding this comment.
Hmm, this is tricky to communicate. When using fetchBaseQuery, this will actually be a combination of baseQueryMeta (the type FetchBaseQueryMeta) and a maybe user-defined SomeCustomInjectedMetaAUserProvides. This results in an object that looks like: { request: Request, response?: Response, ...someCustomInjectedMeta }. This will be present for any fulfilled or rejected request.
This might be fine for now, but we'll definitely want to revisit this as well as the Adding Meta information to queries section in customizing-queries.md
There was a problem hiding this comment.
I appreciate the clarification. Let me chew on this feedback and I can push another iteration.
There was a problem hiding this comment.
little confused by this comment - when is baseQueryMeta not determined by the baseQuery? (#4098 not withstanding, which i just discovered)
|
|
||
| 1. the result as the first argument, | ||
| 1. the response error as the second argument, | ||
| 1. the argument originally passed into the `query` method as the third argument, |
There was a problem hiding this comment.
This is generally difficult to read.
Was it (passed into the query method) and is now the third argument to invalidatesTags?
or
Was it (passed into the query method as the third argument)?
Updates docs to reflect changes after PR-1910 was merged.
References
Note: this should also be attached to #1926.