Cookbook on AngularTS

Debug a running application

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A page is running, but you do not know which state, controller, or service owns the DOM you are looking at. You want to inspect it before changing code.

Before you start

Run a development build with AngularTS debugging helpers available. Open the page and browser DevTools; no source changes are required for the first inspection.

Recipe

Open the browser’s Elements panel and select the element you want to inspect. The DevTools console exposes that element as $0.

Select an element with ng-el

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Your controller needs a native element so it can focus an input, draw on a canvas, measure layout, or call another browser API.

Do not search the document with querySelector. Declare the element you need and let AngularTS wire it to your state.

Before you start

Use this inside a compiled scope or controller that owns the element. Keep document-wide elements in a service rather than attaching unrelated DOM to a local scope.

Pass server data with ng-init or ng-setter

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The server already knows values that the browser needs, such as the current locale, a record ID, or the initial result count. You want AngularTS to use those values without making another request.

Before you start

The server template must safely serialize and HTML-encode the initial value. Decide whether the value is fixed at compilation or can change when another system replaces element content.

Recipe

Render an ng-init expression with the page:

Update text, classes, styles, and visibility

Mon, 01 Jan 0001 00:00:00 +0000

Problem

State changes, and the page must update without finding elements or assigning DOM properties by hand.

Before you start

Identify the scope or controller property that owns the visible result. User-provided text must remain text unless it has passed an explicit trusted-HTML policy.

Recipe

Bind each part of the element to scope state:

<article ng-controller="ProductController as product">
 <h2 ng-bind="product.name"></h2>

 <p
 ng-class="{ featured: product.featured, soldOut: !product.inStock }"
 ng-style="{ opacity: product.inStock ? 1 : 0.5 }"
 >
 {{ product.price | currency }}
 </p>

 <p ng-show="product.inStock">Available now</p>
 <p ng-hide="product.inStock">Out of stock</p>

 <button ng-click="product.featured = !product.featured">
 Toggle featured
 </button>
</article>

Change the model, not the element:

Replace part of the page from state

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A page has mutually exclusive steps or an expensive section that should not exist while it is inactive.

Before you start

Decide whether hidden DOM state must survive. Structural directives destroy branches; visibility directives keep their controls, media, and browser state alive.

Recipe

Use ng-switch when one state selects one subtree:

<section ng-switch="checkout.step">
 <cart-review ng-switch-when="review"></cart-review>
 <payment-form ng-switch-when="payment"></payment-form>
 <order-confirmation ng-switch-when="complete"></order-confirmation>
 <p ng-switch-default>Loading checkout...</p>
</section>

Change the state normally:

Swap server-rendered HTML into the page

Mon, 01 Jan 0001 00:00:00 +0000

Problem

An action needs fresh HTML from the server, but it does not justify a client route or a JSON API followed by client-side rendering.

Before you start

The endpoint must return a fragment rather than a complete document. Choose a stable target that belongs to the same application and define what remains when the request fails.

Recipe

Let the server return the final HTML. Select the target with data-target and choose how to place the response with swap:

Run an effect when state changes

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A state change must update something outside AngularTS, such as analytics, storage, a chart, or another browser library.

Before you start

Use an effect only for work outside AngularTS rendering. Identify the scope that owns the external resource and the operation that releases it.

Recipe

const stopThemeEffect = scope.watch('settings.theme', (theme) => {
 themeStore.save(theme);
 chart.setTheme(theme);
});

A watch listener runs after the write, in a microtask. Several synchronous writes to the same property are coalesced before listeners run:

Handle DOM and scope events

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The page must react to user input, control browser event behavior, or notify related scopes.

Before you start

Start from a native user interaction and decide whether communication is local DOM behavior, a short scope notification, or durable shared state.

Handle a DOM event

Use the directive named after the native event:

<button ng-click="cart.add(product)">Add to cart</button>

<input
 ng-keydown="$event.key === 'Escape' && dialog.close()"
 aria-label="Search"
/>

$event is the native event. Declare event policy on the same element:

Build and validate a form

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A form needs reactive values, validation messages, submit state, and a server request without replacing native form behavior unnecessarily.

Before you start

The server endpoint must validate independently and return a deliberate success or error format. Give every submitted native control a name.

Recipe

Name the form and every control. Bind values with ng-model and use native validation attributes:

<form
 name="signupForm"
 ng-post="/api/signup"
 on-success="account = $res"
 on-error="submitError = $res.message"
 loading
 loading-class="is-saving"
>
 <label for="email">Email</label>
 <input id="email" name="email" type="email" ng-model="user.email" required />

 <div ng-messages="signupForm.email.error" ng-show="signupForm.email.dirty">
 <p ng-message="required">Enter your email.</p>
 <p ng-message="email">Enter a valid email.</p>
 </div>

 <p ng-if="submitError" ng-bind="submitError"></p>
 <button type="submit" ng-disabled="signupForm.invalid">Create account</button>
</form>

The form name exposes its controller on scope. Each named ng-model control has an NgModelController.

Read and write REST resources

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Several screens call the same endpoint and repeat URL construction, response mapping, and CRUD request code.

Before you start

Register $rest and $http in the application that owns the data. Define stable resource IDs and the server methods supported by the endpoint.

Recipe

Create one typed resource with $rest:

interface Task {
 id: number;
 title: string;
 complete: boolean;
}

class TaskRepository {
 static $inject = ['$rest'];

 private tasks: ng.RestService<Task, number>;

 constructor($rest: ng.RestFactory) {
 this.tasks = $rest<Task, number>('/api/tasks');
 }

 list() {
 return this.tasks.list();
 }

 get(id: number) {
 return this.tasks.get(id);
 }
}

RestService provides list(), get(), create(), update(), and delete(). Writes stay close to HTTP:

Authenticate requests

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Requests need authentication, but controllers should not copy tokens or credential flags into every call.

Before you start

The server must authenticate and authorize every request. Choose cookie or bearer transport, define session expiry, and register any router states used after login.

Recipe

Prefer a server-managed, HttpOnly cookie when the application and API can share a cookie session:

const session = { currentUser: null };

angular
 .createModule('app', [])
 .value('session', session)
 .config({
 $security: {
 fallback: 'deny',
 isAuthenticated: () => session.currentUser !== null,
 credentials: { cookie: true },
 },
 })
 .controller('LoginController', [
 'session',
 function LoginController(session) {
 this.credentials = {};
 this.signedIn = (user) => {
 session.currentUser = user;
 };
 },
 ]);

$http and $rest consult $security before a request and enable browser credentials when policy allows it. Login remains a normal server request:

Cache REST reads

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Reference data is requested repeatedly even though it changes infrequently.

Before you start

Provide a RestCacheStore implementation and classify the response as public, user-specific, mutable, or immutable before selecting a policy.

Recipe

Start with a cache store. This in-memory version lasts until the page reloads:

class MemoryRestCache {
 entries = new Map();

 async get(key) {
 return this.entries.get(key);
 }
 async set(key, value) {
 this.entries.set(key, value);
 }
 async delete(key) {
 this.entries.delete(key);
 }
 async deletePrefix(prefix) {
 for (const key of this.entries.keys()) {
 if (key.startsWith(prefix)) this.entries.delete(key);
 }
 }
}

const appCache = new MemoryRestCache();

The object implements RestCacheStore. Replace it with IndexedDB or another persistent store when cached data must survive a page reload. Then wrap the HTTP REST backend:

Add application routes

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A client-owned area needs URLs, back-button support, nested views, and route data. A normal server page is no longer enough for that area.

Before you start

Use client routing only inside an area the browser must own. The server must still serve the initial application URL and authentication endpoints.

Recipe

const accountRoutes = [
 {
 name: 'account',
 url: '/account',
 component: 'accountHome',
 },
 {
 name: 'account.orders',
 url: '/orders',
 component: 'orderList',
 policy: {
 navigation: { authenticated: true, redirectTo: 'login' },
 },
 },
 {
 name: 'account.order',
 url: '/orders/:id',
 component: 'orderDetail',
 policy: {
 navigation: { authenticated: true, redirectTo: 'login' },
 },
 },
] as const satisfies readonly ng.RouterModuleDeclaration[];

angular.createModule('account', []).router(accountRoutes);

Render the active state and create links:

Load content when it enters the viewport

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A chart, comment list, or request should not start until the user scrolls near it.

Before you start

Measure the initial request or CPU work first. The deferred feature must have a visible loading or empty state when it has not started.

Recipe

Use ng-viewport and run the enter expression once:

<section
 ng-viewport
 data-viewport-once
 data-viewport-margin="200px 0px"
 on-enter="comments.load()"
>
 <p ng-if="comments.loading">Loading comments...</p>
 <comment-list ng-if="comments.ready"></comment-list>
</section>

The margin starts work 200 pixels before the section enters the viewport. data-viewport-once stops later enter events after the first one.

Receive live server events

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The server must push notifications or status updates to the page without client polling.

Before you start

The server must support text/event-stream, flush events, and handle reconnects. Decide what the page shows before the first event arrives.

