Replies: 1 comment
-
Personally, I see no reason not to favor components over partials 100% of the time, and here's why:
In theory, it's possible to use components in place of partials everywhere. In order to do so, you'd need to:
Something that might help you do this consistently is to ensure you have snapshot test coverage across partials, then repurpose those tests for components. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We have been using ViewComponents for a while now and really love them for things like design system components. We are using Tailwind, so it helps keep all of the design elements tight when we need to put a common design element on a page. Some examples of components that fit in this category are things like Tabs, Accordions, Alert Boxes, Pagination, Description Lists, and Tables.
However, one of the things I'm struggling with trying to decide is if we should switch all of our partials to use ViewComponents. For example, we might have a specific table with data (which uses a
TableComponent
to lay out the data) that we want to show on multiple pages. I'm not sure if that should be a ViewComponent or a partial. In some ways it feels like a partial since it is only used in very specific circumstances, but then ViewComponents also provide some other benefits like speed and testing. Keeping it as a partial also leaves our component system cleaner and maintains a focus on reusability.We are already leaving some partials in our app for things like a
_form.html.erb
since those are usually specific to just thenew
andedit
actions for a given controller.Where should we draw the line between using ViewComponents vs using partials? My gut is kind of telling me to just have the generic design system elements as ViewComponents and keep repeated content as partials, but I'm curious what other people are doing.
Beta Was this translation helpful? Give feedback.
All reactions