[Task](ui): collect established practices and conventions

[franzheidl]

This task is to collect our findings and document established practices and conventions in the Juno ui-components codebase.

These are practices and conventions we have established over time building ui-components , they may be adhered to throughout some, most or all of our existing components, but have never been documented properly anywhere.

These should inform the future development of components. They refelct what we have been doing and intend to keep doing, however they are not cast in stone and may change over to time, but we should do so intentionally, and not by accident or somebody's preferred AI-assistent told them otherwise.

In the future, the practices collected here may inform AI-tooling to check whether a component is compliant, and as such become a part of our Definition of Done contract.

This is a Work In Progress.

Components

Each component should:

• render a root node with a juno-foo identifier class
• use the correct semantic elements (when applicable)
• render state-describing identifier classes that extend the base identifier class (e.g. juno-foo-disabled, juno-foo-selected)
• for componts that render semantic variants, render a variant-describing identifier class based on the component identifier class added to the root node (e.g. juno-foo-error, juno-foo-warning)
• each component needs to respect the Rule of Hooks if hooks are used
• preferably use tailwind-based classes in string literals named fooBarStyles (camel case)
• only resort to external css files if they make styling much easier or readable, or to implement styling that is impossible to do with tailwind

Stories

• Each component as a minimum should have a Default story that shows the component without any additional props or configuration, if sensible.
• If not sensible, or the component requires some configuration, props, context, etc. in order to render anything meaningful, these should be demonstrated and explained, showing a simple use case with at least basic real-world value. (In these cases we should consider using sensible defaults in order to keep their number at a minimum).

Tests

• Each component should have a smoke test that
  • tests whether the component renders as expected without any additional props
  • tests whether the component renders an juno-foo identifier class at its root node
  • tests whether the component renders the correct semantic elements using role (if applicable)