3 ms·

[not OP but I can remember feeling the same, also I haven't done a big redux project in about a year] I haven't looked at the docs in a while but I'm not sure

[not OP but I can remember feeling the same, also I haven't done a big redux project in about a year] I haven't looked at the docs in a while but I'm not sure that's where the big problem lies. The hard thing about Redux is that you need to "get" the core concepts (not that complex), and how they interplay with how (and when) React renders component subtrees (very complex - this requires a new understanding of react you didn't need before). After you learn React and finally "get" it you definitely won't get Redux. Not because of Redux perse, but because the way you structure your application is so different. After that you'll encounter more subjective questions like do we put this (semi localized) state in Redux? And there are no right answers anymore, just opinions. Also the boilerplate doesn't help.

acemarke 8y ago
Yeah, the docs can't solve everything, but I'm hoping we can improve the structure, the content, the reading flow, and how the prerequisite concepts are handled. As part of that, I definitely want to have new category sections on "Using Redux with a UI" (which would include both how that works in general, and specific pages for use with React, Angular, Vue, Ember, etc), and "Real World Usage" (which could cover things like app structure, code splitting, choosing a side effects approach, and so on). As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're thinking of when you say that? FWIW, we have a new package called `redux-starter-kit`, which is specifically intended to help simplify several common Redux use cases. It includes utilities that help with store setup, reducer definitions, immutable update logic, and even creating entire "slices" of state automatically without having to write any action types or action creators yourself. I'd encourage everyone to try it out, and let us know how much it helps improve your apps and what else ought to be included: https://redux-starter-kit.js.org/ https://redux-starter-kit.js.org/
- pbowyer 8y ago
  > As part of that, I definitely want to have new category sections on "Using Redux with a UI" (which would include both how that works in general, and specific pages for use with React, Angular, Vue, Ember, etc), and "Real World Usage" (which could cover things like app structure, code splitting, choosing a side effects approach, and so on). Those new sections sound awesome! Kudos for thinking about adding them to the docs.
  - acemarke 8y ago
    Sure! If you'd like to look at our plans and discussions, see these issues: https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/3313 https://github.com/reduxjs/redux/issues/3313 I'm particularly hoping to do some brainstorming about the revamped docs structure and content over the next couple days.
- askmike 8y ago
  > As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're thinking of when you say that? As stated before I haven't done a big JS project for about a year now. In the last project I did we used redux in a create-react-app. At the time the best practice was creating presentational and container components[1]. The biggest boilerplate was: - Whenever we added a react component (presentational) we would need to create a container component to wrap it in, this would always result in ~20 or basically the same lines (in our project we did things pretty verbose, so we didn't have a HoC or whatever people use). - "immutable update logic", reducing deeply nested objects is a pain an error prone (using es6 spread or Object.assign), I've heard about some libraries that can help with this, but we didn't use anything at the time). > FWIW, we have a new package called `redux-starter-kit` I am most definitely going to use this for an upcoming project! [1] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
  - acemarke 8y ago
    FWIW, I've always felt that having duplicate / parallel "container" and "component" folders/files just for the sake of separating them is completely overkill. Most components are only connected once - just do that in the same file and export the plain and connected versions separately. I wrote some thoughts on that here: https://gist.github.com/markerikson/ea312b5ee398627ffceb09f89904831f https://gist.github.com/markerikson/ea312b5ee398627ffceb09f8... Similarly, I'm actually thinking that in the upcoming Redux docs revamp, I'd like to have the tutorials and examples switch from a "folder-by-type" approach to either a "feature folder" or even a "ducks" approach, and maybe even cut down on having separate action constant variables. There's valid reasons to do things in multiple files, but it's also not _necessary_, and I want to simplify things. Yes, I totally agree immutable update logic is a pain to write and write correctly, which is why Immer is awesome, and why the starter kit uses Immer internally. My only concerns are that the code _is_ mutating unless you wrap it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to be hard to figure out how to teach this properly. But, in terms of LOC and simplicity, it's a huge win. Please let me know how well it works for you, and if you've got any other suggestions for what it should include!

acemarke 8y ago

Yeah, the docs can't solve everything, but I'm hoping we can improve the structure, the content, the reading flow, and how the prerequisite concepts are handled. As part of that, I definitely want to have new category sections on "Using Redux with a UI" (which would include both how that works in general, and specific pages for use with React, Angular, Vue, Ember, etc), and "Real World Usage" (which could cover things like app structure, code splitting, choosing a side effects approach, and so on). As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're thinking of when you say that? FWIW, we have a new package called `redux-starter-kit`, which is specifically intended to help simplify several common Redux use cases. It includes utilities that help with store setup, reducer definitions, immutable update logic, and even creating entire "slices" of state automatically without having to write any action types or action creators yourself. I'd encourage everyone to try it out, and let us know how much it helps improve your apps and what else ought to be included: https://redux-starter-kit.js.org/ https://redux-starter-kit.js.org/

pbowyer 8y ago
> As part of that, I definitely want to have new category sections on "Using Redux with a UI" (which would include both how that works in general, and specific pages for use with React, Angular, Vue, Ember, etc), and "Real World Usage" (which could cover things like app structure, code splitting, choosing a side effects approach, and so on). Those new sections sound awesome! Kudos for thinking about adding them to the docs.
- acemarke 8y ago
  Sure! If you'd like to look at our plans and discussions, see these issues: https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/3313 https://github.com/reduxjs/redux/issues/3313 I'm particularly hoping to do some brainstorming about the revamped docs structure and content over the next couple days.
askmike 8y ago
> As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're thinking of when you say that? As stated before I haven't done a big JS project for about a year now. In the last project I did we used redux in a create-react-app. At the time the best practice was creating presentational and container components[1]. The biggest boilerplate was: - Whenever we added a react component (presentational) we would need to create a container component to wrap it in, this would always result in ~20 or basically the same lines (in our project we did things pretty verbose, so we didn't have a HoC or whatever people use). - "immutable update logic", reducing deeply nested objects is a pain an error prone (using es6 spread or Object.assign), I've heard about some libraries that can help with this, but we didn't use anything at the time). > FWIW, we have a new package called `redux-starter-kit` I am most definitely going to use this for an upcoming project! [1] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
- acemarke 8y ago
  FWIW, I've always felt that having duplicate / parallel "container" and "component" folders/files just for the sake of separating them is completely overkill. Most components are only connected once - just do that in the same file and export the plain and connected versions separately. I wrote some thoughts on that here: https://gist.github.com/markerikson/ea312b5ee398627ffceb09f89904831f https://gist.github.com/markerikson/ea312b5ee398627ffceb09f8... Similarly, I'm actually thinking that in the upcoming Redux docs revamp, I'd like to have the tutorials and examples switch from a "folder-by-type" approach to either a "feature folder" or even a "ducks" approach, and maybe even cut down on having separate action constant variables. There's valid reasons to do things in multiple files, but it's also not _necessary_, and I want to simplify things. Yes, I totally agree immutable update logic is a pain to write and write correctly, which is why Immer is awesome, and why the starter kit uses Immer internally. My only concerns are that the code _is_ mutating unless you wrap it in RSK's "magic" `createReducer` utility that uses Immer, and it's going to be hard to figure out how to teach this properly. But, in terms of LOC and simplicity, it's a huge win. Please let me know how well it works for you, and if you've got any other suggestions for what it should include!