The browser side uses SseService through ng-sse. AngularTS owns the SseConnection, reconnects it, and closes it when the scope is destroyed.

For a custom production runtime, include sseModule from @angular-wave/angular.ts/runtime/realtime. Do not include the aggregate realtimeModule unless the same runtime also uses WebSocket and WebTransport.

Move CPU-heavy work off the main thread

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Sorting, compression, or data processing blocks input and rendering on the main browser thread.

Before you start

Profile a realistic input and define a serializable message contract. Browser APIs and DOM nodes cannot be passed to the worker as ordinary values.

Recipe

Point ng-worker at a worker file and bind its result:

<button
 ng-worker="/workers/sort.js"
 data-params="{ items: products }"
 on-result="sortedProducts = $result"
 on-error="sortError = error"
 trigger="click"
>
 Sort products
</button>

<ul>
 <li ng-repeat="product in sortedProducts">{{ product.name }}</li>
</ul>

The worker receives data-params through postMessage:

Load a WebAssembly module

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A calculation already exists as WebAssembly and the page needs to call its exports without writing module-loading lifecycle code.

Before you start

Have a deployed WebAssembly module and know its exported function contract. The server must send the correct MIME type.

Recipe

Load the module with ng-wasm and name its scope resource with as:

<div ng-wasm src="/wasm/shipping.wasm" as="shipping"></div>

<p ng-if="shipping.status === 'loading'">Loading shipping calculator...</p>
<p ng-if="shipping.status === 'error'">Shipping estimate is unavailable.</p>
<p ng-if="shipping.status === 'ready'">
 Shipping: {{ shipping.exports.quote(cart.weightGrams, destination.zone) }}
 cents
</p>

AngularTS exposes a WasmResource as shipping. Check status before calling the pricing export. The cart and destination stay in normal reactive scope state.

Edit a server record in place

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A user should edit one record without leaving the page. The server owns validation and returns the saved record.

Before you start

The page already has the record ID and summary. The endpoint accepts JSON and returns field errors with status 422.

Working example

<article
 ng-init='profile = {"id":42,"name":"Ada"}; editing = false; errors = {}'
>
 <p ng-if="!editing">{{ profile.name }}</p>
 <button ng-if="!editing" ng-click="editing = true">Edit name</button>

 <form
 ng-if="editing"
 ng-put="/api/profiles/{{ profile.id }}"
 on-success="profile = $res; editing = false; errors = {}"
 on-error="errors = $res"
 >
 <input name="name" ng-model="profile.name" required />
 <span ng-if="errors.name">{{ errors.name }}</span>
 <button type="submit">Save</button>
 <button type="button" ng-click="editing = false">Cancel</button>
 </form>
</article>

Server contract

PUT /api/profiles/42
Content-Type: application/json

{"name":"Ada Lovelace"}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"name":"That name is already used"}

What AngularTS wires

The form creates JSON from named controls. A 2xx response replaces profile; a 4xx response becomes $res and stays beside the editor.

Delete a row without rebuilding its list

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Deleting one item should not recreate the list, lose scroll position, or remove the row before the server authorizes the action.

Before you start

The server must authorize deletion and return success only after the record is gone. Give the rendered row a stable DOM ID that is unique on the page.

Working example

<ul>
 <li id="task-42">
 <span>Send invoice</span>
 <button
 ng-delete="/api/tasks/42"
 data-target="#task-42"
 swap="delete"
 on-error="deleteError = $res.message"
 >
 Delete
 </button>
 </li>
</ul>
<p ng-if="deleteError">{{ deleteError }}</p>

Server contract

Return 204 No Content only after authorization and deletion succeed. Return a 403 or 409 JSON body such as {"message":"This task is locked"} when the row must remain.

Search while the user types

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Search should feel immediate without sending a request for every keystroke or letting an older response replace newer results.

Before you start

The search endpoint must accept a bounded query and echo its normalized query in the JSON response. Decide the minimum useful query length and result limit.

Working example

<section ng-init="query = ''; results = []">
 <input
 type="search"
 name="query"
 ng-model="query"
 ng-get="/api/search?q={{ query }}"
 data-trigger="input"
 data-delay="250"
 on-success="$res.query === query && (results = $res.items)"
 />

 <p ng-if="query && !results.length">No results for {{ query }}.</p>
 <ul>
 <li ng-repeat="result in results">{{ result.name }}</li>
 </ul>
</section>

Server contract

Echo the normalized query with the results: {"query":"boots","items":[...] }. The equality check prevents a slow response for an earlier query from winning.

Load one select from another

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A city, model, or category list depends on an earlier selection and should not be loaded before it is needed.

Before you start

The parent values must use stable server identifiers. The child endpoint must validate the parent identifier and return only choices valid for it.

Working example

<form
 ng-init="countries = [{code:'LV', name:'Latvia'}, {code:'EE', name:'Estonia'}]; cities = []"
>
 <select
 name="country"
 ng-model="country"
 ng-options="item.code as item.name for item in countries"
 ng-get="/api/cities?country={{ country }}"
 on-success="cities = $res; city = undefined"
 ></select>

 <select
 name="city"
 ng-model="city"
 ng-options="item.id as item.name for item in cities"
 ng-disabled="!cities.length"
 ></select>
</form>

Server contract

GET /api/cities?country=LV returns a bounded JSON array such as [{"id":1,"name":"Riga"}]. Reject unknown country codes on the server.

Load the next page near the viewport

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A long feed should load another server-rendered page shortly before the user reaches the end without rebuilding existing rows.

Before you start

The server must expose normal paginated URLs and return HTML fragments with stable row identity. Keep explicit pagination as the non-JavaScript and keyboard fallback.

Working example

<ul id="orders">
 <li>Order 1001</li>
 <li>Order 1002</li>
</ul>
<div
 id="next-orders"
 ng-viewport
 data-viewport-once
 data-viewport-margin="300px 0px"
 on-enter="nextPage = 2"
 ng-get="/orders?page={{ nextPage }}"
 data-latch="{{ nextPage }}"
 data-target="#next-orders"
 swap="outerHTML"
>
 Loading more orders...
</div>

Server contract

Return new <li> rows followed by the same marker configured for page 3. Omit the marker on the last page. Keep a normal paginated URL so refresh and sharing work.

Update immediately and roll back on failure

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A reversible action such as completing a task should feel immediate, but a rejected request must restore the last confirmed value.

Before you start

Choose a reversible, low-risk action and retain the last confirmed server value. The endpoint must return the canonical value or a clear conflict response.

Working example

<form
 ng-init='task = {"id":42,"complete":false}; confirmed = false'
 ng-put="/api/tasks/{{ task.id }}"
 on-success="task = $res; confirmed = $res.complete; saveError = undefined"
 on-error="task.complete = confirmed; saveError = $res.message"
>
 <label>
 <input name="complete" type="checkbox" ng-model="task.complete" />
 Complete
 </label>
 <button type="submit">Save</button>
 <span ng-if="saveError">{{ saveError }}</span>
</form>

Server contract

Return the canonical task after success. Return 409 Conflict with {"message":"Task changed on another device"} when the submitted version is stale.

Return users to login after a session expires

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A user opens a private action after their cookie session expires. The application must show login rather than leaving a broken panel.

Before you start

Register the login router state and configure the request credential transport. Decide how the login flow stores and restores the intended destination.

Working example

<section>
 <button
 ng-get="/api/account"
 on-success="account = $res"
 on-error="sessionError = $res.message"
 data-state-error="login"
 >
 Refresh account
 </button>
 <p ng-if="sessionError">{{ sessionError }}</p>
</section>

Server contract

The private endpoint returns 401 with {"message":"Your session expired"}. The login state records the intended state and returns there after successful login.

Cache reference data without sharing user data

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Country, currency, or category lists are downloaded repeatedly even though they change rarely and are identical for every user.

Before you start

Provide an application cache implementing the linked cache-store contract. Confirm the endpoint is independent of user identity before sharing entries.

Working example

import {
 CachedRestBackend,
 HttpRestBackend,
} from '@angular-wave/angular.ts/services/rest';

const referenceBackend = new CachedRestBackend({
 network: new HttpRestBackend($http),
 cache: appCache,
 policy: ({ url }) =>
 url.startsWith('/api/reference/') ? 'cache-first' : 'network-first',
});

const countries = $rest<Country, string>('/api/reference/countries', Country, {
 backend: referenceBackend,
});

<label>
 Country
 <select
 ng-model="shipping.country"
 ng-options="country.code as country.name for country in countries"
 ></select>
</label>

The cached result is ordinary application state. Bind it like any other list; the template does not need to know which cache policy supplied it.

Cancel a file upload and handle server rejection

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A large upload needs cancellation and useful server errors. The current fetch transport does not expose upload progress events.

Before you start

Register the controller on the application module and attach it to the form. Set server-side size, content, authorization, and storage limits before accepting files.

Working example

class UploadController {
 static $inject = ['$http'];

 constructor($http) {
 this.$http = $http;
 }

