> Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience.

Sticking to reducers IS a good idea and it does make things a bit better. The problem with global state goes deeper than that, though.

Often, as you learn about the structure of the data, it becomes useful to change how the data is structured and stored. In global state, you can change that in reducers, sure, but then all the places that render that data have to be updated. You don't have the option to represent the same data in different ways that might be more suitable for different parts of the application. You either have to change them all at once, or synchronize a bunch of states that really contain the same data (which is even worse).

With independent components, you do spend some time synchronizing data across components, but each component has the option of how to represent its data internally, so the effects of changing data representation in one area are usually very local, and each area of the code gets to represent the data in a way that's reasonable for what it's doing.

I'll also add that with independent components, you sometimes get components whose only real job is to manage data. That's actually sort of like a Redux! But you can spin up multiples of them without having to manage an array, and compose them or even nest them without issues.

> (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered throughout your app.)

To be clear, I don't really care about boilerplate. It's easy to generate that stuff, but even if you write it by hand it's faster than debugging implicit, hidden complexity. Boilerplate ISN'T the problem with Redux, as far as I'm concerned.

If you're giving me the choice between dealing with this:

> Often, as you learn about the structure of the data, it becomes useful to change how the data is structured and stored. In global state, you can change that in reducers, sure, but then all the places that render that data have to be updated. You don't have the option to represent the same data in different ways that might be more suitable for different parts of the application. You either have to change them all at once, or synchronize a bunch of states that really contain the same data (which is even worse).

or this:

> With independent components, you do spend some time synchronizing data across components

I'm not even hesitating before I choose the first option. My editor, static analysis, and the mystical art of the function can give me all sorts of help with the first problem. Good luck with those sync bugs.

You selectively quoted me, ignoring where I explained that synchronization isn't as big of a problem with passing properties into components. I already addressed your concern. Don't selectively quote me, it's rude and just shows you aren't following the conversation.

Futher, Redux doesn't solve synchronization issues in situations where you can't represent the data the same way. In the most complicated situations, it actually exacerbates the issue because it separates the data from the components that use it, making static analysis tools unable to see how your data changes might break the components. This also goes to show you didn't even understand the part of what I said that you selectively quoted, since I already said this.

> I'm not even hesitating before I choose the first option.

Perhaps if you hesitated a bit more, you could use that time to read all of the options and understand them.

> Futher, Redux doesn't solve synchronization issues in situations where you can't represent the data the same way.

I would argue that synchronizing data between multiple representations is an anti-pattern, and the exact anti-pattern that redux, with its emphasis on a single source of truth, was designed to solve. Synchronizing state is almost always going to lead to hard to diagnose bugs in edge cases. There's even a blog post on why it's a bad idea on the official react blog [0]

My solution to this problem is to use computed values generated by a library with memoization like reselect. I structure my data as close as possible to the API data models and use selectors to transform the models into the data structures that disparate UI components require. If you need to change your UI component, you don't need to refactor your store, and if you need to change your store structure, you don't need to refactor your UI components.

[0]: https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...

I read the thread. You hand-waved away a non-trivial problem by "explaining" properties are a thing. Thanks, bud. I'm sorry I didn't cite your favorite source to your satisfaction, but I quoted the relevant parts of the post I replied to.

> Futher, Redux doesn't solve synchronization issues in situations where you can't represent the data the same way.

It's kind of the whole Redux philosophy that you won't do that. It's in the FAQ. There's no "can't". You're never forced to keep duplicate data in your store.

But, in a project of any significant complexity, you will represent the data in different formats, because transforming data into different formats is one of the main functions of software. Relying on a framework that assumes you won't do something that you will do is a Very Bad Idea.

It's almost like `mapStateToProps` is a thing and Dan Abramov has built a web app before. You have to store and transform your data in a normalized form, but you can consume it however you want.

Restrictions are the price of solving hard problems (even if you don't want to admit they're hard) in a deterministic fashion.

It's generally considered a best practice to use pure selector functions in your UI components so the only place in your application that references the actual data structure is the root selector that pulls data out of the state tree. I personally try to structure my selectors so that any refactoring only requires changing a single line of code.

Okay, so the only way it's actually possible to have any refactoring of your data structures require only changing one selector is that you've got a single selector for literally every piece of data in your system, at which point you've had to manually flatten everything out into a bunch of selectors, and lost all the benefits of being able to read a structured chunk of data. If you actually do that (which I don't think most projects do fastidiously) you're creating a lot of boilerplate, again to solve a problem which was created because you decided to use global state in the first place.

I'm not saying there aren't solutions to the problems I'm bringing up. I'm saying you don't have to solve them in the first place if you don't bring in Redux.

