Hugs
mount_hug(definition, options) is the easy path for a hug’s page: it connects to the host, keeps the answer,
checks it with the definition on every change, and draws your edit or view. The options are listed in
Defining a hug; this page is about using them.
Where the answer starts
When the page opens in answer mode, the answer is the first of:- the person’s draft — what they had typed, a first answer or a change to one, before reloading the page. The host keeps it (not the frame) in that browser tab only, until they submit, cancel the change, or the Hug ends; closing the tab drops it;
- their earlier answer (
mine) — when they chose Change answer; initial(params)— or{}.
initial is merged as a partial answer, so return only what has a sensible default:
Changing the answer
set(path, value) changes one part. Paths use dots and brackets, and missing objects and arrays along the way are
created:
replace(value) swaps in a whole answer. Use it when the answer takes different shapes — approve or reject, an
answer or Can’t answer — so nothing from the other shape is left behind:
set or replace, mount_hug checks the answer, tells the host whether it is valid (Submit is enabled
only then), its problems, the Submit label and the summary — and redraws.
Conditional fields
edit redraws on every change, so a field that depends on another is a plain condition. Keep the same rule in the
definition, so an answer that skips the page is checked too, and clear a field when you hide it:
Problems
problems maps each path to its first problem ('' for the answer as a whole); problem_list has them all. Show a
field’s problem next to it — the kit’s .problem does — and anything without a field at the top or bottom:
refine / superRefine issues
(path: [i, 'note'] becomes verdicts[1].note).
The Submit button
The Hub draws Submit, not the page.submit chooses its label, from the answer if you like, and its tone:
submit, it says “Submit”.
The view
After the person answers — and for everyone else’s answers, and once the Hug has ended — the page draws an answer read-only. Withoutview, mount_hug draws one from the definition: each field’s label (.describe(), else the
key humanized), with booleans, numbers and dates formatted for the viewer’s locale, form’s choices by their labels,
lists as lists, and file fields as attachments. Write view when the answer reads better another way:
answer is the answer being shown, with responder and responded_at. Every hug must draw view mode; check yours
with cliq hug dev --view answer.json.
Errors
- Bad params (they don’t fit the definition) show an error panel listing why, instead of the editor — the Hug was opened wrongly, and nothing the person does can fix it.
- An error thrown in
editorviewshows an error panel too, and is logged to the console (and tocliq hug dev’s panel).
Anything else
edit receives hug, the runtime API, for what mount_hug doesn’t do: read an
attachment’s bytes (hug.read_file), open a link (hug.open_link), react to progress (hug.on('update', …)).
Something edit reads outside the answer changed — a filter, a selection? Call mounted.redraw() (see the
triage-list example, which keeps its filters and selection outside the answer).
html
html is lit-html:
Don’t build HTML strings —
html escapes values, and strings wouldn’t be.