I think we set Params fields to read-only when possible.

Why not pass the whole InputState? Is there a use case where these wouldn't come from the same InputState object?

https://phab.comm.dev/D5718?id=18817#inline-38200

In linked diff the comment mention props that have to be read-only (one of React principles), but do why do we need to do it in utility functions, if everything is passed by value (and not by reference) anyway. It feels like a good practice, so we don't accidentally reuse param as variable inside of function, but is there more meaning to it?

Return value is memoized later on and there's a lot of stuff in InputState. I had some problems with infinite rerender loops, when a lot of things depended on entire InputState, changed other part of it and then recalculated. That's why I decided to only depend on parts of InputState function really uses

The more precise your types, the more type errors you catch. We want to encourage developers to not only answer the question of what properties an object has, but to also answer the question of whether those properties are read-only or not

We default to $ReadOnly because that's more narrow, and only make things non-$ReadOnly if we need to. It's the same reason more JS defaults to const

I see, thank you for explaining!

SetState feels fine, but in input-state.js we're not using it at all. What convention should we use than?

+setDraft: (draft: string) => void,
+setTextCursorPosition: (newPosition: number) => void,
+setTypeaheadState: ($Shape<TypeaheadState>) => void,