3 ms·

Can anyone ELI5 the first sentence in each of the two above paragraphs please?

hinkley 7y ago
I can ELI20 easily enough. 5 is a bit tougher. Don’t make me look under every rock to figure out why you changed the stuff I gave you. We aren’t built to deal with chaos. When you put stuff in one end and something random comes out the other end, you have no idea at all what’s going on (until you do, and then they try to put you in charge). You want heaps of code that looks but doesn’t touch. Push the changes to the edges where they are easy to see. If I can trust that things in the middle aren’t mucking around with things all the time then lots of little methods don’t hurt my ability to think about what is happening. (This is not quite the point of Hexagonal Architecture, but they have some common ground. See also early Angular’s philosophy of cooking all input data immediately and passing it around cooked.)
- acemarke 7y ago
  Which is indeed one of the points of Redux. The more of your app you can write as pure functions, the more of it is predictable and easily testable, so you don't have to worry about how it's going to behave. That's part of why we now specifically recommend writing as much of your logic as possible in reducers: https://redux.js.org/style-guide/style-guide#put-as-much-logic-as-possible-in-reducers https://redux.js.org/style-guide/style-guide#put-as-much-log...
  - hinkley 7y ago
    I think as long as the mutators are cohesive, the design is more coherent to the users. In a purely pigeonhole principle sense, more pure code crowds out impure. But if you can put all of the impure code into one or two phases of an interaction, you’re improving things without really changing the ratios at all. We often get sucked into analogs of the things we really need and I feel like this is one of them. You want the state changes to be comprehended. Fewer of them might help a lot or make things worse (legibility or performance). I believe it’s another quality over quantity situation.

I can ELI20 easily enough. 5 is a bit tougher. Don’t make me look under every rock to figure out why you changed the stuff I gave you. We aren’t built to deal with chaos. When you put stuff in one end and something random comes out the other end, you have no idea at all what’s going on (until you do, and then they try to put you in charge). You want heaps of code that looks but doesn’t touch. Push the changes to the edges where they are easy to see. If I can trust that things in the middle aren’t mucking around with things all the time then lots of little methods don’t hurt my ability to think about what is happening. (This is not quite the point of Hexagonal Architecture, but they have some common ground. See also early Angular’s philosophy of cooking all input data immediately and passing it around cooked.)

acemarke 7y ago
Which is indeed one of the points of Redux. The more of your app you can write as pure functions, the more of it is predictable and easily testable, so you don't have to worry about how it's going to behave. That's part of why we now specifically recommend writing as much of your logic as possible in reducers: https://redux.js.org/style-guide/style-guide#put-as-much-logic-as-possible-in-reducers https://redux.js.org/style-guide/style-guide#put-as-much-log...
- hinkley 7y ago
  I think as long as the mutators are cohesive, the design is more coherent to the users. In a purely pigeonhole principle sense, more pure code crowds out impure. But if you can put all of the impure code into one or two phases of an interaction, you’re improving things without really changing the ratios at all. We often get sucked into analogs of the things we really need and I feel like this is one of them. You want the state changes to be comprehended. Fewer of them might help a lot or make things worse (legibility or performance). I believe it’s another quality over quantity situation.