What needs is view components solving for your project?

[khiga8]

Hi everyone!

Our team is in the early stages of rolling out view components to our Rails app and we're still figuring a lot of things out! We're loving it so far.

I've been thinking about view components from a more design-system standpoint with a focus on reusability, modularity, and bringing consistency to our UI.

Others in my team have been thinking about the benefits that view components can provide us in terms of testability, explicit API, validation etc. Even if a component is used once, view_component could provide a lot of testing benefits that aren't available in HAML, and may help us abstract out and test some of our more complex views even if it page specific and not reused. An idea that has been proposed is having view-specific components, and setting up a structure like:

app/components/common # for common use like modals, cards
app/components/app/user # components specific to user view page 

I'm having a harder time wrapping my head around single-use, page-specific components given how I traditionally think of components, but I can definitely see how view components may provide benefits that HAML alone lacks.

I would love to hear all of your thoughts!

1. What needs is view components solving for your project?
2. What criteria (if any) do you use when creating a component?
3. BONUS: When do you decide to create a view component vs a partial file?

[jaredcwhite]

I'm still experimenting with The Best Patterns(tm), but something that seems to feel pretty good is to first break up a large page (say a show.html.erb…or haml, etc.) into multiple partials in a subfolder, one for each main section. Then identify which parts of each main section can be turned into reusable components.

So the key for me is if you are using a partial more than once, and especially in many different contexts, then it probably should be promoted to component status. But if it's just something that's basically a smaller template to help to break up a larger template, remaining a partial seems fine to me.

[jaredcwhite]

Oh, and as far as your first question goes, I like the ViewComponent solution because it provides for OOP-style encapsulation at the view template level. With partials, you inherit the scope of the parent views and you can't guarantee what is provided to you, plus it's unclear where view-specific logic goes (other than helpers). (And testing/previewing in isolation is also difficult.)

With a component, it's like a mini-controller and a template got together and made their own little view logic baby. You can use and interact with that bundle of code anywhere without any adverse side-effects.

[khiga8]

With a component, it's like a mini-controller and a template got together and made their own little view logic baby. Y

Ha, that's a good way to put it! I see what you're saying. I've been so focused on the more design-system-y side of components, but there's a lot that view components can provide. There's a lot to explore!!! Thanks for chiming in!

(Side note: I came across this Ruby blend episode where there's a pretty in-depth discussion of view components and different forms of view components -- others might find it interesting!)