Consider replacing immutableJs with immer

Do you want to request a feature or report a bug?

infrastructure change, continuing discussion in #2153

What’s the current behavior?

Currently immutable.js is used in slate models, which has some serious disadvantages compared to immer:

• ImmutableJS requires learning new API, which is problematic especially for Slate users who didnt use immutableJS in the past
• ImmutableJS is much bigger library, around 15kb compared to Immer 4kb
• ImmutableJS objects introduces new data structures, which need to be converted to native JS objects, which is bad for performance and also forces developers to pay attention whether a given object is Immutable wrapper or not, while with Immer no conversion is necessary - you work with native JS data structures always.

What’s the expected behavior?

After switching to Immer, suddenly Slate would be much easier to use for people especially not knowing how to work with ImmutableJS. Also performance should be better as no objects convertion from and to ImmutableJS would be needed anymore.

[ianstormtaylor]

@steida thanks for the input.

This functional typed API thing is probably a little bit confusing for you. I can see because of how Slate is written. Don’t get me wrong, Slate is excellent. But it’s old school OOP. I would love to have a pure and typed functional Slate API. No instance methods, no classes. Just objects, types, and pure edit helpers. Much easier to write, maintain, learn, and use.

I understand functional APIs, sorry for the confusion. I was originally questioning whether moving to Immer would not involve switching to a functional API, but it sounds like it mostly would, and that would be where the big gains are anyways. So now this issue for me has changed from “could we switch to Immer” to “would a functional API work for us”.

When I say that those parts of the API are still a “question” I’m more concerned about the UX of the potential functional API. The “much easier to write, maintain, learn and use” is just your opinion. It depends on what the API is for—there are definitely APIs that are “functional” and “pure” that end up harder to use because of it.

I’m more curious about what the functional API would end up looking like in end-user code.

If people are using the instance methods and getters on the current Slate models heavily, I can see it being a lot more cumbersome to use a functional version of the API. The “pipeline” operator would help things here, but it’s not something we can use easily yet. If we only ever used TypeScript that would help too, but that’s not something I want to mandate.

That said, the potential benefit of using native JavaScript data structures, and not having any serialize/deserialize steps is hugely appealing, which is why I’ve left this open, so that others can prove out this idea if they’d like to see it in core.

If anyone wants to see this happen, please provide code snippets for API design/architecture ideas that make it easier to visualize how these pieces will fit together. And then from there we can decide whether the tradeoffs are worth it.

[ianstormtaylor]

I’ve commented in the immer repo to hopefully figure out some of those remaining questions, so that we can make an informed decision!

(This is just to feel out what the true pros/cons are. Of course there are other implications since this would be a huge change to the API regardless, so it would require more discussion about its worth.)