Use case

As mentioned in #177415 (comment):

Divider | Can it just be removed? Or possibly we should create a RawDivider in Widgets if there is a real need.

1. There are 12 places using Divider material widget in widget tests:

2. Divider concept exists in both Material and iOS design specs/docs:

• Material: https://m3.material.io/components/divider/overview
• iOS design docs: https://developer.apple.com/documentation/SwiftUI/Divider

Proposal

We can go with one of these options:

• A. building a new RawDivider widget in widgets:
  • Pros:
    • the import will be neat and tidy. Maintainers will only need to import RawDivider widget in widgets and corresponding design libraries on either widget usage or test.
    • allow other design systems to build their own divider based on RawDivider widget
    • follow existing patterns as other widgets: RawAutocomplete/Autocomplete, RawRadio/Radio...
  • Cons:
    • Increase API maintenance cost (design docs needed?, documentation for itself and update Material one too, bug fixes and reviews, etc...)
    • Does this seem to be over-engineering? As the current Divider widget is simply a sized Container with border and theming
• B. adding a helper widget or something like that in a utils file in test/widgets
  • Pros:
    • No risk and lower API maintenance cost: no need design docs, minimum documentation (only class and method docs are needed in new utils file in test directory only). If there are new issues introduced, the fix for them will be simpler than RawDivider widget
    • Quickly solve the main goal of cleaning up cross-imports issue without getting sidetracked into other time-consuming tasks.
    • The test helper can be modified or removed at any time without considering breaking changes like RawDivider widget
  • Cons:
    • The helper widget may duplicate the "drawing a line" logic in the test utils, which is already implemented in the Divider material widget.

Based on the above analysis, I lean towards option B, as it helps achieve the goal of cleaning up cross-imports effectively at a lower/minimal cost. cc @justinmc for thoughts. Regardless of which option is chosen, I assign myself to this work.