Live data from Hacker News

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

amplitude.engineering

21–30 of 63 posts

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

#21
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 thing I don't like in Redux is all the boilerplate code required to make simple things. I understand that in some point you may want/need to switch over to Redux but to start some projects I'm always considering a simple Event Emitter like node-events.

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

#22
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…

Consider MobX, it's just getter-setter pairs for actual change detection. It's the declarative reactive one-way flow binder you want. It saved me a lot of time.

People think redux is about functional immutable stuff. It's not functional and state is obviously not immutable (then nothing would happen). Redux is just about "what's the smallest thing we can do to get React to know when to render" and the answer is "put everything in one function".

It's a great educational tool but I don't get why people build big things with it.

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

#24
post #15
post #13

Earlier quoted context omitted.

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.

That was actually the early advice for how to use Redux, but experience has shown that leads to less than optimal performance. In fact, benchmarks show that _more_ connected components usually leads to better perf, as the cost of notifying more subscribers is less than the cost of more wasted re-renders.

See the following links for more info:

- http://blog.isquaredsoftware.com/2017/01/practical-redux-par...

- http://redux.js.org/docs/faq/Performance.html#performance-sc...

- http://somebody32.github.io/high-performance-redux/

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

#25
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.

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

#26
post #13
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 "container component" pattern is widely used throughout the React world - it's simply any component whose primary responsibility is retrieving some data, and passing that as props to children. Could be making an AJAX call in `componentDidMount`, or something else. In this case, the container components generated by `connect` simply manage a subscription to the Redux store, retrieve the current state when notified, and run your `mapState` and pass the result down. Absolutely no magic at all, and definitely not "also changing any component's state without you knowing it".

Dan Abramov wrote a simplified version of `connect` to illustrate what it does: https://gist.github.com/gaearon/1d19088790e70ac32ea636c025ba... .

As for other libraries, they're still dispatching actions, which means that all updates to the store are traceable (especially if you're using the Redux DevTools).

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

#27
If anyone's interested, I maintain a list of Redux-related addons and utilities over at 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 :) )

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

#28
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

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

#29
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 thing I don't like in Redux is all the boilerplate code required to make simple things. I understand that in some point you may want/need to switch over to Redux but to start some projects I'm always considering a simple Event Emitter like node-events.

Obligatory link: Dan Abramov's article on "You Might Not Need Redux", discussing the tradeoffs involved in Redux: https://medium.com/@dan_abramov/you-might-not-need-redux-be4... .

Also, Dan has pointed out that the Redux docs were written in a deliberately verbose style to illustrate what's going on, and people sorta followed that. There's plenty of ways to reduce the boilerplate, and you're welcome to do that as much as you want.

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

#30
post #12
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 al…

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.

Post reply on HN