feat(base-components): add ability to remove ios and md theme

[liamdebeasi]

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Some docs updates need to be made in the ionic-docs repo, in a separate PR. See the contributing guide for details.
• Build (npm run build) was run locally and any changes were pushed
• Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

When Ionic was first created, it was incredibly valuable to have apps that looked like cookie cutter iOS and Android applications. As mobile designs evolve, it has become more valuable to have designs that a) match a company’s branding and b) are consistent across platforms. This puts Ionic’s theming system at odds with the design changes over the past several years.

Breaking this down further, there are two specific issues with theming in Ionic:

1. It is not easy to customize built-in components.

There is no way to “turn off” the built-in iOS or Android styling. This means that developers need to override every single CSS property on every single component. For scoped components, this also means ensuring that your CSS selectors are specific so that they can override the built-in styles (See: #17425).

2. Developers do not have the tools to build a consistent theme.

Even if developers had a way to “turn off” the built-in iOS or Android styling, Ionic is lacking in the tools to help developers build consistent and scalable themes. For example, it is common to have tools to control font styles across header texts, body texts, etc. Additionally, it is common to have tools to create consistent elevation levels (i.e. box shadow). While it is possible for each developer to build out this tooling themselves, this can be cumbersome to setup, especially on smaller development teams.

What is the new behavior?

This PR introduces a new experimental feature called "base components". Base components seek to solve the problem that it is not easy to customize built-in components. For example, customizing ion-toolbar is difficult because we add different style per-platform. On Android we add a box shadow, but on iOS we add a border. This means that the developer need to override multiple styles just to get a consistent theme.

Base components will solve this problem by giving developers an API that lets them disable iOS or MD specific styles while still getting the structural styles required for the components to be usable.

This PR is a combination of past PRs. This PR makes the following changes:

1. Introduces a baseComponents global config. This allows developers to opt-in all components/specific components to base components in their Ionic config.
2. Introduces the useBase virtual prop. This allows developers to opt specific instances of a component in/out of base components.
3. Adds the mode virtual prop to components that have mode-specific stylesheets but do not have the virtual prop already. This seems to have been done only on Ionic components designed to be used as child of other Ionic components (i.e. ion-segment-button, ion-menu). However, setting mode on these components still work so I think the virtual prop should be there.
4. Creates separate getIonStylesheet and getIonBehavior functions so Ionic Team members can check the visuals of a component separately from its behavior. getIonStylesheet is the new name for getIonMode.
5. Updates the setMode function to keep track of which components are using base components.

Note This feature is being introduced in "developer preview". As a result, it should not be used in production. This feature may change or be removed entirely at anytime, even outside of a major release.

Does this introduce a breaking change?

• Yes
• No

Other information

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sean-perkins]

Looks good to me. One callout about a potential any type we can make stricter.

[amandaejohnston]

Looking great, nice work! 🚀