3 ms·

>The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the co

by rtpg 12y ago

>The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the code without breaking the view: They have to be maintained completely in sync with each other As someone working on a team that practices a good amount of separation of concerns, this is patently false. This is more dependent on how good your template language is than anything, but this separation helps to assure that we're not introducing new bugs or the like. The main arguments for React along what you're saying is that people seem to abuse the "view model" concept. It's rarely as necessary as people seem to want to make it (though again, dependent on template language).

lobster_johnson 12y ago
The fact that you're able to do it doesn't mean it's a good idea. On the contrary, I believe it's a bad idea. It has nothing to do with how good your template language is. It's simply that a controller's main controller (not talking about partials here) has an implicit dependency on the controller, and the controller has a dependency on the template. Unlike, say, data models, the relationship is not unidirectional. But really, what is this separation for? What does it gain us? We generally separate stuff out into declarations and files because it gains us modularity ("separation of concerns") and reusability. Data models are constantly reused, for example, as are views. But that one template belonging exclusively to the controller isn't reusable. It's separated out for no particular reason other than the fact that, historically, it has been expressed in a different language and must be parsed and "compiled" separately, so it has not been about "concerns" but about implementation details. React removes that step, and because the template is unequivocally tied to the controller, there is nothing gained by separating them. The point of React is that the "template" is the component. The component's rendering is intimately tied to how its internal state and data model is wired up because the one half wouldn't work without the other, and vice versa. (As an aside, in a well-designed, pure component, there is little state and the component is mostly template, anyway.) (As an aside, most template languages don't even let you validate a template's inputs — that is, declaring that it requires specific named inputs and what their types/structure are. No idea why, seems pretty obvious defensive functionality to me. But React does this.)

by rtpg 12y ago

lobster_johnson 12y ago

The fact that you're able to do it doesn't mean it's a good idea. On the contrary, I believe it's a bad idea. It has nothing to do with how good your template language is. It's simply that a controller's main controller (not talking about partials here) has an implicit dependency on the controller, and the controller has a dependency on the template. Unlike, say, data models, the relationship is not unidirectional. But really, what is this separation for? What does it gain us? We generally separate stuff out into declarations and files because it gains us modularity ("separation of concerns") and reusability. Data models are constantly reused, for example, as are views. But that one template belonging exclusively to the controller isn't reusable. It's separated out for no particular reason other than the fact that, historically, it has been expressed in a different language and must be parsed and "compiled" separately, so it has not been about "concerns" but about implementation details. React removes that step, and because the template is unequivocally tied to the controller, there is nothing gained by separating them. The point of React is that the "template" is the component. The component's rendering is intimately tied to how its internal state and data model is wired up because the one half wouldn't work without the other, and vice versa. (As an aside, in a well-designed, pure component, there is little state and the component is mostly template, anyway.) (As an aside, most template languages don't even let you validate a template's inputs — that is, declaring that it requires specific named inputs and what their types/structure are. No idea why, seems pretty obvious defensive functionality to me. But React does this.)