Map returns an Immutable object
See original GitHub issueI don’t really understand why .map is wrapped to return an Immutable object. This seems needlessly restricting. In combination with #16, this also causes unexpected stack overflow errors.
Immutable([1,2,3]).map(function() {
return React.createElement( "div", null );
});
// too much recursion
Issue Analytics
- State:
- Created 8 years ago
- Reactions:1
- Comments:7 (2 by maintainers)
Top Results From Across the Web
Map - Immutable.js
Returns a new Map also containing the new key, value pair. If an equivalent key already exists in this Map, it will be...
Read more >Is it better to return an ImmutableMap or a Map? - Stack Overflow
Immutable Map is a type of Map. So leaving the return type of Map is okay. To ensure that the users do not...
Read more >Immutable Map Implementations in Java | Baeldung
Using copyOf() Method. First, let's use the ImmutableMap.copyOf() method that returns a copy of all the entries as in the original map:
Read more >3 Creating Immutable Lists, Sets, and Maps - Oracle Help Center
Convenience static factory methods on the List, Set, and Map interfaces, which were added in JDK 9, let you easily create immutable lists,...
Read more >Immutable Map in Java - GeeksforGeeks
ImmutableMap, as suggested by the name, is a type of Map which is immutable. · If any attempt made to add, delete and...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
map
does indeed return a collection of elements which may be completely unrelated to the original elements. However,map
is still supposed to return the same type of collection you began with. If you call[].map
you get back an Array, if you call$().map
you get back a jQuery object, and if you callImmutable([]).map
, you get back aseamless-immutable
array. This is the standardmap
behavior.I sympathize with the fact that this
map
implementation doesn’t work with React components, because I useseamless-immutable
with React and find it annoying that this doesn’t Just Work. I manage this annoyance by using_.map
when it finally comes time to turn myseamless-immutable
arrays into React components, but naturally it would be less trouble in this particular use case if I didn’t have to.That said, I don’t think it makes sense to couple this library to React, and I don’t see a strong case for changing
map
on its own merits. When libraries start developing implicit dependencies on other libraries, unexpected consequences tend to snowball into unpleasant surprises. I value the simplicity and consistency of this library, and hope to maintain it.As such, I appreciate your perspective, but the current design still makes the most sense to me overall. 😃
This is by design. One of the invariants of the library is that once you invoke
Immutable
, what you get back is immutable, and continuing to use its methods will only yield further immutable results.However, since you can pass
seamless-immutable
’s data structures to other JS libraries, if you really want a mutable copy back, you can just pass them to other libraries that are not designed for immutability.For example: