Add rtl support with dynamic right & left properties

[iamsoorena]

This PR resolves this issue.
I've checked result of this PR with both RTL and LTR apps.
It works as expected in both situations.

• LTR(default):

• RTL:

[RichardLitt]

Any reason you changed the syntax, instead of using tooltip.end?

[mohebifar]

The bracket notation is for computed keys. tooltip.end = 1; results in { end: 1 } whereas const end = 'left'; tooltip[end] = 1 gives { left: 1 }, unless I misunderstood your question.

[RichardLitt]

Why this change of syntax, again? How do the brackets help?

[MaxBolotnyi]

@RichardLitt
This syntax reaches the variable instead of the stable key, so the 'end' variable may switch depending on the LTR or RTL orientations.

[RichardLitt]

Thanks for this PR, @iamsoorena! Made a few small comments.

[iamsoorena]

Hi @RichardLitt ,
React Native Allegedly 😊 has support for end and start, you can find more info about it here.
But I'm currently working on a RTL app. And I know that this feature is not well implemented in react native. It simply doesn't work as expected.
So I defined my own start, end.

const rtl = I18nManager.isRTL;
const start = rtl ? 'right' : 'left';
const end = rtl ? 'left' : 'right';

So If I used end: leftOverlayRight, without brackets, React-native would have replaced end with It's own definition, BUT I want end to be strictly set as left in RTL apps.

---

We can refactor usage of [end] [start] in the future when React-Native resolved this issue. I'll keep an eye for that. 😊

[mohebifar]

@iamsoorena Thanks! I'm on a vacation right now. I'll test and review this next week.

[mohebifar]

@iamsoorena Sorry for the delay on reviewing this. This looks really good! Thank you. I'm just curious if it is possible to programmatically switch the direction. For example, when changing the language within the app's settings (English -> Farsi -> English). I couldn't find any function for switching back to LTR on I18nManager. I18nManager.forceRTL(false) also does not seem to work.

[mohebifar]

This looks good to me. I would just like to know if the programmatic change of direction is a possibility. In that case, we would have to move the RTL check (Line 48-50) into the _animateMove method.

[iamsoorena]

@iamsoorena Sorry for the delay on reviewing this. This looks really good! Thank you. I'm just curious if it is possible to programmatically switch the direction. For example, when changing the language within the app's settings (English -> Farsi -> English). I couldn't find any function for switching back to LTR on I18nManager. I18nManager.forceRTL(false) also does not seem to work.

@mohebifar I've not used or implemented this feature before. I don't know about this. 😀

[iamsoorena]

This looks good to me. I would just like to know if the programmatic change of direction is a possibility. In that case, we would have to move the RTL check (Line 48-50) into the _animateMove method.

@mohebifar As far as I know, using I18nManager.forceRTL(false/true) should do the trick, but I've not used it before.

[mohebifar]

Seems that #82 includes these changes as well as the onPress thing. It would be better if the PRs only introduce one new feature or bug fix. But for now, we can just close this one, and follow up the rest in #82 and merge both functionalities at once.

[iamsoorena]

@mohebifar First I think you mean #71.
Since I thought #71 would be merged long time ago, I just worked on that branch to avoid conflicts in the future, But I don't have a problem with separating PRs.

[RichardLitt]

@iamsoorena Thanks for letting us know, @iamsoorena. Sorry about the delay - we don't have unlimited time to work on this repository. :)

[iamsoorena]

@RichardLitt no problem.

[mohebifar]

@iamsoorena Just wanted to follow up with you to see if you want still would like to:

1. Make the change to check the direction dynamically in the measurement code. (For example, for apps that support switching the language in the settings menu)
2. Keep out the changes available in this PR from Add onPress support in the middle of steps #71 so that Add onPress support in the middle of steps #71 will only contain changes related to the onPress functionality.
   Thanks!

[iamsoorena]

@mohebifar once again I'm sorry for my slow responds.
critically busy on a project.
I'll let you know ASAP.

[ab-sami]

Can someone please merge this PR. It's look good to me as well.
It's really urgent