7 posts tagged with "UI"

A failing test gives you a stack trace and a line number. It does not give you the twelve steps that ran before it, the value two of them passed along, or the branch that was taken three calls earlier. So the first debugging session is usually a re-run with print statements — the same information, paid for twice.

Blong's Test runs console starts the run from inside the portal and shows it while it happens. The steps are a timeline, the dependencies are a graph, and every assertion sits beside the value the step returned. The console is a page in the application, not a separate report.

A page in these docs has always been able to describe a screen. The Storybook next door could always show it. This week the two moved in together: the Storybooks are published with the documentation, and a page embeds a story the way it embeds a picture.

<StorybookStory
    site="browser"
    id="editor--toolbar"
    title="The Editor's toolbar"
/>

That is a real call, and this is its result:

A Storybook story is the cheapest place to look at a screen and the most expensive place to trust one. The model page renders perfectly in the story, and in the application it fails — because the story's rows came from a fixture file and the gateway method the page calls does not exist. The toolbar that used to solve this in the previous, webpack-based setup has been rebuilt for Blong's Vite Storybook, and a realm now gets it in one line:

export default defineBlongStorybookPreview(browser, {backend: true});

That line brings five toolbar items — Backend, Role, Theme, Language, Direction — and the machinery behind them. This post is about the two interesting ones.

The usual way to give a product a second look is to fork the components. It works, and it costs a second copy of every bug fix: the design changes the theme, the theme needs a component to behave slightly differently, and from that point on there are two editors, two tables and two places to fix the keyboard handling.

Blong keeps one component library and gives it more than one visual identity. A theme names the identity; the identity itself is a scoped stylesheet plus, where the look needs them, generated textures. The same coral editor renders on three different surfaces without a component knowing which one it is on.

Every framework that generates CRUD screens eventually meets the same objection: the generated page is never quite the page you need, so you write it by hand — and then the entity has two descriptions, a server-side one that validates and a client-side one that renders, which drift apart the first time somebody adds a field.

Blong answers by removing the second description. The type written for a handler is the model: it validates the request at the edge, creates the table that stores it, appears in the API document, and is what a generated form reads. A page is a declaration on top of that, not a parallel universe.

A generated form is easy to demo and hard to live with. The demo shows a text field appearing from a schema; the thing that decides whether the generator is useful is what happens when a field needs a different control, when one field has to influence another, when a record owns a list of children, or when the same data has to be edited as a permission matrix. Those are the cases where a generator either has an answer or sends you back to hand-written pages.

Blong's answers are all declared in the same place the page comes from: the widget a field gets, the method a widget may call back, the children a record owns, and the rows a matrix starts from.

A UI framework has a decision to make long before it renders anything: how much of the application does it own? Own too little and every realm re-invents a menubar, a login page and a place to put state; own too much and a realm that wants a different shell has to fight the framework to get one.

Blong's browser realm answers with a stack of four levels, each of which can be replaced, and with one small convention that keeps translation from being a second vocabulary everybody has to learn.