 async send(file) {
 this.cancellation = Promise.withResolvers();
 const body = new FormData();
 body.append('file', file);

 try {
 await this.$http.post('/api/uploads', body, {
 timeout: this.cancellation.promise,
 });
 } catch (error) {
 if (error.xhrStatus !== 'abort') this.error = error.data.message;
 }
 }

 cancel() {
 this.cancellation?.resolve();
 }
}

<form
 ng-controller="UploadController as upload"
 ng-submit="upload.send(upload.files[0])"
>
 <input type="file" name="file" ng-model="upload.files" required />
 <button type="submit">Upload</button>
 <button type="button" ng-click="upload.cancel()">Cancel</button>
 <p ng-if="upload.error">{{ upload.error }}</p>
</form>

Server contract

Validate size, MIME signature, filename, authorization, and storage limits on the server. Return 413 for size limits and 422 JSON for rejected content.

Load a dialog from the server

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A confirmation dialog needs current server data, but its trigger must keep focus and remain usable if loading fails.

Before you start

The trigger must remain in the DOM while the fragment is open. The server fragment owns its accessible title, initial focus, close behavior, and authorization result.

Working example

<button
 ng-el="dialogTrigger"
 ng-get="/account/delete-dialog"
 data-target="#dialog-host"
 swap="innerHTML"
 on-error="dialogError = $res.message"
>
 Delete account
</button>
<div id="dialog-host"></div>
<p ng-if="dialogError">{{ dialogError }}</p>

Server contract

Return a labelled dialog fragment with a focused cancel button. Its close action calls dialogTrigger.focus() before removing the fragment. Return 403 JSON when the current user may no longer perform the action.

Understand the similarity to HTMX

Mon, 01 Jan 0001 00:00:00 +0000

Problem

AngularTS HTTP directives look familiar if you know HTMX. You want to understand the shared approach without assuming the APIs behave alike.

Before you start

Start with the AngularTS HTTP directive reference. Treat HTMX knowledge as background for the server-first design, not as documentation for AngularTS.

Design question	AngularTS mechanism
Trigger a request	`ng-get`, `ng-post`, `ng-put`, `ng-delete`, `data-trigger`
Choose the destination	`data-target`
Choose insertion behavior	`swap`
Render a server fragment	Return HTML; AngularTS inserts and compiles it
Read JSON	Assign `$res` in `on-success` or `on-error`
Show request state	`loading`, `loading-class`, bindings
Navigate after success	`data-state-success`
Prefetch from intent	Event trigger plus hidden scope state
Lazy load near the viewport	`ng-viewport` plus an HTTP directive
Keep local interaction state	Scope, controller, or typed component view

Where the approach feels similar

Both approaches encourage useful questions for click-to-edit, active search, polling, lazy loading, server validation, fragment swaps, pagination, and prefetching: who renders the result, what triggers the request, where it goes, and what failure looks like.

Design an HTTP response for the UI

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A directive can only handle success, validation, navigation, and swaps correctly when the server response has a deliberate contract.

Before you start

Choose whether the server or browser renders the result. Write down what the user should see after success, invalid input, expired authentication, conflict, and unexpected failure.

Choose the response

Situation	Response contract
Saved data is needed locally	`2xx application/json` with the canonical saved record
Only success matters	`204 No Content`
Server owns the replacement UI	`2xx text/html` with one fragment
User can correct submitted values	`422 application/json` keyed by field name
Authentication expired	`401 application/json` with a safe user message
User lacks permission	`403 application/json`
Submitted version is stale	`409 application/json` with conflict details
Server failed unexpectedly	`5xx application/json` with a public message ID

Use on-success or on-error for JSON. Use data-target and swap for HTML. Do not return HTML error pages to a JSON interaction or 200 for rejected form data merely to avoid the error path.

Make a server-driven interaction accessible

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A request updates the page visually, but keyboard and screen-reader users also need an operable trigger, announced status, and predictable focus.

Before you start

Use a native button or link for the trigger. Choose a stable result container and decide whether focus should remain on the trigger or move to the new result.

Working example

<section ng-init="requestStatus = 'Results not loaded'">
 <button
 ng-get="/account/orders"
 data-target="#order-results"
 swap="innerHTML"
 loading
 on-success="requestStatus = 'Orders loaded'; orderResults.focus()"
 on-error="requestStatus = $res.message"
 aria-describedby="order-status"
 >
 Load orders
 </button>

 <p id="order-status" role="status" aria-live="polite">
 {{ requestStatus }}
 </p>
 <div id="order-results" ng-el="orderResults" tabindex="-1"></div>
</section>

Server contract

Return a heading and order rows as one HTML fragment. Return JSON with a short, actionable message for errors so the live region can announce it.

Audit a server-driven interaction before shipping

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A form or HTTP directive works, but its security depends on decisions spread between markup, request configuration, the endpoint, and storage.

Before you start

Choose one real state-changing request. Record its authenticated user, resource, method, credential transport, response type, cache path, and uploaded content.

Audit the interaction

Surface	Shipping check
Authorization	Server verifies this user may act on this resource
Cookie request	Server validates CSRF protection on every state-changing method
Bearer credential	Token never appears in URL, HTML, storage logs, or error output
HTML response	Server escapes untrusted values before AngularTS compiles it
JSON error	Body contains safe field messages, not stack or database details
Cache	Private entries are partitioned and cleared on logout
Upload	Server checks size, MIME signature, filename, and storage limits
Redirect	Destination is allowlisted rather than copied from user input

Client validation, hidden buttons, route policy, and disabled controls improve the user experience. None of them authorize a server operation.

Keep a form useful before AngularTS starts

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A request should still work when JavaScript is slow, unavailable, or fails to start.

Before you start

Make the endpoint accept a normal form submission and return a complete page. Only then add AngularTS behavior to improve the interaction.

Start with the browser’s form behavior

<form
 action="/orders"
 method="post"
 ng-post="/orders"
 data-state-success="orders"
 on-error="errors = $res"
>
 <label>
 Quantity
 <input name="quantity" type="number" min="1" required />
 </label>
 <button type="submit">Place order</button>
 <p ng-if="errors.quantity">{{ errors.quantity }}</p>
</form>

Without AngularTS, the browser posts the form to /orders. With AngularTS, the HTTP directive submits it without a page reload and the router enters orders after success. The endpoint must accept both the browser’s form encoding and the enhanced request body.

Debug an HTTP interaction from the browser

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A click or submission produces the wrong result and you need to find whether the problem is the element, scope, request, response, or rendering.

Before you start

Open the Elements, Console, and Network panels. Select the element that owns the HTTP directive so it is available as $0 in the console.

Follow one interaction

const scope = angular.getScope($0);
scope.order;

Check the directive attributes on $0, inspect the values used by its expressions, then perform the interaction with Network recording enabled. Read the request method, URL, payload, status, content type, and response before looking at the rendered result.

Control repeated requests

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Typing, scrolling, hovering, or repeated clicks can start more requests than the user needs.

Before you start

Record the interaction in the Network panel. Count requests, transferred bytes, server time, and stale responses. Do not add request control without seeing the problem first.

Choose the smallest control

What you observe	First response
Fast typing starts a request per key	Add a short delay after input settles
Scroll or resize fires continuously	Throttle the event
The same read repeats unchanged	Reuse an appropriate public or user-partitioned cache
An old search overwrites a newer one	Reject stale results or cancel the old request
Hover prefetch repeats	Guard it with loaded and loading state
Double-click repeats a write	Disable while pending and make the server idempotent

Use a promise-valued $http timeout to cancel an obsolete programmatic request. Treat xhrStatus === "abort" as cancellation rather than a server failure. HTTP directive flows should usually prevent another trigger while the current request is pending instead of creating custom cancellation code.

Show validation errors returned by the server

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A form needs immediate, useful errors without duplicating the server’s validation rules in browser code.

Before you start

Make the endpoint return 422 with a JSON object whose keys match form control names. Use short messages that are safe to show directly to the user.

Render the error object

<form
 ng-post="/account/profile"
 on-success="profile = $res; errors = {}"
 on-error="errors = $res"
>
 <label ng-class="{ error: errors.email }">
 Email
 <input
 name="email"
 type="email"
 value="{{ profile.email }}"
 aria-invalid="{{ errors.email !== undefined }}"
 ng-keyup="errors.email = undefined"
 />
 <span ng-if="errors.email">{{ errors.email }}</span>
 </label>
 <button type="submit">Save profile</button>
</form>

The same error object drives the message, error class, and accessibility state. Browser validation can improve feedback, but the server still checks every value.

Protect a cookie-authenticated form from CSRF

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A form uses authentication cookies, so another site may be able to cause the browser to send an unwanted state-changing request.

Before you start

Configure CSRF protection on the server. Generate a token tied to the user or session and render it into the page. Cookie SameSite settings help, but they do not replace server-side CSRF validation.

Submit the server-issued token

<form ng-post="/account/email" on-error="errors = $res">
 <input
 type="hidden"
 name="csrf_token"
 value="SERVER_RENDERED_TOKEN"
 />
 <label>
 New email
 <input name="email" type="email" required />
 </label>
 <button type="submit">Change email</button>
</form>

