feat: Add logical border inline color properties #36046
feat: Add logical border inline color properties #36046gabrieldonadel wants to merge 4 commits intofacebook:mainfrom
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.
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
There was a problem hiding this comment.
Could you explain what these conditions are doing, and why this change puts precedence in this order?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
This function is already pretty chunky. Can we cleanly pull out the logic to resolve these values?
There was a problem hiding this comment.
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