For better tooling support, we would like to make two improvements to the metadata on property & style declarations:
To break up large listings of properties on an item, need to grow the set standardized categories that properties and styles can be bucketed into.
To provide validation of numeric input, need new metadata to specify the allowed numeric range of int and Number properties.
Decision
Complete this section when a decision has been made and approved
h3.
Decision Criteria
What factors should be accounted for in a reasonable solution to the problem?
Proposed Solution(s):
Categories
Add two new values for the category="" metadata attribute:
"Text" -- font/paragraph styles, text color, etc.
"Layout" -- settings that affect how a component lays out its children (padding/gap/etc.) or how a component is laid out by its parent (constraints, etc.)
Start using the category="" attribute as applicable on [Style] metadata too, not just [Inspectable] as today.
Numeric range
There are three proposals:
Syntax A:
minValue="N" -- value must be >= N
minValueExclusive="N" -- value must be > N
maxValue="N" -- value must be <= N
maxValueExlusive="N" -- value must be < N
Syntax B:
minValue="N" -- value must be >= N
minValue=">N" -- value must be > N
maxValue="N" -- value must be <= N
maxValue="<N" -- value must be < N
Syntax C:
range="[N,M]" -- value must be >= N, <= M
range="(N,M)" -- value must be > N, < M
range="(N,M]" -- value must be > N, <= M
range="(N" -- value must be > N
etc.
Notes:
N (or M) is any number -- for int properties it must be an int; for Number properties it must be a Number
In syntax A or B, if both min or both max attributes are specified, tooling's numeric validation behavior is undefined.
If the range is inverted (min > max), tooling's numeric validation behavior is undefined.
Recommended Solution:
Categories
See above.
Numeric range
Recommend syntax A. This has the least "microsyntax"iness to it.