Add documentation for using with an immutable redux store

[amplitude]

Add documentation for using with an immutable redux store

[ryanashcraft]

Thanks for sharing, @rblakemesser.

[acontreras89]

@ryanashcraft I've been thinking about something since I started working with redux-query, which is described in the README as

a library for querying and managing network state in React/Redux applications.

If that's its scope, why does it impose its own entities reducer?

Don't take me wrong, I'm ok with redux-query shipping an entity reducer for whoever wants to make use of it, but I'd love to be able to opt it out in a simple manner.

For now, what I'm doing is something like this:

const mapDispatchToProps = { actionCreator }

const mapPropsToQuery = (props) => ({
  url: `api/todos`,
  // gets dispatched as soon as the requests completes
  transform: props.actionCreator,
  update: {} // required by redux-query
})

const enhance = compose(
  connect(void 0, mapDispatchToProps),
  connectRequest(mapPropsToQuery)
)

export default enhance(Component)

Note that I'm using trasnform instead of update to have a more generic code, but it would work either way. #2 uses a similar approach.

Where actionCreator is in charge of handling responses (normalize and store data, and potentially other stuff like handling pagination logic.) This enables me to work with my own reducers.

However, to roll back optimistic updates, I'd need to have my entities reducer react to the MUTATE_FAILURE action. #9 (which was created by the same user as #2) proposes adding other callbacks which could help in dealing with this scenario.

Even if this was added I feel like the code for updating entities (optimistically and otherwise) is too coupled to your implementation of the entities reducer. Both this issue and #34 display how cumbersome it can be to use your own reducers.

I'd love to hear your thoughts on this :)

[ryanashcraft]

@acontreras89 FYI the rollback handler has been added in 2.0.

As far as it goes with the coupling between entities reducer and the middleware – I don't have a better answer other than redux-query is opinionated in this way. Having this coupling keeps the overall API simpler for our use case where we want all of the network state in a single location.