3 ms·
Yeah, unfortunately once something gets a large community, it takes on a life of its own. Part of the issue is that the Redux docs _do_ show many of these patt
by acemarke 7y ago
Yeah, unfortunately once something gets a large community, it takes on a life of its own.
Part of the issue is that the Redux docs _do_ show many of these patterns (`const ADD_TODO = "ADD_TODO"`, separate files and folders for constants / actions / reducers, etc). Dan has said several times that he didn't expect folks to literally mimic everything that was shown in the docs, but tbh that's what people do. He's also said he wishes he'd emphasized teaching it in some different ways.
We're doing everything we can to try to teach better practices and patterns now, but that can't magically change the gazillions of existing tutorials and codebases that are out there.
- JMTQp8lwXL 7y ago> didn't expect folks to literally mimic everything that was shown in the docs Isn't that the point of documentation? To give you a reasonable, suggested way of incorporating a library into an existing project? This is almost saying, "the docs were wrong and everyone learned the wrong thing". I don't think you can blame package users for that. People reference documentation to know what to do, and also what to avoid, when using a new library.
- acemarke 7y agoYeah, I know. I'm not blaming Dan here, specifically, just repeating what he's said several times himself. That's why we're doing the docs rewrite. The target audiences have changed since 2015 (new devs learning Redux in a bootcamp vs folks coming from other Flux libraries), we've got a better understanding of how Redux should be used, and we want to set folks on a better path from the beginning.
- randompi 7y agoPeople need standardization. The docs are usually the source of truth or go-to for any disputes. Whatever's written there is the best practice since literally everyone who uses it would have read it.