Add View Type swap test and gate RedHerb card edit links#935
Draft
malberts wants to merge 2 commits into
Draft
Conversation
The reactive ViewTypeRegistry lets a View Type registered after
NeoWikiApp has resolved its views re-trigger resolution, swapping the
fallback infobox for the registered component (the warm-cache path
where an extension's frontend module loads late). That behaviour was
only verified in the browser.
Drive the production resolution path: a {{#view: | layout=}} placeholder
whose Layout selects a not-yet-registered View Type renders the fallback
infobox; register the type afterwards and assert the rendered component
swaps from the infobox to the registered one. The test fails if the
registry is made non-reactive again.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The redherb-card example showed its Edit subject button only to users who can edit the subject, but the Edit schema and Edit layout links rendered for everyone, so anonymous viewers were shown edit affordances they cannot use (the links target action=edit, which without edit rights only yields the read-only view-source page). Resolve the Schema and Layout edit rights through the useSchemaPermissions / useLayoutPermissions composables and hide each link when the viewer cannot edit that page, consistent with how the subject editor is gated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
malberts
force-pushed
the
test/view-swap-and-card-edit-gating
branch
from
June 26, 2026 19:34
ee2a239 to
19895a1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two follow-ups from the review of #921 (View Type registration).
Regression test for the View Type swap
#921 made
ViewTypeRegistryreactive so a View Type registered afterNeoWikiApphas already resolved its views re-triggers resolution, swapping the fallback infobox for the registered component. This is the warm-cache path where an extension's frontend module loads after the app mounts. That behaviour had no automated coverage (NeoWikiAppis never mounted in the suite); it was only verified in the browser.This adds a
NeoWikiApptest that drives the production resolution path: a{{#view: | layout=}}placeholder whose Layout selects a View Type that is not yet registered renders the fallback infobox, the type is registered afterwards, and the test asserts the rendered component swaps from the infobox to the registered one. It fails if the registry is made non-reactive again (confirmed by temporarily reverting thereactive()call). It resolves through the Layout (the path the parser emits viadata-mw-neowiki-layout-name), not the unuseddata-mw-neowiki-view-typeattribute.Gate the RedHerb card's edit links
The
redherb-cardexample gated its Edit subject button oncanEditSubject, but the Edit schema and Edit layout links rendered for everyone, so a viewer without edit rights was shown edit affordances they cannot use (the links targetaction=edit, which without edit rights only yields the read-only view-source page). The card now resolves the Schema and Layout edit rights through theuseSchemaPermissions/useLayoutPermissionscomposables and hides each link when the viewer cannot edit that page, consistent with how the subject editor is gated. It checks the real Schema and Layout permissions rather than reusingcanEditSubject, since those are distinct rights.This UX change has no unit test (the RedHerb example extension has no JS test harness in the repo). It is verified in the browser (automated, Playwright): with the example extension loaded, an editor sees all three edit affordances, an anonymous viewer sees none, the card still renders, and the console is clean.