I defined the actions a little differently and followed the rescript-react pattern of having effects return an Option of a cleanup fn but most of the idea is there.
Really the only jump you need from react to the elm architecture is having the reducer be (State, Action) -> ('State, Effects) instead of simply returning the new state alone. The then you have a useEffect that invokes the side effect fns, passing in dispatch so they can send updates back to the reducer & so reducer stays pure. There are a bunch of different ways to set that up, and honestly a lot of react apps blunder into an accidental and incomplete version of this anyway it's such a natural model.
How has your experience been with runtime errors? One of the things I like about Elm is that for pure Elm code, there's very little surface area where a runtime error can occur.
For pure rescript code it's pretty much as reliable as elm.
The only time I've really seen them is when interacting with js/ts code. The rescript externals system is easier and more flexible than elm ports, but for that reason less safe.
If you don't model the types of incoming data exactly it can cause runtime errors. For some packages it's very difficult to do that with high confidence so I've seen a few leak in. Similarly if you use gentype to map typescript types to rescript, it assumes the types are both correct and sound. Which are not actually guarantees typescript makes I don't think. So I've seen some from that as well.
Rescript doesn't really do a great job at displaying these types of errors either. It's usually pretty obvious where they came from but not always why unless you have good knowledge of the API you're hooking to. So, rare but anomalously frustrating in an otherwise very pleasant language.
I think for this reason it's pretty standard to avoid writing or consuming package-wide bindings to npm modules. It seems like everyone is just writing tuned limited externals only for the parts they actually use, except for a handful of very popular libraries.
