Repository navigation
Group B: the MeshNode surface renderers fold into MeshWeaver.Blazor.Graph - #2082
Conversation
…raph The second half of the entity-view extraction: 12 files (~2.3k lines + 4 scoped-CSS bundles) leave src/MeshWeaver.Blazor/Components for src/MeshWeaver.Blazor.Graph — MeshNodeThumbnailView, MeshNodeCardView, MeshNodeErrorCardView, MeshNodeCollectionView, MeshNodeContentEditorView, MeshNodeRoleEditorView. (MeshNodePickerView moved in the previous PR: its FormComponentBase base forced the pull-forward.) This FIXES an existing inconsistency rather than creating a new seam: AddGraphViews already registered four of these views from the WRONG assembly (via `using MeshWeaver.Blazor.Components`), and MeshNodeCardControl was DOUBLE-registered — once in the pack, once in the base registry's switch. After the move there is ONE registration, in Blazor.Graph, and the base arms for MeshNodeCollectionControl and MeshNodeCardControl are gone (MeshSearchControl stays — MeshSearchView remains a base surface). ## The MeshSearchView seam MeshSearchView (staying in base) rendered <MeshNodeCardView …/> at four sites — a compile-time component reference the base pack can no longer make without inverting the reference direction. All four now render <DispatchView ViewModel="@cardcontrol" …/>: the search page renders whatever view the mesh's registered pack maps to MeshNodeCardControl. Pinned by MeshNodeCardControl_ResolvesThroughThePortalRegistry on the real portal composition (AddBlazor + AddGraphViews — the same ILayoutClient instance DispatchView consults, verified identical through PortalApplication.Hub); the card MARKUP stays pinned by the two existing RenderAsync card tests. Asserted at the registry rather than through a static DispatchView render because the one-shot HtmlRenderer cannot drive DispatchView's post-parameter re-render — a harness artifact, not a seam. ## The rest - BlazorGraphExtensions registers MeshNodeCollectionControl and drops the foreign-assembly using; Graph's _Imports gains the base-component / Layout / Data / Messaging usings the views relied on from the base pack's _Imports chain. - The react parity ratchet: MeshNodeCard + MeshNodeCollection move to EXTERNALLY_PACKED_CONTROLS (the >30 scrape guard still clears at 32) — coverage moved, not deleted. - ViewPackRegistrationGateTest: the Graph rows now name the views in their new home and gain the MeshNodeCollection row. ## Verified - Release builds green (warnings-as-errors): Blazor, Blazor.Graph, Portal.Shared, Portal.Shared.Test, Hosting.Blazor.Test, Layout.Test, Graph.Test. - Suites: Hosting.Blazor.Test 444/444, Layout.Test 474/474 and Graph.Test green, react parity 9/9. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR continues the entity-view extraction chain by relocating the “MeshNode surface” Blazor renderers (card/collection/thumbnail/content editor/role editor) into MeshWeaver.Blazor.Graph, updating registration and base-pack call sites so the base pack no longer directly references pack components.
Changes:
- Move MeshNode surface view components (and scoped CSS) into
src/MeshWeaver.Blazor.Graphand update namespaces/usings accordingly. - Update view registration: Graph pack (
AddGraphViews) becomes the single source of truth for these controls; baseBlazorViewRegistrydrops theMeshNodeCardControlarm andMeshSearchViewswitches toDispatchViewfor card rendering. - Update tests and parity ratchets to reflect external packing and to pin resolution through the real portal registry composition.
Reviewed changes
Copilot reviewed 12 out of 20 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| test/MeshWeaver.Hosting.Blazor.Test/ViewPackRegistrationGateTest.cs | Updates gate rows to assert Graph pack registrations from the new assembly; adds MeshNodeCollection coverage. |
| test/MeshWeaver.Hosting.Blazor.Test/ControlStyleRenderingTest.cs | Registers both EntityViews + Graph packs in the harness; adds a registry-resolution assertion for MeshNodeCardControl. |
| src/MeshWeaver.Blazor/Components/MeshSearchView.razor | Replaces compile-time <MeshNodeCardView/> usage with DispatchView to avoid base→pack component references. |
| src/MeshWeaver.Blazor/BlazorViewRegistry.cs | Removes base switch arms for Graph-owned controls and documents the new dispatch seam. |
| src/MeshWeaver.Blazor.Graph/MeshNodeThumbnailView.razor.cs | Namespace move into MeshWeaver.Blazor.Graph. |
| src/MeshWeaver.Blazor.Graph/MeshNodeThumbnailView.razor | Adds the thumbnail renderer component in the Graph pack. |
| src/MeshWeaver.Blazor.Graph/MeshNodeRoleEditorView.razor.cs | Namespace move into MeshWeaver.Blazor.Graph. |
| src/MeshWeaver.Blazor.Graph/MeshNodeRoleEditorView.razor | Adds the role editor renderer component in the Graph pack. |
| src/MeshWeaver.Blazor.Graph/MeshNodeErrorCardView.razor | Adds an error-card renderer in the Graph pack with localized titles/details. |
| src/MeshWeaver.Blazor.Graph/MeshNodeContentEditorView.razor.cs | Namespace move into MeshWeaver.Blazor.Graph. |
| src/MeshWeaver.Blazor.Graph/MeshNodeContentEditorView.razor | Adds the content editor renderer component in the Graph pack. |
| src/MeshWeaver.Blazor.Graph/MeshNodeCollectionView.razor.css | Adds isolated styling for the new collection renderer. |
| src/MeshWeaver.Blazor.Graph/MeshNodeCollectionView.razor.cs | Namespace move into MeshWeaver.Blazor.Graph. |
| src/MeshWeaver.Blazor.Graph/MeshNodeCollectionView.razor | Adds the collection renderer component in the Graph pack. |
| src/MeshWeaver.Blazor.Graph/MeshNodeCardView.razor.css | Adds isolated styling for the new card renderer. |
| src/MeshWeaver.Blazor.Graph/MeshNodeCardView.razor | Adds the card renderer component in the Graph pack (including external-link mode). |
| src/MeshWeaver.Blazor.Graph/BlazorGraphExtensions.cs | Makes Graph pack registrations include the full MeshNode surface set (incl. collection). |
| src/MeshWeaver.Blazor.Graph/_Imports.razor | Adds required imports previously provided implicitly by the base pack import chain. |
| clients/react/src/render/parity.test.ts | Moves MeshNodeCard/MeshNodeCollection into externally packed control allowlist. |
| clients/react-native/src/parity.test.ts | Same parity ratchet update for RN. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Test Results (shard 3) 9 files 9 suites 6m 26s ⏱️ Results for commit 7c7a0fe. |
Test Results (shard 0)1 254 tests 1 254 ✅ 12m 13s ⏱️ Results for commit 7c7a0fe. |
Test Results (shard 5)1 233 tests 1 232 ✅ 6m 57s ⏱️ Results for commit 7c7a0fe. |
Test Results (shard 4)2 026 tests 1 726 ✅ 8m 4s ⏱️ Results for commit 7c7a0fe. |
Test Results (shard 1)1 748 tests 1 748 ✅ 9m 11s ⏱️ Results for commit 7c7a0fe. |
Test Results (shard 2)3 245 tests 3 245 ✅ 7m 58s ⏱️ Results for commit 7c7a0fe. ♻️ This comment has been updated with latest results. |
Test Results 55 files 55 suites 50m 52s ⏱️ Results for commit 7c7a0fe. ♻️ This comment has been updated with latest results. |
What
PR 2 of the entity-view extraction chain (#2080 → #2081 → this). 12 files (~2.3k lines + 4 scoped-CSS bundles) move from
src/MeshWeaver.Blazor/Componentsintosrc/MeshWeaver.Blazor.Graph:MeshNodeThumbnailView,MeshNodeCardView,MeshNodeErrorCardView,MeshNodeCollectionView,MeshNodeContentEditorView,MeshNodeRoleEditorView. (MeshNodePickerViewalready moved in #2081 — itsFormComponentBasebase forced the pull-forward.)This FIXES an inconsistency rather than creating a seam
BlazorGraphExtensions.AddGraphViewsalready registered four of these views from the wrong assembly (viausing MeshWeaver.Blazor.Components), andMeshNodeCardControlwas double-registered — once in the pack, once in the base registry's switch (BlazorViewRegistry.cs:153). After the move there is ONE registration, in Blazor.Graph; the base arms forMeshNodeCollectionControlandMeshNodeCardControlare removed.MeshSearchControlstays —MeshSearchViewremains a base surface.AddGraphViewsalso gains the previously base-onlyMeshNodeCollectionControlregistration.The MeshSearchView seam
MeshSearchView(staying in base) rendered<MeshNodeCardView …/>at four sites (lines 362/368/373/794) — compile-time component references the base pack can no longer make without inverting the reference direction. All four now render<DispatchView ViewModel="@cardControl" …/>: the search page renders whatever view the mesh's registered pack maps toMeshNodeCardControl.Pinned by
MeshNodeCardControl_ResolvesThroughThePortalRegistryon the real portal composition (the mesh'sAddBlazor()+AddGraphViews()— the sameILayoutClientinstanceDispatchViewconsults, verified identical throughPortalApplication.Hubduring development). The card markup stays pinned by the two existingRenderAsync<MeshNodeCardView>tests. The resolution is asserted at the registry rather than through a staticDispatchViewrender because the one-shotHtmlRenderercannot driveDispatchView's post-parameter re-render — a harness artifact, not a seam. Non-vacuous: withoutAddGraphViewson that mesh, no map claims the control and the fallback slot answers withHtmlView, failing the type assertion.The rest
_Importsgains the base-component/Layout/Data/Messaging usings the views relied on from the base pack's_Importschain;MeshNodeErrorCardView(a parameter-driven component with no registry entry and no external markup users) moves cleanly.clients/react+ RNclients/react-native):MeshNodeCard+MeshNodeCollectionmove toEXTERNALLY_PACKED_CONTROLS(the >30 scrape guard still clears at 32) — coverage moved, not deleted.ViewPackRegistrationGateTest: the Graph rows now name the views in their new home and gain theMeshNodeCollectionrow (23 gate cases total).Verification
PR 3 (the module-lane flip for EntityViews) follows once this merges.
🤖 Generated with Claude Code