chore: add webui-todo-app example with declarative FAST HTML and webui prerendering#7362
Closed
janechu wants to merge 3 commits into
Closed
chore: add webui-todo-app example with declarative FAST HTML and webui prerendering#7362janechu wants to merge 3 commits into
janechu wants to merge 3 commits into
Conversation
…ndering
Adds a new example in examples/webui-todo-app that:
- Converts the todo-app to use declarative FAST HTML syntax (f-template,
f-repeat, {{}}/{} bindings) via @microsoft/fast-html
- Prerenders the DOM content using @microsoft/webui (build + render)
- The Express server calls build() at startup to compile the HTML template
into a binary protocol, then render() on each request to inject
prerendered todo items and component templates as raw HTML
- Client-side hydration uses RenderableFASTElement and TemplateElement
from @microsoft/fast-html, seeded with window.__INITIAL_STATE__
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
5 tasks
Collaborator
Author
|
superceded by #7424 |
janechu
added a commit
that referenced
this pull request
May 22, 2026
# Pull Request ## 📖 Description Adds a complete, unified Todo example surface to the `examples/` tree that showcases the same UI and behavior across three different rendering strategies, and backs it with a shared end-to-end test suite. What this PR delivers: - **`examples/ssr/webui-todo-app`** — new SSR example built on declarative FAST HTML templates with `@microsoft/webui` prerendering and `@microsoft/fast-html` client-side hydration via `RenderableFASTElement` + `defineAsync` (`defer-and-hydrate`). - **Unified UI across all three todo apps** — `examples/csr/todo-app`, `examples/csr/todo-mobx-app`, and the new SSR app render the same heading, form, filter `<select>`, list, and footer. The MobX app collapsed from five components to one to match the canonical layout while keeping the MobX bridge (singleton store, `makeAutoObservable`, single `autorun`) intact. - **Footer counter row (`X items left · Y completed`)** in every todo app, finally surfacing the previously-unused computed counters on each store / state. - **New `@microsoft/fast-examples-e2e` workspace (`examples/test/`)** with a shared Playwright suite that runs identically against every app via per-project DOM adapters. Specs use the `.pw.spec.ts` suffix so we can add Node `.spec.ts` tests later without collision. - **CI** — `npm run test:e2e` is wired into `ci-validate-pr.yml` as a separate step after the existing unit-test job. - **`@microsoft/webui` bumped to 0.0.6** across the workspace. This supersedes the approach from #7362 and replaces the older imperative `webui-todo-app` example. ### 🎫 Issues - Supersedes #7362 ## 👩💻 Reviewer Notes A few intentional choices worth a closer look: - **`@volatile` on `DefaultTodoList.activeCount` / `completedCount`** — required because the initial `_todos` array is empty, so without `@volatile` FAST captures the dependency graph only on first evaluation and never subscribes to `item.done` for items added later. Inline comments document this. - **Imperative `syncCounts()` in the SSR app** — same pattern as the existing `syncDescription()` workaround for the fast-html text-binding hydration mismatch. SSR initial render does not include the counter text; it is populated client-side after hydration. - **Adapter design in `examples/test/`** — both CSR apps share `createCsrAdapter()` since their unified UI exposes the same selectors; the SSR app has its own adapter because items are rendered through a nested `<todo-item>` shadow root. See [`examples/test/DESIGN.md`](./examples/test/DESIGN.md) for the contributor guide. ## 📑 Test Plan - `npm run build` — succeeds for all packages and example workspaces. - `npm run biome:check` — passes. - `CI=1 npm run test:e2e` — **21/21 passing** across all three projects (6 baseline scenarios + 1 new footer-counters scenario × 3 apps). - `npm run test` — `fast-element` and `fast-html` unit tests pass. Pre-existing Firefox flakiness in `fast-test-harness` (page.goto timeouts) is unrelated to this work; Chromium passes 46/46. - `npm run checkchange` — no change file needed (no `packages/*` source edits). ## ✅ Checklist ### General - [ ] I have included a change request file using `$ npm run change` - [x] I have added tests for my changes. - [x] I have tested my changes. - [x] I have updated the project documentation to reflect my changes. - [x] I have read the [CONTRIBUTING](https://github.com/microsoft/fast/blob/main/CONTRIBUTING.md) documentation and followed the [standards](https://github.com/microsoft/fast/blob/main/CODE_OF_CONDUCT.md#our-standards) for this project. ## ⏭ Next Steps - Investigate the underlying FAST observation behavior that requires `@volatile` on getters iterating reactive arrays — worth confirming whether this is by design or a bug that should be fixed in `fast-element`.
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
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.
Summary
Adds a new
examples/webui-todo-appthat fulfills the integration-with-webui requirements:todo-appto use@microsoft/fast-htmldeclarative templates (<f-template>,<f-repeat>,{{}}/{}bindings) instead of imperativehtmltagged template literals@microsoft/webui: An Express server usesbuild()at startup to compile the HTML template into a binary protocol, thenrender()on each request to inject prerendered todo items and component template definitions as raw HTMLtodo-app: add todos, filter (all/active/completed), mark done, remove itemsArchitecture
Server-side (
server.js)build({ appDir: './src', plugin: 'fast' })compilessrc/index.htmlat startuprender(protocol, { prerenderedItems, componentTemplates })injects:{{{prerenderedItems}}}— raw HTML of todo<li>items, visible before JS loads{{{componentTemplates}}}—<f-template>definitions for client-side hydrationwindow.__INITIAL_STATE__so the client hydrates with the same dataTemplate (
src/index.html)<todo-app defer-hydration>with<template shadowrootmode="open">DSD — prerendered content shows immediately{{{prerenderedItems}}}placeholder in the shadow DOM<ul>for webui to fill{{{componentTemplates}}}placeholder for<f-template>injection after the elementClient (
src/main.ts)RenderableFASTElementmixin withtemplateOptions: "defer-and-hydrate"TemplateElement.define({ name: 'f-template' })registers the template processorTodoList.provide(document, new DefaultTodoList(window.__INITIAL_STATE__))seeds stateDeclarative
<f-template>bindings (single-brace{}, client-only)