The boundary only wraps islands, which already sit in the page layout and have no React Query client for the footer, so a render error (e.g. a blocked captcha script) left a blank island.
`toLocaleLowerCase()` follows the browser locale, so with a Turkish locale `I` became a dotless `ı`, which is not a valid localpart and does not match what the server does with `to_lowercase`.
The server-rendered registration form is replaced by a React island mounted
on `/register`, which renders the CAPTCHA in-page, gives live password
complexity feedback, and lays out the upstream provider buttons and the
sign-in link the way `/login` does. The island owns the whole form, so every
variant of the page is rendered from the mount data alone, and the user fills
it in one step. Server-side validation errors are threaded back into it
through the mount node, so a rejected submission re-renders with the errors
attached to the fields they belong to, until the user edits them.
`RegisterContext` resolves the provider names and the sign-in link server-side
so that the island only has to render them. The sign-in link is derived from
the post-auth action in the query string instead of the `PostAuthContext`
loaded from the database, which drops a round trip from both the GET and the
invalid-form re-render.
Registering now requires JavaScript, including on the variant with upstream
providers only and on the one without a CAPTCHA: the <noscript> block shows a
notice instead of a duplicate form, which could not work anyway when a CAPTCHA
is configured. While the script loads, the page shows a skeleton of the form
to avoid layout shifts, and a hidden error notice is revealed if it fails to
boot. The server-rendered CAPTCHA component and its entrypoint are removed
with their only consumer.
The class becomes `or-separator`, as the global `.separator` also matched the
footer's separator. The module is imported by `templates.css` for the SSR
`field.separator()` macro.
The helper parses the mount node's dataset, waits for the i18n setup
before the first render, and swaps the page to a server-rendered error
notice when booting fails. This fixes the account app staying on its
loading screen forever when fetching the locale data fails, and gives
upcoming server-rendered pages with React islands a common entry point.
Waiting on the setup requires `setupI18n` to return the initialisation
promise, so it now does.
The strength meter, the improvement hints and the too-weak error move to
a `PasswordComplexityFeedback` component backed by a
`usePasswordComplexity` hook, so that forms which lay out their password
fields differently can reuse them. `PasswordCreationDoubleInput` takes
the minimum complexity as a plain number instead of a `SiteConfig`
fragment; its two callers already query `siteConfig`, so they pass the
field directly.
Instead of provider-specific markup and script tags in the head, the
captcha.form() template macro now emits a placeholder element carrying
the CAPTCHA configuration in data attributes, on which a new entrypoint
mounts the React Captcha component. The widget still injects its hidden
response field inside the form, so the server-side verification flow is
unchanged.
This is the first use of inline React components to progressively
enhance server-rendered pages.
The previous commit grew a load timeout, script-tag eviction, an error
boundary and a retry button, and swapped the imperative `CaptchaHandle`
ref for an `onValidChange` callback. None of that is needed to mount a
widget on a server-rendered page, and some of it does not work: removing
the `<script>` tag does not stop a load the browser has already started,
and the timeout deletes the global onload callback, so an SDK which is
merely slow ends up calling into nothing.
Go back to exposing validity through a ref, and keep only the
per-provider placeholder heights, which are what stops the page jumping
once the widget renders. Whatever a React form needs to react to the
captcha being solved belongs with that form.
Adds a reusable Captcha React component along with the type
definitions for the supported providers (hCaptcha, Cloudflare
Turnstile, Google reCAPTCHA). The provider SDKs are lazy-loaded by the
component itself, suspending the tree while they load, and evicted on
failure so a retry can re-attempt the load. The widgets report
solved/expired state through an `onValidChange` callback.
`import.meta.glob` now generates lazy loaders for the locale JSON modules
rather than hashed asset URLs, so `Backend.read` awaits an `import()` instead
of doing a `fetch`. This puts translation loading under the `script-src` CSP
directive instead of `connect-src`, and lets the browser preload them as
modules, which the `<link rel="preload" as="fetch">` hint never really did
because of the credentials-mode mismatch.
Dynamic imports are cached for the lifetime of the page, so locale
hot-reloading now triggers a full page reload in dev instead of asking i18next
to re-read its resources.
Instead of injecting configuration through inline <script> tags setting
window globals, server-rendered templates now carry the configuration
as data attributes on the entrypoint mount node, validated client-side
with a valibot schema over element.dataset. This removes all inline
scripts from the templates, which is friendlier to CSP, and gives the
frontend runtime-validated, typed configuration.
The DOM read and the wiring now happen in the entrypoints themselves:
main.tsx parses the mount node dataset, owns the QueryClient, and
injects the basepath and GraphQL endpoint into the router and request
layer instead of those being module-scope singletons.
v4 replaced the global `zxcvbnOptions`/`zxcvbnAsync` singleton with the
`ZxcvbnFactory` class. The warning/suggestion codes and options shape
are unchanged.
Tailwind 4 ships its own Vite plugin and no longer needs PostCSS plumbing.
Drop postcss/autoprefixer/postcss-import/postcss-nesting and the .postcssrc.json,
wire @tailwindcss/vite into vite.config.ts, replace the @tailwind directives
with @import "tailwindcss", and convert the JS tailwind.config.cjs theme
into a CSS @theme block in shared.css. An @source directive points back at
the SSR templates so the Jinja-rendered HTML in templates/ still gets scanned
for utility classes.
The third-party CSS (compound design tokens, compound-web, fontsource) moves
into a new vendor.css entrypoint, loaded ahead of shared.css from main.tsx,
storybook, and base.html. Tailwind v4's @import bundler silently drops the
nested `@import url(...) layer(cpd-base) screen` statements inside the
compound-design-tokens.css barrel, so we have to keep those imports out of
any file that contains Tailwind directives and let Vite's normal CSS pipeline
resolve them instead.
They are very small and don't need an extra request to load. This is useful as
well for making the snapshots not dependant on where the project is installed
Quentin Gliech