Description

Currently, the RemixApp injects styles globally, causing every component to inherit a monolithic style. This approach reduces the composability of individual widgets, as all components become tightly coupled with a global style rather than being self-contained. To resolve this, we propose localizing style definitions within each widget, ensuring that components manage their own styles.

Proposed Changes

Embed styles directly within individual components (e.g., PrimaryButton, SecondaryButton) instead of relying on global style injection. It will reduces monolithic dependencies in RemixApp, making the system more modular and maintainable

Before
Styles were globally managed in RemixApp.theme, where all components retrieved their styles from the context:

RemixThemeData(
  components: RemixComponentsData(
    button: CustomButtonStyle(),
  ),
),

After
Components now define their own styles locally, removing dependency on global styles:

class GhostButton extends Button {
  const GhostButton({
    super.key,
    // all button props
  }) : super(variants: const [_BaseButtonStyle.ghost], style: CustomButtonStyle());
}

Impact Analysis

Benefits:

• Clearer separation of concerns with self-contained styles.

Potential Drawbacks:

• Lose the support for multi component tokens.

Implementation Plan

Tasks:

1. Design and implement localized style modules for key components.
2. Refactor components to use dedicated style definitions.
3. Update documentation and style guides accordingly.

Testing Strategy:.

• Visual regression tests to detect unintended UI changes.
• Integration tests to confirm the overall behavior of the RemixApp remains stable.

Additional Considerations

White-label and Multi-theme apps

A comum way to White-label and Multi-theme apps to spread the stylization for the components are with a centralize class that holds all the Style classes and are reused for components, however with this new update this class will on longer be provided by Remix, instead we will define it specifically for component.
For applications that need to reuse styles from a single class, this will still be possible. The SpecConfiguration inside makeStyle references BuildContext, allowing access to contextual styles when needed.