Hacker News Reader

Comment by giraffe_lady | Hacker News Reader

I was also using it for these reasons up to about 10 months ago. I've switched to rescript now because it still addresses most of these, while being a lot closer to the mainstream of frontend programming.

Rescript does piggyback on normal JS ecosystem and build systems so comes out worse there. But it's easier to integrate with existing js codebases and npm packages for the same reason, and its output can be used from js in any framework if you plan for it.

I was really missing the elm command/update model for a while but at some point I realized adding that semantics to a react reducer with a custom hook was completely reasonable, and there are a couple existing projects doing exactly that. I wrote my own in an afternoon and have been copying it around to new projects since.

I'm like 90% happy with this transition now. It doesn't always feel quite as safe & magical as elm did, but it's also a lot easier to integrate with other systems.

View on HN

Interesting, got any repos written in this style?

Not that I can share unfortunately. But here is the implementation I got the idea from. https://github.com/mjal/rescript-use-tea/blob/master/src/Use...

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.

Looking around just now I also found this PoC of someone doing a very similar thing but all inline with react. https://github.com/mishaszu/rescript-model-view-poc/tree/mai...

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.

Reply on news.ycombinator.com