refactor: Use component tokens within includes

[driskull]

Related Issue: #7180

Summary

• Uses component tokens within include files.
• Removes unused spacing file.
• Moves xButton mixin to its own file
• Converts header to a mixin
• removes animation import from some components (it only has mixins and functions)
• Further issues should be created to fix any components using heading or xButton
• Removes unused global vars

[alisonailea]

If we're going to keep using these we should convert them to @mixins with passable parameters so each component can use it's own variables.

[driskull]

If we're going to keep using these we should convert them to @Mixins with passable parameters so each component can use it's own variables.

Agreed. This could be done in any one of the following components for #7180 or in a follow up issue.

• block
• pick-list-group
• tip
• tip-manager

Combobox is the only component that uses xButton so it really shouldn't be in the includes. Ill move it to its own file.

[driskull]

@jcfranco @macandcheese whats the history of x-button? Shouldn't we just use a calcite-action or calcite-button instead? Not sure we need the xButton functional component.

Functional components should have their own CSS file as well. includes should be for more generic mixins.

[macandcheese]

I think it was built to eventually support all close affordances - accepting arguments for round, square, stretch to fill, etc. as needed, but seems like it hasn't been adopted much.

[alisonailea]

Input could also be a mixin, given there are so many very similar components

[jcfranco]

🕹️👾

[jcfranco]

Could you explicitly list the props that will be transitioned by state? Looks like it's color and background-color.

[jcfranco]

I thought we agreed to only inline Tailwind utils related to component tokens. FWIW, we can automate this step later to make it easier for review.