# Field > Frame component that wires the label, field, help text and error text together for you. A form field is accessible when the help text and the error text are wired to the field itself. LO-TEK gives you that wiring in two ways, and **you use one of them, not both**. | Can the code that renders the markup call a builder function? | Use | | - | - | | **Yes.** React, Astro, a Node server, an app with no server at all, or a Kotlin or Java server | [`lt.field()`](#as-a-function), or [`Lt.field()`](/kotlin.md). Then you do not need the web component | | **No.** A Go template, a PHP file, a Razor view, a JTE or Thymeleaf template, a CMS or hand-written HTML | [``](#as-an-element) | Both use the same function underneath, so the contract cannot drift apart. The only difference is whether the code that produces the HTML can call a builder function, in TypeScript, Kotlin or Java. `` creates no markup itself and does not use Shadow DOM, so `FormData`, form libraries and test tools find the elements as before. > **Other components are not either-or** > > `` can be replaced entirely by the builder function, because the wiring is markup and not behaviour. The same goes for [Dialog](/components/dialog.md), when the app calls `showModal()` itself. [Tabs](/components/tabs.md), [Popover](/components/popover.md), [Suggestion](/components/suggestion.md) and [Error Summary](/components/error-summary.md) do something a function cannot, like arrow keys and focus, so there you use the builder function **and** the component. See [Markup and behaviour](/markup-and-behaviour.md#builder-function-or-web-component). ## How to use it `defineLtField()` registers the web component in the browser, and is called once at startup. More calls are harmless. The stylesheet must be imported because the children are elements you write, with the classes `lt-label`, `lt-input` and so on, and those classes must be on the page. `field.css` collects them. **Plain HTML** ```html ``` ```html
``` You write `for` and `id` yourself, as HTML requires for the field to have a name before the script has run. The field is invalid when the error text is visible: the script toggles `hidden`, and the component wires the error text to the field and sets `aria-invalid`. `new FormData(form)` picks up the field by itself. That is the whole point of the component staying in plain DOM. **React** In React you call `lt.field()`. Then the wiring is in the markup React renders itself, on the server as in the browser, and you do not need to register anything. ```tsx // main.tsx, runs once when the app starts import "@lo-tek/interfaces/tokens.css" import "@lo-tek/interfaces/field.css" import "@lo-tek/interfaces/button.css" ``` ```tsx title="OrderForm.tsx" import { lt } from "@lo-tek/interfaces/react" import { useId, useState } from "react" export function OrderForm() { const [codename, setCodename] = useState("") const [touched, setTouched] = useState(false) const invalid = touched && codename.trim() === "" const field = lt.field({ id: useId(), required: "symbol", error: true, invalid, }) return (
{ e.preventDefault() setTouched(true) }} > setCodename(e.target.value)} onBlur={() => setTouched(true)} />

Enter a codename.

) } ``` `required: "symbol"` gives the asterisk on the label. That the field must be filled in is said by `required` on the field itself. > **In React the id comes from useId()** > > An id that is generated on its own is not the same on the server and in the browser, and React then reports a hydration mismatch on the label, the field and the error text. The warning itself says the mismatch will not be patched up. `createFieldId()` will not do in a component body either: it gives a new id on every render. > **The web component gives hydration errors in React with server rendering** > > The component writes `aria-describedby`, ids and the class on the elements when it is registered, before React hydrates. React then finds attributes it did not render, and the React 19 development build reports “A tree hydrated but some attributes of the server rendered HTML didn’t match the client properties”. The field works, but the error is in the console on every page with a field. Use `lt.field()`. > > If the app renders only in the browser, without a server, `` also works in React. Invalid is then controlled with `hidden={!invalid}` on the error text, a plain HTML attribute React writes the same way in all versions. **Astro** If the field only needs to be shown in one state, `lt.field()` does the wiring at build time. Then no JavaScript is sent for the field at all: ```astro --- import { lt } from "@lo-tek/interfaces" import "@lo-tek/interfaces/tokens.css" import "@lo-tek/interfaces/field.css" const codename = lt.field({ id: "codename", required: "symbol", error: true }) ---

Enter a codename.

