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].
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 :)
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.
Redux itself has absolutely no magic. The only "magic" I see is when you add state diffing and memoization (reselect). And even in this case, it's not really hard to understand what's happening.
React with redux is just a big pubsub system, how you set up your application state and how each component interacts with that state will decide how "tangled" and hard to maintain your code is.
Agree with all your other points though.
> you lose the concept of independent components
How? Components take props. They're just as independent as they were previously.
> everybody is notified of the inner state of each component
This... isn't the case.
Redux (and Flux in general) is useful when there is application-level data that needs to be shared across different components, and otherwise something ends up being a prop to a bunch of things that shouldn't be. Or when you want something to remain around when components go out of scope. If you don't have this problem, Redux is overkill. For larger apps, it's damn useful.
> 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.
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.
Edit: The first result for MobX in the French version of DDG is a porn site xD.
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.
most people complain there is too much boilerplate!
(And yes, I already had redux-query in the list before this post :) )
Great work :)
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?
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.
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?
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.
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.
1. declare your connect's in a separate file that import your component and live alongside your containers, actions, reducers, etc.
2. write your own connect HOC that brings in redux. If you read the connect source[0] you'll find that it is actually really simple at it's core - but it is over complicated by having to account for so many use cases - your own HOC could/should be ~30 lines
I now use 2. because it produces proper separation and makes it easy to swap out components later on (or use more than one).
[0] https://github.com/reactjs/react-redux/blob/master/src/conne...
Recently we had a small "hackathon" event to evaluate GraphQL and Relay. Once the GraphQL server was up and running, getting Relay working with our app was really easy. Unfortunately, the migration path for adopting it heavily didn't seem to be worth it for us.
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...
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.
https://github.com/limscoder/react-wrangler
It uses immutable and allows for time travel debugging.
[1] https://github.com/heroku/react-refetch [2] https://logrocket.com/
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
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.
