Description

Mix includes essential layout modifiers like Flexible and Align, which are vital for Flutter layouts. However, using these modifiers within a Style class can obscure layout behavior and complicate style reuse, ultimately making the widget tree less clear.

To address this, we plan to refocus Mix on styling while relying on Flutter’s default layout widget. This approach preserves widget tree clarity and clarifies when to use Mix versus Flutter’s built-in layout, allowing Mix to enhance style reusability and consistency without interfering with layout.

For example, some developers create styles solely to wrap widgets with layout modifiers, leading to an unclear widget tree.

Before

Box(
  style: Style(
    $box.chain
       ..wrap.expanded(),
  )
)

After

Expanded(
  child: Box(),
)

In the “Before” example, a style is used just to apply a layout modifier, whereas the “After” example employs Flutter’s native layout widget for a cleaner, more understandable widget tree

Proposed Changes

Remove all layout-related modifiers from the list below. The following widgets should be excluded:

• IntrinsicWidth
• IntrinsicHeight
• RotatedBox
  Unlike Transform, which applies a transform just prior to painting, this object applies its rotation prior to layout, which means the entire rotated box consumes only as much space as required by the rotated child
• Visibility
  By default, it controls whether the widget is included in the subtree or not.
• Flexible
• Expanded

The widgets that should remain include:

• Opacity
• All clip widgets
• AspectRatio
• Transform
• Align
• FractionallySizedBox
• SizedBox
• Cursor
• Padding

Impact Analysis

Benefits

• Better Maintainability: Reducing the number of modifiers will decrease the potential for inconsistencies and technical debt.
• Clearer Best Practices: Many users struggle with when to use modifiers versus wrapping widgets and Style Attributes versus Wrapping Widgets. Removing support for certain modifiers will help establish clearer best practices.
• Simplified Logic: Currently, Mix requires logic to manage the order of applied modifiers, especially for layout-related ones. By removing them, this concern is eliminated, allowing us to simplify Mix and potentially remove the orderOfModifiers logic entirely. This results in a cleaner, more maintainable system.

Potential Drawbacks:

• Breaking Changes for Existing Users: Some projects may rely heavily on these specific modifiers, making the transition more challenging.
• Learning Curve for Existing Users: Users may need time to adjust to the new modifiers best practices.

Implementation Plan

Tasks

• Deprecate the listed widgets
• Update all remix components that are using the layout modifiers
• In a future version remove those modifiers definitely.
• Update documentation with all new best practices

Testing Strategy

Because it is just a remotion there is no need to extra tests

Additional Considerations

An opportunity to review the order of modifiers

Currently, Mix includes logic to control the order of modifiers. This is necessary because certain modifiers are layout-related and must be applied in a specific sequence to prevent potential breakages. Without this ordering, improper application could lead to unexpected layout issues.