Vue Composition API preferences

Description

With the introduction of Vue 2.7, we will now have access to Vue new composition API, which means that a new pattern is going to be introduced to the frontend codebase. The composition API has many benefits over the options API, but is less opinionated/structured than the Options API (which is the default, currently in used API with computed, methods, etc). @ntepluhina already has documented the how to build components with the Composition API, so this RFC should only focus as to the when should we use one or the other (or if we even need these guidelines!).

Before diving into this RFC, I would recommend reading through Vue own FAQ on the matter, which even has a section of tradeoffs: https://vuejs.org/guide/extras/composition-api-faq.html

Goal

This RFC goal is not to deprecate/prohibit one way or the other. The reality is that all our current components are written with the Options API, but the composition API offers many benefits and will be used in our codebase. The discussions, therefore, should be focused on:

Should we allow existing components to be have both the Options and Composition API at the same time?
Should new component be written exclusively with the Composition API?
Should new component be written exclusively with the Options API _unless_there is a need for the Composition API?
Should renderless components be deprecated in favour of the Composition API?
Should mixins be deprecated in favour of the Composition API? (The only right answer is yes)
What set of rules should be put in place as far as linting goes? (@markrian made an excellent point that some rules already exist from the Vue team and we should implement them defacto (things like: https://eslint.vuejs.org/rules/no-lifecycle-after-await.html)
Is supporting both the Options API and Composition API potentially dividing in our codebase (some teams stick with Options, others use Composition)
Any other questions that are raised by this discussion

Edited Jun 30, 2022 by Frédéric Caplette