3 ms·

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

by pault 8y ago

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.

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

by pault 8y ago

kerkeslager 8y ago

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.

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