React Router revalidation in Board Web

Revalidation means loading route data again so the page reflects current records.

This page covers Framework Mode with ssr: true. Start with React Router and Rails authentication if the request model is unfamiliar.

As a frontend engineer, I want current page data after a change. I also need the displayed session to follow login and logout.

What triggers another data read

A data read calls the selected route's server loader or client loader.

Operation	Behaviour
Initial document request	Server loaders supply initial data; this is initial loading, not revalidation
Client navigation	Load destination data according to the route exports and revalidation rules
Successful route action	Reload route data by default
Action result with status 400 or higher	Default handling skips revalidation; a route may opt back in
revalidator.revalidate()	Request another read of current route data
Ordinary API call from an event handler	No automatic revalidation merely because that call finished

Navigating from /dashboard to /settings does not reload the departed dashboard route. The router considers the matched destination routes.

A route with a clientLoader controls its browser data read. It can call Rails directly or call serverLoader().

Sources: React Router — route module revalidation, actions.

What shouldRevalidate controls

shouldRevalidate is a function exported by a route module. It controls whether that route reloads its data.

Returning false does not turn off Rails authorization. It also does not stop unrelated client loaders or cancel API work already started.

The defaultShouldRevalidate argument holds the router's default answer for this operation. Keep that answer unless a specific rule requires a different one.

Jod's virtual roots add revalidation after an action returns an authentication or authorization failure:

export function shouldRevalidate({ actionStatus, defaultShouldRevalidate }) {
  const isAuthFailure = actionStatus === 401 || actionStatus === 403
  if (isAuthFailure) return true
  return defaultShouldRevalidate
}

An action's 403 can mean access facts changed. Reloading the session lets policies read those facts again.

An invalid password is an expected login form error. Jod's login action returns 422 with the code invalid_login for that case, so it does not request this extra session read.

Sources: Jod's public virtual root, Team login action.

Session data must follow session changes

Session data is the root loader's summary of the signed-in person and access states.

Login changes cookies. Company selection changes access facts. Components need another session read after either operation.

Do not return false for every navigation on a session-owning root. That can retain stale session data.

Page data may have separate performance needs. Review those needs per route. Do not disable authentication reads as a general optimization.

An action failure is different from a loader failure

An action failure appears in actionStatus. A failed API call inside a clientLoader does not.

Failure source	Recovery responsibility
Route action	Preserve the error status so the virtual root's rule can run
Client loader	Handle the refused request through the defined access recovery path
Direct component API call	Request revalidation when fresh access facts are needed

Reloading cannot grant access. Rails still checks the next request.

A recovery path must be bounded. If the session still allows the area but one record is refused, show that record's error. Do not keep revalidating forever.

See actions and session changes for the complete request sequence.