[$16,000] Let's fix a React Native issue -- useWindowDimensions() returns swapped height and width in iOS

[deetergp]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

We have an issue where opening the app in native iOS on an iPad in Landscape orientation, the Chat Selector component is floating in the middle of the screen. We opened this issue to deal with it and had a workaround put forward by one of our contributors, but in the process of investigating, discovered that the real issue is with React Native core. They have an open issue and are working on a fix, but it's anyone's guess when it will be ready.

Let's keep an eye on the React Native team's solution and see if we can put it into place and undo the the temporary workaround we are using for now.

cc @marcaaron @mallenexpensify

Workaround:

https://github.com/Expensify/Expensify.cash/issues/2180#issuecomment-833695795

Original React Native Issue

https://github.com/facebook/react-native/issues/29290

Platform:

Where is this issue occurring?

• [ ] Web
• [x] iOS (iPad)
• [ ] Android
• [ ] Desktop App
• [ ] Mobile Web

Version Number: 1.0.2-51 Notes/Photos/Videos: See the original issue

View all open jobs on Upwork

[mallenexpensify]

Quick update before the weekend hits, we're still discussing, expect an update on Monday, thanks for the patience and the help so far

[mallenexpensify]

Thanks for the patience, we're actively discussing and making updates that will help with issues like this where the final deliverable is to have a PR merged in a 3rd party repo.

We made an update to the CONTRIBUTING.md

Solution: Update the CONTRIBUTING.md to include written "Your solution proposal should include a brief written technical explanation of the changes you will make""

@lbaldy , your videos were helpful and easy to follow, the reason we added written is because it makes it easier to compare proposals to ensure "Any new proposal should be substantively different from existing proposals."

