Hi folks!
I’ve started working on some Remix bindings
5 Likes
I’ve created issues for all of the missing bindings, feel free to contribute if you find this useful
https://github.com/tom-sherman/remix-rescript-example/issues
I’m also thinking about how to make this as useful as possible, right now I see two approaches:
- Publish Remix bindings to npm, with companion docs on how to integrate it into a Remix app.
- Use a repo-template approach a la https://github.com/ryyppy/rescript-nextjs-template
@ryyppy Would love to hear your thoughts about the best direction to take here!
1 Like
IMO the best approach is publishing the bindings to npm 
3 Likes
Obviously I am biased and tend to the repo-template approach.
I did that specifically for NextJS, because I know that my needs are oftentimes more nuanced, and other users may want to modify them for their use-cases without jumping hoops forking my repo and do this weird egg-dance of vendoring npm deps.
Encouraging copy-paste for these kind of bindings is not a bad thing. Your Remix.res file currently counts 74 lines.
1 Like
Thanks for your insight! I hadn’t thought about the “number of lines” heuristic up until now, I agree that vendoring is a sound approach here. The bulk of the setup is going to be outside of the bindings it seems, and so a template probably works best.
…until Remix supports ReScript officially and via npx create-remix that is 
This is great! I’ve been meaning to do this myself and write a full set of bindings since they’ve hit 1.0