Replace SERVER_RENDERED_TOKEN in the server template. AngularTS serializes the named hidden control with the rest of the form; the server validates it before changing state.

Confirm a destructive action in place

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A single accidental click can delete important data.

Before you start

Make deletion authorization and resource ownership checks authoritative on the server. Decide whether the operation is reversible and say so in the interface.

Ask for a second explicit action

<article ng-init="confirming = false; deleted = false" ng-if="!deleted">
 <h2>Quarterly report</h2>
 <button type="button" ng-click="confirming = true">Delete</button>
 <div ng-if="confirming" role="alert">
 <p>This permanently deletes the report.</p>
 <button
 type="button"
 ng-delete="/api/reports/42"
 on-success="deleted = true"
 on-error="deleteError = $res"
 >
 Delete permanently
 </button>
 <button type="button" ng-click="confirming = false">Cancel</button>
 <p ng-if="deleteError">{{ deleteError.message }}</p>
 </div>
</article>

The first button changes only local state. The second button sends the request and names the exact consequence.

Handle two people editing the same record

Mon, 01 Jan 0001 00:00:00 +0000

Problem

One person can overwrite a change saved by someone else while both are editing the same record.

Before you start

Give each record a version, revision, or strong ETag. Require the client to send the version it originally loaded with every update.

Send the version with the edit

<form
 ng-put="/api/articles/42"
 on-success="article = $res; conflict = undefined"
 on-error="conflict = $res"
>
 <input name="version" type="hidden" value="{{ article.version }}" />
 <label>
 Title
 <input name="title" value="{{ article.title }}" required />
 </label>
 <button type="submit">Save article</button>
 <aside ng-if="conflict.current">
 <p>Someone saved a newer version: {{ conflict.current.title }}</p>
 <button
 type="button"
 ng-click="article = conflict.current; conflict = undefined"
 >
 Load newer version
 </button>
 </aside>
</form>

Server contract

Update only when the submitted version matches the stored version. Otherwise return 409 with a safe representation of the current record. Increment the version atomically with the successful update.

Let the user retry a failed read

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A temporary network or server failure leaves a section empty or forces a full page reload.

Before you start

Keep reads safe and idempotent. Decide whether old data is more useful than an empty screen while a refresh fails.

Keep recovery next to the result

<section ng-init="orders = []; loadError = undefined">
 <button
 type="button"
 ng-get="/api/orders"
 on-success="orders = $res; loadError = undefined"
 on-error="loadError = $res"
 >
 Refresh orders
 </button>
 <p ng-if="loadError" role="alert">
 Orders could not be refreshed. Try again.
 </p>
 <p ng-if="!loadError && orders.length === 0">No orders yet.</p>
 <ul>
 <li ng-repeat="order in orders">{{ order.number }}</li>
 </ul>
</section>

The existing list remains visible if refresh fails. The user controls when another request is sent.

Paginate a large result on the server

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A large collection is slow to query, transfer, render, and navigate.

Before you start

Make the server return a bounded page and stable next and previous URLs. Prefer a cursor when records change frequently; use page numbers when random access is important and the data is stable enough.

<section>
 <div id="orders">
 <p>Orders 21–40</p>
 </div>
 <nav aria-label="Order pages">
 <a
 href="/orders?page=1"
 ng-get="/orders?page=1"
 data-target="#orders"
 swap="innerHTML"
 >
 Previous
 </a>
 <a
 href="/orders?page=3"
 ng-get="/orders?page=3"
 data-target="#orders"
 swap="innerHTML"
 >
 Next
 </a>
 </nav>
</section>

The href remains useful for opening a page in another tab and for normal navigation before AngularTS starts. The HTTP directive can replace only the list when the enhanced interaction runs.

Download a generated file with the browser

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A report or export needs to download without turning a large binary response into scope state or manually constructing a browser blob.

Before you start

Make the server stream the file with the correct Content-Type and a safe Content-Disposition filename. Authorize the download on every request.

Let the browser own the response

<form action="/reports/orders.csv" method="get">
 <label>
 From
 <input name="from" type="date" required />
 </label>
 <label>
 To
 <input name="to" type="date" required />
 </label>
 <button type="submit">Download CSV</button>
</form>

A native form lets the browser stream, name, save, and expose download progress without retaining the file in AngularTS memory.

Replace a region with trusted server HTML

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The server already renders a useful partial and returning JSON would duplicate the same presentation rules in a client template.

Before you start

Choose a stable target element. Treat every returned fragment as executable UI: escape untrusted values on the server and allow only application-owned markup.

Swap the fragment into a named region

<section>
 <button
 type="button"
 ng-get="/account/summary"
 data-target="#account-summary"
 swap="innerHTML"
 >
 Refresh summary
 </button>
 <div id="account-summary" aria-live="polite">
 <p>Summary not loaded.</p>
 </div>
</section>

AngularTS wires directives and bindings in the returned application-owned fragment. That makes server escaping and content ownership security requirements, not optional cleanup.

Show a request ID when an operation fails

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A user reports “Save failed,” but operators cannot connect that report to one server request among thousands.

Before you start

Generate or accept a request ID at the trusted server edge, carry it through logs and downstream calls, and return it in safe unexpected-error responses.

Render the identifier with the error

<form ng-post="/api/invoices" on-error="saveError = $res">
 <label>
 Customer
 <input name="customer" required />
 </label>
 <button type="submit">Create invoice</button>
 <div ng-if="saveError" role="alert">
 <p>The invoice could not be created.</p>
 <p ng-if="saveError.requestId">
 Support code: {{ saveError.requestId }}
 </p>
 </div>
</form>

The user sees a stable support code, not internal diagnostics.

Check a server interaction before shipping

Mon, 01 Jan 0001 00:00:00 +0000

Problem

An interaction works in the happy path but its production behavior has not been checked as one complete system.

Before you start

Choose one real user action and use its production-like endpoint and permissions. Open the Elements, Console, and Network panels.

Walk the whole path

Check these in order:

Step	Question
Page	Does the useful server-rendered page work before enhancement?
Input	Are labels, names, constraints, and server validation aligned?
Request	Is the method correct and sent only once?
Access	Does the server check authentication, authorization, and CSRF?
Response	Are status, content type, and body appropriate?
State	Does success update only the intended scope and DOM?
Failure	Can the user understand, retry, cancel, or recover safely?
Concurrency	Can stale or duplicate requests corrupt state?
Accessibility	Are status and focus understandable without a pointer?
Operations	Can a request ID connect the visible failure to server logs?

Failure path

Treat any unanswered row as unfinished implementation rather than documentation debt. Fix the smallest owning layer: browser markup, AngularTS wiring, endpoint, storage transaction, or operational logging.

Recover from a rate-limited request

Mon, 01 Jan 0001 00:00:00 +0000

Problem

An endpoint limits repeated requests, but the page reports a generic failure or immediately retries and makes the limit worse.

Before you start

Make the server return 429 and a Retry-After header. Use rate limits to protect a resource, not as the only defense against abusive or unauthorized use.

Keep retry under the user’s control

<section ng-init="limitError = undefined">
 <button
 type="button"
 ng-get="/api/reports/preview"
 on-success="preview = $res; limitError = undefined"
 on-error="limitError = $res"
 >
 Refresh preview
 </button>
 <p ng-if="limitError" role="alert">
 {{ limitError.message }} Try again after {{ limitError.retryAfter }}.
 </p>
 <div ng-if="preview">{{ preview.summary }}</div>
</section>

Do not run a tight automatic retry loop. Keep the last useful result visible and tell the user when another attempt can succeed.

Run slow work as a background job

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A report, import, or media conversion takes too long for one request and becomes fragile behind browser, proxy, or deployment timeouts.

Before you start

Give the job a durable ID, owner, state, progress value, and expiry policy. Make starting the same job twice safe when duplicate work would be expensive.

Start the job, then ask for status

<section>
 <form ng-post="/api/exports" on-success="job = $res">
 <label>
 Format
 <select name="format"><option value="csv">CSV</option></select>
 </label>
 <button type="submit">Create export</button>
 </form>
 <div ng-if="job">
 <p>Status: {{ job.status }}</p>
 <button
 type="button"
 ng-get="/api/exports/current"
 on-success="job = $res"
 >
 Refresh status
 </button>
 <a ng-if="job.downloadUrl" href="{{ job.downloadUrl }}">Download</a>
 </div>
</section>

Use manual refresh first. Add measured polling or server-sent events only when the user benefits from continuous progress.

Make a critical write safe to repeat

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A double click, reconnect, proxy retry, or impatient refresh can submit the same critical operation more than once.

Before you start

Generate a unique operation key on the server-rendered page. Scope it to the authenticated user and operation, and store the first result atomically.

Submit the operation key with the form

<form ng-post="/api/payments" on-error="paymentError = $res">
 <input
 type="hidden"
 name="idempotency_key"
 value="SERVER_RENDERED_OPERATION_KEY"
 />
 <label>
 Amount
 <input name="amount" inputmode="decimal" required />
 </label>
 <button type="submit">Pay once</button>
 <p ng-if="paymentError" role="alert">{{ paymentError.message }}</p>
