chore: v2 - integrate update components#2242
Conversation
🎩 PreviewA preview build has been created at: |
| * | ||
| * The window is only opened from the V2 editor, so {@link useSpec} should | ||
| * always return a non-null spec here; the null branch is defensive and | ||
| * returns no candidates without doing any work. |
There was a problem hiding this comment.
🤖 This is an AI-generated code review comment.
Nit: the doc says "returns no candidates without doing any work", but the if (!spec) branch is checked after useOutdatedComponents(EMPTY_USED_COMPONENTS) runs (hook rules require this). With an empty input the query function returns [] immediately so this is cheap in practice, but the comment overstates it.
Suggest rewording to something like "the null branch returns no candidates without iterating the spec".
| @@ -0,0 +1,82 @@ | |||
| import type { ComponentReference } from "@/models/componentSpec"; | |||
| import type { ComponentSpec } from "@/models/componentSpec/entities/componentSpec"; | |||
| import type { ComponentSpecJson } from "@/models/componentSpec/entities/types"; | |||
There was a problem hiding this comment.
🤖 This is an AI-generated code review comment.
Minor: ComponentSpec and ComponentSpecJson are both re-exported from the @/models/componentSpec barrel, so the deep paths here are inconsistent with the other new files in this PR (which all use the barrel). Suggest:
import type {
ComponentReference,
ComponentSpec,
ComponentSpecJson,
} from "@/models/componentSpec";| @@ -0,0 +1,21 @@ | |||
| import type { ComponentSpec } from "@/models/componentSpec"; | |||
| import type { ComponentReference } from "@/utils/componentSpec"; | |||
There was a problem hiding this comment.
🤖 This is an AI-generated code review comment.
Nit: ComponentReference is re-exported from @/models/componentSpec too, so both imports can come from the same module. The mixed sources are unnecessary churn given the rest of the new files in this PR consistently use @/models/componentSpec.
import type { ComponentReference, ComponentSpec } from "@/models/componentSpec";|
|
||
| const usedComponents = spec | ||
| ? collectUsedComponentReferencesFromV2Spec(spec) | ||
| : (usedComponentsFolder.components ?? []); |
There was a problem hiding this comment.
🤖 This is an AI-generated code review comment.
This V2 branch only renders inside a window context, which only exists inside the V2 editor where useSpec() returns a non-null spec. The usedComponentsFolder.components ?? [] fallback path looks unreachable in practice, but the useComponentLibrary() call still subscribes this component to ComponentLibraryProvider updates — extra re-renders for behavior we never hit.
Two options:
- If the invariant really is "spec is non-null in V2", drop the destructure (and the
useComponentLibrary()call) and just use the spec. - If spec genuinely can be null here, a one-line comment explaining when would help.

Description
Wires the Upgrade Components window in the V2 editor to real outdated-component data instead of always using mock candidates.
Key changes:
collectUsedComponentReferencesFromV2Spec– new utility that collects unique component references from V2 spec tasks (deduped by digest), mirroring the existing graph-basedfetchUsedComponents.buildUpgradeCandidateFromResolved– extracted shared logic for building anUpgradeCandidatefrom a resolved task spec and a target component ref (including lost-binding detection and issue prediction). Previously this logic was duplicated insideuseMockUpgradeCandidates.useUpgradeCandidatesFromOutdated– new hook that callsuseOutdatedComponentswith the V2 spec's used components and maps the outdated pairs toUpgradeCandidateobjects usingbuildUpgradeCandidateFromResolved.UpgradeComponentsContent– now accepts adataSourceprop ("real"|"mock")."real"(the default) usesuseUpgradeCandidatesFromOutdated;"mock"uses the existing mock hook. The inner rendering logic is extracted intoUpgradeComponentsInner.useUpgradeComponentsWindow– accepts an optional{ useMock?: boolean }argument. WhenuseMockis true (debug panel only), it opens with mock data; otherwise it opensUpgradeComponentsContentwithdataSource="real"wrapped in a suspense boundary with a skeleton fallback.UpgradeAvailableAlertBox– now renders two variants depending on whether a window context is present. Inside the V2 window chrome (e.g. docked Component Library), the Review button opens the Upgrade Components window viauseUpgradeComponentsWindow. In the V1 sidebar (no window context), the existing nodes-overlay flow is preserved. Alert visibility and dismiss logic are extracted into a shareduseUpgradeAlertVisibilityhook.useOutdatedComponentsquery key – changed from the fullComponentReference[]array to a sorted array of digest strings, preventing unnecessary cache misses caused by object reference changes.Related Issue and Pull requests
Type of Change
Checklist
Screenshots (if applicable)
Component Update.mov (uploaded via Graphite)
Test Instructions
Additional Comments
The debug panel intentionally continues to use
useMock: trueso developers can exercise the upgrade UI without needing a pipeline with genuinely outdated components.