
Redux-query – A React/Redux library for querying and managing network state - ryanashcraft
https://amplitude.engineering/introducing-redux-query-7734e7215b3b
======
acemarke
If anyone's interested, I maintain a list of Redux-related addons and
utilities over at [https://github.com/markerikson/redux-ecosystem-
links](https://github.com/markerikson/redux-ecosystem-links) . Includes just
about every vaguely-useful-looking middleware, action-generation utility,
devtool, store enhancer, fill-in-category-here, that I've seen out there.

(And yes, I already had redux-query in the list before this post :) )

~~~
ryanashcraft
Awesome resource! And thanks!

~~~
acemarke
Sure. I'll also throw in a pointer to my React/Redux links list, which
contains links to high-quality tutorials, articles, and other resources for
React, Redux, ES6, Webpack , and related topics. Specifically intended to be a
great starting point for anyone trying to learn the ecosystem, as well as a
source of solid info on more advanced topics:

[https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

------
stymaar
I love react, with the reusable components and the ergonomic of jsx but I
really don't like what redux does to your code: it involves too much magic,
you lose the concept of independent components and every change becomes a
global one: everybody is notified of the inner state of each component …

To me it just break all encapsulation and just lead to massive tangled code
that is really hard to maintain …

Edit: I want to clarify what I mean with the «too much magic» part. It's not
redux itself which has too much magic in it, just your application flow that
becomes magic when using redux, especially with libraries like the one showed
by this article or redux-form[1].

[1]: [http://redux-form.com/](http://redux-form.com/)

~~~
shados
The beauty of redux itself is the lack of magic. It's essentially just a
design pattern and is trivial to follow.

So the "edit" part of your comment is key here: frameworks built on top of
redux, including middlewares, store enhancers and stuff can definitely lead to
an app that is hard to reason about with side effects happening in places you
don't expect.

IMO that ends up being the worse of both world: even with all that tooling,
Redux is far from terse (in favor of being explicit), but you also get the
drawback of a deeply layered framework. This isn't worth it. There are other
frameworks and tools that do this better. If you want to be terse, and don't
mind throwing in a lot of layers on top of your code to achieve it, use one of
the countless other (mainstream!) solutions to do so.

Redux really excel at "putting the code in your face", giving you easy to
follow logic where very little is abstracted (and when it's abstracted, it's
just via simple function composition). And at doing that, it is amazing and is
my pattern of choice. At anything that diverge from that though, it is so bad
it's not funny. Right tool for the right job :)

~~~
limscoder
Redux is difficult to reason about because side-effects can be triggered from
anywhere in the application by middleware.

If you're using something like redux-thunk, a single dispatch can cause both a
store mutation AND trigger a side effect, which is confusing. I'd rather have
those be 2 separate concerns.

Those dispatches can be triggered from anywhere in the app, and multiple
middlewares may trigger multiple side-effects in new and exciting ways.

I find that logic to be difficult to follow and test.

I wish it had a more opinionated way to do side-effects, but the solutions
like redux-saga seem even more complicated and confusing.

~~~
shados
yup. Its like i said: redux is simple. Middlewares are what makes it
complicated.

Redux-loop had a nice model for side effects, but the syntax did not mesh well
with javascript limitations. Redux-saga is nice for testing, but it adds new
non-standard concepts on top of generators that make it complicated. I really
like the Netflix solution (redux-observable).

Since JS is not Haskell, side effects can be shoved to the side a bit, but
there aren't a whole lot of ways to make them nice.

CycleJS probably has one of the better systems. In Redux, even without redux-
observables, if you closely follow redux semantics I find that reasoning
around thunks works quite well (if you're making sure that your actions are
semantic and not glorified setters)

~~~
jwarren
+1 for redux-observables, I've found RxJS to be an excellent tool for managing
async without going insane.

I'd also second the notion to be rigorously consistent in following the
semantics. I always end up regretting shortcuts.

------
arbesfeld
This is really cool! We have been using react-refetch from Heroku [1] for a
similar purpose and it will be nice to have all our state in Redux. Another
perk is that LogRocket [2] will capture this data now :)

[1] [https://github.com/heroku/react-refetch](https://github.com/heroku/react-
refetch) [2] [https://logrocket.com/](https://logrocket.com/)

------
tonyhb
Heh, I made the same thing but with global endpoints and swappable drivers so
that components can be shared and endpoints can be stubbed/mocked:
[https://gitHub.com/tonyhb/tectonic](https://gitHub.com/tonyhb/tectonic)

Think that genraally we're learning that these things should be automated for
us: loading data traditionally sucks. GraphQL is really where it's at!

edit: that mobile keyboard though...

~~~
djmashko2
Yeah, Apollo Client helps you do a lot of these kinds of things with GraphQL -
deduplicating requests, keeping track of loading states, etc:
dev.apollodata.com (disclaimer: I work on Apollo)

------
gtf21
I've been having this discussion both in my own head and with my team for the
last couple of weeks and have been thinking about how to implement something
like this (but haven't got around to it). Looks great!

------
limscoder
I've been experimenting with using a component to fetch data. The data to
fetch is declaratively described as props.

[https://github.com/limscoder/react-
wrangler](https://github.com/limscoder/react-wrangler)

It uses immutable and allows for time travel debugging.

~~~
netghost
That's a really neat approach. I like how it allows you to trigger code on
missing paths. That seems like a really simple way to model an API.

------
mpolichette
This is cool, I was looking a library which would help me with CRUD and paging
data recently and there weren't a lot of great options. So I started working
on a library which ended up looking kind of similar to this.

One of the goals I've had is to stay encapsulated and not force any decision
on the developer for the request library like redux-query does. I also try to
avoid touching their data.

It isn't quite flushed out all the way, and needs more test, but I've started
using it and enjoyed the way it works.

I'd love any feedback if anyone wanted to check it out,
[https://github.com/SpinGo/crudux](https://github.com/SpinGo/crudux)

------
netghost
This looks like a really great library for simplifying API interactions.

I'm curious though if there's any way to indicate that a component depends on
more than one end point. Would you just wrap it in multiple `connectRequest`
wrappers?

~~~
ryanashcraft
Author here. Thanks!

That's what we do. It's an OK workaround but ideally `connectRequest` would
support multiple queries. Another workaround is to manually dispatch
`requestAsync` actions, which might be necessary if you need to chain the
requests.

~~~
HorizonXP
We were just about to start migrating to GraphQL and Apollo, so this
definitely came out at the right time.

Our issue is that our API is nested, and does require many nested requests.
This would probably be the best solution for us though.

Unfortunately, I don't see anything related to server-side rendering?

~~~
ryanashcraft
Yeah server-side rendering hasn't been a focus for us. Currently, I don't
think it is a great solution for server-side-rendered apps. I'm not exactly
sure how much it would take to improve things here.

If you have any thoughts around multiple requests or server-side rendering
feel free to submit an issue on Github to discuss!
[https://github.com/amplitude/redux-
query/issues](https://github.com/amplitude/redux-query/issues)

------
Rodeoclash
I'm very surprised that Relay is not getting more traction in this space.
Given, it's a lot of work to get it set up and running but once it's in place
it's great. I haven't found a library that manages network state and the
associated difficulties that come with it better.

No reason why you cannot combine both Redux + Relay, in fact once the app gets
to a certain size and you want to rely less on passing around long chains of
callbacks and state objects then you pretty much have to implement either
Redux, Mobx or similar.

~~~
djmashko2
We built a new GraphQL client that makes it especially easy to integrate with
Redux, which also handles all of the related concerns about data caching and
state management: [http://dev.apollodata.com/](http://dev.apollodata.com/)

------
weq
Everyone says redux and react make for great component isolation.

How many of you people who use this combo can swap redux out at a whim, for
another state management tool? How many of your components have been modified
to work with the opinions of redux? Why do i need to couple my components with
redux using connect()?

In my experience, redux and react on there own present decent patterns to
simplify UI experience, but ive never seen a discussion that involves them
that doesnt couple one with the other.

~~~
mlsarecmg
Swapping the management would be difficult, they all have their own patterns
and implementations. But swapping Redux is absolutely possible. The logic sits
in a self contained container which you can plug into literally every
framework under the sun. The "connect" you're talking about is in place for
React, Ember, Angular, Vue, Knockout, Mithril, Cycle, etc. Redux is also the
closest you can get to a true universal app, because you can share it between
code-bases (desktop app, web app, mobile app, backend even if you need).

We deploy a library based on this. It has reactive/changing datastructures
that need to be presented visually. It runs on redux internally, and that is
what makes it possible for our customers to embed it, no matter which
framework they choose, even if it's JQuery. They form a simple dress and get
served the properties and actions to display and excute. "Connect" makes their
stuff aware of changes.

------
ex3ndr
Nice component, we are working internally on something same, but for Kotlin.Js
+ React (nothing to show yet), but i have one question:

How to solve a problem when same entities have different fields, for example:
List of members of a chat should display avatar, name and username, but
viewing profile usually use much much more data to display. How to merge them?
How to keep fields in sync and not to download everything in all requests. For
example, loading all members can be slow when fetching full user profiles and
should be avoided.

------
sktrdie
I don't understand how this solution differs from actual side-effects managing
libraries such as redux-saga or redux-cycles. Network requests are certainly
side-effects and putting all their logic together with your Container code
seems like a code-smell.

------
cel1ne
I managed network state using react in the DOM itself, using hidden divs with
custom onDidMount, onWillUnmount hooks. Worked really well.

