3 ms·

Yeah, I guess I'm not giving the documentation enough credit here. The main issue I see is all the companies rewriting their applications in React. Because I do

Yeah, I guess I'm not giving the documentation enough credit here. The main issue I see is all the companies rewriting their applications in React. Because I don't think they see it as a complicated engineering decision with tradeoffs and potential issues. They see it as "we need x buzzword and y buzzword". I'd prefer that the documentation outright say "This is a BAD idea if you're just doing xyz" instead of "if you need, you can check out this". Because it's very easy for developers, especially magpie developers or younger developers to think "oh yeah, of course I need this. I need my app to be S C A L E Able". The idea behind the tutorial would be giving precise problems that are solved by the tools, while also demonstrating what can be accomplished without them. Also, is it just me or is the tic tac toe tutorial really not useful? Sure, it's a good isolated example, but it's a really contrived one as well. Something like an address book or a blog would be a lot more fitting with people's usecases.

mephitix 8y ago
>> I'd prefer that the documentation outright say "This is a BAD idea if you're just doing xyz" instead of "if you need, you can check out this". That's a good point - I wonder if devs think enough about when not to use the tools they build. I was about to mention that the Redux docs do this but the only thing I could find was the 'Before Proceeding Further' section on the first page. I think my impression came from Dan/Mark's tweets and articles, like this one: "You Might Not Need Redux" [0]. But even that article talks about all the benefits of Redux first :) >> Also, is it just me or is the tic tac toe tutorial really not useful? I agree it's contrived. Building a game I think is a good way to get introduced to working with state in a slightly more complex and interesting way. React is at its heart all about rendering a state machine. It's up to you how to represent that state machine - either as primitive state, context provider, or redux. Personally I'm not a fan of address book examples but that's just because I've seen so many of them they don't hold my interest... [0]: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
acemarke 8y ago
Writing docs is hard. To quote Dan from when he was writing the initial Redux docs: > So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone” Both React and Redux introduce a lot of new concepts for someone coming from a typical jQuery / Backbone-type background. The larger the example apps you show, the more potential there is for them to get lost on what concepts are actually relevant (which is actually part of what Brad was saying in the original linked post for this discussion). The docs for both React and Redux are open for PRs. If you feel that we need to have sections that better lay out the pros, cons, and reasons to use React and Redux, please submit a PR and we can figure out the best solution from there.

mephitix 8y ago

>> I'd prefer that the documentation outright say "This is a BAD idea if you're just doing xyz" instead of "if you need, you can check out this". That's a good point - I wonder if devs think enough about when not to use the tools they build. I was about to mention that the Redux docs do this but the only thing I could find was the 'Before Proceeding Further' section on the first page. I think my impression came from Dan/Mark's tweets and articles, like this one: "You Might Not Need Redux" [0]. But even that article talks about all the benefits of Redux first :) >> Also, is it just me or is the tic tac toe tutorial really not useful? I agree it's contrived. Building a game I think is a good way to get introduced to working with state in a slightly more complex and interesting way. React is at its heart all about rendering a state machine. It's up to you how to represent that state machine - either as primitive state, context provider, or redux. Personally I'm not a fan of address book examples but that's just because I've seen so many of them they don't hold my interest... [0]: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

acemarke 8y ago

Writing docs is hard. To quote Dan from when he was writing the initial Redux docs: > So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone” Both React and Redux introduce a lot of new concepts for someone coming from a typical jQuery / Backbone-type background. The larger the example apps you show, the more potential there is for them to get lost on what concepts are actually relevant (which is actually part of what Brad was saying in the original linked post for this discussion). The docs for both React and Redux are open for PRs. If you feel that we need to have sections that better lay out the pros, cons, and reasons to use React and Redux, please submit a PR and we can figure out the best solution from there.