App
App copied to clipboard
Expensify
[Tracking] Update navigation to support wide layouts on native
Problem
We have an iPad app, and it doesn't work as expected, because we have code that assumes that any code in index.native.js must be representing a narrow layout. Using platform as a proxy for:
- device layout
- presence of a mouse/hoverability
- keyboard handling
is a bad practice and a source for technical debt. It also violates one of the driving philosophies of this app - cross platform 99.99%.
For the sake of scope management, this issue will focus on removing instances where platform is used as a proxy for device layout, specifically these known issues, which will soon be fixed via a temporary workaround.
- https://github.com/Expensify/App/issues/35753
- https://github.com/Expensify/App/issues/35755
- https://github.com/Expensify/App/issues/35752
- https://github.com/Expensify/App/issues/35758
- https://github.com/Expensify/App/issues/35759
- https://github.com/Expensify/App/issues/35764
Solution
Remove code in index.native.js files that assumes it will be running on a narrow layout. Let's get wide layouts working on an iPad Pro (in portrait mode). When this was investigated before, one of the key difficulties found was that we rely on position: fixed in wide layouts on web, but that style is not currently supported in React Native.
cc @mountiny @hayata-suenaga @adamgrzybowski @WojtekBoman @mateuuszzzzz @kosmydel @MaciejSWM
Maybe one alternative to using position: fixed would be to leverage @gorhom/portal to move the view outside the positional scope, as suggested here
What if we create a parent component that fills the entire screen with its position set to relative, and then make the target component a child of this parent component, setting its position to absolute?
Job added to Upwork: https://www.upwork.com/jobs/~01290d6331a572c985
![melvin-bot[bot] avatar](https://avatars.githubusercontent.com/in/179547?v=4 "Published by a pub.dev verified publisher"){kind=small}
Triggered auto assignment to Contributor-plus team member for initial proposal review - @sobitneupane (External)
Triggered auto assignment to @sakluger (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.
Noted in the OP we still do not want to allow the landscape mode. Making this External to get proposals going. If anything is not clear, please ask. Thanks
Can I close my issue Unable to navigate away from Profile page using the back button (which is already linked on the OP) as the issue will be fixed in this issue?
@hayata-suenaga that issue is linked to the PR so I would just leave it open so we can confirm it was fixed in staging once the PR is deployed
We actually just spent a couple months adding support for position: "static" in the new architecture.
I will warn that adding position: "fixed" would be fairly complicated, and break a good number of assumptions in both Yoga and Fabric. E.g. beyond layout, it we would need to change Fabric mounting layer as well (e.g. we couldn't put a fixed item under a scrolling container. IIRC fixed has stacking context implications as well).
I would discourage trying to take it on without previous experience in both Yoga and Fabric's mounting later.
It sounds like that would be a potentially valuable improvement, but we'd need to assemble a dream team to do it and recognize that it would be a big initiative that would take a lot of time and might not be a top priority for Meta.
An alternate solution, if possible, would be much more expedient.
The position fixed is used because we need to modify the position of cards inside the StackView component provided by react-navigation, to display them side by side.
As a potential idea to investigate, we could try to use two or more StackViews in the custom navigator. This should give us more flexibility with positioning.
Alternatively, we could create our own / modify the StackView.
However, I am not sure how it would work with native stacks
š£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? šø
š£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? šø
Hi, Iām Michael (Mykhailo) from Callstack and I would like to work on this issue.
Actively working on the issue. Resolving a problem with 2 active stacks on a screen at the same moment.
Discuss internally how to handle the feature with 2 active stacks on a screen at the same moment.
I need to create a custom navigator to handle this case on native devices (iPads). So, I am going to develop it. Btw, looks like it is a hard task, therefore I need some time to investigate and implement.
š can someone catch me up on why this one was added to #wave8, and should it now be transfered to #wave-collect?
Going to integrate something similar to what they described in this article. Testing on a bare project now.
@rezkiy37 Just wanted point you also towards this ideal nav PR which makes some updates to the navigators https://github.com/Expensify/App/pull/37421
@trjExpensify This is a follow up to the ideal nav / app navigation reboot updates, we want to clean up how the layout is handled based on the device size.
At the moment, some actions are decided based on the screen width which because on native devices we struggled to achieve the desktop layout due to some RN styling limitations. We want to remove this debt.
It was added as a follow up to ideal nav then
Okay, so @mountiny I'm putting this one in #wave-collect polish. I've also added [Ideal Nav] in the issue title to associate it with that project.
I have some progress on the issue. The idea is to have 2 NavigationContainers. Continue working on it.