4 ms·

Hi, I'm a Redux maintainer. Anything specific that confused you? Which tutorials were you looking at? We're currently planning a revamp of the Redux docs. I

Hi, I'm a Redux maintainer. Anything specific that confused you? Which tutorials were you looking at? We're currently planning a revamp of the Redux docs. I'd really appreciate any feedback on what things caused problems, so we can know how to make the docs better. Feel free to comment here, or ping me on Twitter or in the Reactiflux chat channels. I've also got a survey open asking for suggestions on docs structuring: https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYMK0YoEgALfAK2qQ0mOj1_ibKv2qDTuQ/viewform https://docs.google.com/forms/d/e/1FAIpQLSfzIkY3fXZ8PrQKScYM... Also, fwiw, you may be interested in my suggested resources for learning Redux: https://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-redux/ https://blog.isquaredsoftware.com/2017/12/blogged-answers-le...

freehunter 8y ago
It wasn't the Redux docs, it was the entire mindframe of Redux. This connects to that which connects to that and sets this while this gets that. Like I said, I'm a terrible programmer and I have a hard time keeping complex interactions in my mind. If this block of code needs to change a variable, I want it to just change the variable right there and move on. Having to write the code that needs to change the variable, then switching to another file to write the code that actually changes the variable, then switching to another file to write the code that returns that new variable to my original function is just... so damn unnecessary. There's just too many moving parts that can (and do) break. It's so complex, and when something doesn't work I struggle to debug why. I will admit I did not choose to use Redux, it was part of a tutorial I was following on Udemy. I never got the hang of it, and once I figured out React Native well enough, I quickly scaled back my reliance on Redux. It's made my life a lot easier. My day job is a technical consultant for a major tech company, and we have meetings to discuss the meeting we're going to have before the meeting. The administrative overhead of Redux reminds me of that in a very bad way. Instead of my Facebook login button calling auth_actions.js which then returns the auth token to auth_reducer.js which then returns the auth token to auth_screen.js (but don't forget to add it to the combineReducers in index.js), I just put the authentication code in 'await doAuth()' inside of the auth_screen.js file. I've never heard a convincing reason as to why I shouldn't do that, even though the tutorial I followed said it's a bad idea.
askmike 8y ago
[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.

freehunter 8y ago

It wasn't the Redux docs, it was the entire mindframe of Redux. This connects to that which connects to that and sets this while this gets that. Like I said, I'm a terrible programmer and I have a hard time keeping complex interactions in my mind. If this block of code needs to change a variable, I want it to just change the variable right there and move on. Having to write the code that needs to change the variable, then switching to another file to write the code that actually changes the variable, then switching to another file to write the code that returns that new variable to my original function is just... so damn unnecessary. There's just too many moving parts that can (and do) break. It's so complex, and when something doesn't work I struggle to debug why. I will admit I did not choose to use Redux, it was part of a tutorial I was following on Udemy. I never got the hang of it, and once I figured out React Native well enough, I quickly scaled back my reliance on Redux. It's made my life a lot easier. My day job is a technical consultant for a major tech company, and we have meetings to discuss the meeting we're going to have before the meeting. The administrative overhead of Redux reminds me of that in a very bad way. Instead of my Facebook login button calling auth_actions.js which then returns the auth token to auth_reducer.js which then returns the auth token to auth_screen.js (but don't forget to add it to the combineReducers in index.js), I just put the authentication code in 'await doAuth()' inside of the auth_screen.js file. I've never heard a convincing reason as to why I shouldn't do that, even though the tutorial I followed said it's a bad idea.

askmike 8y ago

[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.