Repository navigation
Re-create the view-pack registration gate (stronger): controls must resolve to pack views - #2080
Conversation
… left ViewPackModuleTest died in 1145451 because it named types this repo no longer has — recorded there as needing a new home. This is that home, and the new gate asserts more than the old one did: not the module-attribute SHAPE, but that each pack entry point's controls actually RESOLVE to the pack's views through LayoutClientConfiguration — the resolution the real renderer uses. An inert registration (the AppleMaps/OpenStreetMap failure shape) now fails a named assertion instead of rendering escaped HTML in production behind a green wall. Covered entry points: AddGraphViews (all five controls), AddChatViews, AddUserProfileViews. The client hub deliberately does NOT call AddBlazor(): with the base registry in the chain, any control it also covers would keep resolving after the pack registration was deleted — vacuous exactly where an extraction makes it matter. AddLayoutClient() + the packs alone means every green row is evidence about the pack, and a decline is a null the assertion names (no fallback slot registered here). A negative control pins that: an unregistered control resolves to null. Non-vacuity verified by falsification: commenting out .WithView<MeshNodeEditorControl, MeshNodeEditorView>() in AddGraphViews makes exactly that theory row fail (7 passed, 1 failed); restored, 8/8. The two view packs about to be carved out of the base pack (MeshWeaver.Blazor.EntityViews, and Group B folding into Blazor.Graph) will add their rows here in their own PRs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Re-introduces a stronger automated “view-pack registration” gate to ensure that each Blazor view pack’s public registration entry point actually wires its controls to the intended views via LayoutClientConfiguration (the same resolution path the renderer uses), preventing inert packs from silently shipping.
Changes:
- Adds
ViewPackRegistrationGateTestthat boots a minimal client hub (AddLayoutClient+ pack registrations only) and asserts each pack control resolves to the pack’s view component. - Adds a negative control test to ensure an unregistered control resolves to
null(proving the gate is non-vacuous in this hub configuration). - Updates the test project to reference the specific view-pack assemblies under test (
MeshWeaver.Blazor.Graph,MeshWeaver.Blazor.Portal).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| test/MeshWeaver.Hosting.Blazor.Test/ViewPackRegistrationGateTest.cs | New gate test that resolves registered controls through ILayoutClient.GetViewDescriptor and verifies the descriptor targets the expected pack view type. |
| test/MeshWeaver.Hosting.Blazor.Test/MeshWeaver.Hosting.Blazor.Test.csproj | Adds direct project references to the view-pack projects so the gate compiles against and exercises the real registration entry points. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Test Results (shard 0)1 238 tests 1 238 ✅ 10m 4s ⏱️ Results for commit 9eba3f3. |
Test Results (shard 3) 9 files 9 suites 5m 25s ⏱️ Results for commit 9eba3f3. |
Test Results (shard 4)2 026 tests 1 726 ✅ 6m 55s ⏱️ Results for commit 9eba3f3. |
Test Results (shard 5)1 233 tests 1 232 ✅ 6m 58s ⏱️ Results for commit 9eba3f3. ♻️ This comment has been updated with latest results. |
Test Results (shard 2)3 243 tests 3 243 ✅ 8m 25s ⏱️ Results for commit 9eba3f3. |
Test Results (shard 1)1 748 tests 1 748 ✅ 8m 45s ⏱️ Results for commit 9eba3f3. |
Test Results 55 files 55 suites 46m 34s ⏱️ Results for commit 9eba3f3. ♻️ This comment has been updated with latest results. |
What
PR 0 of a 5-PR chain carving the entity default-view renderers out of the base Blazor pack (
MeshWeaver.Blazor.EntityViews+ the MeshNode surface renderers folding intoMeshWeaver.Blazor.Graph, then the module-lane flip and the catalog package).ViewPackModuleTestwas deleted in 1145451 when six view packs moved to MeshWeaver.Plugins — its commit message recorded that it "pinned something real — that a pack actually registers its views, the invariant whose absence let AppleMaps and OpenStreetMap ship inert — and it needs a home". Since then, nothing gates that a view pack's registration entry point actually wires anything. This PR re-creates the gate before the two new registration sets land on it.How it is stronger than the old one
The old test asserted the module-attribute SHAPE (
MeshNodeProviderAttributepresent,HubConfigurationsnon-empty). The newViewPackRegistrationGateTest(intest/MeshWeaver.Hosting.Blazor.Test) drives each pack entry point —AddGraphViews(all five controls),AddChatViews,AddUserProfileViews— through a real hub and asserts each control resolves to the pack's view throughLayoutClientConfiguration, the exact resolution the renderer uses.Design point: the test hub deliberately does not call
AddBlazor(). With the base registry in the chain, a control it also covers (today:MeshNodeCardControl, double-registered inBlazorViewRegistry.cs:153) would keep resolving after the pack's registration was deleted — the gate would be vacuous exactly where the coming extraction makes it matter.AddLayoutClient()+ the packs alone means a missing registration is a null descriptor the assertion names; a negative control (UnregisteredControl_ResolvesToNull) pins that a decline is observable, not masked.Non-vacuity evidence
Commented out
.WithView<MeshNodeEditorControl, MeshNodeEditorView>()inAddGraphViewslocally → the corresponding theory row failed (7 passed / 1 failed), naming the control and the pack. Restored → 8/8 green.Verification
dotnet build test/MeshWeaver.Hosting.Blazor.TestRelease: 0 warnings, 0 errors (warnings-as-errors).ViewPackRegistrationGateTest: 8/8 green.PRs 1 and 2 (the
MeshWeaver.Blazor.EntityViewsextraction, then the Group B fold into Blazor.Graph) add their registration sets to this gate; they conflict with each other by construction, so this merges first.🤖 Generated with Claude Code