refactor(app): improve top level query chaining #16179
Conversation
mjhuff
force-pushed
the
app_refactor-top-level-query-chaining
branch
from
738becd
to
1c4126c
Compare
| runRecord == null || | ||
| runStatus == null || | ||
| runActions == null || | ||
| isFetching |
There was a problem hiding this comment.
won't using isFetching mean that we renav away after every notification? I think we just want the data being nullish.
There was a problem hiding this comment.
Nope! There's no navigation action taking place if isFetching is null. This isFetching check currently exists in chore_release8.0.0. I talked about it a bit in #16084.
There was a problem hiding this comment.
Resolved per in person convo. Returning null doesn't do a redirect.
| ) { | ||
| return null | ||
| } | ||
| // grabbing run id off of the run query to have all routing info come from one source of truth |
There was a problem hiding this comment.
feels a little gross since we're fetching the run by exact id, hard to think of a situation where they'd be different
There was a problem hiding this comment.
Ok, yeah, I see what you mean here, and yeah, I agree. I guess this comes down to whether we want to keep isFetching, which we probably do per in person convo
| } | ||
| // grabbing run id off of the run query to have all routing info come from one source of truth | ||
| const runId = runRecord.data.id | ||
| const hasRunStarted = runActions?.some( |
There was a problem hiding this comment.
you know, i know this has been the approach for a while, but it does feel a little gross and I wonder if it would be better to do one or more of
- check whether
startedAtis non-null - have the run data model present a different status for "done" and "not started yet"
There was a problem hiding this comment.
Agree with #1, good idea.
For #2, I'd have to think about it a bit (and I'm starting to mull over the idea of run statuses in general with the ProtocolRunHeader refactor). If this was just the "not started yet" case, I'd say this is a different question, but the concept of a done status (or terminal status as we more commonly call it in the app) would go a long way...the issue being that while a "not started yet" status is directly tied to one status only, a done status is tied to "failed", "completed", and "cancelled" statuses.
| import { CURRENT_RUN_POLL } from './constants' | ||
| import { useCurrentRunRoute } from './hooks' | ||
|
|
||
| export function TopLevelRedirects(): JSX.Element | null { |
There was a problem hiding this comment.
can we call this ODDTopLevelRedirects? It will only ever be used there.
There was a problem hiding this comment.
Let's be the change we want to see in the world.
mjhuff
force-pushed
the
app_refactor-top-level-query-chaining
branch
from
ce30d89
to
a43aea5
Compare
Closes EXEC-695
Overview
#16084 highlighted some of the existing issues we had after the recent React Router migration. While that PR fixed some problems, the intention was to prioritize keeping the bug radius small for the upcoming 8.0 release, which meant some changes were not implemented optimally.
Now that we have plenty of time before the 8.1 release, let's dog food networking changes for as long as possible, starting with this one: currently,
TopLevelRedirectschains react queries, taking thecurrentRunIdfromuseCurrentRunIdand feeds it directly intouseNotifyQuery. WhenevercurrentRunIdisnull, weGET /runs/null, which is a network request that we should avoid.After discussion, the most Reactive solution is to isolate the hooks into their own components, and conditionally render a component with the chained hook only if the hook(s) farther up the chain are not
null. In other words, keep the concept of query chaining, but just do it in components.This PR adds some light refactoring and testing, too.
Current Behavior
Fixed Behavior
Test Plan and Hands on Testing
/runs/nulloccurred.Changelog
run/nullroute.Risk assessment
low in theory, but routing changes are always a bit fun