-
Notifications
You must be signed in to change notification settings - Fork 24.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add logical border inline color properties #36046
feat: Add logical border inline color properties #36046
Conversation
OptionalT leftEdge{}; | ||
OptionalT topEdge{}; | ||
OptionalT rightEdge{}; | ||
OptionalT bottomEdge{}; | ||
OptionalT startEdge{}; | ||
OptionalT endEdge{}; | ||
OptionalT horizontalEdges{}; | ||
OptionalT verticalEdges{}; | ||
OptionalT allEdges{}; | ||
OptionalT blockEdges{}; | ||
OptionalT blockStartEdge{}; | ||
OptionalT blockEndEdge{}; | ||
OptionalT inlineEdges{}; | ||
OptionalT inlineStartEdge{}; | ||
OptionalT inlineEndEdge{}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately I had to rename these because inline
is a reserved word in C++
Base commit: 803bb16 |
6e4263f
to
918bbbf
Compare
React/Views/RCTView.m
Outdated
UIColor *borderStartColor = _borderInlineStartColor ?: _borderInlineColor ?: _borderStartColor ?: _borderLeftColor; | ||
UIColor *borderEndColor = _borderInlineEndColor ?: _borderInlineColor ?: _borderEndColor ?: _borderRightColor; | ||
|
||
directionAwareBorderLeftColor = isRTL ? borderEndColor : borderStartColor; | ||
directionAwareBorderRightColor = isRTL ? borderStartColor : borderEndColor; | ||
} else { | ||
directionAwareBorderLeftColor = (isRTL ? _borderEndColor : _borderStartColor) ?: _borderLeftColor; | ||
directionAwareBorderRightColor = (isRTL ? _borderStartColor : _borderEndColor) ?: _borderRightColor; | ||
UIColor *borderStartColor = _borderInlineStartColor ?: _borderInlineColor ?: _borderStartColor; | ||
UIColor *borderEndColor = _borderInlineEndColor ?: _borderInlineColor ?: _borderEndColor; | ||
|
||
directionAwareBorderLeftColor = (isRTL ? borderEndColor : borderStartColor) ?: _borderLeftColor; | ||
directionAwareBorderRightColor = (isRTL ? borderStartColor : borderEndColor) ?: _borderRightColor; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain what these conditions are doing, and why this change puts precedence in this order?
/** Spacing type that represents inline directions (left, right). E.g. {@code marginInline}. */ | ||
public static final int INLINE = 12; | ||
/** | ||
* Spacing type that represents the inline end direction (right in left-to-right, left in | ||
* right-to-left). E.g. {@code marginInlineEnd}. | ||
*/ | ||
public static final int INLINE_END = 13; | ||
/** | ||
* Spacing type that represents the inline start direction (left in left-to-right, right in | ||
* right-to-left). E.g. {@code marginInlineStart}. | ||
*/ | ||
public static final int INLINE_START = 14; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as the inline PR
, it could create confusion to have Spacing.END
not be the last enum here. As we are adding, I think we should update this. If there is existing code relying on Spacing.END
which only needs the ones before it, we should add a new well-known enum where Spacing.END
used to be.
@@ -192,6 +209,9 @@ private static float[] newFullSpacingArray() { | |||
YogaConstants.UNDEFINED, | |||
YogaConstants.UNDEFINED, | |||
YogaConstants.UNDEFINED, | |||
YogaConstants.UNDEFINED, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to specify in the type that the array is of size Spacing.ALL
so that when we add an enum, we are forced to update this?
@@ -442,6 +442,35 @@ private void drawRoundedBackgroundWithBorders(Canvas canvas) { | |||
} | |||
} | |||
|
|||
// colorInlineStart and colorInlineEnd have precedence over colorEnd and colorStart values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is already pretty chunky. Can we cleanly pull out the logic to resolve these values?
final boolean isColorInlineStartDefined = isBorderColorDefined(Spacing.INLINE_START); | ||
final boolean isColorInlineEndDefined = isBorderColorDefined(Spacing.INLINE_END); | ||
|
||
final boolean isDirectionAwareColorInlineLeftDefined = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the same as the above? Can we avoid duplication?
918bbbf
to
1484508
Compare
What are the next steps to get this PR merged? |
Should we expect this PR to be further updated? |
Hey, @gabrieldonadel @NickGerleman are you still working on this or can I continue this on my own ? |
Hey @JakubKasprzyk17, I have not looked at this change in a while, but I have actually been spending some more time recently around this layer, and we have some more tests over this now, so we are probably in a better place to make the change than before. For you, or anyone else interested in fleshing out logical edges for border props, I have a few updates:
|
Oh, we also removed the MapBuffer ViewProps, and iterator style props parser code for layout props (and we could also for view props if we want to). I.e. matrix for this should be a lottt smaller than before. And we no longer want to worry about Paper specific bugs. |
Also no more |
I made: If you want to check my changes I can push PR. |
@JakubKasprzyk17 please take caution the PR you mention matching against ended up needing changes after changing some border rendering behavior. For future contributions, I would want us to:
Some of the churn with this original series of changes was that we would sometimes find a visual regression, that we had a hard time reproing and communication, but I think if we follow all the above guidelines, we can end up with a more scoped, lower risk change. |
@NickGerleman if I'm right we must change whole flow with new borderColor and rewrite |
These are only used by legacy architecture, compared to |
This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
1 similar comment
This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This PR was closed because it has been stalled for 7 days with no activity. |
Summary:
This PR implements logical border inline color properties as requested on #34425. This implementation includes the addition of the following style properties
borderInlineColor
, equivalent toborderEndColor
andborderStartColor
.borderInlineEndColor
, equivalent toborderEndColor
.borderInlineStartColor
, equivalent toborderStartColor
.Changelog:
[GENERAL] [ADDED] - Add logical border inline color properties
Test Plan:
View
pageLogical Border Color
sectionScreen.Recording.2023-02-03.at.01.40.10.mov
Screen.Recording.2023-02-02.at.23.28.40.mov