Closed InsomniacFury closed 8 years ago
Appreciate the suggestion, but one of the design goals for seamless-immutable is to free yourself from worrying about whether anything you pass to Immutable
will be mutated; it simply won't be. The production build being "all or nothing" means you should only use it when you're confident enforcement wouldn't have done anything anyway.
This change would make it so you'd instead have to start thinking about when enforcement applied on a case-by-case basis, and avoiding that is important to me.
Thanks for the idea, but I'm not open to changing the current behavior on this. :smile:
Cool, thanks for your consideration.
From what I can tell the only difference between development and production is
I think it would be less confusing to produce 1 set of artifacts, i.e.
where the constructor for immutable would effectively flag that behavior, e.g. whether to enforce immutability. Ideally avoiding the need for something like https://github.com/rtfeldman/seamless-immutable/pull/86 to clarify up front.
I would propose similar to merge(),
This would be backwards compatible interface-wise. The default value of
enforceImmutablity
is up for debate, but I would suggest it be true, so that anyone who is concerned about performance can specifically make the call. Or if performance is only a concern on a specific browser then that flag can be dynamically set based on user agent or something to that effect.Thoughts?