i hadn't really thought about it in a deliberate way but something i see about React is that useState is both about time and type erasure. consider a tree of elements in an elm-like system... the state contains and therefore references the types of, every internal state that the ui contains. these can't be erased but you can use various methods to contain the inner states so that the whole system can view them in an abstract way. you could still do that in react, holding all the state at the root component and having each component delegate rendering using part of it. there's no delegation of state update in this scenario... you'll ultimately have a setter or some setters originate from the top level and be called from satellite components. the elm architecture is this if the number of setters is 1 and the function passed down is a message handler that calls the state setter rather than the state setter itself. in elm each component modifies the whole state. in react you can choose to obscure the @react.component let make = (~central, ~updateCentral) => { let (derived, setDerived) = React.useState(() => "hi " + central.text); <div> <div>{central.text->React.string}</div> <div>{derived->React.string}</div> ... </div> } The first div renders whatever the parent component decides and updateCentral allows this component to ask to change it. That's more elm-like. The second one starts with a value based on the "central" value but it's type and value are hidden (and persistent) for as long as rerenders of this component are mounted to the same parent with the same key (this is a magical bit in react). both subsequent values of derived and the type of derived are not visible in the parent. i hadn't though of this as a deliberate choice in this way before, but both the types used in the component interface and the live visibility of the edited value matter to this choice.