feat(integration-xwiki): CnXwikiTab + CnXwikiCard + xwiki registration (leaf, frontend)

[rubenvdlinde]

The @conduction/nextcloud-vue half of the integration-xwiki leaf (openregister issue #1326, depends_on pluggable-integration-registry) — the JS twin of the PHP XwikiProvider (openregister PR for it lands the backend). Stacked on #210 (built-in registrations) → #209 → #204 → #202 → beta.

Summary

The worked external-storage example for the pluggable integration registry.

• CnXwikiTab — sidebar "Articles" tab: linked XWiki pages with their full breadcrumb (AD-3), a link form accepting a full XWiki URL or a Space.Page path (AD-2), an unlink button (removes the OR sub-resource pairing only — never deletes the page in XWiki), a reconnect/unavailable banner on a 503 (AD-23). Emits linked / unlinked.
• CnXwikiCard — surface-aware widget (AD-19):
  • detail-page — linked list + a text preview of the first page (HTML stripped to plain text, ~500 chars, macros not executed — AD-1) + an "Open in XWiki" link
  • user-dashboard / app-dashboard — compact list
  • single-entity — a title + breadcrumb chip resolved from the value prop (for referenceType: 'xwiki' properties), with a minimal-chip fallback when the lookup fails
  • 503 → quiet unavailable state
• src/integrations/builtin/xwiki.js — xwikiIntegration descriptor + registerXwikiIntegration(). Leaf, not a built-in: not in builtinIntegrations, not registered by registerBuiltinIntegrations() — OpenRegister's bundle calls registerXwikiIntegration() explicitly (skip-on-collision so a consuming app can override xwiki).
• barrels + 4 doc files

Test plan

• npx jest tests/integrations/xwiki.spec.js tests/components/CnXwiki*.spec.js → 21 tests, green
• Full suite: 74 suites, 1032 passing, 4 pre-existing failures (CnMapWidget + CnAiChatPanel, unrelated, also red on origin/beta)
• npm run lint — no new errors/warnings on the xWiki files
• node scripts/check-docs.js — only pre-existing CnAi*/useAi*/default gaps
• docs/components/_generated/CnXwikiTab.md / CnXwikiCard.md need regenerating (cd docusaurus && npm run prebuild:docs) — docusaurus deps weren't installed in the dev env; same as CnFilesCard/CnTagsCard/CnAuditTrailCard from feat(integrations): CnFilesCard + CnTagsCard + CnAuditTrailCard widgets #204
• Live smoke-test after the chain merges: with OpenConnector installed + an xwiki source configured, the "Articles" tab/widget should populate and the detail-page text preview should render (with no macros executed)

[WilcoLouwerse]

[CONCERN] HTML tag-stripping regex is bypassable — script body text may appear in preview

The previewText computed strips <script> only via /\<script[\s\S]*?\<\/script>/gi. Because the final output is rendered via {{ }} (text interpolation), Vue itself escapes it — so there is no XSS risk in the DOM — but the raw script body text will appear in the visible preview if the regex is bypassed by exotic variants. A safer approach is to parse through a temporary DOM element (el.textContent) or use a well-tested sanitiser. At minimum add a second /\<script[^>]*>[\s\S]*?\<\/script>/gi pass before the generic tag-strip.

[WilcoLouwerse]

[CONCERN] unlink(): no guard on falsy page.id — DELETE fires against empty/undefined path

The unlink call uses encodeURIComponent(page.id). There is no validation that page.id is a non-empty string before the call; if the API returns an object with a falsy or missing id, the URL becomes .../xwiki/ (or .../xwiki/undefined) and a spurious DELETE fires. Add a guard: if (!page?.id) { return } before this.unlinkingId = page.id.

[WilcoLouwerse]

[CONCERN] unlink() silently swallows non-2xx, non-503 errors — no user feedback on failure

When the DELETE returns a status that is neither ok nor 503 (e.g. 403, 404, 500), the code falls through without setting any error state and without removing the row. The user clicks the unlink button, nothing changes, no feedback is shown. Add an else branch that sets an appropriate error state so the user knows the action failed.

[WilcoLouwerse]

[CONCERN] Watch on surface triggers load() without cancelling in-flight requests — race condition

When surface changes while a loadList() or loadEntity() is in progress, the new load() call starts a second fetch. Both resolve independently and the last one to settle wins, potentially replacing the correct result with stale data. The component should use an AbortController keyed to the current load, or at minimum track a generation counter and discard responses from superseded loads (const gen = ++this._loadGen; ... if (gen !== this._loadGen) return).

[WilcoLouwerse]

[CONCERN] Full page content fetched on all surfaces — over-fetch on non-detail surfaces

On the detail-page surface, loadList() sends _limit = maxDisplay (default 5), but previewText only needs the first page's content field. On other surfaces, content is never read but is still fetched. Consider sending _fields=id,title,url,space,breadcrumb on non-detail-page surfaces to avoid transferring unused payload on dashboards loading multiple widgets simultaneously.

[WilcoLouwerse]

[CONCERN] NcTextField uses :value.sync — may not match actual NcTextField contract

<NcTextField :value.sync="linkInput" ...> relies on the child emitting update:value. In @nextcloud/vue v8+ NcTextField uses a standard v-model (emits input, not update:value). If the installed version does not emit update:value, the binding becomes one-way and linkInput will never be updated by the user's typing, so submitLink() will always receive an empty string. Change to v-model="linkInput" or verify the NcTextField version supports .sync. The test circumvents this by directly setting wrapper.vm.linkInput, so CI does not catch the bug.

[WilcoLouwerse]

[CONCERN] fetchPages() not re-triggered when register or schema props change

Only objectId is watched. If a parent component changes register or schema while objectId stays the same (e.g., navigating between schemas in the same object view), the list is not refreshed. Add watchers for register and schema similar to the objectId watcher, or combine them into a single computed key and watch that.

[WilcoLouwerse]

[CONCERN] xwikiIntegration.label evaluated at module load time — translation may not be ready

label: t('nextcloud-vue', 'Articles') is evaluated when the module is first imported, which can be before translations are loaded. Consider making label a getter or a function, mirroring the approach used for prop defaults (default: () => t(...)).

[WilcoLouwerse]

Review

🟡 Concerns (8)

• HTML tag-stripping regex is bypassable — script body text may appear in preview — src/components/CnXwikiCard/CnXwikiCard.vue:427
• unlink(): no guard on falsy page.id — DELETE fires against empty/undefined path — src/components/CnXwikiTab/CnXwikiTab.vue:897
• unlink() silently swallows non-2xx, non-503 errors — no user feedback on failure — src/components/CnXwikiTab/CnXwikiTab.vue:891
• Watch on surface triggers load() without cancelling in-flight requests — race condition — src/components/CnXwikiCard/CnXwikiCard.vue:447
• Full page content fetched on all surfaces — over-fetch on non-detail surfaces — src/components/CnXwikiCard/CnXwikiCard.vue:479
• NcTextField uses :value.sync — may not match actual NcTextField contract — src/components/CnXwikiTab/CnXwikiTab.vue:684
• fetchPages() not re-triggered when register or schema props change — src/components/CnXwikiTab/CnXwikiTab.vue:802
• xwikiIntegration.label evaluated at module load time — translation may not be ready — src/integrations/builtin/xwiki.js:84

🟢 Minor (4)

• breadcrumbText() called multiple times per render — should be computed (src/components/CnXwikiCard/CnXwikiCard.vue:284)
  In the single-entity template, breadcrumbText(entity) is called twice (:title attribute and interpolation). In the list template it is called twice per row. A displayedPages computed that pre-computes breadcrumbs would be cleaner and avoid redundant calls.
• Hardcoded hex fallback color — may be inconsistent with Nextcloud 28+ warning palette (src/components/CnXwikiTab/CnXwikiTab.vue:927)
  background: var(--color-warning, #e9a40f) — the hex is Nextcloud 25 amber; Nextcloud 28+ changed the warning palette slightly. Prefer var(--color-warning) only (without fallback) if the minimum supported Nextcloud version guarantees the variable, to avoid colour inconsistency in dark mode.
• baseUrl() is a method but should be a computed — redundant string building on every call (src/components/CnXwikiCard/CnXwikiCard.vue:454)
  baseUrl() concatenates apiBase, register, schema, and objectId on every invocation. Since these are all props, a computed: { baseUrl() { ... } } would cache the value and is more idiomatic in Vue 2. Same issue exists in CnXwikiTab.
• Test directly mutates vm.linkInput — bypasses NcTextField binding contract (tests/components/CnXwikiTab.spec.js:1323)
  wrapper.vm.linkInput = 'https://wiki.example.org/...' sets data directly, skipping the UI interaction. This means the test would pass even if the NcTextField binding is broken (see the CONCERN about :value.sync). Prefer triggering actual input events on the text field to catch binding regressions.

Reviewed by WilcoLouwerse via automated batch review.