Skip to content
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

gabrieldonadel
Copy link
Collaborator

@gabrieldonadel gabrieldonadel commented Feb 3, 2023

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 to borderEndColor and borderStartColor.
  • borderInlineEndColor, equivalent to borderEndColor.
  • borderInlineStartColor, equivalent to borderStartColor.

Changelog:

[GENERAL] [ADDED] - Add logical border inline color properties

Test Plan:

  1. Open the RNTester app and navigate to the View page
  2. Test the new style properties through the Logical Border Color section
Android iOS
Screen.Recording.2023-02-03.at.01.40.10.mov
Screen.Recording.2023-02-02.at.23.28.40.mov

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Feb 3, 2023
Comment on lines 93 to 107
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{};
Copy link
Collaborator Author

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++

@analysis-bot
Copy link

analysis-bot commented Feb 3, 2023

Platform Engine Arch Size (bytes) Diff
android hermes arm64-v8a 8,521,091 +1,919
android hermes armeabi-v7a 7,836,854 +2,154
android hermes x86 9,001,725 +2,219
android hermes x86_64 8,856,514 +1,756
android jsc arm64-v8a 9,144,237 +1,763
android jsc armeabi-v7a 8,335,824 +1,982
android jsc x86 9,199,281 +2,052
android jsc x86_64 9,456,929 +1,594

Base commit: 803bb16
Branch: main

Comment on lines 734 to 745
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;
}
Copy link
Contributor

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?

Comment on lines 58 to 69
/** 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;
Copy link
Contributor

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,
Copy link
Contributor

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
Copy link
Contributor

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 =
Copy link
Contributor

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?

@gabrieldonadel gabrieldonadel force-pushed the feat/add-logical-border-inline-color branch from 918bbbf to 1484508 Compare March 30, 2023 01:14
@necolas
Copy link
Contributor

necolas commented Jun 1, 2023

What are the next steps to get this PR merged?

@necolas
Copy link
Contributor

necolas commented Sep 11, 2023

Should we expect this PR to be further updated?

@facebook-github-bot facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Nov 8, 2023
@JakubKasprzyk17
Copy link

Hey, @gabrieldonadel @NickGerleman are you still working on this or can I continue this on my own ?

@NickGerleman
Copy link
Contributor

NickGerleman commented Jan 29, 2024

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:

  1. We have now more universally been targeting new architecture only. This is a lot easier to reason about, because of how it stores props, and cuts down the matrix a good bit. E.g. on iOS, we only need to worry about ComponentView and not the Paper native component impl.
  2. We have more UI tests against border scenarios in RNTester, for both Paper and Fabric. Tests against RNTester and products run continuously, but Android (and soon iOS) we will run tests when we try to land, which sees if rendering of RNTester scenarios (we have more for border now) changed.
  3. I have been trying to move up the layer where we "compute" physical edges from logical edges, so interesting code should always get a representation that is just "left, right, top, bottom". That makes the eventual sink dealing with borders a lot easier to reason about, and more efficient
  4. This code has changed a lot since this PR
  5. I have a current change in progress, that I'm trying to land next week, that refactors how we store and process these border values in the RN Fabric layout prop storage logic (YogaStylableProps). This is an invasive change, but will make the model a lot easier to reason about.
image

@NickGerleman
Copy link
Contributor

NickGerleman commented Jan 29, 2024

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.

@NickGerleman
Copy link
Contributor

Also no more deprecated-prop-types in a separate repo

@JakubKasprzyk17
Copy link

I made:
• borderInlineColor equivalent to borderEndColor and borderStartColor
• borderInlineEndColor equivalent to borderEndColor
• borderInlineStartColor equivalent to borderStartColor
Following @gabrieldonadel work in this PR #35999.
Without changes in MapBuffer View Props, because was removed.

If you want to check my changes I can push PR.

@NickGerleman
Copy link
Contributor

@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:

  1. Not touch Paper at all. I.e. no edits to RCTView or RCTViewManager.
  2. Add test cases, that we can show are rendering correctly
  3. Avoid any code which needs to do interesting logic with 12 or more edges, that should really only be dealing with the four physical edges. I.e. factor this as converting logical edge, to physical edge, before interesting logic, and not otherwise ever dealing with logical edge directly.

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.

@JakubKasprzyk17
Copy link

@NickGerleman if I'm right we must change whole flow with new borderColor and rewrite
borderInline and borderBlock. Operate only on 4 physical edges. But now I've no idea how to do it without changes in RCTView and RCTViewManager

@NickGerleman
Copy link
Contributor

But now I've no idea how to do it without changes in RCTView and RCTViewManager

These are only used by legacy architecture, compared to RCTViewComponentView for new architecture.

@react-native-bot
Copy link
Collaborator

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
@react-native-bot
Copy link
Collaborator

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.

@react-native-bot react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 28, 2024
@react-native-bot
Copy link
Collaborator

This PR was closed because it has been stalled for 7 days with no activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. Stale There has been a lack of activity on this issue and it may be closed soon.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants