3 ms·
This makes sense to me. And it also seems notable to me that Rails (which I generally like; I am not a Rails hater this is not a Rails hate comment) -- often s
by jrochkind1 5y ago
This makes sense to me.
And it also seems notable to me that Rails (which I generally like; I am not a Rails hater this is not a Rails hate comment) -- often seems to be trying to do the opposite. Like separating a controller and it's view code -- things which in the typical Rails app are pretty tightly coupled -- into the higher level controllers and views folders, putting all controllers next to each other and all views next to each other, instead of a controller next to it's coupled view. (which I do find an inconvenience as a developer).
But the risingly popular view_component library for use with Rails makes the 'proximate' choice, putting the view template(s) next to the logic it's coupled to.
- rubyist5eva 5y agoas a rails dev, I agree with this, instead of app->{models/views/controllers}->resource, I would prefer app->resource->{models/views/controllers}
- Ixio 5y agoThis is kind of what Django does instead and I much prefer the Rails way. Though it might just be because I started MVC-dev with Rails. I think I find it easier to find common abstractions on the {models/views/controllers} level than the resource level and that frustrates me with Django app-based dev.
- jrochkind1 5y agoInteresting, because I realize I would not personally want that done with models, in my apps models/controllers frequently don't have a 1-1 relationship. But controllers and view templates almost always do, because of the nature of the architecture. So actually just using the `view_component` gem for all my views from now on (not just partials) probably satisfies me!
- rubyist5eva 5y agoI don’t see what the benefit to view components are over simple views and partials though?