proposal.re

reducer: {
  | Edit => (state) => ReasonReact.Update({...state, editText: todo.title})
  | Submit => submitHelper
  | Change(text) => 
    (state) =>
      editing ?
        ReasonReact.Update({...state, editText: text}) :
        ReasonReact.NoUpdate
  | KeyDown(27) =>
    /* escape key */
    onCancel();
    (state) => ReasonReact.Update({...state, editText: todo.title})
  | KeyDown(13) =>
    /* enter key */
    submitHelper
  | KeyDown(_) => state => ReasonReact.NoUpdate
}

proposalExtra.re

/* swap ordering */
| KeyDown(_) => ReasonReact.NoUpdate
| Change(text) => editing ? ReasonReact.Update(state => {...state, editText: text}) : ReasonReact.NoUpdate

Still mentally absorbing this proposal.

I had an unrelated observation about your syntax:
If { | ... } is a syntax for lambda that matches its argument, then:

expression |> {
| Case =>
| Case =>
};

Is semantically equivalent to:

switch expression {
| Case =>
| Case =>
};

They wouldn't parse to the same AST unless we put effort into it - and we could put effort into it. (In the same pass that we special case |> to be parsed as function application).

The general proposal sounds cool. I think it allocates more closures though. Luckily, it might only be one additional closure at the time the event occurs. Even if there's ten cases, each allocates another closure, I think we'll only allocate on upon a match occuring.

One downside: It's a lot more typing out of lambdas. I think it would increase the demand for a lighter weight way to register event handlers like:

<div onClick=self.reduceAction />

Just to avoid lambda fatigue.

There's ways to do that but it's a fairly invasive change.