v2.0 plans

[ryanashcraft]

Breaking Changes

Use latest entities state when the network request finishes for mutations

Motivation:

With redux-query 1.x, if you have simultaneous mutations that update the same entity, you could end up in with one mutation completely overwriting the changes of the other one. This is because the entities state for the update is captured before the network request starts, as opposed to when it finishes. Naturally, this has confused several people and just feels wrong.

Solution:

We'll make mutations behave more like requests when it comes to how the entities state is used when updating. transforms and updates will always be passed the latest entities state.

Breaking changes:

• Logic depending on the previous behavior will break and need to be updated.
• The returned value to the promise on mutation failures no longer include the "entities" field.
• The "entities" field in mutation failure actions has been renamed "originalEntities".

Related issues:

• "Simultaneously queries does not work properly" Simultaneously queries does not work properly #36
• "[docs] clarify difference between mutateAsync and requestAsync" [docs] clarify difference between mutateAsync and requestAsync #37
• "Possible stale store is passed into update call for mutate" Possible stale store is passed into update call for mutate #50

Change "request" field in the actions and queries reducer

Motivation:

Currently there's a bug in redux-query 1.x where the middleware is calling abort on the request instance (i.e. the superagent instance), when the intention is that it should be called on the returned value from the network adapter.

Solution:

Provide a way for external code to reference both the adapter and the underlying instance. We may or may not want to rename "request" to better reflect its purpose.

Breaking changes:

• Logic previously referencing the "request" field from the request/mutation start actions in order to get a reference to the underlying superagent instance need to be updated.

Related issues/PRs:

• "Abortion is not being performed on the controller" Abortion is not being performed on the controller #68
• "Store request controller, rather than its instance" Store request controller, rather than its instance #69

New Features

New rollback behavior and optional handler for reverting optimistic updates when mutations fail

Motivation:

With redux-query 1.x, mutation failures blindly revert the entire entities state. This shouldn't have much impact for apps that don't have many mutations going on simultaneously, but it's obviously a suboptimal/dangerous behavior.

Solution:

We now need to explicitly handle rollbacks per entity. By default we'll simply revert all optimistically-updated entities back to their previous value before the optimistic update. All entities without an optimistic update handler will be unaffected.

Additionally, we'll offer a custom hook in query configs to enable manual control of the rollback logic. This will enable you to safely support simultaneous mutations for the same entity when using optimistic update. It'll be important that apps consider providing a rollback handler whenever an entity is partially updated by multiple, possibly-simultaneous mutations.

Related issues:

• "Feature: Error and Rollback config keys => fns for handling error cases" Feature: Error and Rollback config keys => fns for handling error cases #9

Non-Breaking Bug Fixes and Improvements

• Change connectRequest to work around race condition resulting in invalid warnings (Invalid "Trying to cancel a request that is not in flight" warnings  #63)
• Avoid creating new functions in connectRequest's render function (Do not create new functions in render #67)
• Errors reducer (pass the responseBody through to the state #51)

[ryanashcraft]

Most of these changes are near completion and are up on the 2.0 branch. I want to wrap this up and publish v2.0 as soon as possible. If you have feedback, please post here to discuss.

cc authors of related issues and PRs: @jnutter @acontreras89 @rogovdm @MrNice @bstro @nlf @ManThursday

[MrNice]

Christmas in April! Thanks for all the work on this library - it's been good at supporting my use case since release, but these changes will give us a better error handling story and I'm excited about that.

Haven't updated in a while, probably since I added the first version of the multiple configs, so if we want a migration guide I'd be willing to help flesh that out.

I'd noticed the invalid warnings, nice to see them getting handled.

[bstro]

This is great news! Thanks for the update.

[RohovDmytro]

Niiiice! 👍

What I want to see is some sort of «scope of the project»-thing. So the project would become officially and formally focused :)

For example, I'm not sure that caching layer fits perfectly — just because if fairly complex and has lot's of use cases and edge cases. Some of that stuff might be abstracted into redux-query-cache.

[ryanashcraft]

Heads up – I've published 2.0.0-rc.1 to npm. If you use redux-query in your app, please try it out and let me know if you run into any issues. See https://github.com/amplitude/redux-query/blob/2.0/docs/transition-guides/v2.md for a transition guide.

[ryanashcraft]

@rogovdm Short answer: I don't envision the scope of redux-query growing much more. The team feels that large, complicated features like query-batching would best be implemented in a separate, optional middleware module that can complement redux-query. I'm not sure exactly what you mean by "caching" here (would like to hear more about this), but likely would be best to have it live as a separate project.

[MrNice]

Redux query is the HTTP layer, so it should have configuration of some sort available for addressing data staleness. Im fine with there being a simple default (no request deduplication or all request deduplication) or controlled via a config object, but there needs to be a way for me to hook in a time to live system (add more caching concerns here) which redux query is aware of. How we get there idk.

…

On May 9, 2017 8:02 AM, "Ryan Ashcraft" ***@***.***> wrote: @rogovdm <https://github.com/rogovdm> Short answer: I don't envision the scope of redux-query growing much more. The team feels that large, complicated features like query-batching would best be implemented in a separate, optional middleware module that can complement redux-query. I'm not sure exactly what you mean by "caching" here (would like to hear more about this), but likely would be best to have it live as a separate project. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACd6xysOfw_hmMi1v6NCssX7WL7iZ2S9ks5r4H_0gaJpZM4NILd8> .

[ryanashcraft]

@MrNice Let's continue discussing this in #1.

[ryanashcraft]

2.0.0 has been published.

[ryanashcraft]

See https://github.com/amplitude/redux-query/blob/master/docs/transition-guides/v2.md for a guide how to transition from 1.x to 2.x.