GrPromptDialog

multiline switches GrInput to GrTextarea (rows, autosize) — the reason for a refusal or a comment must not be assembled through a slot. For a single-line field there are inputType (email, password, number, …) and inputmode. maxlength with showCount draws a counter; it is already linked to the field through aria-describedby.

The field is obliged to introduce itself to the browser

autocomplete, name, autocapitalize and spellcheck reach the field in both branches — the single-line and the multiline one. The default of all of them is the absence of the attribute: the window makes nothing up.

dialog.prompt('Confirm the password', {
  inputType: 'password',
  autocomplete: 'current-password',
  name: 'password',
})

Without them a password manager does not recognise the field: 1Password, Safari and Chrome look at autocomplete and at the name of the field, and the confirmation of a password has to be typed by hand on every action.

autocomplete is not derived from inputType. One and the same password has three different correct values — current-password, new-password, one-time-code — and the window does not know which of them is right: it is used to ask for the old password, the new one and a one-time code alike. A guess here would be a lie.

autocapitalize and spellcheck are the pair to autocomplete="off" for secrets that are typed by hand. A 2FA backup code is compared byte for byte and is generated in mixed case: without autocapitalize="off" a mobile keyboard raises the first letter.

dialog.prompt has the same four fields — a divergence between the declarative and the imperative paths is guarded by the GrDialogService/__tests__/promptSurface.test.ts gate.

The field is not given an id: GrFormField generates it, and the field reads it from the context. A literal id used to break exactly what it was written for — two open dialogs (an ordinary one and one through the service) gave a duplicate DOM id, and <label for> led to someone else’s input.

required (true by default) is a quick synchronous “not empty” check. It blocks the button and does not go into the asynchronous engine.

Everything else is the rules prop with the same rules as in GrForm: type, min/max/len, pattern, a validator of your own, an asynchronous one included. There is no third special case of validation in the package — it is the same runFieldRules, and the messages are resolved by the same createGrFormMessageResolver (both are public).

<GrPromptDialog
  v-model="open"
  v-model:value="email"
  :rules="{ type: 'email', message: 'A work address is required' }"
/>

The rules are run on blur (after the first touch) and on the confirmation. While a check is running, the button shows loading; the answer of a stale run is discarded — an asynchronous rule may come back after the value has already changed.

An error arrives from the outside as well: fieldError (the server-side validation of the field) is stronger than the built-in checks, and error draws a general banner in the body of the window.

On opening, the focus goes into the field rather than onto the panel of the window: the dialog exists precisely for the sake of the input. That is done on the side of the content rather than with the initialFocus prop of GrModal — the element is born inside the subtree of the dialog, and returning it upwards through a prop closes the render into a loop.

Enter in a single-line field confirms. In the multiline mode Enter remains a line break, and the confirmation is done with the button.