</form>

Disabling the button improves feedback but cannot provide this guarantee. The server key protects retries from every source.

Build a multi-step form on the server

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A long form needs several steps, but refreshing, navigating back, or changing devices must not discard completed work.

Before you start

Create a server-side draft with an owner and current step. Validate and save each step independently. Make every step addressable with a normal URL.

Enhance a normal step form

<form
 action="/checkout/address"
 method="post"
 ng-post="/checkout/address"
 data-state-success="checkout-payment"
 on-error="errors = $res"
>
 <label>
 Delivery address
 <textarea name="address" required></textarea>
 </label>
 <p ng-if="errors.address">{{ errors.address }}</p>
 <button type="submit">Continue to payment</button>
</form>

The server saves the address before advancing. AngularTS can enter the next router state after success, while the native action remains a working fallback.

Apply one action to several records

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Users need to update several records without opening and submitting each one individually.

Before you start

Choose a maximum batch size. Authorize every selected record independently and decide whether the operation is atomic or may partially succeed.

Submit explicit selected controls

<form ng-post="/api/tasks/archive" on-success="result = $res">
 <fieldset>
 <legend>Tasks to archive</legend>
 <label><input name="task_42" type="checkbox" /> Draft invoice</label>
 <label><input name="task_43" type="checkbox" /> Review contract</label>
 </fieldset>
 <button type="submit">Archive selected tasks</button>
 <p ng-if="result">Archived {{ result.archived }} tasks.</p>
 <ul><li ng-repeat="error in result.errors">{{ error.message }}</li></ul>
</form>

Named controls make the submitted selection inspectable in the Network panel. For dynamic lists, use the server’s documented array representation consistently.

Archive first and offer restore

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Users need to remove an item from active work, but permanent deletion is too easy to regret.

Before you start

Model archived state on the server. Define retention, visibility, uniqueness, restore permissions, and the separate conditions for permanent deletion.

Keep restore beside the result

<section ng-init="archived = false">
 <button
 ng-if="!archived"
 type="button"
 ng-post="/api/projects/42/archive"
 on-success="archived = true"
 >
 Archive project
 </button>
 <div ng-if="archived" role="status">
 <p>Project archived.</p>
 <button
 type="button"
 ng-post="/api/projects/42/restore"
 on-success="archived = false"
 >
 Restore
 </button>
 </div>
</section>

The page changes only after each server operation succeeds.

Handle a permission rejection without hiding it

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The interface hides controls based on known permissions, but permissions can change and direct or stale requests still reach the server.

Before you start

Authorize every operation on the server using the authenticated user and current resource. Client visibility is presentation, not enforcement.

Render the server rejection

<form
 ng-put="/api/team/42/settings"
 on-success="settings = $res; accessError = undefined"
 on-error="accessError = $res"
>
 <label>
 Team name
 <input name="name" value="{{ settings.name }}" required />
 </label>
 <button type="submit">Save settings</button>
 <p ng-if="accessError" role="alert">
 {{ accessError.message }}
 </p>
</form>

A disabled or hidden button can reduce confusion when permission is already known, but the rejection path remains necessary.

Keep search and filters in the URL

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Filters exist only in browser state, so refresh, sharing, Back, and opening a new tab lose the current result.

Before you start

Define stable query parameter names and defaults on the server. Return the same result for the same authorized URL.

Start with a real GET form

<form
 action="/orders"
 method="get"
 ng-get="/orders"
 data-target="#orders"
 swap="innerHTML"
>
 <label>Status <select name="status"><option>Open</option></select></label>
 <label>Search <input name="q" type="search" /></label>
 <button type="submit">Apply filters</button>
</form>
<section id="orders" aria-live="polite">
 <p>Choose filters to update the result.</p>
</section>

The native GET form defines the canonical URL. Enhancement may replace the result region, but it must preserve a URL that reproduces the same filters.

Log out with a state-changing form

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Logout is implemented as a GET link or only clears browser state, leaving the server session active or allowing unwanted cross-site logout requests.

Before you start

Provide a server POST endpoint that invalidates the session and rotates relevant credentials. Decide which private caches and client state must be discarded.

Submit logout as a protected form

<form
 action="/logout"
 method="post"
 ng-post="/logout"
 data-state-success="signed-out"
>
 <input
 type="hidden"
 name="csrf_token"
 value="SERVER_RENDERED_TOKEN"
 />
 <button type="submit">Log out</button>
</form>

The normal form works without client routing. The enhanced form can enter a public signed-out state after the server confirms invalidation.

Keep requests same-origin unless they must cross origins

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The page and API use different origins, introducing preflight, credential, cookie, caching, and deployment behavior that same-origin requests avoid.

Before you start

Ask whether the application server can proxy the API under the page’s origin. Prefer that simpler setup unless direct browser access to the other origin is a real requirement.

Configure the server, not the browser workaround

Allow only known application origins, required methods, and required headers. When cookies are involved, use explicit origins and credentials; wildcard origin responses cannot safely represent authenticated access. Keep CSRF protection for cookie-authenticated state changes.

Handle a uniqueness race on submit

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The page checks that a name is available, but another request claims it before the user submits.

Before you start

Enforce uniqueness with a database constraint. Availability checks improve feedback but can never reserve the value unless the server explicitly does so.

Return the conflict to the field

<form ng-post="/api/teams" on-error="errors = $res">
 <label ng-class="{ error: errors.slug }">
 Team address
 <input
 name="slug"
 required
 aria-invalid="{{ errors.slug !== undefined }}"
 ng-keyup="errors.slug = undefined"
 />
 <span ng-if="errors.slug">{{ errors.slug }}</span>
 </label>
 <button type="submit">Create team</button>
</form>

Server contract

Attempt the insert and translate the known uniqueness violation into 409 or a field-oriented 422 body such as {"slug":"That address is already used"}. Do not expose database error text.

Submit money without floating-point surprises

Mon, 01 Jan 0001 00:00:00 +0000

Problem

An amount changes by a cent because browser or server code treats currency as a binary floating-point number.

Before you start

Choose the currency, accepted decimal precision, rounding rule, minimum, and maximum on the server. Never infer currency only from the user’s locale.

Submit the entered decimal text

<form ng-post="/api/invoices" on-error="errors = $res">
 <label>
 Amount in EUR
 <input
 name="amount"
 inputmode="decimal"
 autocomplete="off"
 required
 />
 </label>
 <input name="currency" type="hidden" value="EUR" />
 <p ng-if="errors.amount">{{ errors.amount }}</p>
 <button type="submit">Create invoice</button>
</form>

Server contract

Parse the amount with a decimal or money type, validate its scale, and store minor units or an exact decimal together with the currency. Return formatted display text separately from the canonical value when needed.

Submit dates and times with an explicit time zone

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A date or appointment moves by a day or hour when users and servers use different time zones.

Before you start

Decide whether each value is a calendar date, a local wall-clock time, or an exact instant. These are different domain values and need different storage rules.

Send the local value and zone together

<form ng-post="/api/appointments" on-error="errors = $res">
 <label>
 Local start
 <input name="localStart" type="datetime-local" required />
 </label>
 <label>
 Time zone
 <select name="timeZone" required>
 <option value="Europe/Riga">Europe/Riga</option>
 </select>
 </label>
 <p ng-if="errors.localStart">{{ errors.localStart }}</p>
 <button type="submit">Schedule</button>
</form>

Server contract

Resolve local time with an IANA zone, reject nonexistent daylight-saving times, and define how ambiguous times are chosen. Store exact instants in UTC while retaining the zone when future local scheduling depends on it.

Keep identifiers as opaque strings

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A large numeric ID is rounded in JavaScript or application code starts depending on structure that should be private to the server.

Before you start

Define public identifiers as strings even when the database uses numbers. Treat them as labels, not values for arithmetic or ordering.

Submit the identifier unchanged

<form ng-post="/api/invitations" on-error="errors = $res">
 <input
 name="accountId"
 type="hidden"
 value="acct_9007199254740993"
 />
 <label>Email <input name="email" type="email" required /></label>
 <button type="submit">Invite</button>
</form>

Server contract

Accept and return the identifier as a string. Validate its syntax, then authorize the referenced resource independently. An unguessable ID is not permission.

Revalidate a cached response with ETag

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The browser repeatedly downloads a response that rarely changes.

Before you start

Confirm the request is safe and cacheable. Decide whether the representation is public, user-specific, or private before choosing cache headers.

Let HTTP perform revalidation

Return a stable strong or weak ETag with the representation. On a later request, compare If-None-Match and return 304 without a body when it still matches. Normal navigation and standards-based HTTP clients can then reuse cached bytes.

Keep a useful page during planned maintenance

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A deployment or dependency outage turns the application into an indefinite spinner, proxy error, or misleading authentication failure.

Before you start

Prepare a small server-rendered maintenance page that does not depend on the database or application service being maintained.

Return the correct temporary status

Use 503 Service Unavailable and a realistic Retry-After header. Explain what is unavailable, whether existing data is safe, and when the user should retry. Keep status and support links on dependencies that remain available.

