Hey folks, over at Darklang we’re starting to put some effort into improving and redefining the fundamentals of our Rescript app, which uses the Elm Architecture rather than React. I’m currently looking at bringing bucklescript-tea up to date and porting over some MVU best practices ([1, 2]), based on some good stuff happening in the Fable and Elm communities.
Anyone else working on MVU/Elm Architecture in Rescript? Would love to hear about what others are working on in this space.
Yes. ReScript ecosystem is sorely missing an idiomatic TEA implementation.
bucklescript-tea looks to be the closest to being portable, but the author isn’t active anymore.
react + redux + redux-loop (the much better, but obscure alternative to the popular saga, thunk, etc., which also fills in the parts of TEA missing from redux) is too verbose. And over all, I am not a fan of being hammered with “use local state for form inputs, then sync it with redux, so now you have 3 places to sync”. This whole problem stems from React’s decision to use oninput behind its onChange API.
I have gotten by with (partial) ReScript bindings to Hyperapp (https://github.com/jorgebucaran/hyperapp), the only JavaScript library true to TEA. It treats input.onchange as input.onchange, thus seamlessly allowing storing a form in its appState. Its also true to the TEA’s declarative side-effects approach, which redux bungles. While it works, its too JavaScripty. For example, it merges the concepts of Msg + update functions into several Action functions, in order to be more JS-friendly. Anyway, here are the unpublished, unpolished bindings: Rescript bindings to Hyperapp · GitHub
There is of course ocaml-vdom from the ocaml + jsoo ecosystem.
That’s all I have.
I imagine that a pure ReScript implementation would need its own vdom implementation too. You might either be able to get by with Hyperapp’s efficient vdom implementation or get inspiration from it.
bucklescript-tea has a very efficient vdom implementation already, so not worried about that. More I’m curious what other people are working on and what libraries they’re using and building. Thanks for the answer!
i would like to use rescript fully for my startup as well, but being tied to react is downside for me at least (by no mean react is bad, just i don’t use react anymore). for now we just use rescript for sveltekit server side logic. kinda wish that svelte have preprocess for rescript.
love to see TEA implemented in rescript (with active maintainers of course 
)
There is framework in F# ecosystem that inspired by svelte (doesn’t have Virtual DOM) and use TEA:
Good to hear about this effort. One thing I want is for cmd and navkey to not be opaque types in elm, so that elm-program-test doesn’t have contort itself around those issues (and the standard advice is not use browser tests, we haven’t addressed integration testing yet)
I am in Elm camp for now. Might head to gren or gleam if they take off.
Some other things to consider when planning/surveying work outside of ReScript: