Open suni-masuno opened 7 years ago
I second this. I don't care if the function is called sort
or sorted
or whatever but we need this.
We could also add sortBy('name')
and sortBy(item => item.name)
helpers ; or it may be beyond the scope of this library.
👍 to adding Immutable.sortBy
(statically, not as an override - I want to preserve the "don't surprisingly change mutable methods to be non-mutating" behavior) if anyone wants to make a PR!
I've had a crack at this in #211
Any update on this? Came looking for sorting and found this. @LukeusMaximus PR seems to be stuck on a broken Travis build.
+1 here - just ran into the need for sorting. An immutable sort replacement would be a good solution and I believe sort is enough of a required feature.
Any progress on this?
Any progress on this (more than half a year later)?
I'm looking for this issue.
I had an issue regarding the sort method cannot be invoked on an immutable data structure
while working on a react-native project.
Here's my workaround on this issue is below:
import Immutable from 'seamless-immutable'; // Existing [].sort(comparator function)
// Change into Immutable.asMutable([]).sort(comparator function)
Can you sort a seamless-immutable array yet?
I'm using seamless in a substantial production project (and loving it by the way) and we are consistently struggling with one minor annoyance, .sort()
My daydream scenario is an override on any immutable array that gives me .sort() that does not mutate and returns an immutable copy, like map, filter, and reduce appear to do. But I'm open if there's a different preferred solution.
Right now we find ourselves using either
[].concat(functionChain).sort(comparator)
for when we MIGHT be immutable (IE when we're first wiring together some stuff) andfunctionChain.asMutabe().sort(comparator)
for when we know we are.This is working ok, so it isn't too urgent, but an override feels like it would be very elegant and result in much more readable and portable code. It also seems a little more 'seamless' ^_^
EDIT: I might note that I understand why it currently throws the error it does, and perhaps a seamless version of sort should be put under a different name, allowing the old mutating method to continue throwing an error. I think there may be some reasonable debate there and I'm not overly committed to either side.