We hope to have another update by EOW (I'm off the next two days so it might not be til next Monday).

[NicMendonca]

@mallenexpensify any update by chance?

[mallenexpensify]

Apologies for the delay. I drafted a reply with details, I need to get more internal 👀 on it before posting since this is a unique edge case and because we're also wanting to create a process for third-party repos. I'll follow up in the morn.

[mallenexpensify]

First, a paraphrased plan for how we plan to compensate for issues that require fixes in third party repos. tl,dr: (and this isn't set in stone until the .md file is created)

• Half will be paid when the fix is merged in our fork, the E/App repo is pointed at the fork and it doesn't break for a week.
• The other half will be paid when the fix is merged upstream, fork is update w/ upstream fix, everything works for a week .

If there’s not a fork, payment would be issued once a fix is merged upstream and released, E/App is updated to use the new dependency version and nothing breaks for a week.

For this specific issue, technically @lbaldy was first and there’s not (apparently) a substantial difference in the following written proposal by @azimgd. We have since updated our CONTRIBUTING.md to require written proposals in the future to avoid similar circumstances.

I propose we hire @lbaldy for $16k to fix the issue with half the payment due once the PR is merged in our fork, the E/App repo is pointed at the fork and there are no regressions for a week. The remaining $8k will be paid to @lbaldy when the fix is merged upstream, fork is updated w/ upstream fix and there are no regressions for a week.

Our intent is to get the PR merged upstream so we want to ensure contributors have an incentive to do so. For @azimgd , compensation will be $8k due once the PR is merged upstream (and no regressions for a week). The deliverable for @azimgd is to follow along as the work is being done on the PR for E/App repo to ensure the final PR is (hopefully) likely to be merged in the 3rd party repo. Then, both @lbaldy and @azimgd will push (with help from others) to get @lbaldy ’s PR merged into the 3rd party repo.

Since this is new for us please take notes on what works and how things might be improved for getting PRs merged in 3rd party repos. Please share those notes in this GH and/or #expensify-open-source.

[lbaldy]

Thanks @mallenexpensify for the explanation and IMHO great way of resolving this. What you described sounds good to me.

I just have one additional comment to the update you did here:

We made an update to the CONTRIBUTING.md Solution: Update the CONTRIBUTING.md to include written "Your solution proposal should include a brief written technical explanation of the changes you will make""

I think it would be worth to mention that the technical explanation means code changes (what files, what lines to add/remove/change).

Something like this:

Your solution proposal should include a brief written technical explanation of the changes you will make, like files to change, critical pieces of code required to present the high level idea of the change.

PR

In terms of the PR (https://github.com/Expensify/react-native/pull/10).

I think the commit in this PR isn't signed.

I don't want to touch it until I get a green light - when I get one I'll do a force push to it so the commit becomes a signed commit.

Also, when the change is merged to a react-native fork, the Expensify/App will use the new version, but also the existing workaround fix has to be removed (https://github.com/Expensify/App/issues/2180#issuecomment-833695795). Shall I open a PR for this one as well or will that be handled internally while updating App's version of react native?

Payment

In terms of splitting the payment into 2 that sounds good to me, only concern is that it falls into higher Upwork commission when it is below 10k. I am thinking if it makes sense to simply do a single payment once it is merged upstream to Facebook's repo. I hope we can discuss that later when we actually prepare a plan.

Merge upstream

In terms of merging the code to Facebook's react native repo. The PR requester has to sign the https://github.com/facebook/react-native/wiki/Contributor-License-Agreement. I have signed it because I did a PR to their repo in the past. I am not sure how that works when it is a merge from another fork that I am not the owner of - https://github.com/Expensify/react-native. I am just wondering if anyone from Expensify has to adhere/sign the CLA or we just file a new PR to Facebook's repo standalone. Something to flesh out I guess.

What should be the next step?

[mallenexpensify]

@lbaldy I'm about to head out, @parasharrajat will followup soon then I will too next week.
For the CONTRIBUTING.md update, that makes sense, I want to run by folks internally then can do it next week.

For the payment commissions, can you double check? We're Enterprise and I thought contributors/freelancers paid a fixed rate (10% was my memory), regardless of $ amount.

[azimgd]

Looks like this issue has been fixed on a: "react-native": "0.68.2". @parasharrajat could you double check and verify both android and ios versions ?

[parasharrajat]

Oh. Great. Thanks I will check it.

[lbaldy]

@azimgd is there any particular commit in react native repository you're referring to?

I just checked the same scenario I used in the original 'react-native' repro (0.68.1). And I still observe the same behaviour - two events (portrait, landscape) when bringing the app to background. I also checked their changelog.md, I don't see anything that could seem related either. Also, checked the DeviceInfo.mm file, and still don't see anything similar to the fixes proposed. Is there anything else you're referring to?

The dependencies used in my repro project:

"dependencies": { "react": "17.0.2", "react-native": "0.68.2" },

[parasharrajat]

Also, when the change is merged to a react-native fork, the Expensify/App will use the new version, but also the existing workaround fix has to be removed (https://github.com/Expensify/App/issues/2180#issuecomment-833695795). Shall I open a PR for this one as well or will that be handled internally while updating the App's version of react-native?

yes, Open a new PR with an updated fork of react-native in E/App(this repo) when you are done with changes on the fork.

TL:DR

1. First PR to our RN fork.
2. Second PR to this repo to update the fork and remove the Hack.
3. Then another PR to react-native.

it falls into higher Upwork commission when

Matt is correct here.

So you can create a new PR from our fork to react-native. That should be possible and as you will be the author, we probably don't have to do anything.

[lbaldy]

@parasharrajat I created a new PR for react-native repo with signed commit here: https://github.com/Expensify/react-native/pull/11

A draft WIP PR reverting the workaround, for App: https://github.com/Expensify/App/pull/9143

[melvin-bot[bot]]

📣 @lbaldy You have been assigned to this job by @mallenexpensify! Please apply to this job in Upwork and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻 Keep in mind: Code of Conduct | Contributing 📖

[lbaldy]

The Upwork job is no longer available: https://www.upwork.com/jobs/~017b165dfa9821e51c thus I cannot apply @mallenexpensify is this something you are able to help with?

[mallenexpensify]

You betcha @lbaldy , please apply here and confirm in comment here once you have https://www.upwork.com/jobs/~01411bf531c59e797e

[lbaldy]

Thanks @mallenexpensify. Applied.

[imran-ranglerz]

const isPortrait = () => { const dim = Dimensions.get('screen'); return dim.height >= dim.width; };

/**

• Returns true of the screen is in landscape mode */ const isLandscape = () => { const dim = Dimensions.get('screen'); return dim.width >= dim.height; };

by using this we can find out the dimension and solve this.

[mallenexpensify]

@lbaldy , hired you in Upwork, assuming you're Lukasz B there

@imran-ranglerz , we already have hired someone for this job, to check all open jobs, click https://github.com/Expensify/App/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22

[lbaldy]

@mallenexpensify thanks. That me, I've received the Upwork email too. The PR is already opened and I think @parasharrajat is on it.

[parasharrajat]

Expect an update soon. Just too exhausted today 😴🛌

[parasharrajat]

I will start reviewing this tomorrow daytime IST. Overall the PR looks good to me. @lbaldy Have you created the issue and PR on RN yet?

[lbaldy]

I haven't as per:

First PR to our RN fork. Second PR to this repo to update the fork and remove the Hack. Then another PR to react-native.

Assuming we should merge it first to Expensify fork, test if all works well for 7 days, and then pull it into react native repo.

Please let me know if you see it different, and I will go ahead and fire a request for Facebook.

[parasharrajat]

Ok, that works for.

[mallenexpensify]

Assuming we should merge it first to Expensify fork, test if all works well for 7 days, and then pull it into react native repo.

Good plan!

[NicMendonca]

@lbaldy @parasharrajat any updates here?

[parasharrajat]

Fork PR is ready to be merged.

Completion: 30%

• [x] PR on the Expensify fork of RN.
• [ ] PR for upgrading the version of RN on E/app.
• [ ] PR to RN.

[lbaldy]

The MR has been merged to master. Have you ever used react native fork in your E/App or have you always been using the official react native release from npm?

[parasharrajat]

I think we always used the official package. And we try use forked repo with V0.68, it may break stuff. So Please test it carefully on your PR. I will do as well.

[lbaldy]

Okay so there are a couple of things we need to flesh out.

a) Upgrading a react native version for an app is always a big project (dev work as well as regression check across the whole app) do we really want to do it twice (once to fork version once to facebooks version)? b) E/App is not and has not been using the fork ever, why do we want to use fork now instead of just getting it straight from official repo? c) Should the react native version upgrade be handled as a 'side effect' of a bugfix?

[mallenexpensify]

@iwiznia @parasharrajat , what you think about @lbaldy 's three questions above?

[lbaldy]

Anyway, I am working on getting the forked version to work. Once ready I will update the https://github.com/Expensify/App/pull/9143

[parasharrajat]

We are already planning to upgrade the app to latest RN 0.68. That should help in transition. https://github.com/Expensify/App/issues/8503#issuecomment-1152785723. But it is still in planning phase. I am not sure if someone is already working on that.

@mallenexpensify Would you be able to forward the discussion on the other issue? Let's see if that can be handled. Thanks.

[mallenexpensify]

@mallenexpensify Would you be able to forward the discussion on the other issue? Let's see if that can be handled. Thanks.

@parasharrajat , are you referring to the new plan for how to manage third-party repo issues?

[parasharrajat]

No, I meant about this issue https://github.com/Expensify/App/issues/8503#issuecomment-1152785723.

[lbaldy]

No matter what we do with the upgrade, I think it makes sense to open a Merge Request to Facebook already to keep the ball rolling.

@parasharrajat do you agree or do you think we should wait for our 7-day period test in E/App before we go to FB?

[parasharrajat]

I will start reviewing this tomorrow daytime IST. Overall the PR looks good to me. @lbaldy Have you created the issue and PR on RN yet?

That's what I was suggesting here.

[lbaldy]

I opened a PR for Facebook: https://github.com/facebook/react-native/pull/34014

[parasharrajat]

@lbaldy Let's add the reproduction repo to the PR showing the real issue. You can also reuse samples from old issues.

Instead of adding the code changes to the PR description, describe changes in words and reasons to do those. Code can be seen in the diff.

[lbaldy]

@parasharrajat thanks for the inputs. Updated the MR, added repro the PR is now following the required format. I guess we now have to wait.

[lbaldy]

Update:

The MR for Facebook (https://github.com/facebook/react-native/pull/34014 has) has been 'imported', this means it is running though their internal checks at Meta. There are two tasks at Meta that are failing but external contributors don't seem to have access to any details about that.

On top of that, I worked upgrading to the 'main' version from Expensify's fork. This isn't trivial, this is not just a react native upgrade to 0.68.x but that's way more. Master is ahead of 0.68.x obviously, moreover it requires react update to 18.0.0. And master isn't stable obviously, we should not be doing that imho.

I was wondering if we can do something to get the fix into E/App as quickly as possible - I see a couple of options here.

a) We take the Expensify/react-native fork, we checkout the tag equal to the current version of react native used in E/App -> and we apply our fix there. Then we can simply switch the react native to use the forked version. - This sounds pretty safe and simple. We may need to do some magic to update android along with ios - but that's well documented.

I created a POC here: https://github.com/lbaldy/ExpensifyApp/tree/bugfix/2727-upgrade-to-fork this seems to be pretty seamless.

b) We apply a monkey patch. Simply by adding a npm postinstall script, we monkey patch the RCTDeviceInfo.mm file - this is a bit hackish.

c) We wait for the PR merged and we perform a full upgrade - this brings all the risks and efforts of a full upgrade as well as waiting time to get the fix in.

