6 ms·

I'm surprised you dislike Redux simply because it's a form of global state. Sure, global variables make debugging difficult when you don't know which function

by skosch 8y ago

I'm surprised you dislike Redux simply because it's a form of global state. 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. (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered throughout your app.)

jorgeleo 8y ago
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.
- ghthor 8y ago
  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.
  - kerkeslager 8y ago
    > 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.
    - johannes1234321 8y ago
      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.
      - kerkeslager 8y ago
        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.
        WorldMaker 8y ago
        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.)
        kerkeslager 8y ago
        > 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.
      - Benjammer 8y ago
        >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?
    - hombre_fatal 8y ago
      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.
  - mosdl 8y ago
    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.
    - abjorn 8y ago
      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.
      - kerkeslager 8y ago
        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.
kerkeslager 8y ago
> 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.
- poink 8y ago
  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.
tomca32 8y ago
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.

by skosch 8y ago

jorgeleo 8y ago

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.

ghthor 8y ago
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.
- kerkeslager 8y ago
  > 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.
  - johannes1234321 8y ago
    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.
    - kerkeslager 8y ago
      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.
      - WorldMaker 8y ago
        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.)
        kerkeslager 8y ago
        > 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.
    - Benjammer 8y ago
      >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?
  - hombre_fatal 8y ago
    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.
- mosdl 8y ago
  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.
  - abjorn 8y ago
    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.
    - kerkeslager 8y ago
      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.

kerkeslager 8y ago

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

poink 8y ago
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.

tomca32 8y ago

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.