-
Notifications
You must be signed in to change notification settings - Fork 289
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
RTL Support #497
RTL Support #497
Conversation
Aria selected and row attributes
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.
Any idea what the backwards compatibility of this change will be? Will behavior be changed for users in a RTL locale?
From what I could tell from the issue this is tied to, users in an RTL locale are not being supported currently. Before this change, they'd need custom styling and position overrides. I don't think this would break backward compatibility, since it seems that there was no support to start with. |
@pradeepnschrodinger @novakps @somavara @mycrobe would you mind reviewing this when you get some time? |
Sorry for the delays, we'll review it soon. |
@@ -20,9 +22,18 @@ function FixedDataTableTranslateDOMPosition(/*object*/ style, /*number*/ x, /*nu | |||
style.left = x + 'px'; | |||
style.top = y + 'px'; | |||
} else { | |||
if (BrowserSupportCore.hasCSSTransforms() && Locale.isRTL()) { |
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.
what's the use of BrowserSupportCore.hasCSSTransforms
?
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.
Inside translateDOMPositionXY.js
, when BrowserSupportCore.hasCSSTransforms
is false, the result of the translate is an inline style change of left
and top
, whereas if that condition is true, a translate3d
is performed.
Basically, it created this situation where the x
value should be flipped when BrowserSupportCore.hasCSSTransforms
is true, but should not be when it's false (since the value should remain unchanged and be moved from style.left
to style.right
)
style.right = style.left; | ||
style.left = 'auto'; |
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 needed? I thought flipping the x value from the condition above will mean that translateDOMPositionXY
will also flip the right and left 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.
Depending on browser support, either translate3d
is used or the style.left
is changed. In either case, it would be safe to flip the style.left
and style.right
values
I strongly prefer RTL controlled through a table prop rather than relying on the html document's property. |
Thank you for the review comments. Currently revising my PR to account for those.
In the meantime, I figure we could discuss a bit more on how to implement the RTL detection. I chose to do it by looking at the Why would a prop be a better way of handling this? |
Prop fits our table better as the table is a react component itself. |
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.
Looking good, just a few minor comments before we proceed on merging.
@wcjordan , this looks go to be merged. I tested out the examples and also tried it on LD, and works fine. There's just a minor CSS issue in RTL mode, but I think we can address it later through as a separate issue. It doesn't affect existing users anyway. Shall I proceed on merging? |
Great, that sounds good to me. Feel free to go ahead. |
@louiebert , released with v1.0.2 |
Fantastic!! Thank you guys for the thorough review! |
Adds RTL support by reversing horizontal scrolling and flipping horizontal rendered position of columns.
Description
Flips interpretations of scroll/keyboard events and flips element positions on render. This approach keeps the app state unchanged, so any callback props users would still receive the same relative values.
Motivation and Context
Some languages read from right to left, so this enables a native support for that use case.
Fixes #209
How Has This Been Tested?
I walked through and manually tested every page on the examples from the locally hosted site, ensuring that every feature not only behaved, but looked the way that it should upon the direction being switched.
Additionally, I wrote some unit tests to validate that the state values and DOM element positions behave as expected during horizontal scrolling.
Screenshots:
Types of changes
Checklist: