Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redux-query – A React/Redux library for querying and managing network state

amplitude.engineering

Post reply on HN
Print view View original

11–20 of 63 posts

Re: Redux-query – A React/Redux library for querying and managing network state

#11

Post by ryanashcraft »

stymaar wrote: post #2

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…

Global state vs. local state is a problem with several tradeoffs that I don't think anyone has nailed. You might be interested in the discussions and solutions people are developing here: https://github.com/slorber/scalable-frontend-with-elm-or-red...

Re: Redux-query – A React/Redux library for querying and managing network state

#12

Post by shados »

stymaar wrote: post #2

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…

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 :)

Re: Redux-query – A React/Redux library for querying and managing network state

#13

Post by stymaar »

jowiar wrote: post #4
stymaar wrote: post #2

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…

"Too much magic" is a serious stretch. Running through the tutorial here: https://egghead.io/courses/getting-started-with-redux , you pretty much reimplement the whole thing. It's just not that much code. There's plenty of optimizations and edge-case handling in the production version, but overall there just isn't much. > you lose the concept of independent components How? Components take props. They're just as indep…

It's not redux itself which has too much magic in it, just your application flow that becomes magic when using redux.

> How? Components take props. They're just as independent as they were previously.

But in raw react it's straitforward: props are properties passed in the jsx tag of the element. With redux your props just pop out of nowhere when some event is dispatched somewhere in your code and your (smart) component can also change any other component's state without you knowing it. I know this kind of behavior can be useful sometimes (because you exactly want to do that) but in many situation you don't need it (in the same app I mean).

My problem with redux is that it makes the remote control implicit instead of explicit. Plus you don't always control redux by yourself but are also encouraged to use a lot of librairies that tamper the global state behind your back: redux-router, redux-form, etc.

Re: Redux-query – A React/Redux library for querying and managing network state

#15

Post by jowiar »

stymaar wrote: post #13
jowiar wrote: post #4

Earlier quoted context omitted.

"Too much magic" is a serious stretch. Running through the tutorial here: https://egghead.io/courses/getting-started-with-redux , you pretty much reimplement the whole thing. It's just not that much code. There's plenty of optimizations and edge-case handling in the production version, but overall there just isn't much. > you lose the concept of independent components How? Components take props. They're just as indep…

It's not redux itself which has too much magic in it, just your application flow that becomes magic when using redux. > How? Components take props. They're just as independent as they were previously. But in raw react it's straitforward: props are properties passed in the jsx tag of the element. With redux your props just pop out of nowhere when some event is dispatched somewhere in your code and your (smart) compone…

The caveat here is that with flux/redux, I'd argue "make as few components as reasonably possible interact with redux" is a best practice. If "things popping out of nowhere" is a problem, you probably have too many components listening on your stores.

Re: Redux-query – A React/Redux library for querying and managing network state

#16

Post by stymaar »

ryanashcraft wrote: post #11
stymaar wrote: post #2

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…

Global state vs. local state is a problem with several tradeoffs that I don't think anyone has nailed. You might be interested in the discussions and solutions people are developing here: https://github.com/slorber/scalable-frontend-with-elm-or-red...

Thanks !

Re: Redux-query – A React/Redux library for querying and managing network state

#17

Post by dvcc »

stymaar wrote: post #13
jowiar wrote: post #4

Earlier quoted context omitted.

"Too much magic" is a serious stretch. Running through the tutorial here: https://egghead.io/courses/getting-started-with-redux , you pretty much reimplement the whole thing. It's just not that much code. There's plenty of optimizations and edge-case handling in the production version, but overall there just isn't much. > you lose the concept of independent components How? Components take props. They're just as indep…

It's not redux itself which has too much magic in it, just your application flow that becomes magic when using redux. > How? Components take props. They're just as independent as they were previously. But in raw react it's straitforward: props are properties passed in the jsx tag of the element. With redux your props just pop out of nowhere when some event is dispatched somewhere in your code and your (smart) compone…

I don't think its really all that magical when looked at as a giant component. In the context of the react-redux lib, its really similar to just having one large top level component that contains your entire state and all methods you would want to commit (but instead its called a store and actions). Everything is still unidirectional in that it has to go through that main redux provider and then gets passed back down to all the children, without the need to pass around every single possible method to each child.

So even if you have two "smart" components they are still just children of that main redux provider and therefore it makes sense that they can impact each other. The same way children can call methods that change a parents state on normal react components.

Re: Redux-query – A React/Redux library for querying and managing network state

#18

Post by ryanashcraft »

netghost wrote: post #14

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?

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.

Re: Redux-query – A React/Redux library for querying and managing network state

#19

Post by 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 [2] https://logrocket.com/

Re: Redux-query – A React/Redux library for querying and managing network state

#20

Post by HorizonXP »

ryanashcraft wrote: post #18
netghost wrote: post #14

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?

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.

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?

Post reply on HN