3 ms·

> They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structure

> They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structures, but you can't get rid of the mutable state. Can you give an example of this? I have worked on fairly complex Redux applications but have never ever mutated states and it has been just fine. In fact, I use ImmutableJS to keep my apps' states. State machines without immutability in a large application sounds like a joke to me, sorry.

saosebastiao 10y ago
If you haven't mutated states, you don't have an interactive UI. With immutable data structures holding your state, you mutate it by re-assigning variables. This is exactly what Redux does. In fact, the rendering benefits of immutable data structures comes from the fact that you can perform equality comparisons by reference safely, and ref comparisons are faster. Any time you re-assign a variable, you change that variable's reference, and it is no longer necessary to deep check the reference's value to know that it changed.
- somlor 10y ago
  > If you haven't mutated states, you don't have an interactive UI. React allows you to treat DOM mutation as an expression of current app state. This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary). I'm befuddled where you're getting the impression that immutable data structures themselves require mutation.
  - saosebastiao 10y ago
    > React allows you to treat DOM mutation as an expression of current app state. Current app state. As in not past state. Not future state. There would be no need for the distinction if the state wasn't mutated. > This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary). You are confusing the mutability of a data structure with the mutability of state. You can model mutable state using immutable data structures, but it's mutable state regardless. In fact, that is exactly what the Redux/ImmutableJS model is. If the state of your "immutable" react app were really immutable, you would have a webpage, not an app.
    - somlor 10y ago
      The DOM can be mutated just fine behind the scenes by React to reflect whatever brand new state has been passed into it. That brand new state can be anything. It can be a single (by definition immutable) integer. It can be a deep clone of an object. This is the ideal intended Redux architecture. Redux reducer(s) receive the state and return either the state untouched, or a non-mutated copy of the state. React reacts accordingly by expressing this brand new state as (possible) DOM mutations.
      - saosebastiao 10y ago
        That is mutable state. Your Redux store is a mutable state container. If your redux store returns a {a:1,b:2}, and then you dispatch an action and it now returns an {a:2,b:1}, then you have mutated your state. It doesn't matter at all if the store's data structures are mutated in place or replaced with a modified immutable updated copy of a previous state, you still have mutable state.
        somlor 10y ago
        I think I see where you're coming from, but I also think you might be moving the target a bit. I suspect you'd garner less debate if you said, I dunno, just "a dynamic UI app needs a way to model state changes". "Mutate" has a specific meaning, in my mind at least, when discussing variables and data structures. React enables avoidance of direct DOM manipulation, Redux obviates direct state mutation.
        DonHopkins 10y ago
        Also, "finite state machine" has a very specific meaning, and that isn't just any machine that has a finite bunch of variables that you call state. If React lets you execute arbitrary JavaScript code (which it does), then you're no longer using just a finite state machine, you're using a Turing machine, which is something different, and more powerful. It may have many finite state machines embedded in it, but to refer to a user interface as a finite state machine is like referring to a car as a pulley, just because the engine requires several pulleys to work, and ignoring all the rest of the engine and car. You can't make a car out of just pulleys, and you can't make a user interface out of just finite state machines.

saosebastiao 10y ago

If you haven't mutated states, you don't have an interactive UI. With immutable data structures holding your state, you mutate it by re-assigning variables. This is exactly what Redux does. In fact, the rendering benefits of immutable data structures comes from the fact that you can perform equality comparisons by reference safely, and ref comparisons are faster. Any time you re-assign a variable, you change that variable's reference, and it is no longer necessary to deep check the reference's value to know that it changed.

somlor 10y ago
> If you haven't mutated states, you don't have an interactive UI. React allows you to treat DOM mutation as an expression of current app state. This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary). I'm befuddled where you're getting the impression that immutable data structures themselves require mutation.
- saosebastiao 10y ago
  > React allows you to treat DOM mutation as an expression of current app state. Current app state. As in not past state. Not future state. There would be no need for the distinction if the state wasn't mutated. > This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary). You are confusing the mutability of a data structure with the mutability of state. You can model mutable state using immutable data structures, but it's mutable state regardless. In fact, that is exactly what the Redux/ImmutableJS model is. If the state of your "immutable" react app were really immutable, you would have a webpage, not an app.
  - somlor 10y ago
    The DOM can be mutated just fine behind the scenes by React to reflect whatever brand new state has been passed into it. That brand new state can be anything. It can be a single (by definition immutable) integer. It can be a deep clone of an object. This is the ideal intended Redux architecture. Redux reducer(s) receive the state and return either the state untouched, or a non-mutated copy of the state. React reacts accordingly by expressing this brand new state as (possible) DOM mutations.
    - saosebastiao 10y ago
      That is mutable state. Your Redux store is a mutable state container. If your redux store returns a {a:1,b:2}, and then you dispatch an action and it now returns an {a:2,b:1}, then you have mutated your state. It doesn't matter at all if the store's data structures are mutated in place or replaced with a modified immutable updated copy of a previous state, you still have mutable state.
      - somlor 10y ago
        I think I see where you're coming from, but I also think you might be moving the target a bit. I suspect you'd garner less debate if you said, I dunno, just "a dynamic UI app needs a way to model state changes". "Mutate" has a specific meaning, in my mind at least, when discussing variables and data structures. React enables avoidance of direct DOM manipulation, Redux obviates direct state mutation.
        DonHopkins 10y ago
        Also, "finite state machine" has a very specific meaning, and that isn't just any machine that has a finite bunch of variables that you call state. If React lets you execute arbitrary JavaScript code (which it does), then you're no longer using just a finite state machine, you're using a Turing machine, which is something different, and more powerful. It may have many finite state machines embedded in it, but to refer to a user interface as a finite state machine is like referring to a car as a pulley, just because the engine requires several pulleys to work, and ignoring all the rest of the engine and car. You can't make a car out of just pulleys, and you can't make a user interface out of just finite state machines.