Return users safely after sign-in

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The login flow accepts an arbitrary return URL, allowing attackers to send users from a trusted sign-in page to a malicious site.

Before you start

Prefer a server-side return target stored in the session. If a destination must travel through the form, restrict it to known local routes or an allowlist.

Submit a local destination

<form action="/login" method="post" ng-post="/login" on-error="errors = $res">
 <input name="return_to" type="hidden" value="/account/orders" />
 <label>Email <input name="email" type="email" autocomplete="username" /></label>
 <label>
 Password
 <input name="password" type="password" autocomplete="current-password" />
 </label>
 <button type="submit">Sign in</button>
</form>

Server contract

Resolve the destination against an allowlist or accept only normalized local paths. Reject protocol-relative URLs, encoded scheme tricks, control characters, and destinations outside the application.

Return one safe error shape

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Every endpoint returns errors differently, so forms contain endpoint-specific parsing and unexpected failures leak internal details.

Before you start

Define a small envelope with a safe message, optional field errors, a stable code, and a request ID. Keep HTTP status as the primary category.

Bind predictable members

<form ng-post="/api/profile" on-error="error = $res">
 <label>
 Display name
 <input name="name" required />
 </label>
 <p ng-if="error.fields.name">{{ error.fields.name }}</p>
 <p ng-if="error.message" role="alert">{{ error.message }}</p>
 <p ng-if="error.requestId">Support code: {{ error.requestId }}</p>
 <button type="submit">Save</button>
</form>

Server contract

Keep the envelope stable across 401, 403, 409, 422, 429, and 5xx, but preserve those statuses. Use machine codes only for behavior the client actually needs; do not mirror exception class names.

Make full-page and fragment responses explicit

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The same URL serves normal navigation and an enhanced region update, but the server sometimes returns a full page where a fragment is expected.

Before you start

Define an explicit request policy using Accept, a documented request header, or separate routes. Do not infer intent from fragile user-agent checks.

<a
 href="/account/orders"
 ng-get="/account/orders"
 data-target="#orders"
 swap="innerHTML"
>
 Refresh orders
</a>
<section id="orders" aria-live="polite">
 <p>Current orders appear here.</p>
</section>

Server contract

Return a complete document for normal navigation and a valid application-owned fragment for the enhanced request. Set Content-Type, cache variation, and error responses consistently for both representations.

Render user-authored rich text safely

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Users can author formatted content, but inserting their HTML as an AngularTS fragment could compile attacker-controlled directives or executable markup.

Before you start

Choose a maintained allowlist sanitizer and a deliberately small formatting policy. Sanitize on the server before storage or rendering, not only in the browser.

Keep content inside an application-owned shell

<article>
 <header><h1>{{ post.title }}</h1></header>
 <div id="post-body" class="rich-text">
 SERVER_RENDERED_SANITIZED_CONTENT
 </div>
</article>

The shell may use AngularTS bindings. The user-authored body is sanitized content, not a template and not a source of directives.

Add Content Security Policy in report-only mode

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The application has no browser policy limiting where scripts, styles, frames, and connections may come from.

Before you start

Inventory real production resources and choose a report endpoint that removes sensitive URL and user data before storage.

Start by observing

Send Content-Security-Policy-Report-Only from the server. Begin with narrow directives for default-src, script-src, style-src, img-src, font-src, connect-src, frame-ancestors, base-uri, and form-action. Use nonces or hashes for deliberate inline content instead of broad unsafe allowances.

Harden an authentication session cookie

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Authentication state is readable by browser scripts or sent more broadly than the application requires.

Before you start

Use the server framework’s maintained session implementation. Store only an opaque session identifier in the browser, not authorization state or personal data.

Use Secure, HttpOnly, and an appropriate SameSite value. Keep Path and Domain as narrow as the deployment allows. Rotate the session after sign-in and privilege changes, and expire it on logout.

Build a password-manager-friendly sign-in form

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Custom sign-in controls prevent password managers, keyboard submission, or browser security features from recognizing the form.

Before you start

Use a normal server POST endpoint over HTTPS. Keep labels, control names, and a submit button in the document.

Use standard autocomplete semantics

<form action="/login" method="post" ng-post="/login" on-error="errors = $res">
 <label>
 Email
 <input name="email" type="email" autocomplete="username" required />
 </label>
 <label>
 Password
 <input
 name="password"
 type="password"
 autocomplete="current-password"
 required
 />
 </label>
 <p ng-if="errors.message" role="alert">{{ errors.message }}</p>
 <button type="submit">Sign in</button>
</form>

Server contract

Use a generic authentication error, rate-limit abuse, rotate the session after success, and keep account recovery separate. New-password forms use autocomplete="new-password".

Keep secrets out of errors and logs

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Request bodies, headers, URLs, or exceptions can copy credentials and personal data into browser errors and long-lived logs.

Before you start

Classify credentials and sensitive fields. Define allowlisted log fields instead of trying to redact an unlimited set after serialization.

Show only a safe support reference

<form ng-post="/api/connections" on-error="connectionError = $res">
 <label>API key <input name="apiKey" type="password" required /></label>
 <button type="submit">Connect</button>
 <p ng-if="connectionError" role="alert">
 Connection failed. Support code: {{ connectionError.requestId }}
 </p>
</form>

Server contract

Never return or log the submitted key. Log an allowlisted operation name, safe resource ID, status, duration, and request ID. Redact downstream exception data before it crosses service boundaries.

Focus the first field rejected by the server

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The server returns validation errors below the visible area and keyboard users do not know which control needs attention.

Before you start

Expose important controls with ng-el and return field errors using control names. Focus only after the failed response, not while the user is typing.

Focus a known field after rejection

<form
 ng-post="/account/profile"
 on-error="errors = $res; emailInput.focus()"
>
 <label>
 Email
 <input ng-el="emailInput" name="email" type="email" required />
 </label>
 <p ng-if="errors.email" id="email-error">{{ errors.email }}</p>
 <button type="submit">Save profile</button>
</form>

For several fields, let the response handler choose the first rejected control in document order. Keep the visible message associated with its input.

Turn an empty result into the next action

Mon, 01 Jan 0001 00:00:00 +0000

Problem

An empty collection renders a blank region that looks broken and gives no path forward.

Before you start

Separate first-use emptiness, filter emptiness, permission limits, loading, and request failure. They require different messages and actions.

Render the empty case deliberately

<section>
 <ul ng-if="projects.length > 0">
 <li ng-repeat="project in projects">{{ project.name }}</li>
 </ul>
 <div ng-if="projects.length === 0">
 <h2>No projects yet</h2>
 <p>Create the first project to organize this work.</p>
 <a href="/projects/new">Create a project</a>
 </div>
</section>

Server contract

Return an empty collection as a successful result. Do not use 404 for a valid collection with no records. Preserve active filters so the empty explanation can offer clearing them when appropriate.

Preserve focus when replacing server HTML

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A fragment replacement removes the focused element or leaves keyboard users outside the newly displayed content.

Before you start

Choose whether focus should remain on a stable trigger or move to the result. Add a programmatically focusable heading only when moving focus is useful.

Keep the target stable and focus its heading

<section>
 <button
 ng-get="/account/summary"
 data-target="#summary-body"
 swap="innerHTML"
 on-success="summaryHeading.focus()"
 >
 Load summary
 </button>
 <article>
 <h2 ng-el="summaryHeading" tabindex="-1">Account summary</h2>
 <div id="summary-body"><p>Summary not loaded.</p></div>
 </article>
</section>

Server contract

Return only the body fragment so the stable heading and its ng-el reference are not removed. Use valid application-owned HTML.

Deliver a feature flag with the server page

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The page waits for a second request before deciding which small interface variation to show, causing flicker and inconsistent first rendering.

Before you start

Evaluate the flag on the server using the authenticated request and rollout policy. Treat the result as presentation, never as permission.

Initialize the evaluated result

<section ng-init="flags = { compactCheckout: false }">
 <a ng-if="flags.compactCheckout" href="/checkout/compact">
 Use compact checkout
 </a>
 <a ng-if="!flags.compactCheckout" href="/checkout">
 Continue to checkout
 </a>
</section>

Render the evaluated boolean into the server template. Do not expose targeting rules, experiment secrets, or unrelated flags.

Record who changed sensitive data

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A sensitive record changed, but the application cannot explain who changed what, when, or through which operation.

Before you start

Define which domain actions require audit history, who may read it, retention, redaction, and the difference between audit events and diagnostic logs.

Ask for context when the domain needs it

<form ng-post="/api/accounts/42/suspend" on-error="errors = $res">
 <label>
 Reason for suspension
 <textarea name="reason" required></textarea>
 </label>
 <button type="submit">Suspend account</button>
</form>

Server contract

Derive actor, tenant, request ID, time, and affected resource on the server. Record the domain action and safe before-and-after facts in the same transaction or a reliable transactional outbox.

Roll out a request contract without breaking old pages

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A deployment changes a field or response shape while users still have pages, workers, or tabs running code from the previous release.

Before you start

Measure how long old clients and cached pages remain active. Identify producers, consumers, integrations, queued jobs, and persisted data using the contract.

