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).
Classify backend fields by contract scope
For every backend field, decide whether it belongs in response only, create payload, update payload, or nowhere in the frontend contract.
Bad example
| 1 | export interface PortfolioDividend { |
| 2 | id: number; |
| 3 | source: string; |
| 4 | notes: string; |
| 5 | amount: number; |
| 6 | } |
| 7 |
|
| 8 | export interface CreatePortfolioDividendPayload { |
| 9 | source?: string; |
| 10 | notes?: string; |
| 11 | amount: number; |
| 12 | } |
| 13 |
|
| 14 | export interface UpdatePortfolioDividendPayload { |
| 15 | source?: string; |
| 16 | notes?: string; |
| 17 | amount: number; |
| 18 | } |
Explanation (EN)
The frontend copies response fields into create and update payloads without deciding whether the UI actually owns them. That creates bloated write contracts and unnecessary validation work.
Objašnjenje (HR)
Frontend kopira response polja u create i update payload bez odluke posjeduje li ih UI stvarno. To stvara napuhane write contracte i nepotreban validation posao.
Good example
| 1 | export interface PortfolioDividend { |
| 2 | id: number; |
| 3 | source: string; |
| 4 | notes: string; |
| 5 | amount: number; |
| 6 | } |
| 7 |
|
| 8 | export interface CreatePortfolioDividendPayload { |
| 9 | amount: number; |
| 10 | exDate: string; |
| 11 | payDate: string; |
| 12 | instrumentId: number; |
| 13 | } |
| 14 |
|
| 15 | export interface UpdatePortfolioDividendPayload { |
| 16 | amount: number; |
| 17 | exDate: string; |
| 18 | payDate: string; |
| 19 | } |
Explanation (EN)
Response models stay complete, while write payloads contain only fields the current UI can legitimately send. Each field is placed in the narrowest contract that matches its ownership.
Objašnjenje (HR)
Response modeli ostaju potpuni, dok write payloadi sadrze samo polja koja trenutni UI legitimno moze slati. Svako polje je smjesteno u najuzi contract koji odgovara njegovom ownershipu.
Notes (EN)
Use this decision order for every new backend field: response only, create only, update only, create and update, or not in frontend contracts at all.
Bilješke (HR)
Koristi ovaj redoslijed odluke za svako novo backend polje: samo response, samo create, samo update, create i update, ili uopce ne u frontend contractima.
Exceptions / Tradeoffs (EN)
Mirrored create and update payloads are acceptable when the UI truly owns the same field set in both flows and that symmetry reduces complexity.
Iznimke / Tradeoffi (HR)
Zrcalni create i update payloadi su prihvatljivi kada UI stvarno posjeduje isti skup polja u oba flowa i ta simetrija smanjuje slozenost.