4 ms·

There's a huge difference between global state in C and redux, though - redux state is immutable and updated atomically. And immutable state really is a game ch

by robto 7y ago

There's a huge difference between global state in C and redux, though - redux state is immutable and updated atomically. And immutable state really is a game changer in reducing complexity. When you're just dealing with functions and data, I don't know how it could get more simple. I know that it has made my code much more readable, testable, and organized.

kerkeslager 7y ago
> redux state is immutable and updated atomically. Immutability certainly makes it less harmful, but it still means that a function in one area of the codebase can modify the global state and affect a completely different area of the codebase. Atomicity is basically a meaningless buzzword in this situation, given JavaScript doesn't have parallelism.[1] > When you're just dealing with functions and data When you're just dealing with functions and data, you aren't using Redux, so really anything you have to say after that isn't relevant. At the end of the day, you can make all these mistakes yourself if you want, but you'd be better served by listening to the programmers of the past and learning from their mistakes instead. [1] What you're actually talking about is the fact that the entire transition is executed in the same event, which isn't the same thing as atomicity, but is actually somewhat useful because it works around the horrible things JS programmers often do that make it difficult to tell what order state transitions will be executed in, despite being in a single-threaded environment. However, the fact that it enables inserting state transitions into utterly untraceable code is hardly a point in Redux's favor if you want your code to be traceable in the first place.
- acemarke 7y ago
  One of the core points of Redux is that all the state update logic gets combined into a single reducer function. How you choose to split the reducer logic into multiple files is up to you, so it may be separated in _that_ sense, but it's ultimately all getting pulled into one spot. So no, you don't have random "functions modifying global state and affecting different areas". And no, it's not "untraceable code". Redux is explicitly meant to make it much easier to trace when, where, why, and how your state has been updated. All state changes happen via reducer functions (not random pieces of code somewhere in your UI logic), and the state updates themselves can be viewed using the Redux DevTools (which can now even give a stack trace for every individual dispatched action).
  - kerkeslager 7y ago
    > All state changes happen via reducer functions Which are called where? > and the state updates themselves can be viewed using the Redux DevTools (which can now even give a stack trace for every individual dispatched action). So now we've added a second tool to fix the problem caused by the first tool.
    - acemarke 7y ago
      You don't seem to actually understand how Redux works. All interactions revolve around "dispatching" an action to the store. The root reducer function is called as part of that `dispatch()` sequence. This gives a central point that allows tracing the resulting state changes: store.dispatch({type: "INCREMENT"}) The store can be configured on app startup to enable the Redux DevTools browser extension to automatically log all dispatched actions, including showing the action types and viewing the results of each dispatched actions (action contents, resulting state, and state diff vs the previous state). This isn't "fixing a problem" with Redux, this is a core designed capability to allow you to understand how your app is behaving.
      - kerkeslager 7y ago
        Again, I'm going to ask, where are you calling `store.dispatch({type: 'INCREMENT'})`? You're saying I can't modify global state and have effects on a completely different area of the code, but I'm saying, yes, you can. All you're doing is telling me about the fairly-pointless layers of indirection Redux adds. Adding a layer of indirection doesn't solve the problem.

by robto 7y ago

kerkeslager 7y ago

> redux state is immutable and updated atomically. Immutability certainly makes it less harmful, but it still means that a function in one area of the codebase can modify the global state and affect a completely different area of the codebase. Atomicity is basically a meaningless buzzword in this situation, given JavaScript doesn't have parallelism.[1] > When you're just dealing with functions and data When you're just dealing with functions and data, you aren't using Redux, so really anything you have to say after that isn't relevant. At the end of the day, you can make all these mistakes yourself if you want, but you'd be better served by listening to the programmers of the past and learning from their mistakes instead. [1] What you're actually talking about is the fact that the entire transition is executed in the same event, which isn't the same thing as atomicity, but is actually somewhat useful because it works around the horrible things JS programmers often do that make it difficult to tell what order state transitions will be executed in, despite being in a single-threaded environment. However, the fact that it enables inserting state transitions into utterly untraceable code is hardly a point in Redux's favor if you want your code to be traceable in the first place.

acemarke 7y ago
One of the core points of Redux is that all the state update logic gets combined into a single reducer function. How you choose to split the reducer logic into multiple files is up to you, so it may be separated in _that_ sense, but it's ultimately all getting pulled into one spot. So no, you don't have random "functions modifying global state and affecting different areas". And no, it's not "untraceable code". Redux is explicitly meant to make it much easier to trace when, where, why, and how your state has been updated. All state changes happen via reducer functions (not random pieces of code somewhere in your UI logic), and the state updates themselves can be viewed using the Redux DevTools (which can now even give a stack trace for every individual dispatched action).
- kerkeslager 7y ago
  > All state changes happen via reducer functions Which are called where? > and the state updates themselves can be viewed using the Redux DevTools (which can now even give a stack trace for every individual dispatched action). So now we've added a second tool to fix the problem caused by the first tool.
  - acemarke 7y ago
    You don't seem to actually understand how Redux works. All interactions revolve around "dispatching" an action to the store. The root reducer function is called as part of that `dispatch()` sequence. This gives a central point that allows tracing the resulting state changes: store.dispatch({type: "INCREMENT"}) The store can be configured on app startup to enable the Redux DevTools browser extension to automatically log all dispatched actions, including showing the action types and viewing the results of each dispatched actions (action contents, resulting state, and state diff vs the previous state). This isn't "fixing a problem" with Redux, this is a core designed capability to allow you to understand how your app is behaving.
    - kerkeslager 7y ago
      Again, I'm going to ask, where are you calling `store.dispatch({type: 'INCREMENT'})`? You're saying I can't modify global state and have effects on a completely different area of the code, but I'm saying, yes, you can. All you're doing is telling me about the fairly-pointless layers of indirection Redux adds. Adding a layer of indirection doesn't solve the problem.