Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Only add token refresh logic to token-auth flows
Do not dispatch token refresh or retry behavior unless the failing request actually depends on a refreshable token.
Bad example
| 1 | if (!response.payload) { |
| 2 | if (response.statusCode === 401) { |
| 3 | const refetchEvent = new CustomEvent('refetchToken'); |
| 4 | window.dispatchEvent(refetchEvent); |
| 5 | } |
| 6 | } |
Explanation (EN)
This assumes every 401 is solved by refreshing a token. If the route is session-based, the retry event is dead behavior and hides the real failure path.
Objašnjenje (HR)
Ovo pretpostavlja da se svaki 401 rjesava refreshanjem tokena. Ako je route session-based, retry event je dead behavior i skriva stvarni failure path.
Good example
| 1 | if (!response.payload) { |
| 2 | showSnackbar({ |
| 3 | message: 'Kunne ikke laste transaksjoner', |
| 4 | severity: 'error', |
| 5 | }); |
| 6 | setIsError(true); |
| 7 | return; |
| 8 | } |
Explanation (EN)
The UI handles the failure according to the real auth model. Refresh logic is used only where the request genuinely depends on a token that can be renewed.
Objašnjenje (HR)
UI hendla failure prema stvarnom auth modelu. Refresh logika se koristi samo tamo gdje request stvarno ovisi o tokenu koji se moze obnoviti.
Notes (EN)
Treat token refresh as part of the auth contract, not as a generic 401 reaction.
Bilješke (HR)
Tretiraj token refresh kao dio auth contracta, a ne kao genericku reakciju na 401.
Exceptions / Tradeoffs (EN)
If the product intentionally centralizes 401 recovery through a shared retry system, document that convention and apply it consistently.
Iznimke / Tradeoffi (HR)
Ako proizvod namjerno centralizira 401 recovery kroz shared retry sustav, dokumentiraj tu konvenciju i primjenjuj je konzistentno.