Use an expand-and-contract rollout

First make the server accept old and new requests. Then deploy clients that use the new shape. Observe adoption and errors. Migrate stored data and background producers. Remove old behavior only after the supported compatibility window.

Find a beginner recipe

Mon, 01 Jan 0001 00:00:00 +0000

Start here

Work through these recipes in order until you reach the problem you need to solve. Each one assumes only the earlier browser and HTML concepts.

What you need	Recipe
Inspect a running page	Inspect the application
Find an element’s scope	Select elements through the scope
Include initial server data	Pass data from the server
Change element content or classes	Update the DOM
Replace an element	Replace DOM
Render server HTML in a region	Swap server HTML
React to state	Run effects
Handle browser and scope events	Handle events
Submit user input	Build forms
Call a JSON endpoint	Use REST services
Keep the page useful without JavaScript	Enhance progressively
Compare the server-driven approach	Understand the HTMX similarity

Choose the next area

Continue with the forms, HTTP, DOM, navigation, security, or performance finder instead of reading the cookbook from top to bottom.

Find a form recipe

Mon, 01 Jan 0001 00:00:00 +0000

Build the basic flow

Problem	Recipe
Submit controls and display responses	Build forms
Render named server errors	Show server validation
Focus a rejected control	Focus the first error
Upload and cancel a file	Upload with cancellation
Search while typing	Build active search
Load one choice from another	Build dependent selects
Save several steps	Build a multi-step form

Protect the write

Problem	Recipe
Protect a cookie-authenticated form	Send CSRF proof
Prevent duplicate critical effects	Use an idempotency key
Confirm permanent deletion	Confirm deletion
Preserve another person’s edit	Handle edit conflicts
Handle a uniqueness race	Return uniqueness errors

Represent input correctly

Problem	Recipe
Submit currency	Send money safely
Submit local time	Send dates with zones
Submit several records	Apply a bulk action
Build sign-in controls	Support password managers
Harden the session form	Harden session cookies

Find an HTTP recipe

Mon, 01 Jan 0001 00:00:00 +0000

Define the response first

Problem	Recipe
Choose status, body, and content type	Design an HTTP response
Keep error bodies predictable	Use an error envelope
Return a page or a fragment	Negotiate content explicitly
Swap trusted server markup	Replace a region with server HTML

Control requests

Problem	Recipe
Recover from a failed read	Offer manual retry
Stop duplicate or stale requests	Control repeated requests
Respect a server limit	Handle rate limiting
Move slow work out of the request	Run a background job
Avoid retransferring unchanged data	Revalidate with ETag
Stream a generated file to disk	Use a browser download

Handle deployment boundaries

Problem	Recipe
Call JSON services	Use REST services
Serve a temporary outage	Return maintenance mode
Call another origin	Configure cross-origin access

Find a DOM recipe

Mon, 01 Jan 0001 00:00:00 +0000

Wire elements to scope

Problem	Recipe
Expose an element without querying	Select elements through scope
Change text and classes	Update the DOM
Replace a node	Replace DOM
Replace a region with server markup	Swap server HTML

Build common interactions

Problem	Recipe
Edit one record in place	Build inline editing
Remove a confirmed row	Delete a row
Update before a request completes	Use an optimistic update
Load a server-rendered dialog	Open a server dialog

Keep updates usable

Problem	Recipe
Announce and focus request results	Make requests accessible
Explain an empty collection	Design an empty state
Keep focus after replacement	Preserve focus after swaps

Find a security recipe

Mon, 01 Jan 0001 00:00:00 +0000

Protect server operations

Problem	Recipe
Audit a complete interaction	Run the security audit
Protect cookie-authenticated writes	Send CSRF proof
Enforce current permissions	Handle permission rejection
Prevent duplicate critical writes	Use idempotency
End an authenticated session	Log out safely

Protect browser content

Problem	Recipe
Validate a return destination	Prevent open redirects
Render user-authored formatting	Sanitize rich text
Restrict executable resources	Deploy Content Security Policy
Restrict session delivery	Harden session cookies
Remove credentials from diagnostics	Redact secrets

Protect destructive actions

Problem	Recipe
Confirm permanent removal	Confirm deletion
Prefer a reversible operation	Archive and restore

Find a performance recipe

Mon, 01 Jan 0001 00:00:00 +0000

Reduce network work

Problem	Recipe
Avoid repeated unchanged reads	Cache reference data
Use HTTP validators	Revalidate with ETag
Delay, throttle, or cancel requests	Control repeated requests
Prefetch before a click	Prefetch a result

Reduce rendering work

Problem	Recipe
Page a large collection	Paginate on the server
Load more near the viewport	Build infinite scrolling
React to visibility	Use viewport observation
Keep simple reference data	Use caching

Move specialized work

Problem	Recipe
Receive incremental server changes	Use server-sent events
Move CPU work off the main thread	Use a worker
Run measured native computation	Use WebAssembly
Move slow server work out of a request	Run a background job

Reduce shipped JavaScript

Problem	Recipe
The measured runtime contains unused features	Build a smaller production runtime

Find a data correctness recipe

Mon, 01 Jan 0001 00:00:00 +0000

Represent values correctly

Problem	Recipe
Keep public IDs unchanged	Use opaque identifiers
Preserve currency precision	Submit money safely
Preserve time meaning	Send dates with zones
Seed initial server values	Pass server data

Protect concurrent changes

Problem	Recipe
Detect a stale edit	Handle edit conflicts
Handle a unique constraint race	Return uniqueness errors
Make a write repeatable	Use idempotency
Report partial batch results	Apply bulk actions

Preserve history and compatibility

Problem	Recipe
Keep useful cached records	Cache reference data
Keep state across an expired session	Handle session expiration
Record a sensitive change	Write an audit trail
Change a contract safely	Use a compatible rollout

Find a navigation recipe

Mon, 01 Jan 0001 00:00:00 +0000

Problem	Recipe
Keep forms useful before enhancement	Use progressive enhancement
Preserve search in the address	Keep filters in the URL
Preserve list navigation	Paginate on the server
Return safely after sign-in	Validate redirects

Add browser-owned state where needed

Problem	Recipe
Define application routes	Use the router
Enter a state after sign-in	Handle authentication
Enter the next saved form step	Build a multi-step form
Recover from an expired session	Handle session expiration
Enter a public state after logout	Log out safely

Find an operations recipe

Mon, 01 Jan 0001 00:00:00 +0000

Diagnose a request

Problem	Recipe
Follow element, scope, request, and DOM	Debug an HTTP interaction
Connect an error to server logs	Show a request ID
Keep credentials out of telemetry	Redact secrets
Check a whole feature	Run the shipping check

Operate degraded systems

Problem	Recipe
Tell users when to retry	Handle rate limits
Move long work to a worker process	Run a background job
Serve a planned outage	Return maintenance mode

Change production safely

Problem	Recipe
Deliver a rollout decision	Use server feature flags
Explain a sensitive state change	Record an audit trail
Support mixed release versions	Roll contracts out compatibly

Find an advanced browser recipe

Mon, 01 Jan 0001 00:00:00 +0000

React to browser and scope changes

Problem	Recipe
Run cleanup-aware reactions	Use effects
Handle browser and scope events	Handle events
React to element visibility	Observe the viewport
Stream server updates	Use server-sent events
Send and receive live messages	Use WebSocket

Add specialized execution

Problem	Recipe
Move computation off the main thread	Use a worker
Call measured native computation	Use WebAssembly
Remove unused framework code	Build a smaller runtime
Cancel a large upload	Control an upload
Call an API on another origin	Configure cross-origin access

Build specialized interaction

Problem	Recipe
Append results near the viewport	Build infinite scrolling
Update before the server responds	Use optimistic updates
Load a modal from the server	Open a server dialog
Render sanitized authored content	Handle rich text

Integrate another framework

Problem	Recipe
Choose an integration boundary	Choose a bridge
Publish transient cross-root messages	Use the event bus
Read reflected web-component state	Observe Fluent UI attributes
Share current reactive state	Use an application model

Exchange live messages with WebSocket

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The browser must send messages while the server pushes new messages over the same long-running connection. Repeated HTTP requests or SSE only solve half of that conversation.

Before you start

Use WebSocket only when both sides need to send independently. Prefer SSE when the browser only receives updates, and ordinary HTTP when messages are infrequent.

AngularTS exposes WebSocketService, WebSocketConfig, and the managed WebSocketConnection. The managed connection handles message decoding, retry policy, heartbeats, and explicit cleanup.

Integrate AngularTS with another framework

Mon, 01 Jan 0001 00:00:00 +0000

Problem

An AngularTS module must coexist with a web component or another UI framework without both runtimes fighting over the same DOM and state.

Before you start

Give each framework its own root element. One framework owns rendering and cleanup inside that root. Integrate at the root boundary instead of compiling the same subtree twice.

Choose the smallest bridge

What crosses the boundary	Use
A transient message that something happened	The event bus
State reflected by a custom element attribute	`ng-observe`
Current domain state needed by both sides	A shared model

