4 ms·

> I don't already understand how an app using redux works when it reaches a decent size; therefore don't know what problems it will have and need to learn more

> I don't already understand how an app using redux works when it reaches a decent size; therefore don't know what problems it will have and need to learn more This sounds like a problem of inexperience (which is a problem everyone faces when using a new tool). If you've never used Rails, you're not going to understand the long term implications of maintaining and scaling a complex Rails application. If you want to know what problems you will encounter, you'll have to read a book or learn the hard way, the same as any other tool. > I can't start using redux to understand those problems without making important architectural choices early on, This means you're not experienced enough with redux to be making those choices and that's ok; use an alternative tool that you understand well, hire someone with the relevant experience, read a book, or understand that you'll have to do some refactoring later on if you make the wrong choices today. > redux on its own seems to need about ten packages before you can load information from a json api and pass it to react, a task which is the basis for most toy apps; therefore, every toy app I write seems bloated and heavyweight This is not correct, but also "not even wrong" in the sense that this concern is outside the scope of redux. If you want to use a bunch of redux related data packages that's fine, you're also free to use GraphQL, Backbone, fetch, jquery, webosckets or straight up XMLHttpRequest. When I hear "I need 100 packages just to do X" it's usually a sign to me that the developer is somewhat inexperienced with the ecosystem and tends to defer to a package whenever they need to solve a problem; this is usually the wrong approach, it's like someone complaining "I need 10 packages just to do string padding"... well no, you don't, just write that code yourself. > It's a hard ecosystem to bootstrap yourself into. So is cross-platform game programming and there are hundreds of different engines, toolkits, SDKs, editors and other utilities spread across a dozen different languages. Which one should you choose? I don't know it's all too confusing, they should just stop making new tools so I can catch up.

strken 9y ago
> This means you're not experienced enough with redux to be making those choices This is the fundamental problem. In order to learn Redux, you need experience with it. In order to get experience, you need to work with Redux. In order to work with Redux, you need to learn it. You use the example of Rails, but Rails is the poster child of opinionated frameworks. For someone trying to learn it, there's no ambiguity about how a project is structured. The same is true of Unity or the UDK: there's a single tech choice to make, after which you can rely on the framework to guide you. I understand that the js community prefers small composable libraries, and agree with the reasoning, but with Redux this is taken to extremes: a tiny core library, documentation that's mostly boilerplate, and much greater cognitive overhead than any other state management.
- acemarke 9y ago
  I opened up an issue earlier this year to discuss possible ways to improve the experience for new Redux users, and additional useful abstractions that could be built on top of Redux: https://github.com/reactjs/redux/issues/2295 https://github.com/reactjs/redux/issues/2295 . If you've got feedback or comments, I'd encourage you to contribute them to that discussion. Also, as unofficial keeper of the Redux docs, I'd also appreciate any suggestions for improving them. Can you clarify what you mean by "documentation that's mostly boilerplate? If you're looking for more of an "integrated" Redux experience, you might want to look at https://kea.js.org/ https://kea.js.org/ .
  - strken 9y ago
    I'm actually already using Kea. Thanks for the suggestion, it's an awesome project! By boilerplate I mean that the docs are written using examples of e.g. a single network request and a handful of actions, where even a small application with a few repeated bits of code would introduce abstractions for common elements. Because the docs lay out the simplest possible way to do this, they don't fully represent a real app, and because the ecosystem is so vast, it's not obvious which abstractions are state-of-the-art. Filling in the "next steps" tab with some hints about where to go would probably help a lot.
    - acemarke 9y ago
      Huh. Indeed, that "Next Steps" page never has been created. That's an excellent suggestion, thank you. I just opened up https://github.com/reactjs/redux/issues/2626 https://github.com/reactjs/redux/issues/2626 to cover adding that docs page. If you or anyone else reading would like to contribute writing that page, please leave a comment and let me know! And yes, it's always tough to balance the various audiences and use cases when writing docs. Minimal examples like a TodoMVC can be helpful for showing off basic concepts and keeping a learner from getting too lost, but then those don't cover the complexities of a real-world app.
    - acemarke 9y ago
      Actually have a request for you, now that I think of it. Like most of the addons I've catalogued, I haven't had a chance to play with Kea myself. I'd be curious to hear your thoughts on how useful it is, how it compares to using "plain" Redux, and so on. Please leave a comment here, or catch me on Reactiflux.

strken 9y ago

> This means you're not experienced enough with redux to be making those choices This is the fundamental problem. In order to learn Redux, you need experience with it. In order to get experience, you need to work with Redux. In order to work with Redux, you need to learn it. You use the example of Rails, but Rails is the poster child of opinionated frameworks. For someone trying to learn it, there's no ambiguity about how a project is structured. The same is true of Unity or the UDK: there's a single tech choice to make, after which you can rely on the framework to guide you. I understand that the js community prefers small composable libraries, and agree with the reasoning, but with Redux this is taken to extremes: a tiny core library, documentation that's mostly boilerplate, and much greater cognitive overhead than any other state management.

acemarke 9y ago
I opened up an issue earlier this year to discuss possible ways to improve the experience for new Redux users, and additional useful abstractions that could be built on top of Redux: https://github.com/reactjs/redux/issues/2295 https://github.com/reactjs/redux/issues/2295 . If you've got feedback or comments, I'd encourage you to contribute them to that discussion. Also, as unofficial keeper of the Redux docs, I'd also appreciate any suggestions for improving them. Can you clarify what you mean by "documentation that's mostly boilerplate? If you're looking for more of an "integrated" Redux experience, you might want to look at https://kea.js.org/ https://kea.js.org/ .
- strken 9y ago
  I'm actually already using Kea. Thanks for the suggestion, it's an awesome project! By boilerplate I mean that the docs are written using examples of e.g. a single network request and a handful of actions, where even a small application with a few repeated bits of code would introduce abstractions for common elements. Because the docs lay out the simplest possible way to do this, they don't fully represent a real app, and because the ecosystem is so vast, it's not obvious which abstractions are state-of-the-art. Filling in the "next steps" tab with some hints about where to go would probably help a lot.
  - acemarke 9y ago
    Huh. Indeed, that "Next Steps" page never has been created. That's an excellent suggestion, thank you. I just opened up https://github.com/reactjs/redux/issues/2626 https://github.com/reactjs/redux/issues/2626 to cover adding that docs page. If you or anyone else reading would like to contribute writing that page, please leave a comment and let me know! And yes, it's always tough to balance the various audiences and use cases when writing docs. Minimal examples like a TodoMVC can be helpful for showing off basic concepts and keeping a learner from getting too lost, but then those don't cover the complexities of a real-world app.
  - acemarke 9y ago
    Actually have a request for you, now that I think of it. Like most of the addons I've catalogued, I haven't had a chance to play with Kea myself. I'd be curious to hear your thoughts on how useful it is, how it compares to using "plain" Redux, and so on. Please leave a comment here, or catch me on Reactiflux.