Not at all; you can write selectors that return a branch of your state tree, and you can generally tell where the line should be (user makes more sense than userName and userEmail).

You keep saying that you won't have these problems if you don't use redux, but I am arguing that _you do have these problems_, you're just creating ad-hoc solutions for everything that you would use redux for, except those solutions are sprinkled into your UI components in a way that makes them full of mutable state that is impossible to test and a constant source of bugs. Note that I have already agreed that there is a scale where redux is overkill and creates more problems than it solves. Once your app has a few dozen components it's time to start thinking about another layer of abstraction.

> Not at all; you can write selectors that return a branch of your state tree, and you can generally tell where the line should be (user makes more sense than userName and userEmail).

And then you're right back to any component that uses User being tightly coupled to the structure of the User, without any of the syntactic cues that allow you and your static tooling to connect the two.

> except those solutions are sprinkled into your UI components in a way that makes them full of mutable state that is impossible to test and a constant source of bugs.

That's not the case:

1. There's nothing preventing you from treating components as a pure function of their props.

2. At the top level, it's necessary to have some mutable state, but I'm not sure where you get the idea that this isn't testable. Redux doesn't remove mutable state: all redux is doing is a big complicated version of newState = pureFunction(oldState) which is perfectly possible to do using Vanilla JS functions.

One of the problems I noticed with Redux is that you need to clean your state. This is one of the reasons why global variables are a problem.

If you keep your state in a component, you don't need any housekeeping, once the component is gone, the state is gone.

This is not true with Redux. You have to keep remembering to clean the state after you're done with something or you're going to introduce a bunch of bugs.

Anecdotical comment: While studying computer science, I almost fail a test because I used global variables. Since then I avoid them like the plage, and I get rashes when I see them.

And I thank my teacher for knocking the bad habit out of me. So when I see global variables beyond the initialization of core objects, I take it as a bad code smell.

Global variables are different from global state. Every program has global state, whether you like it or not. Global variables are a poor way to declare, mutate, and read global state.

Redux means everything is global state which is terrible. A grid I render now has to have global state and most projects forget to do any cleanup - so you end up with all this junk in redux that isn't needed anymore, clogging up memory.

Nothing is forcing you to put everything in Redux. If state only has relevance to a single component then keep it in that components state, Redux works perfectly fine with this approach.

And when the state has relevance to two components? Now it's okay to make it a global, because we can't be bothered to type "prop = value"?

I'm just not buying this argument. People add Redux to projects because they intend to use it, and there's almost never a case where a piece of data is actually needed in enough places that it should be global. It's certainly not common enough to justify importing a whole framework for managing global state.

> Every program has global state

Could you explain what you mean by this?

My intuition here is that what you're saying is true in a trivial sense, but that most state CAN BE (and should be) local if you're breaking your programs into reasonable building blocks.

You have information which has global nature, used in multiple sorts of the application. This could be, among other things - STDIN/STDOUT/STDERR file handles - static configuration - some parts of runtime configuration - application info (in a game maybe current score, current level, active players, ...)

All that information exists only once and is needed in many parts.

>exists only once and is needed in many parts.

I think many people could argue that this concept itself is a bit misguided. There are plenty of application patterns and architectures that help you move stateful data around your app and translate it for the components who need to consume it or change it, while hiding it from components in the tree which do not interact with or care about the state.

If you have many different components in your app that all need access to the same state data, and they exist at different levels in the hierarchy, maybe you need to re-think your component structure rather than figure out a way to inject mutable global state everywhere?

Sorry to reply twice to the same comment, but if you have an instance of a user model, and you need to display the model data in the navigation bar, on the user profile page, and in a comment thread, how would you manage that data? And do you think that having a single source of truth reduces complexity or creates more problems than it solves?

There are definitely options and choices for all of this, but I can give my professional opinion.

First question (show user data in nav bar, user details page, and "comment thread"):

User profile page is obviously showing full user details, so you're going to want to have a separate endpoint for "getUserDetailsByUserId(int userId)" or however you want to name it.

What data are you showing in your nav bar? Is this just a user-avatar image link/button? You would rarely want to display anything other than an avatar and/or username in a navigation bar. You could maybe talk about a navigation drawer instead, where you have more simple details like maybe email address and phone number or something.

What about the "comment thread"? Are you showing anything more than an avatar and/or username? This sounds like the same use-case as the nav bar... how would the display differ here?

If you have use-cases for anything more than your basic "user avatar" and "full user profile," (and maaaybe "user basic info," for a "nav drawer" or something, although those are being phased out of most current design standards) then I would seriously urge you to re-think your app design. That polish of showing the user info in a slightly different slice on some specific page is almost never going to pay off for your company, imo.

