Skip to content

Remove mixin from recommended approach in docs

Scott Stern requested to merge rm-mixin-from-docs into master

What does this MR do?

With Vue 3 migration coming up, we will need to move away from mixins. To which pattern? Im not sure, i have a few ideas but i think it should be discussed as a group. There has been some confusion in the last week, to use a mixin or to not. Hopefully by removing this from the docs we can start getting creative in different ways to approach the problem this pattern solves.

For more context and discussion please see: gitlab-org/frontend/rfcs#32 (closed)

What about the tracking and the FF mixin??

Great question, im glad you asked. I think until we have come to a conclusion about which pattern to use we hold on updating the docs/functionality on those 2 mixins. This way when a decision is made from the architecture side we have a clear path forward and can systematically phase out those 2 mixins and reimplement the approach with a pattern in mind.

Preferred personal solution:

  • Using a combination of renderless components and slots with CE component being the "base" on a decorator-like solution. Then wherever we are using the component we can import ee_else_ce and it will either pull the CE component with the slot that doesnt do anything OR the EE component that renders the CE component with the EE slot as a decorator. WIP MR that shows this pattern

Screenshots

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

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
Edited by Scott Stern

Merge request reports