Open nikparo opened 4 years ago
Hm, I don't see the value of this. If the library isn't using these things then it shouldn't have to care about them. As far as version compatibility, if the user is going to break the abstraction and use immer
functionality directly, it's incumbent on them to ensure that a consistent version of immer
is used across the whole app; bundling 2 different versions would be undesirable in any case.
The value for us was mainly in exporting original
. We have a very large reducer maintaining the state of an editor. Some callbacks would warrant the previous content (held in the state) to be pushed to a history array for undo / redo. However, to make sure nothing had been changed during the call it would have been nice to push original(draft).content
. We got around it, but there are uses for them.
While bundling 2 different versions is indeed undesirable, I would rather have a bundle that is a few kilobytes larger than an app that breaks. Also, I may have multiple versions anyway since different packages may depend on different versions of immer.
Immer has multiple helper functions for working with drafts. Many of these are at least version dependant, so it would be good to expose them through
useMethods
. For example,isDraft
from immer 6.0.8 (currently the latest version) will returnfalse
for drafts created byuseMethods
.There are quite a few more methods exported by
immer
. I don't think it's a good idea to re-export everything however, as e.g.produce
would be better imported straight fromimmer
.On a side note, I had to disable prettier in order to prevent changes to unrelated parts of the code.