Anyways, if you want to be naive about all of this, you just save the userId (and token or whatever, but that should be in your http middleware) after a new login session, and then you request separate "getUserNavBarInfo(userId)", "getUserDetails(userId)", and "getUserCommentInfo(userId)" and load the results of those into your UI views on-demand. If you need to progressively tune/cache your API, you do this separately based on usage stats for each of these 3 use-cases, you don't start with directly caching "Users" and adding the business logic client-side to translate into the 3 use-cases.

If you want to do a more thorough dependency-injection "user component," then this might vary depending on your DI framework, but the high-level idea would always just be to create a user module with all the info needed for a given user, wire it up to reload the module in your DI graph on new login and on-success of any request to update user info. You could have both your "login" and "update user" endpoints both return the full set of data needed for the "user module" on success. Then you need to set up your DI injection component scoping so that your user info injection component is dumped on user logout and settings change, and is recreated to do it's injections with the new/updated user module each time. A singleton DI "user component" that you must choose to inject into any UI component that wants to show user information seems much more constrained in complexity to me than just having the ability to arbitrarily pull out various bits of user info from a global redux state, at any place in your app.

Second question (single source of truth, increases or decreases complexity?):

I think this question is orthogonal to the capabilities Redux (and similar) provides. Redux has nothing to do with outright increases or decreases in app complexity, it is simply a tool that enables various (opinionated) architecture patterns. If you have a separate, domain-specific, well-defined event+data architecture that you are sticking to very strictly to keep a handle on complexity, then Redux can (imo) reduce boilerplate and allow very elegant interactions between various data/biz logic/UI components of your application, all without any "tight coupling". It's really just a message-bus pattern at some level. This sort of thing has been around longer than the concept of software itself, there are hardware components literally called "buses" that basically do the exact same thing (ship events and data around to various interested parties without requiring a direct circuit connection). The danger is that it opens up a TON of pathways to insane complexity and totally unintuitive event & data flows, because it kind of allows you to arbitrarily add "side effects" to basically anything in your application. VERY easy to foot-gun yourself here if you start getting lazy and just wiring up random shit instead of following strict event/data patterns and keeping the "feature code" as simple as possible (e.g. with a strict facade for writing new pages).

This might rustle some feathers on here, but I wish people would think of React/Redux sort of as "framework primitives" that are SUPER useful for constructing your own domain-specific client-app frameworks, but somewhat dangerous to open up directly to front-line product code written by junior devs. I would much rather see a few senior devs use React/Redux to construct a tightly-defined domain framework that exposes a simple facade to junior devs to construct new pages/routes/behaviors in your FE application. I think using these tools like this would greatly reduce the dreaded "React learning curve" of 3-4 months that everyone talks about. That could be done over time if you put in the work up front to build an internal facade pattern around your core React/Redux app architecture. Then junior devs could choose to dig into things behind the scenes as they go, instead of being forced to front-load the entire React/Redux knowledge stack up front right when they walk in the door.

Redux state isn't mutable. Mutating the state tree in a redux reducer is a bug.

Okay, technically it's copy on write, but I think if you put a bit of effort into understanding what people mean, you're smart enough to understand what the parent comment meant. Let's avoid making this holy war into a semantic argument. :)

Okay, I think we're talking about different things. I don't think of stdin/stdout/stderr or static configuration as state because they don't change. Typically when I talk about state, I'm talking about mutable data that may change over the lifetime of a program.

stdin/stdout/stderr may be redirected during the lifetime of a program. The OS manages them and they are "reference pointers" (file handles) for multiple reasons.

Also, "state" does not necessarily imply "mutable". (Redux encourages an immutable state approach where good reducers don't mutate state in place, but instead build new state from old, though Redux is not strict in enforcing this best practice. For Redux the "current state" is "file handle" that simply updates from one object to the next, not all that different from stdin/stdout/stderr or even somewhat to static configuration that is somewhat updateable without restarting the application.)

> stdin/stdout/stderr may be redirected during the lifetime of a program. The OS manages them and they are "reference pointers" (file handles) for multiple reasons.

> Also, "state" does not necessarily imply "mutable".

Okay, sure. I'd rather not get into a semantic argument about the meaning of the word "state". Suffice it to say that I'm talking about mutable global state.

Like the state of the logged-in user.

I think these debates about global variables or state could be much more specific, though.

For example, we tend to realize that letting any component access a `require('./store').currentUser` singleton may make testing harder, but this global dependency still exists when, say, it's distributed to all components through the React context. I reckon most people are thinking of the singleton example when they lambast Redux but it certainly doesn't have to be that way.