{extends:gui}

# Frontend Knowledge

Web applications require decisions about URLs, HTML interactions, and how communication results are displayed in addition to component design.

## URLs and navigation

A router opens the screen for a URL. Read target identifiers from the path or query, and show distinct results for a missing target, an invalid value, or insufficient permission.

Putting search conditions in the URL lets users share a link and reproduce the same search with Back and Forward. A value used only while editing or opening a menu can stay in the part that uses it.

When adding a screen, make sure it opens from the links or menus required by the specification, opens correctly when its URL is entered directly, and shows the expected result when the user moves with Back and Forward.

Choose a link or a button from the meaning of the operation. A link moves to another URL; a button performs an operation in the current screen. Do not choose an element from its appearance alone.

## HTML interactions and accessibility

HTML buttons and links provide keyboard and focus behavior. Choose the HTML element and accessible name that match the meaning of the operation, and use the behavior provided by the browser.

Give each interactive element a name that assistive technology can announce. Associate labels with inputs, and expose selected, expanded, checked, and disabled states through the element or its attributes. In a modal dialog, move focus into the dialog when it opens and return focus to the element that opened it when it closes.

While a modal dialog is open, keep focus from leaving it through Tab or Shift+Tab, and do not accept any background user interaction such as clicks, keyboard input, or shortcuts. An `aria-modal` attribute alone does not stop background interaction, so provide a mechanism that suppresses it.

When edit and delete controls appear in a list, make the target row identifiable from the announced name or its relationship to the row. Announce communication results when needed, and show a retry or a way to correct input after a failure.

Check the types and official documentation for the installed UI library version. Also inspect the HTML it actually generates, including its name, role, state, and keyboard behavior. Mock-based tests alone do not show the HTML generated by the library.

Native browser DOM events also reach ancestors. If a click handler and a form submission handler start the same operation, it runs twice. Keep one entry responsible for starting the side effect.

## Showing loading, empty, and failure states

Communication has different states: not started, loading, success, empty, failure, and cancelled. If loading or failure is represented as an empty array, users cannot tell whether to wait or retry.

When retry is offered, use the failed target and content together with the current state to decide the failure display and retry availability. Retry must correspond to the displayed target and content. Show the guidance or operation required by the specification. The display part does not call a specific API or navigate; the screen that owns fetching starts the operation. The retry processing side checks the target, content, and current retry permission when it runs, and keeps the displayed retry target and content consistent with the actual processing.

When an API client already exists, use its types, authentication, and error handling. Reimplementing the same communication in each screen means a change to the API can be reflected in only one of them.

## Data fetching and cache

If the list and detail view use the same data, the screen can fetch it and pass it to both. An independent notification panel can own its fetch and retry behavior. Framework or data-fetching library facilities can manage fetch state and cache.

Manage a cache with a key that distinguishes the data being fetched. Do not omit conditions such as user, tenant, target identifier, search conditions, or sort order when they change the result.

After an update or deletion, update the cache or fetch again so the display reflects the change. For a list built from multiple pages, also check that inserting, deleting, or reordering items does not create duplicates or gaps.

Choose between fetching a small fixed set at once and paging through a list that may grow from its actual size, response-time requirements, permission scope, and update frequency.

## Browser and server responsibilities

The browser can validate an input format while it is being entered, sort data it has received, and show a preview. The server checks inventory, payment, permission, and whether the current data can be saved.

Even when the screen accepts an operation, permission or data can change while the request is in flight. The server checks again when executing it, and the screen displays the result as success, insufficient permission, a conflict, or invalid input.

## Values entering and leaving the browser

Inserting user input as HTML can execute an unintended script. Display strings as text, and sanitize them when HTML is required. Validate and escape values embedded in URLs or CSS for their specific use.

Keep external navigation targets within allowed URLs and schemes. Keep credentials out of URLs and logs, and review cookie send conditions, data stored in Web Storage, and destinations for cross-origin requests. State-changing requests authenticated with cookies also need CSRF protection on the server.