Skip to content

EE2-2313 Web Fragments#89

Merged
AndrewKirkovski merged 11 commits into
masterfrom
ee2-2313-web-fragments
Jul 20, 2026
Merged

EE2-2313 Web Fragments#89
AndrewKirkovski merged 11 commits into
masterfrom
ee2-2313-web-fragments

Conversation

@AndrewKirkovski

Copy link
Copy Markdown
Contributor

Adds a web fragments support and bumps to 45th vetsion

…2313]

Add fragment_gateway.lua + a GET /frag/{id}/{path...} endpoint that serves the
reframing contract for a view.page rendered as a web-fragment:
- Sec-Fetch-Dest: iframe    -> the reframed realm stub document
- Sec-Fetch-Dest: empty/doc -> the page's app HTML with the fragment proxy
  <script> (absolute, host-served) + <base href> (real page base_url) injected
- otherwise (assets)        -> proxied to base_url + subpath via http_client

render.lua is untouched — this is a delivery-mode wrapper over the same page.
The handler is auth-agnostic (token is client-held): the injected fragment proxy
performs the GetConfig/SetConfig handshake with the host to obtain config. Reuses
the existing public_registry / http_client.request / private_ip security policies.

Phase 1 of the Web Fragments PoC (EE2-2313). Pending live-boot verification.
…[EE2-2313]

The api_router ns.requirement enumerates each endpoint whose .meta.router it
sets; the new fragment_gateway function + endpoint were missing, so boot failed
with "router not found". Add both targets.

Verified in a live app-template-raw boot: GET /api/public/frag/{id}/ returns the
reframed stub for Sec-Fetch-Dest: iframe, and the app HTML with <base href> +
the fragment proxy <script> injected for empty/document.
… asset routing [EE2-2313]

Makes the CSR reframeWithFetch path actually boot the app end-to-end:
- The realm STUB (Sec-Fetch-Dest: iframe) now carries the merged host import map
  ({fe_facade_url}/import-map.json) + the fragment proxy <script>. Scripts execute
  in the realm, so bare specifiers (@wippy-fe/proxy, vue, ...) resolve there.
- The streamed document (empty dest) has its own <script type=importmap> REMOVED
  (a chunk-streamed import map errors), keeps scripts ACTIVE (writable-dom runs
  them — the reference applies ONLY prefixHtmlHeadBody here, not neutralize), and
  gets <base href> + html/head/body -> wf-*.
- Discriminate document vs asset by the request SUBPATH derived from req:path()
  (the {path...} wildcard is not surfaced via param()), so realm module fetches
  (which arrive with empty Sec-Fetch-Dest) are proxied as assets with the correct
  content-type instead of being served the HTML document.

Verified live: a view.page renders as a <web-fragment>, the proxy boots in-realm
([wf-probe]), and the app makes an authenticated /api/v1 call returning 200.
The gateway reads wippy.facade:fe_facade_url (registry) and merges/serialises the
import map (json).
…asset URLs [EE2-2313]

Two fixes that make the app actually paint after login:
- Remove the @wippy/scripts dev-proxy placeholder (shows "Accept config to
  continue loading" and hijacks the render); the real proxy is in the realm stub.
- Rewrite relative href/src="./x" to ABSOLUTE base_url. A <base> in the reflected
  <web-fragment> shadow is NOT honored, so <link rel=stylesheet>/<img> resolved
  against the host origin (404 → unstyled app with ballooning images). Module
  scripts already worked (reframed runs them in the realm).
…-2313]

Port the canonical injector's scripts array [loading.js, proxy.js, chat.js] to
the reframed realm stub: loading.js (registers <wippy-loading>/<wippy-error>)
plus the reframed-realm proxy. chat.js is deliberately omitted — app-main uses
the HOST chat (right panel) via a host command, not an embedded <wippy-chat>,
and eagerly loading the heavy chat bundle into every realm destabilises boot
(the app SPA failed to mount). A fragment that embeds chat opts in per-page.
…E2-2313]

transform_document injects the four host stylesheets (theme-config, iframe,
tailwind/primevue, data-content) into the app <head> so the reframed stream
delivers them — deterministic, no client-side re-injection loop after the
stream wipes the stub head.
…2-2313]

Adds a global, operator-owned page render-engine switch for the Web Host,
mirroring the fe_mode/theme_mode requirement pattern exactly:

- _index.yaml: new `render_engine` ns.requirement (default `iframe`), documented
  as iframe (legacy srcdoc) vs fragment (Web Fragment — requires the wippy/views
  fragment gateway + a fragment-capable host bundle serving proxy-fragment.js).
- config_handler.lua: read + clamp (only the exact string "fragment" opts in;
  anything else → "iframe" so a typo/blank can't ship the non-legacy engine) and
  emit into host_config as `renderEngine`, shipped to the host via hostConfig.
- config_handler_test.lua: render_engine in REQ_NAMES + setup defaults; a
  clamp mirror + cases; registry default assertion.
- README.md: requirements-table row.

Verified live: /api/public/facade/config emits hostConfig.renderEngine — "fragment"
under -o wippy.facade:render_engine:default=fragment, "iframe" by default.
Master already grants template.get; keep explicit get/release handling so ACL denials show as HTTP 500 instead of a nil render crash.
Point fe_facade_url at the new CDN release and re-vendor loading.js embed.
@AndrewKirkovski
AndrewKirkovski merged commit 76cedb7 into master Jul 20, 2026
17 of 18 checks passed
@AndrewKirkovski
AndrewKirkovski deleted the ee2-2313-web-fragments branch July 20, 2026 12:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant