A target is the named action a surface can request. Good targets read like product verbs, accept small payloads, and return a shape the surface can render.
The customer dashboard has anArchive button. The target should be customers.archive, not a generic doThing command with a hidden action string.Name
Name the action around the user’s intent.
→
Payload
Pass only what the target needs to do the work.
→
Reply
Return enough for the surface to show success or failure.
Naming rule
Use a name that tells the caller what business action is being requested.| Good | Bad | Why |
|---|---|---|
customers.archive | customers.command | The good name says the exact action |
rooms.join | roomMutation | The good name is a product verb |
invoice.send | runWorkflow | The good name does not hide intent in payload |
Payload rule
The payload should be narrow and explicit. It should carry identity and user intent, not a second command language.Reply rule
Return a result the surface can use.| Reply field | Purpose |
|---|---|
ok | Lets the surface show success or failure |
message | Lets the surface show human-readable feedback |
| product id fields | Lets the surface reconcile the specific item |
| next read name | Optional pointer to the named data read that should refresh |
Common failures
| Symptom | Cause | Fix |
|---|---|---|
| Every button calls the same target | The target is hiding many actions behind one generic action name | Split targets by product action |
| Payloads keep growing | The target boundary is too vague | Name the target more narrowly |
| The surface cannot show result | Reply shape is not renderable | Return ok, message, and product ids |
| The target imports screen placement rules | Action and layout are tangled | Keep placement in shell/surface descriptor |