@mittwald/flow-react-components 1.2.0-next.31 → 1.2.0-next.33

package/AGENTS.md

@@ -158,6 +158,15 @@ Remote generation details:
   output, because the host has to call it: that needs an eager slot or
   `@flr-ignore-props`. `checkSerializableProps` **fails generation** on any such
   prop, so a new one cannot ship.
+- **A function property's return value is a Promise on the host.** Functions do
+  cross — as thread proxies — but calling one is a round trip. Type the return
+  as `Promise<T> | T` and await it on the host (`ChartTooltip`'s formatters), or
+  keep the prop off the remote surface with `@flr-ignore-props` (`XAxis`/`YAxis`
+  `tickFormatter`). A host that reads the result synchronously gets the Promise
+  itself — recharts concatenated it into every tick as `[object Promise]`.
+  `checkSerializableProps` fails generation on a new one; the pre-existing set
+  is listed in `acknowledgedValueReturningProps`, which can neither grow nor go
+  stale.
 - `@flr-ignore-props` excludes props that must not cross the remote boundary —
   either because they cannot be serialized, or because they could do **too much
   on the host side**. A global ignore list lives in

package/MIGRATION.md

@@ -1011,18 +1011,39 @@ Only function **references** are affected. An inline arrow
 (`onAction={() => …}`), a zero-parameter function, and anything already
 accepting `unknown` are all fine.
 
-A codemod renames the prop. It deliberately does not wrap: whether the
-referenced function declares a parameter cannot be decided from the source —
-that needs type information — and wrapping everything would silently drop the
-arguments `Action` passes to handlers that do accept them.
+A codemod renames the prop and wraps the reference.
+
+Whether a reference _needs_ wrapping is not decidable from the source — that
+needs type information. Performing the wrap does not need it: `() => fn()` calls
+what `Action` would have called, and `onAction` takes no arguments. So the wrap
+fixes the reference that needed it and changes nothing for the rest, which makes
+the decision unnecessary.
+
+Wrapped: a plain identifier and a member expression (`close`,
+`controller.close`, `this.handleSave`). Left alone: an arrow function and a
+function expression, which already are the handler; a call (`makeHandler()`,
+`close.bind(controller)`), which produces it; and anything that is not one
+reference (`isOpen ? close : open`, `onClose ?? noop`, `controller?.close`).
+
+Two wraps are worth a look afterwards. A handler that read the event `Action`
+forwards — undocumented, but it does forward the trigger's event — stops
+receiving it. And `onAction={props.onAction}`, where the reference may be
+`undefined`: passing it was fine, calling it is not, so TypeScript now reports
+the call and wants a guard.
 
 **Apply:** Rename the `action` prop on `Action` to `onAction`. Not only a
 rename: the new prop is typed `ActionFn` (`(...args: unknown[]) => unknown`), so
 a function _reference_ that declares a parameter no longer type-checks and needs
 wrapping — `onAction={() => controller.close()}` rather than
-`onAction={controller.close}`. Check every site where you passed a reference
-rather than an inline arrow; the codemod renames the prop but cannot decide this
-one from the source.
+`onAction={controller.close}`. A codemod does both. It wraps every bare
+reference (`close`, `controller.close`), because the wrap is a no-op for a
+reference that did not need it. It leaves a value that already is the handler or
+produces one — an arrow function, a function expression, a call like
+`makeHandler()` or `close.bind(controller)` — and anything that is not one
+reference, such as `isOpen ? close : open` or `controller?.close`. Two wraps to
+look at afterwards: a handler that read the event `Action` forwards stops
+receiving it, and a possibly-undefined reference (`onAction={props.onAction}`)
+becomes a call TypeScript rejects — add the guard it asks for.
 
 ```shell
 npx @mittwald/flow-codemods@latest action-prop-to-on-action src