Draft: Experiment using ViewComponent instead of two partials
What does this MR do?
This experimentally introduced ViewComponent in the project and replaces two partial with view components.
View components have a few advantages (as explained at https://viewcomponent.org/motivation.html):
Testing
Unlike traditional Rails views, ViewComponents can be unit-tested. In the GitHub codebase, ViewComponent unit tests take around 25 milliseconds each, compared to about six seconds for controller tests.
Rails views are typically tested with slow integration tests that also exercise the routing and controller layers in addition to the view. This cost often discourages thorough test coverage.
With ViewComponent, integration tests can be reserved for end-to-end assertions, with permutations and corner cases covered at the unit level.
Data Flow
Traditional Rails views have an implicit interface, making it hard to reason about what information is needed to render, leading to subtle bugs when rendering the same view in different contexts.
ViewComponents use a standard Ruby initializer that clearly defines what is needed to render, making them easier (and safer) to reuse than partials.
Performance
Based on our benchmarks, ViewComponents are ~10x faster than partials.
Standards
Views often fail basic Ruby code quality standards: long methods, deep conditional nesting, and mystery guests abound.
ViewComponents are Ruby objects, making it easy to follow (and enforce) code quality standards.
IMO the main argument is the Data Flow one, as it ensures views have a clear interface and can thus be easily tested.
Screenshots (strongly suggested)
| View | Partial | View component |
|---|---|---|
| Wiki clone panel |  |
 |
| Admin labels |  |
 |
| Group labels |  |
 |
| Project labels |  |
 |
Does this MR meet the acceptance criteria?
Conformity
-
📋 Does this MR need a changelog?-
I have included a changelog entry. -
I have not included a changelog entry because _____.
-
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team