Repository navigation
Replies: 2 comments 1 reply
|
I don't have a link off the top of my head, but I'm pretty sure we have some other discussion threads where we actually did describe or semi-recommend that kind of "custom combination" endpoint - ie, using It's an understandable use case, just not one we've tried to support specifically. |
|
I would avoid creating the promise during render and passing it to React The least surprising RTKQ-shaped version is probably the “view model” endpoint Mark mentioned. It does not have to map 1:1 to a backend route. It can be a composed query whose const api = createApi({
// ...
endpoints: (build) => ({
fetchExonsViewData: build.query<Data, QueryParameters>({
async queryFn(args, queryApi) {
const transcriptResult = await queryApi.dispatch(
api.endpoints.fetchDefaultEntityViewerTranscript.initiate(
{
genomeId: args.genomeId,
transcriptId: args.transcriptId,
},
{ subscribe: false }
)
)
if (transcriptResult.isError || !transcriptResult.data) {
return { error: transcriptResult.error as any }
}
const { transcript } = transcriptResult.data
const [genomic, upstream, downstream] = await Promise.all([
queryApi.dispatch(
api.endpoints.fetchRefgetSequence.initiate(
getTranscriptGenomicSequenceQueryParams(transcript),
{ subscribe: false }
)
),
queryApi.dispatch(
api.endpoints.fetchRefgetSequence.initiate(
getUpstreamGenomicSequenceQueryParams({ transcript }),
{ subscribe: false }
)
),
queryApi.dispatch(
api.endpoints.fetchRefgetSequence.initiate(
getDownstreamGenomicSequenceQueryParams({ transcript }),
{ subscribe: false }
)
),
])
if (genomic.isError || upstream.isError || downstream.isError || !genomic.data) {
return { error: (genomic.error ?? upstream.error ?? downstream.error) as any }
}
const exons = prepareExonsData({ transcript, sequence: genomic.data })
const introns = prepareIntrons({ transcript, sequence: genomic.data })
return {
data: {
exons,
introns,
exonsAndIntrons: combineExonsAndIntrons({ exons, introns }),
upstreamFlankingSequence: upstream.data ?? "",
downstreamFlankingSequence: downstream.data ?? "",
},
}
},
}),
}),
})Then the component just does: const result = api.endpoints.fetchExonsViewData.useQuery({ transcriptId, genomeId })That gives you one hook for the view, keeps the sequential/parallel coordination outside render, and still lets the underlying transcript/sequence endpoints participate in RTKQ caching and request de-duping. Two small notes:
So I think your current idea is close. I would just move it behind an RTKQ endpoint boundary instead of combining render-time |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Here is my use case: I have a number of endpoints defined in RTK query; and I love that their results get cached; and in some views, I need to call them individually; but in some other views, I need to call them sequentially.
For example (my domain is genetics), fetch a transcript, then fetch the DNA sequence of the transcript, an upstream DNA sequence, and a downstream DNA sequence. So, four api calls in total. I already have an RTKQ endpoint that can fetch the transcript, and an RTKQ endpoint that can fetch a DNA sequence provided its coordinates.
I can use the RTKQ hooks api; but I have always found it cumbersome for coordinating multiple requests. So instead, I combined multiple requests in a single promise by directly calling RTK endpoints, like so:
I then tried to wait for this promise using the
usehook, which the React team is now advertising as a more appropriate api for data fetching than auseEffectfollowed byuseState.This approach works; however, while doing so, I noticed the following error in the browser console:
Here is a bit of the stacktrace
Now, I recognize that I am probably committing multiple sins at once here, combining the
usehook meant for concurrent rendering, with calls to redux, which is a synchronous external store. I am curious whether you have uncovered best practices for use cases like mine. I am really reluctant to create a dedicated RTKQ endpoint specifically for serving data for a single view by combining within itself calls to several other RTKQ endpoints.All reactions