Consider deprecating variants

[camertron]

Proposal

I propose we deprecate the variants feature and remove it entirely in v4.0 of the ViewComponent framework.

Rationale

The ViewComponent project has supported Action Pack variants since at least v1.16, which allow you to specify multiple templates per component. The component chooses which template to use on render based on the current request variant. Variants were designed to support rendering different markup for mobile vs desktop, etc.

Unfortunately, variants have proven difficult to maintain. In ViewComponent, they work by defining multiple #call_* methods on the component class. Let's look at one of the issues I ran into recently that was exacerbated by variants. Components can inherit from other components, and if the child supports a particular variant but the parent does not (or vice versa), calling super to render the parent can lead to NoMethodErrors. It would be simpler to implement parent rendering if the component only had a single #call method.

A few more issues:

1. Variants introduce complexity in our test suite. We have tests to make sure Slim and HAML work with variants, for example.
2. Variants add complexity to the compiler, which is already one of the more complicated classes in the framework.

In my opinion, variants are a complex feature to support that bring very little value. For one thing, it is possible to replicate the existing behavior using a simple if statement in a component's template. But an even more important consideration should be that the same markup should work for multiple screen sizes. These days, modern CSS is more than capable of adding and hiding elements at specific breakpoints.

Thoughts?

[boardfish]

I agree we should do away with variants, but there's definitely a pocket of folks in the community who are actively using the feature. I think it'd be good to make folks who have raised issues relating to the feature aware of this discussion.

[BlakeWilliams]

I'm in favor of removing variant support. I don't feel like the functionality fits well in component based architectures (implicit vs explicit) and it does make the framework code significantly more complex in a lot of cases.

In general, I feel like most uses could be replaced with:

<% if variant == :mobile %>
  <% render Mobile::PageComponent %>
<% else %>
  <% render PageComponent %>
<% end %>

I like how explicit that is and how easy it is to reason about what will be rendered on the page.

I don't use this functionality myself, so I'd love to hear from folks who are using it and what your use-cases are. I'd also like to hear from folks who actively decided not to use variants too.

[adrienpoly]

I have been using variants mostly as a versioning system when as I example I was building a new design of an app. The views and components would have this (:new) variant. The main advantage of this solution vs a new file name, is that all I18n remains the same and I don’t have to worry about fixing all translation keys paths.

If this feature is removed could it be replaced by some kind of versioning system of the component ?

[Spone]

What about namespacing them? (V1::ButtonComponent...) That's what Primer does with Alpha and Beta namespaces.

Can you elaborate on the translation keys paths issue? If you're using relative paths it's not really a problem, right?

[Spone]

I've never used the variants feature in Rails, and I can't really find any use case for them in the applications I'm working on (and some are pretty large design systems).

Building a ButtonComponent that can render different HTML whether it's used in a web page or a mailer? I would probably end up having several components in this case, so I'd simply put them in their own namespace, such as Emails::ButtonComponent.

We're always trying to keep the markup the same whether it's viewed on mobile or desktop. I feel like the mobile/desktop variants in Rails are kind of a relic of ancient times, when we built separate "low-def" mobile websites.

I'm fine with deprecating variants in ViewComponent, especially since keeping it brings quite a lot of overhead when refactoring or building new stuff. I'd love hearing more about specific use cases, though!