- 
                Notifications
    
You must be signed in to change notification settings  - Fork 24.9k
 
feat: Add logical border inline color properties #36046
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
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
  
    | 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.
| 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?
| } | ||
| } | ||
| 
               | 
          ||
| // 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 ?  | 
    
| 
           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 toborderEndColorandborderStartColor.borderInlineEndColor, equivalent toborderEndColor.borderInlineStartColor, equivalent toborderStartColor.Changelog:
[GENERAL] [ADDED] - Add logical border inline color properties
Test Plan:
ViewpageLogical Border ColorsectionScreen.Recording.2023-02-03.at.01.40.10.mov
Screen.Recording.2023-02-02.at.23.28.40.mov