-
Notifications
You must be signed in to change notification settings - Fork 24.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix issue where start/end would not be respected in flex edge getters (…
…#41682) Summary: X-link: facebook/yoga#1479 Pull Request resolved: #41682 There are two ways to get the value of a style for a specific edge right now: 1) From the inline start/end edge which is determined via the writing direction (ltr or rtl), assuming you do not have errata on 2) From the flex start/end edge which is determined via the flex direction (row, row-reverse, column, column-reverse) There is a weird curiosity in the second case: you can define a style to be on the "start" or "end" edge when writing the stylex/css. The physical edge that this refers to is dependent on the writing direction. So `start` would be `left` in `ltr` and `right` in `rtl`, with `end` the opposite. It is **never** determined via the flex direction. Additionally, `start`/`end` takes precedence over the physical edge it corresponds to in the case both are defined. So, all of this means that to actually get the value of a style from the flex start/end edges, we need to account for the case that one of these relative edges was defined and would overwrite any physical edge. Since this mapping is solely determined by the writing direction, we need to pass that in to all the flex start/end getters and do that logic. This is done in `flexStartRelativeEdge`/`flexEndRelativeEdge` which was added earlier but for some reason only being used on border. Reviewed By: NickGerleman Differential Revision: D51293315 fbshipit-source-id: 26fafff54827134e7c5b10354ff9bfdf67096f5b
- Loading branch information
1 parent
7459529
commit aa31c6c
Showing
3 changed files
with
117 additions
and
53 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters