A client request is not complete when Python finds a callable. Reliable code waits for the right owner, verifies current eligibility, submits through the native request layer, observes synchronized client state, and stops cleanly when context changes.
Classify the action
Separate local presentation, local persistence, and server-changing requests.
Use native processors
Reuse the client’s validation, response, and message contracts instead of bypassing them.
Verify observable state
A successful response and a synchronized inventory update are related but distinct facts.
Classify the action before implementing it
Every feature should state which layer it changes. This determines the required owner, lifetime, error handling, and user messaging.
| Action class | Examples | Required evidence |
|---|---|---|
| Presentation-only | Show a panel, decorate a card, play a local sound. | The target view exists and the mod owns the visual. |
| Local state | Save a preference, cache a confirmed snapshot, remember a pending selection. | The schema is valid and the ownership boundary is explicit. |
| Server-changing request | Submit a native request whose accepted result changes account, inventory, queue, or other server-owned state. | The correct account/controller is ready, the action is currently legal, and the native request path is known. |
Presentation state is not a server request
Some features intentionally alter only a local view model, badge, panel, counter, or result presentation. Keep that path visibly separate from any native processor or server-changing command. A presentation-only feature may make the UI easier to read, but it must not imply that the account inventory, rewards, prebattle state, or battle-result records changed on the server.
- Name the code path and user-facing message so it is clear whether it is local-only or server-changing.
- Do not call the native apply/request method from a view-model refresh hook unless the user action explicitly requires a server change and all request gates pass.
- When a local click is swallowed for presentation reasons, update only owned local state and fire only the UI events needed to repaint that view.
- Scope local presentation state by the same identity the view uses, such as account, arena, result, route, or view generation.
Read by topic
Choose a focused chapter. Complete examples and reference details are preserved on their topic pages.