``` If the field should be able to become invalid while the user is in it, use `` and register it in a ` ``` **Datastar** [Datastar](https://data-star.dev) adds reactivity to plain HTML with `data-*` attributes. One script, no build step. ```html ``` ```html ``` ```html
``` `data-attr:hidden` hides the error text when the field is valid and shows it when it is invalid. `` sees that the error text is visible, and sets `aria-invalid` and `aria-describedby` on the field. The field has no id the component created, so a patch from the server recognises it, and what the user has typed stays. **kotlinx.html** On a Kotlin server you call `Lt.field()`, here with kotlinx.html and `lo-tek-kotlinx-html`. The server writes the whole wiring every time it renders the form, and the error text is shown when it renders the field as invalid, so the field needs no `` and no script, as in the React tab. The handler for `POST /jobs` renders the form again with what was typed and `invalid = codename.isBlank()`, in the same shape as the round trip in [With Ktor](/kotlin.md#with-ktor). The invalid field gets `autofocus`, so it takes focus when the page arrives, as the HTML tab focuses it in its script. Only the first invalid field in a form should have it, and none when the form has an [error summary](/components/error-summary.md): then the summary takes focus, and its links lead to the fields. ```kotlin import kotlinx.html.* import no.lotek.* import no.lotek.InputType import no.lotek.html.lt fun FlowContent.orderForm(codename: String = "", invalid: Boolean = false) { val field = Lt.field(id = "codename", required = RequiredMarker.SYMBOL, error = true, invalid = invalid) form(action = "/jobs", method = FormMethod.post) { id = "order-form" attributes["novalidate"] = "" label { lt(field.label); +"Codename" } input { lt(Lt.input(type = InputType.TEXT), field.control) name = "codename" required = true // What the user typed comes back, so a failed submission loses nothing. if (codename.isNotEmpty()) value = codename if (invalid) autoFocus = true } p { lt(Lt.errorText(), field.error); +"Enter a codename." } button { lt(Lt.button()); type = ButtonType.submit; +"Order the job" } } } ``` ```kotlin // Once for the whole app, in the page template. Not once per component. head { link(rel = "stylesheet", href = LotekWebJar.CSS) } body { orderForm() script(type = "module") { unsafe { +"import { defineLt } from \"${LotekWebJar.REGISTER}\"; defineLt()" } } } ``` **`lt.input()` should only get `type`.** The state is in `field.control`, and the two deliberately do not overlap. If you passed `state` to both, `aria-invalid` would be written out twice in templates that render the attributes literally, like Astro and plain HTML. `field.state` still exists if you want to drive something else with it. ### The required marker `data-required` on the label chooses how a required field is marked, `symbol` or `text`, and is in the markup, so the marker is visible also before the script has run. `optional` on `` turns it around: mark the optional field instead of the required one, when almost everything in the form must be filled in. `optional` has no place in the recipe above, since it shows one field and not a form. ```html ``` ## Why the wiring is hard A field with help text and an error text needs five connections that must all be right at once: ```html

The board writes to the fixer, never to the crew.

Enter the fixer's address, for example fixer@relay.example.

``` Every `id` must be unique, `aria-describedby` must point to both texts, and `aria-invalid` must follow the validation. Five places to get it wrong per field, multiplied by the number of fields. And nothing shows on the screen when one of them is missing. ## As a function `lt.field()` computes the attributes where you render, whether at build time in Astro, on every render in React, or on the server. On a Kotlin or Java server it is `Lt.field()`, with the same options, as the kotlinx.html tab above shows. The browser needs no registered component, and the wiring is ready in the HTML before any script has run: ```tsx const field = lt.field({ id: "fixer", required: "symbol", help: true, error: true, invalid })

The board writes to the fixer, never to the crew.

Enter the fixer's address, for example fixer@relay.example.

``` If you use React, import from `@lo-tek/interfaces/react`, which gives `className` and `htmlFor` instead of the HTML names. **`id` is required.** In React it comes from `useId()`. Otherwise the field’s own name is usually the obvious choice. If you know for certain that the markup is rendered once, as on an Astro page, you can call `createFieldId()`, which you get from both `@lo-tek/interfaces` and `@lo-tek/interfaces/react`. The reason is that an id generated on its own is random: two runs give two different ones. If the same field is rendered on a server and then in the browser, `for` and `aria-describedby` point to something other than what is there, and React reports a hydration mismatch. If you write JavaScript without types, you see no type. Then the function creates an id anyway, and warns in the console, so the field works while you fix it. ## As an element If the code that produces the HTML cannot call a builder function, `` does the same wiring in the browser. You write your elements as usual, with `for` on the label and `id` on the field, or with the label around the field. That is what HTML requires for the field to have a name before the script has run, and for voice control to find it. The component sets `aria-describedby` and `aria-invalid` on the field and gives the help text and the error text ids. The component never writes an id on the field. Datastar and idiomorph recognise an element by its id, and a field with an id the server did not send would be replaced on the next update, along with focus and what the user has typed. Without an id from the component the field stays. If the server sends the same region again while the user is working, as in a Datastar app, the morph tears the wiring away: none of it was in the HTML the server sent. The component sees that and puts it back, so your template needs no `data-preserve-attr`. The reasoning is in [Markup and behaviour](/markup-and-behaviour.md#when-the-markup-is-not-made-with-a-builder-function). In a loop you make the id from a key in the data, like `note-{{.Code}}`, never from the index or a counter. An id that follows the position moves what the user typed to the wrong row when the server inserts a new one. If the template makes the id from something that changes between renders, the component warns in the console when an update replaced the field for that reason. Send the field and its error text in the same patch. If the server clears the error by sending only the ``, the old error text stays visible, and the component reads that as invalid and writes `aria-invalid` back. If the component cannot find its parts, it warns in the console. An `` without a control gives a warning naming what is missing, instead of a field that silently has no wiring. The same goes for a field without a label, but only when it has no name in any other way either: a `