Use browser custom events directly when one element and its immediate owner are the only participants. Use the event bus when producers and consumers should not know each other. Use a model when consumers need the current value, not only a notification that it changed.

Send messages across framework roots

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A component in another framework needs to notify an AngularTS module without holding its controller, scope, or DOM implementation.

Before you start

Name the event after something that happened, such as product:selected. Keep the payload small and define its shape at the integration boundary.

const app = angular.createModule('catalog', []);

app.controller('SelectionController', [
 '$eventBus',
 '$scope',
 function SelectionController($eventBus, $scope) {
 this.selected = undefined;
 $eventBus.subscribe(
 'product:selected',
 (product) => (this.selected = product),
 $scope,
 );
 },
]);

externalCatalog.onSelected((product) => {
 angular.eventBus.publish('product:selected', product);
});

The injected $eventBus and angular.eventBus expose the same application bus. Delivery is asynchronous through a microtask and listeners run in subscription order. Passing a scope as the subscription context removes the listener when the scope is destroyed and skips queued delivery to that destroyed scope.

Read Fluent UI custom-element state with ng-observe

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A custom element owns its internal behavior and reports current state by changing an attribute. AngularTS needs that value without taking over the element’s DOM.

Before you start

Confirm the component reflects the required state to an attribute. ng-observe watches attributes with MutationObserver; it does not poll JavaScript-only properties.

Observe the Fluent UI attribute

This example is taken from the repository’s Fluent UI observe demo.

Share current state through an application model

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Two framework roots need the current shopping-cart state. Sending only item:added events makes late consumers reconstruct state and handle missed messages.

Before you start

Choose one owner for the model and its mutations. Retrieve the same registered model from the AngularTS application injector instead of copying it into each framework store.

Register one shopping-cart model

const shop = angular.createModule('shop', []);

shop.model('cart', () => ({
 items: [],
 currency: 'EUR',
}));

shop.controller('CartSummary', [
 'cart',
 function CartSummary(cart) {
 this.cart = cart;
 },
]);

Inject cart into AngularTS controllers, services, or component views. A non-Angular root can retrieve the same instance from the injector associated with the shared application root.

Build a smaller production runtime

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The production JavaScript bundle is larger than its measured budget even though the application uses only a small part of AngularTS. Importing the full runtime ships directives and services that this page never uses.

Before you start

Optimize the server response, images, fonts, and application code before maintaining a custom runtime. Use this recipe only after a production bundle report shows that unused AngularTS features are material.

Add behavior to server-rendered HTML

Mon, 01 Jan 0001 00:00:00 +0000

Problem

The server already renders a useful page. One part needs client-side behavior, but the page should still work when JavaScript fails or loads slowly.

Recipe

Keep navigation, forms, and initial content in HTML. Put AngularTS on the smallest element that needs it.

<main>
 <h1>Search products</h1>

 <form
 action="/products"
 method="get"
 ng-app="catalog"
 ng-controller="SearchController as search"
 >
 <label for="query">Search</label>
 <input id="query" name="q" ng-model="search.query" />

 <span aria-live="polite" ng-bind="search.message()"></span>
 <button type="submit">Search</button>
 </form>
</main>

const app = angular.createModule('catalog', []);

app.controller('SearchController', function SearchController() {
 this.query = '';

 this.message = () => {
 const count = this.query.trim().length;
 return count === 0 ? 'Enter a search term' : count + ' characters';
 };
});

The form remains a normal GET request. AngularTS adds feedback, but does not own navigation or the initial result page.

Make a component view reactive

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A component changes its controller state, but a value in its component view stays frozen at the initial value.

Recipe

Pass a reader function for values that can change.

import { button, output } from '@angular-wave/angular.ts';

class CounterController {
 count = 0;
}

const app = angular.createModule('counter', []);

app.component<CounterController>('counter', {
 controller: CounterController,
 view: ({ controller }) => {
 return [
 button(
 {
 type: 'button',
 onclick: () => {
 controller.count += 1;
 },
 },
 'Add',
 ),
 output(() => controller.count),
 ];
 },
});

Use () => controller.count, not controller.count, for the changing child.

Why this works

controller.count reads the value while the view is being created. The view receives one number and has nothing to read later.

Keep repeated rows stable

Mon, 01 Jan 0001 00:00:00 +0000

Problem

Refreshing a collection replaces every object. ng-repeat then rebuilds rows, which loses focus, selection, local element state, and animation continuity.

Recipe

Reconcile incoming records with the existing objects before replacing the collection.

interface User {
 id: string;
 name: string;
}

function reconcileUsers(current: User[], incoming: User[]): User[] {
 const existing = new Map(current.map((user) => [user.id, user]));

 return incoming.map((next) => {
 const user = existing.get(next.id);

 if (!user) {
 return next;
 }

 Object.assign(user, next);
 return user;
 });
}

Use the reconciled array after a refresh:

controller.users = reconcileUsers(controller.users, response.data);

Render it normally:

<ul>
 <li ng-repeat="user in users">
 <input ng-model="user.name" />
 </li>
</ul>

Why this works

ng-repeat tracks objects by identity. Reusing the object for the same id lets AngularTS reuse that row. New records get new rows, removed records lose their rows, and existing records keep their DOM.

Stop hidden UI from doing work

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A closed panel still runs watchers, observers, timers, or network work because CSS hides it without removing it.

Recipe

Use ng-if when closing the UI should destroy it.

<button type="button" ng-click="detailsOpen = !detailsOpen">
 Toggle details
</button>

<account-details ng-if="detailsOpen"></account-details>

Use ng-show only when the DOM and its state must stay alive:

<video-player ng-show="playerOpen"></video-player>

Why this works

ng-if removes the subtree and destroys its child scope. Reopening it creates a fresh subtree.

Ignore stale request results

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A user searches for cat, then quickly searches for caterpillar. The second request finishes first. The slower cat response arrives later and replaces the correct results.

Recipe

Give each request a sequence number. Apply a response only when it belongs to the newest request.

app.controller('SearchController', function SearchController($http) {
 let latestRequest = 0;

 this.results = [];
 this.loading = false;
 this.error = '';

 this.search = async (query) => {
 const request = ++latestRequest;
 this.loading = true;
 this.error = '';

 try {
 const response = await $http.get('/api/search', {
 params: { q: query },
 });

 if (request === latestRequest) {
 this.results = response.data;
 }
 } catch (error) {
 if (request === latestRequest) {
 this.error = 'Search failed';
 }
 } finally {
 if (request === latestRequest) {
 this.loading = false;
 }
 }
 };
});

Why this works

Network responses can arrive in any order. The sequence number records which request currently owns the screen. Older requests may finish, but they cannot change results, errors, or loading state.

Clean up browser resources

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A component adds a browser listener or timer. After navigation or ng-if removes the component, the callback still runs and keeps old state in memory.

Recipe

Create the resource inside the component view and register its cleanup at the same time.

import { time } from '@angular-wave/angular.ts';

class ClockController {
 now = new Date();
}

app.component<ClockController>('clock', {
 controller: ClockController,
 view: ({ controller, onDestroy }) => {
 const timer = window.setInterval(() => {
 controller.now = new Date();
 }, 1_000);

 onDestroy(() => {
 window.clearInterval(timer);
 });

 return time(() => controller.now.toLocaleTimeString());
 },
});

For browser listeners, an AbortController keeps several listeners under one cleanup:

Find the slow part of an interaction

Mon, 01 Jan 0001 00:00:00 +0000

Problem

An interaction feels slow, but changing watchers or rendering code without a trace only moves work around.

Recipe

Record one interaction and optimize the longest measured task.

Reproduce the problem with realistic data and a production build.
Open the browser Performance panel.
Start recording immediately before the interaction.
Stop after the screen reaches its final state.
Find the longest main-thread task or network wait.
Expand that task until you can name the function, layout, paint, or request responsible.
Change one cause and record the same interaction again.

Add marks when the trace does not show where application work starts:

Render every request state

Mon, 01 Jan 0001 00:00:00 +0000

Problem

A request-driven screen shows stale content during loading, treats an empty result as an error, or leaves the loading indicator visible after failure.

Recipe

Model request status separately from its data.

app.controller('OrdersController', function OrdersController($http) {
 this.status = 'idle';
 this.orders = [];

 this.load = async () => {
 this.status = 'loading';

 try {
 const response = await $http.get('/api/orders');
 this.orders = response.data;
 this.status = this.orders.length === 0 ? 'empty' : 'ready';
 } catch (error) {
 this.status = 'error';
 }
 };
});

Render each state once:

<section aria-live="polite">
 <p ng-if="orders.status === 'loading'">Loading orders...</p>

 <button ng-if="orders.status === 'error'" ng-click="orders.load()">
 Try again
 </button>

 <p ng-if="orders.status === 'empty'">No orders yet.</p>

 <ul ng-if="orders.status === 'ready'">
 <li ng-repeat="order in orders.orders" ng-bind="order.number"></li>
 </ul>
</section>

Why this works

One status value prevents impossible combinations such as loading and error appearing together. Empty data is a successful response, so it gets its own state instead of sharing the error path.