fix(FR-2977): open add-revision modal directly from revision history#7743
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has required the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Coverage Report for react-coverage (./react)
File Coverage
|
||||||||||||||||||||||||||||||||||||||
There was a problem hiding this comment.
Pull request overview
Removes redundant outer <Suspense> wrappers around the lazily-mounted Add Revision modal so opening it no longer triggers a page-level Suspense fallback flash or a “loading modal → real modal” swap. The modal now opens directly while its internal sections handle their own loading UI.
Changes:
- Drop the page-level
<Suspense fallback={null}>wrapper aroundDeploymentAddRevisionModalinDeploymentDetailPage. - In
DeploymentRevisionHistoryTab, remove the<Suspense fallback={<Modal loading />}>shell-swap and mount the modal viaReact.startTransitionfrom both entry points. - Update stale inline comments on the Add Revision buttons to reflect the modal’s current non-suspending mount behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| react/src/pages/DeploymentDetailPage.tsx | Removes the outer Suspense boundary around the Add Revision modal to prevent page-level fallback flashes. |
| react/src/components/DeploymentRevisionHistoryTab.tsx | Removes the loading-modal Suspense fallback swap and opens the modal via transitions from both revision-history entry points. |
| react/src/components/DeploymentConfigurationSection.tsx | Updates button comment to match the modal’s current loading/suspense behavior. |
5b35048 to
7411070
Compare
Merge activity
|
…7743) Resolves #7601 (FR-2977) > **Stacked on #7724 (FR-2977).** Addresses Seungwon Lee's review feedback on the FR-2977 / FR-2957 revision stack ([devops Teams thread](https://teams.microsoft.com/l/message/19:acd1be4236b94664b814f4d4e5c84da6@thread.skype/1780626400941)). ## Problem Opening the **Add Revision** modal from the revision-history entry points (row overflow menu / drawer **More ⋯**) showed a `<Modal loading />` shell first, then **swapped** it for the real modal once the modal's lazy chunks resolved — the modal visibly went down and a new one came up, inconsistent with the rest of the app. ## Why the boundary is load-bearing (and the fallback was the only problem) `DeploymentAddRevisionModal` **does** suspend on mount: its preset / model-folder / runtime-variant selects (`BAIAvailablePresetSelect`, `BAIVFolderSelect`, `BAIRuntimeVariantSelect`) each run their own `useLazyLoadQuery` and are rendered directly in the form body (not behind the modal's inner `<Suspense>` sections). So the local `<Suspense>` boundary around the mount is **load-bearing** — it keeps that suspend from bubbling up to the page-level boundary and blanking the page. The boundary must stay; only its **fallback** was wrong. ## Change `DeploymentRevisionHistoryTab` — change the modal-mount Suspense `fallback` from a `<Modal loading />` shell to **`null`**, so the modal simply appears once ready instead of a loading-modal-then-real-modal swap. This matches how the same kind of lazily-mounted modal is handled elsewhere: - `DeploymentDetailPage` → `<Suspense fallback={null}><BAIUnmountAfterClose><DeploymentAddRevisionModal/></BAIUnmountAfterClose></Suspense>` - `VFolderNodesV2` → identical `<Suspense fallback={null}>` wrapper around `VFolderDeployModal` Removes the now-unused `Modal` import. One-file, behavior-only change — no data-flow, query, or schema change. ## Test plan - [x] Revision History row **⋯ → New revision based on this** opens the real modal directly (no loading-modal-then-real-modal swap), prefilled from that revision. - [x] Revision-detail drawer **More ⋯ → New revision based on this** — same: drawer closes and the real modal opens directly. - [x] The modal's lazy selects still show their own field-level skeletons while loading; the page never blanks (local Suspense boundary retained). - [x] `bash scripts/verify.sh` — Relay, Lint, Format, TypeScript all PASS. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
7411070 to
606e1b9
Compare

Resolves #7601 (FR-2977)
Problem
Opening the Add Revision modal from the revision-history entry points (row overflow menu / drawer More ⋯) showed a
<Modal loading />shell first, then swapped it for the real modal once the modal's lazy chunks resolved — the modal visibly went down and a new one came up, inconsistent with the rest of the app.Why the boundary is load-bearing (and the fallback was the only problem)
DeploymentAddRevisionModaldoes suspend on mount: its preset / model-folder / runtime-variant selects (BAIAvailablePresetSelect,BAIVFolderSelect,BAIRuntimeVariantSelect) each run their ownuseLazyLoadQueryand are rendered directly in the form body (not behind the modal's inner<Suspense>sections). So the local<Suspense>boundary around the mount is load-bearing — it keeps that suspend from bubbling up to the page-level boundary and blanking the page. The boundary must stay; only its fallback was wrong.Change
DeploymentRevisionHistoryTab— change the modal-mount Suspensefallbackfrom a<Modal loading />shell tonull, so the modal simply appears once ready instead of a loading-modal-then-real-modal swap. This matches how the same kind of lazily-mounted modal is handled elsewhere:DeploymentDetailPage→<Suspense fallback={null}><BAIUnmountAfterClose><DeploymentAddRevisionModal/></BAIUnmountAfterClose></Suspense>VFolderNodesV2→ identical<Suspense fallback={null}>wrapper aroundVFolderDeployModalRemoves the now-unused
Modalimport. One-file, behavior-only change — no data-flow, query, or schema change.Test plan
bash scripts/verify.sh— Relay, Lint, Format, TypeScript all PASS.🤖 Generated with Claude Code