[parasharrajat]

a works for me. @iwiznia Any thoughts on the above?

[lbaldy]

@parasharrajat I went ahead and prepared the following:

Here is a working version: https://github.com/lbaldy/ExpensifyApp/tree/bugfix/2727-upgrade-to-fork

Which uses this fork branch: https://github.com/lbaldy/expensify-fork-react-native/tree/bugfix/2727_on_0.66.4

I cannot open a PR, because we don't really want to merge it to E/react-native#main.

Ideally, if you could create a branch inside E/react-native from the v0.66.4 tag, after that I'd be able to fire a PR from my branch to your branch.

Once the above is done, I'll open a MR (lbaldy/expensify-fork-react-native/tree/bugfix/2727_on_0.66.4 to E/react-native#0.66.4_patch). Once this is merged, I will update the lbaldy/ExpensifyApp/tree/bugfix/2727-upgrade-to-fork to use your patched version. And only after that will open a final MR to get the E/App#main fixed via the fork.

Sorry for so much back and forth, but this seems to be the only way to get this in with minimal impact on unrelated areas.

[AndrewGable]

My personal thoughts is we should do "C" here. Yes, it's a big lift and will take time, but it's the "correct" thing to do and we will eventually need to upgrade. This seems like a great excuse to do it.

[parasharrajat]

Thanks for the suggestion @AndrewGable. I am also in favor of that if we are fine with the delay. https://github.com/Expensify/App/issues/2727#issuecomment-1154431164 We can handle this via https://github.com/Expensify/App/issues/8503#issuecomment-1152785723

[iwiznia]

Agree with @AndrewGable and @parasharrajat

[lbaldy]

I come bearing good news, that the PR https://github.com/facebook/react-native/pull/34014 has been merged to react-native's main branch! :)

[parasharrajat]

Good news. Let me open an internal discussion to understand the timeline and next step.

[demedos]

I come bearing good news, that the PR facebook/react-native#34014 has been merged to react-native's main branch! :)

Awesome! What's the current workaround, if I may know?

[parasharrajat]

Debouncing the DimensionsChange event https://github.com/Expensify/App/blob/02f433979a7d22baa7d544ba5b6e236d77e7e0e3/src/components/withWindowDimensions.js#L42.

[lbaldy]

Good news. Let me open an internal discussion to understand the timeline and next step.

Great. Please let me know about the outcome whenever you get to any consensus.