4 ms·
But you certainly can NOT do that. You can write "smart" components that each talk to the necessary store(s) and make decisions. As your project grows, you'll
by ergothus 11y ago
But you certainly can NOT do that. You can write "smart" components that each talk to the necessary store(s) and make decisions.
As your project grows, you'll come to see WHY small, dumb components are helpful, and how the top-down view manages the scope of rerendering.
You can come around to the espoused best practices organically.
- dsp1234 11y agoYou can come around to the espoused best practices organically. As I said before, it's reasonable that some people are not going to like these particular best practices, and that in some instances it's going to get in the way. As a concrete example, I just put up a form that is basically just a SSR datatables.net table and a save button. Adding react into the mix is literally unnecessary, and just adds boilerplate/extra code for no gain. In other words, it gets in the way. So I chose not to use it.
- apalmer 11y agoYou can but fundamentally, if you dont buy into the fundamental guiding principles that a framework is based on, you probably shouldn't use the framework. Its like saying lets use angular but not limit DOM manipulation in directives, build fat controllers that include direct requests to the server and business logic because all the service boiler plate is annoying and makes the application harder to reason about, and add objects directly to the global object because angulars dependency injection based on string values is error prone, not DRY, and kinda fool hardy, not use data binding because of the performance issues... yeah those may be valid points, but if you buy into that you should just drop angular and use backbone or something else...