Beg to differ, yes, implicit call order will result in huge clusterfucks. React+Redux is already causing Frankenstein apps (which is not implicitly caused by those frameworks (ok, maybe except redux) but when you throw in react-redux, react-router, redux-thunk, etc. in the mix it just deteriorates quickly).
Well the NPM report showed us the trends. Every major fad peaks around 5 years in the making in JS land and then it fades away. We are halfway through. We just have to sit through the next 3-5 years.
You can write really messy confusing apps with lots of magic and indirection with anything, redux included, but redux by design enforces a single, mono directional and easily traceable chain of events whenever you fire an action. Whether you have 1 action or 100, this doesn't change. It's not, in my view, a pattern which works in the simple case but doesn't scale up.
Actually the complexity of understanding redux actions and their effects doesn't seem to change much at all from small to very large apps. This may come down to a well designed state tree (data model), or designing simple actions that don't try to do too much. There are actually big parallels with API design. It might even be the same problem.
So does a badly designed REST API mean REST as a concept is the cause? Of course not. In most cases, REST isn't even a limiting factor. It's just been badly designed and badly implemented. I think it's the same with blaming redux for a poorly designed, poorly implemented web app.
In actual use I've seen that Redux apps often wind up with a lot of accidental data dependencies that probably wouldn't have happened without a centralized store. For example devs will lazily use a "currentUser" key in the store for all kinds of unrelated stuff and subtle bugs creep in. Another common problem with Redux is memory issues because various components don't clear their data out of the store when they're unmounted.
Redux has some nice features but at this point I recommend people avoid it until they start to suffer from some of the problems it was designed to solve. You can get pretty far with a lot less complexity by use using local component state in vanilla React.
I absolutely agree with you and that's been my experience too, I've seen exactly those problems in both my own code and others' code. It took me personally many iterations over various projects to learn the boundaries of where redux makes more sense and where component state makes more sense.
That's perhaps the biggest actual inherent problem with redux, that it may implicitly encourage everything to be in the one single centralised store, for newcomers. That's a hard problem to solve, though I'm fairly certain Dan Abramov and the other maintainers have tried to make it clear that this, and using redux at all in simple apps, is usually a mistake.
The Redux FAQ specifically has an entry with rules of thumb to help decide when it makes sense to keep a given piece of state in Redux [0].
I do agree that the "Single Source of Truth" principle [1] is probably over-interpreted, and maybe needs some caveats somehow. That said, it's tough to simultaneously say "here's the basics of how Redux works", "here's the ideas behind why you _should_ use Redux", and also try to tell people when to _not_ use Redux.
We're currently planning a revamp of the Redux docs content [2]. I'd appreciate it if you could fill out this survey on how we can improve the docs structure [3], or leave a comment in that issue thread with some suggestions.
Yeah my approach now is to use Redux only for state that's shared among a bunch of components. Local state is fine and a lot simpler for things that aren't globally interesting.
You are implying that the causation goes like this: redux good -> so the app will be good too. And to make a case in point you are trying to make an argument that because many apps are poorly designed, everyone should use redux.
You really can't see how fundamentally broken is your argument? Really???
And you are not the only one who makes this HUGE fallacy.
All the redux/react fanboys are like you. At this point I already consider those people who make these arguments that they are just following/using redux because it's a religion for them.
Not to mention the fact that some people considers the whole uni-directional message flow a HUGE antipattern. See:
https://youtu.be/QM1iUe6IofM?t=1306
I'd love to debate the part about persistent call order but the rest of your comment has nothing to do with the content of my article and appears to be a generic rant.
Could you help me see how it would result in "huge clusterfucks" with an example?
Note React doesn't rely on particular call order. You can move your calls around any way you like. Just that it's persistent between re-renders.
Dan, I've seen this a few times already. I believe people are misunderstanding "persistent call order" to mean that they cannot change call order between versions of their app. I wonder if another name would help people understand this, maybe: "Non-conditional call order."?
That does better highlight that you are worried about conditionals. (It doesn't address the loop issuie though.) Hmm, here is another one. "Static call order"?
I guess what I'm saying and what I'm reading from the parent comment is that they are misunderstanding the name.
On the contrary: Redux's insistence on serializable events and side effect-free reducers makes debugging these pernicious "state update" ordering issues, which exist with or without Redux, a far easier job.
I don’t agree that state update ordering has ever been an issue, it’s a straw man to justify redux with. The correct solution here is to not design UI updates that can fail because of ordering! Mobx removes all the boilerplate and is far simpler to reason about and test in complex systems. Also async actions/side effects are built in, not third party.
If you haven’t tried Mobx it is definitely worth saving yourself thousands of lines of boilerplate in your next project.
if someone doesn't want to they don't need to write most of the Redux boilerplate, my last project a colleague wrote out all the boilerplate you normally see in a reducer - 100s of lines, and then I had to go write a new reducer of the same level of complexity and managed to write it with maybe 20 lines of Object.Assign and some values lookup.
For him he found my code harder to reason about because it was not explicit everywhere, but for me his was harder to reason about because I had to read the same thing over and over again with just different names.
But I wonder which one devtools would have handled easier, probably his.
Please check out our new `redux-starter-kit` package, which includes utilities to simplify common use cases like store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically:
You have to concede though that once someone sets up the call order, it's really unlikely to change unless there are bugs or someone's coming to do some yak-shaving.
People just don't write productive programs where the instruction sequencing at the function level is non-deterministic or chaotic. The UI is already insane enough with CSS and browser differences fighting you every step of the way to make it worse with clever preambles.
When we deal with state full objects (classes instances/ database objects/ in memory caches) -- we have to segregate the operations on those objects as:
( 1 )
Operation can be applied multiple times -- result will not change (idempotant op) -- eg delete, select
( 2 )
Operation order is important (eg balance cannot increment before payment is processed )
( 3 ) operation order is not important, or ordering conflicts can be mitigated by the solution/underlying platform completely.
So what React team has realized, is that updating a state variable ( a change operation), often falls into ( 2 ).
As react getting more and more use, it tries to find more and more areas to optimize. Which is good.
In both time and ram-space dimensions...
For the React's run-time system, to perform global optimizations, it is really important to know what order the developer had implied in his/her design for case ( 2 ).
Very similar, to what an optmizing compiler, would like to know about a flow of calls/etc.
this is very difficult to do for a user level application in JS.
Without some help from the developer using the library, those optimizations cannot be done, or they will cause user's state to get corrupted.
Their solution is to keep the existing machinery as is, but allow a user to 'tell' the framework about the state variables a bit more than usual.
To me this this a fair tradeoff/ask.
So I will have to learn a bit more, and may be even restructure my code, to let React (and React Native) to do better global optimizations....
Why not ?!
Most programming languages syntax is poor as specifying the intended order of function invocation or value change rules, as 'compile-time' directive.
(well, I at least, do not know of any language that let's me do that -- so I resort to forcing some order though function arguments and return type, so that a call to nxt function, must have a certain type provided by a return of a previous function...
I think explicit state management, is absolutely the correct problem to tackle. it is difficult and error prone.
It is not fair, in my view, to judge React added complexity in this area, as 'deterioration'.
Ideally these types of things should have been solved by the compilers .. but javascript (and browser) ecosystem is probably 10-15 years away from even thinking about this.
That's a loaded question. What about comparing to the current day alternatives and upcoming ones? People have learned from react/redux and are pursuing alternatives.
Dont think anything was superior but that doesnt mean its perfect. It still amaze me how much time we have to spent(engineer) to get a frontend working. It really should be a completely or semi completely visual process.
It's always strange when people act indignant about the fact that engineering a large frontend is difficult, like the world owes it to them for it to be easy. Frontend code is by nature highly repetitive, but each different unit has its own arbitrary tweaks because of the fact that people have to use it. This makes it very hard to abstract.
There are a million visual frontend builders out there, and they are all terrible, because you can never get them to do what you want. They are only usable to build example apps, and if used for anything real, require a huge amount of hacking around which results in code that is worse than what it would have been otherwise.
Yep. Underestimating frontend complexity is how we got into this mess. Say what you will about framework churn, React is the first one where I really feel like it's easy to apply basic coding hygiene (e.g. treating abstraction and composition as first-order concerns).
>There are a million visual frontend builders out there, and they are all terrible, because you can never get them to do what you want.
I disagree. I had worked with Visual Basic and it had a great balance of ease of use and flexibility. If you are not obsessed with the feeling that you need to see the underlying code of the UI, you can have a great visual builder. Of course you need to code the event handlers, that's pretty much should be the coding required. I am talking about something like webflow + code for event handling.
>require a huge amount of hacking around which results in code that is worse than what it would have been otherwise.
that is because you haven't seen a great implementation yet. and as another commenter mentioned below, mobile UI builders are better because there is a uniformity in mobile design, while desktop (web) design lacks uniformity. It's possible.
While I agree with you, I think it's important to maybe specify that visual frontend builders generally suck -- for web frontends. In general, the visual UI builders for mobile apps tend to be very good.
The reason I think it's important to mention this is because I believe that the amount of variability you have to deal with in the web is far greater, which is why I believe these visual frontend builder systems tend to fall apart.
There's two layers to front end development. There is the visual layer and the arrangement of UI elements on the screen...and then there's application state management, routing, http request handling, data caching, inlining assets, etc that all come into play as well. UI builders might help you arrange elements on the screen but they do little to help with the latter except for minor cases like click through handlers.
When you declare a variable in your code, the variable is actually allocated a slot on the stack, which means there are implicit call orders when you declare a variable.
There's nothing wrong with implicit call order when you only call it once.
Well the NPM report showed us the trends. Every major fad peaks around 5 years in the making in JS land and then it fades away. We are halfway through. We just have to sit through the next 3-5 years.