Skip to content

Unused token reference types in prop_refs.dart and token_refs.dart #915

Description

@tilucasoli

Summary

After dropping TextDecorationRef in #c68d30953 (because TextDecoration became a final class in newer Flutter SDKs), it became clear that many other ref types in packages/mix/lib/src/core/prop_refs.dart and packages/mix/lib/src/theme/tokens/token_refs.dart are also dead code — they're declared, exported, and matched in assertIsRealType, but nothing in the codebase ever produces an instance.

We should decide what to do with them: either wire them up to real MixToken subclasses (so users can actually tokenize these types) or remove them.

Unused refs

In prop_refs.dart (31 classes, never instantiated by getReferenceValue or any MixToken):

  • AlignmentGeometryRef, AlignmentRef, AlignmentDirectionalRef
  • FontFeatureRef
  • OffsetRef, RectRef
  • LocaleRef
  • ImageProviderRef, DecorationImageRef
  • GradientTransformRef, GradientRef, LinearGradientRef, RadialGradientRef, SweepGradientRef
  • Matrix4Ref
  • TextScalerRef, StrutStyleRef, TextHeightBehaviorRef
  • TableColumnWidthRef, TableBorderRef
  • BoxBorderRef
  • BorderRadiusGeometryRef, BorderRadiusRef, BorderRadiusDirectionalRef
  • EdgeInsetsGeometryRef, EdgeInsetsRef, EdgeInsetsDirectionalRef
  • BoxDecorationRef
  • ShapeBorderRef
  • BoxConstraintsRef
  • CurveRef

In token_refs.dart (4 classes, unreachable — actual shadow tokens are list-based):

  • ShadowRef, BoxShadowRef
  • ShadowMixRef, BoxShadowMixRef

Why this matters

  • They appear in the public API surface (exported) but can't be created by users, so they're misleading.
  • They bloat assertIsRealType with branches that are never exercised in real flows.
  • Some (like TextDecorationRef) actively break compilation when Flutter marks the implemented type final or sealed. Several of the above (e.g. Alignment, EdgeInsets, BoxConstraints) are also at risk.
  • The token-migration guide currently advertises some of these as supported, which is stale.

Options

  1. Remove them all (and trim assertIsRealType + getReferenceValue + the migration guide).
  2. Add corresponding MixToken subclasses so they become real, supported token types.
  3. Hybrid — keep the ones we plan to support and remove the rest.

Worth a discussion before picking a direction.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions