mirror of
https://github.com/nestriness/nestri.git
synced 2026-09-20 01:35:19 +03:00
eedb143b46
Providers no longer return a `Response`. Each one says what it needs from the person — an address, a pin, a yes-or-no — as a `Screen`, and a single `Renderer` decides how that is drawn. The old arrangement made every provider a small web framework. It had to know about markup, about the stylesheet's attribute names, about how a page is assembled, so each grew its own callback signature and its own copy of `new Response(jsx.toString())`. Three consequences, all of them visible in the tree before this change: - The device flow never got a design at all. Its two pages were built by concatenating HTML strings, with an inline `style` on the user code, and six of its replies were `text/plain` — unstyled black-on-white in the middle of signing in, which is also what a person got when their sign-in cookie expired. - The password screens were drifting. They were written against attribute names the stylesheet no longer had, and nobody noticed because password sign-in is not switched on. They are deleted here rather than repaired; the flow is now six screen descriptions and no markup. - A provider could not be named or marked without editing the library. The brand marks and display names were two hardcoded records inside the code that drew the chooser, so anything missing from them rendered as its own lowercase identifier with no icon. Providers now declare `display` themselves, and the chooser is built from what they say. Also removes the theme global. It was `globalThis`, with a comment conceding as much, which made every component depend on something invisible at the call site — untestable in isolation, and shared mutable state on a runtime that keeps one module instance across requests. The theme is now a closure argument, and the same change shrinks `Theme` to the handful of values a deployment sets that the stylesheet cannot. Adding a screen now touches no CSS, and swapping the presentation layer means implementing one method. The code flow's tests demonstrate the second: they render screens as JSON. Behaviour is unchanged. Status codes, cookies and the confirmation step are the same, which the device tests cover unmodified.
69 lines
2.3 KiB
TypeScript
69 lines
2.3 KiB
TypeScript
import type { Context, Hono } from 'hono';
|
|
|
|
import { StorageAdapter } from '../storage/storage.js';
|
|
import type { Mark, Screen } from '../ui/screen.js';
|
|
|
|
export type ProviderRoute = Hono;
|
|
|
|
/**
|
|
* How a provider is offered to a person choosing one.
|
|
*
|
|
* Declared by the provider rather than looked up by whatever draws the
|
|
* chooser. That used to be two hardcoded records inside the rendering code, so
|
|
* a provider the library had not been told about rendered as its own lowercase
|
|
* identifier with no mark beside it — and there was no way to fix it from
|
|
* outside the library.
|
|
*/
|
|
export interface ProviderDisplay {
|
|
/** The name as a person reads it: `GitHub`, not `github`. */
|
|
name: string;
|
|
/** Raw SVG for the brand mark, from `ui/mark.ts`. */
|
|
icon?: Mark;
|
|
}
|
|
|
|
export interface Provider<Properties = any> {
|
|
type: string;
|
|
/**
|
|
* What to call this provider, and what to draw beside it.
|
|
*
|
|
* Optional because a provider nobody picks from a list — one reached
|
|
* directly, or one with no browser in the flow at all — has nothing to
|
|
* display. Falling back to `type` is correct there and only there.
|
|
*/
|
|
display?: ProviderDisplay;
|
|
init: (route: ProviderRoute, options: ProviderOptions<Properties>) => void;
|
|
client?: (input: {
|
|
clientID: string;
|
|
clientSecret: string;
|
|
params: Record<string, string>;
|
|
}) => Promise<Properties>;
|
|
}
|
|
|
|
export interface ProviderOptions<Properties> {
|
|
name: string;
|
|
success: (
|
|
ctx: Context,
|
|
properties: Properties,
|
|
opts?: {
|
|
invalidate?: (subject: string) => Promise<void>;
|
|
}
|
|
) => Promise<Response>;
|
|
forward: (ctx: Context, response: Response) => Response;
|
|
/**
|
|
* Draw a screen and return it as this request's response.
|
|
*
|
|
* The only way a provider produces a page. It cannot reach the renderer
|
|
* itself, which is the point: a provider says what it needs to ask and
|
|
* never how it looks, so there is exactly one place that has to agree with
|
|
* the stylesheet.
|
|
*/
|
|
screen: (ctx: Context, screen: Screen) => Response;
|
|
set: <T>(ctx: Context, key: string, maxAge: number, value: T) => Promise<void>;
|
|
get: <T>(ctx: Context, key: string) => Promise<T>;
|
|
unset: (ctx: Context, key: string) => Promise<void>;
|
|
invalidate: (subject: string) => Promise<void>;
|
|
storage: StorageAdapter;
|
|
}
|
|
export class ProviderError extends Error {}
|
|
export class ProviderUnknownError extends ProviderError {}
|