Closed tleunen closed 8 years ago
I considered it, but I don't think this makes sense from a design perspective.
I think it's important that the contents of a seamless-immutable value be actually immutable unless there are extremely good reasons for them not to be. The more exceptions to that rule that exist (currently Dates, functions, and React components - all for specific practical reasons that come up very often), the harder debugging gets.
Considering almost everyone either uses Immutable.js or seamless-immutable, not both at once, I don't think this comes up anywhere near enough to justify special-casing.
Thanks for bringing it up though!
In my use case, I'm using both Immutable.js and seamless-immutable, because I'm using Draft.js, which use Immutable.js but in the rest of my application uses seamless-immutable.
I was able to prevent seamless-immutable to change the immutable.js structure by adding a __immutable_invariants_hold
property and a asMutable
function on my object but this is a very hacky solution.
In a more general case though, what is the best way to add "complex" objects (in opposite of plain objects) in a seamless-immutable structure? I agree an immutable structure should be plain objects only but sometimes I have to put a complex object in there :/
I'm also working with Draft.js and have the same issue!
I wonder if a solution to #142 might be able to accomodate this use case too, via a slight API tweak.
Seamless immutable is trying to transform an immutable.js object when the state is merged/updated.
Would it be possible to add a condition to not touch any immutable.js objects?