Skip to content

feat: Keyed layout traits#553

Merged
watt merged 2 commits intomainfrom
awatt/layout-keys
Jun 5, 2025
Merged

feat: Keyed layout traits#553
watt merged 2 commits intomainfrom
awatt/layout-keys

Conversation

@watt
Copy link
Collaborator

@watt watt commented May 20, 2025

This PR adds keyed layout traits that work similarly to SwiftUI's LayoutValueKey. You can define keys in the style of Environment keys, and then read the values off subelements during layout.

To support legacy layout implementations, the SingleTraitLayout protocol provides the existing API. When legacy layout is removed, layouts that have an associated trait type only need to conform to this protocol to keep working as-is.

Decoupling the legacy Traits type from the Layout protocol will allow us to remove the LegacyLayout requirements cleanly. I'll do that in a follow-up.

@watt watt force-pushed the awatt/layout-keys branch 2 times, most recently from 51318cb to 6f73658 Compare May 23, 2025 20:29
@watt watt changed the title feat: keyed layout traits feat: Keyed layout traits May 23, 2025
@watt watt force-pushed the awatt/layout-keys branch from 6f73658 to 129028f Compare May 23, 2025 23:54
@watt watt marked this pull request as ready for review May 24, 2025 00:26
@watt watt requested a review from a team as a code owner May 24, 2025 00:26
@@ -0,0 +1,18 @@
/// A protocol for layouts that have a single associated trait type.
///
/// Legacy layout implementations can implement this protocol to easily apply and read their traits
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a neat way to support legacy layouts - and looks like it's also handy for some non legacy ones!

Just out of curiosity, would it also work if LayoutTraitsKey conformance were added to the legacy layout (and flow, gridRow, etc.) instead of SingleTraitLayout? The defaultValue might be awkward (but could be renamed to defaultTraitValue or something), or isn't the api you're going for.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, other than the slight API mismatch, you could accomplish the same thing that way. I think there's some good semantic info conveyed by SingleTraitLayout though, and storing the SingleTraitLayout key separately from new standalone keys feels nice.

@watt watt merged commit b36724a into main Jun 5, 2025
4 checks passed
@watt watt deleted the awatt/layout-keys branch June 5, 2025 21:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants