I would definitely love to have support for preact to reduce my bundle size and improving performance. In the vast majority of cases I can use it as a drop in replacement, and even when using react itself preact signals are almost always a better abstraction than react hooks and contexts.
Okay, what do you do to make it alias in Rescripts build system? Is there some config file where you tell it to grab Preact instead of react ? I’m looking at the interop between rescript and javascript build systems right now.
Yes, I am familiar with that, thank you. I am asking about the rescript side of things. Assume Vite/Webpack if it makes the question specific enough.
Does setting up aliases in webpack make rescript just automatically import the aliased library? Does rescript integrate easily with webpack? Or is that the wrong question to ask because rescript happens to cover something without involving the build system? Etc etc
The point of setting up aliases is that it should ‘just work’ without any other effort. So it may be worth your while to just try it out and report your findings.
I haven’t tried it with webpack, but I have used rescript + preact with vite as the build system using the aliases as described in the preact docs. It was just a toy project, not production, but it seemed to work fine.
I’m using ReScript 11.1+ and just started a project through create-rescript-app but I want to switch to Preact over React but not sure where to start yet. Anyone have an example or guidance?
You can copy those over to your project and set the JSX module to “preact”. As for getting started with swapping over you should be able to follow the Preact getting started guid: Getting Started – Preact Guide
My mistake, should have checked the timestamps. Probably wouldn’t hurt for me to compare against yours and see if anything is different.
As for Signals, I did see that but it seemed aimed at a react specific version and wasn’t feeling the way it was organized. Plus I wanted to relearn how to create bindings, which helped me understand the Signal APIs better
I 100% prefer to write my own bindings. I also feel like it helps me understand the source library better, and I get to come up with a solution that matches how I want to use it.
Totally fair! I got the mutable version working, but figured it wouldn’t hurt to have a get and set function to play nicely with the chaining → operator.
I did get those working with:
@set external set: (t<'a>, 'a) => unit = "value"
@get external get: (t<'a>) => 'a = "value"
@send external peek: t<'a> => 'a = "peek"