Do you need immer-like library bindings in ReScript?

1

I’ve just got an idea how to make immer work with ReScript, are there people who need it?
The API can be something like this:

type subState = {
  prop1: int
}
type state = {
  sub: subState
}

let state = {
    sub: {
        prop1: 1
    }
}

let newState = state->produce((draft) => {
    draft->Mutate.set(d => d.sub.prop2, draft.sub.prop2 + 1)
})
1 Like
2

I don’t know. AFAIK, Immer was born out of Michel Westrate’s frustration with verbosity of immutable assignment in JS, so he wanted to turn { ...obj, sub: { ...obj.sub, prop2: obj.sub.prop2 + 1} } into obj.sub.prop2++.

So far, I’m not sure that your example achieves the terseness of JS.

P.S., also, updating seriously nested structures could be a sign of bad decomposition, so something Immer-like could potentially lead to a worse architecture :grin:

1 Like
3

Not using CoW, but there is an immutable collections library I maintain, more suitable for functional manner

2 Likes
4

Yes…dealing with deeply nested records is very annoying (and in OCaml too).

In OCaml at least you can use a lens library (eg this or this), but with ReScript not having the custom infix operators, something like that would also be sort or tedious to use (imo).

^ That’s a fair point. Though, even if you hide the deeply nested record behind an abstract type, so that consumers don’t have to worry about it, some lens-like library, or immer-like library could still be cool for dealing with that nested-messiness internally.

5

If there is a way to convert immutable record types to mutable ones, then should be straightforward to correctly type immer’s produce function

type person = {
  name: string,
  age: int
}
// converts to
type person = {
  mutable name: string,
  mutable age: int
}