Composer Behavior

The message input is data now — a draft that survives a trip to Settings, an Enter-vs-Shift-Enter policy, a clamped autosize, and a send that refuses a turn in flight.

The composer is a value, not just a <textarea>: your draft survives a trip to Settings, the height grows with your text and stops before it eats the transcript, and Enter sends the right thing on the right keyboard.

Every decision lives in ui/src/composer/composer as a pure function — the field mirrors the state, the state is the source of truth.

Quick Start

1. Start from an empty composer

   import { emptyComposer, setDraft, draftOf } from "praisonai-mobile/ui/composer/composer";
   
   let state = emptyComposer();
   state = setDraft(state, "Plan my week");
   draftOf(state); // "Plan my week"

   setDraft is immutable in, immutable out — a subscriber may hold the previous state and diff against it.

2. Mirror the field to the state

   input.addEventListener("input", () => {
     composerState = setDraft(composerState, input.value);
     input.style.setProperty("height", `${heightFor(lineCountOf(input.value))}px`);
   });

   The input event copies the field into the state; the state drives the height back.

3. Decide what a key means

   import { keyAction } from "praisonai-mobile/ui/composer/composer";
   
   keyAction({ key: "Enter", shiftKey: false, altKey: false,
               ctrlKey: false, metaKey: false, isComposing: false });
   // "newline" under the default modifier-sends policy

   keyAction is pure and total — both policies and the IME case are assertable without a keyboard.

The draft survives the screen that holds it

A draft lives in ComposerState, keyed by conversation — not in the text node a route change unmounts. Navigating to Settings and back does not eat what you typed.

// ComposerState — drafts by conversation id.
export interface ComposerState {
  readonly activeId: string;
  readonly drafts: ReadonlyMap<string, string>;
}

Autosize is clamped at both ends

The composer’s height is heightFor(lineCountOf(text)) on every draft change — a floor that keeps it tappable, a ceiling that stops it eating the conversation.

import { heightFor, lineCountOf } from "praisonai-mobile/ui/composer/composer";

heightFor(lineCountOf(""));            // 52  — COMPOSER_MIN_PX floor
heightFor(lineCountOf("a\nb\nc"));     // grows one line at a time
heightFor(Number.NaN);                 // 52  — a mid-rotation NaN yields the floor

Send is disabled on an empty draft; Stop never is

The disable rule guards on the action so a streaming Stop never goes dead just because the draft happens to be empty.

// main.ts — the disable rule in publish().
sendButton.disabled = streaming ? false : draftOf(composerState).trim() === "";

The key policy

keyAction decides send, newline, or ignore from the handful of fields a key event actually turns on.

input.addEventListener("keydown", (event) => {
  const action = keyAction({
    key: event.key, shiftKey: event.shiftKey, altKey: event.altKey,
    ctrlKey: event.ctrlKey, metaKey: event.metaKey, isComposing: event.isComposing,
  });
  if (action === "send") {
    event.preventDefault();
    void submit();
  }
  // "newline" and "ignore" both let the field handle the key normally.
});

How It Works — submit is atomic

submit(state, busy) takes the draft and clears it in one call. That is what makes the second tap of a double tap a no-op: it finds an empty draft.

import { submit } from "praisonai-mobile/ui/composer/composer";

const result = submit(state, /* busy */ false);
result.sent; // "Plan my week" — trimmed
result.next; // draft cleared

const refused = submit(state, /* busy */ true);
refused.sent; // null — a turn is in flight
refused.next; // unchanged — a refused send must not eat the draft

// main.ts — the app returns without calling the controller on a refusal.
const result = submitComposer(composerState, busy);
composerState = result.next;
input.value = "";
syncComposer();
if (result.sent === null) return; // refused while a turn is in flight
await app.controller.send(result.sent);

Your message row appears when the run is issued

The user-message row is drawn when a run is actually handed to an engine (beginTurn(prompt)), not when Send is tapped. submit returning sent is the tap; the row belongs to the run that follows it.

That distinction is what keeps a stray “You said:” bubble off the screen:

See Transcript User Row → When the row appears.

Layout invariants

Three CSS rules decide whether the composer is usable on a phone, each pinned by app/src/css.test.ts.

Each of these was a measured defect, not a hypothetical. The shipping-to-stores page ties them into the wider ship path.

Best Practices

Related