Cannot change results order/sort in reducer

[SachaG]

When I re-sort a list of results in a query reducer (for example, the list could be organized alphabetically and one of the item names just changed), it doesn't seem like the new sort gets propagated through to the UI, or even to the store (although any modifications to documents within the list do get propagated correctly).

Has anybody else observed a similar issue? Or should I assume the problem is coming from my side of things?

[wmertens]

You should always create new objects when you change props. E.g. return [...oldArray].sort(etc)

[SachaG]

@wmertens oh that totally worked, thanks so much!

I still think it's worth asking if apollo-client should create new objects itself behind the scenes, to avoid that issue? Or else maybe just highlight it in the docs?

[helfer]

@SachaG we were thinking about using deep freeze in development mode to make sure objects aren't changed accidentally.

[wmertens]

Deep freezing objects comes at a performance cost in Safari, and cloning objects has a cost in all browsers. I much prefer no magic behind the scenes.

…

On Mon, Dec 19, 2016 at 4:47 AM Jonas Helfer ***@***.***> wrote: @SachaG <https://github.com/SachaG> we were thinking about using deep freeze in development mode to make sure objects aren't changed accidentally. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1057 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWlgwP_vN1yyRcB5Ia-V_jctqU8VkQks5rJf5ugaJpZM4LQFS_> .

[SachaG]

I guess we need to weigh the performance cost vs the lost developer productivity if this turns out to be an issue people frequently run into. Personally I like a little magic :)

[helfer]

@wmertens I think it's a reasonable tradeoff to use it in development mode where performance isn't quite as important. The potential time savings of not having to track down accidental modifications are worth the limited overhead, especially considering that in production you don't have to pay that price.

[wmertens]

Yes, agreed, in development it's a useful feature.

…

On Mon, Dec 19, 2016 at 10:36 AM Jonas Helfer ***@***.***> wrote: @wmertens <https://github.com/wmertens> I think it's a reasonable tradeoff to use it in development mode where performance isn't quite as important. The potential time savings of not having to track down accidental modifications are worth the limited overhead, especially considering that in production you don't have to pay that price. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1057 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWljNRLav_3TUPPb49JAX4k-sJe5BKks5rJlAWgaJpZM4LQFS_> .

[helfer]

@SachaG Thanks for bringing it up! I think I'll close this issue since we're already tracking it on the roadmap.