[Ideal Nav] [$1000] [Tracking] Update navigation to support wide layouts on native

[roryabraham]

Slack context: https://expensify.slack.com/archives/C07J32337/p1707147391183469

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.

• [HOLD for payment 2024-02-20] [$500] LHN - Unable to navigate away from Profile page using the back button #35753
• [HOLD for payment 2024-02-20] [$500] LHN - User navigated on the workspace overview page when created workspace #35755
• [$500] [HOLD for payment 2024-02-20] LHN - User navigated on Workspaces listing page when tapped on the settings tab in bottom #35752
• [HOLD for payment 2024-02-20] [$500] LHN - Unable to navigate on the account settings page #35758
• [HOLD for payment 2024-02-20] [$500] LHN - Workspace announce chat opened when selected workspace on "Choose workspace" page #35759
• [HOLD for payment 2024-02-20] [$500] LHN - Unable to navigate to workspace settings from bottom tab and from Workspace listing page #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.

This does not mean we will allow the native apps to rotate into a landscape mode.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01290d6331a572c985
• Upwork Job ID: 1754814923483574272
• Last Price Increase: 2024-08-08

[roryabraham]

cc @mountiny @hayata-suenaga @adamgrzybowski @WojtekBoman @mateuuszzzzz @kosmydel @MaciejSWM

[roryabraham]

Maybe one alternative to using position: fixed would be to leverage @gorhom/portal to move the view outside the positional scope, as suggested here

[hayata-suenaga]

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?

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01290d6331a572c985

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @sobitneupane (External)

[melvin-bot]

Triggered auto assignment to @sakluger (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.

[mountiny]

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

[hayata-suenaga]

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?

[mountiny]

@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

[roryabraham]

From Nick Gerleman at Meta:

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.

[roryabraham]

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.

[adamgrzybowski]

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

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

Upwork job price has been updated to $1000

[BrtqKr]

Hey, I'm a developer from SWM I'd like to take over this ticket

[adamgrzybowski]

Hey! @BrtqKr and I had a meeting where I gave my insights and we did a little brainstorming.

He can start the research, but our current idea for a solution depends on the changes I want to make, described here.

These changes are still in progress and I'll be OOO for two weeks soon, so I want to let you know that work on this issue will probably start after I get back.

Besides this issue is a tough one so I would like to be around 😄 for @BrtqKr

[sakluger]

Commenting for melvin since we just got an update yesterday.

[mountiny]

Makes sense, though could @BrtqKr already be making some progress on this based on the POC branch you have?

[BrtqKr]

I'm trying to wire this up with the POC, so I might be able to figure this out in advance, but I'll keep you updated on that during this week.

[sakluger]

Hey @BrtqKr any updates?

[BrtqKr]

@sakluger, I had to prioritize workspace rules PRs first. I'm done tho, so I'm working on that right now

[BrtqKr]

Had some time to experiment with this, this week. With some help from adam we've applied this layout for the tablets using the poc with split stack. I'm trying to research the animations/styling atm, since it's a bit problematic.

We've got one question about the layout though - do we always want to have a split nav in the portrait layout for the tablets, or maybe just for a landscape? It seemed a bit too narrow in some cases, but there are apps that are approaching it in this manner.

[mountiny]

We've got one question about the layout though - do we always want to have a split nav in the portrait layout for the tablets, or maybe just for a landscape? It seemed a bit too narrow in some cases, but there are apps that are approaching it in this manner.

I don't think this should ever depend on the device and orientation technically; the layout should always be dictated by the viewport size, so if the tablet portrait mode is too narrow, then we would just use narrow mode. Basically the viewport width should be the source of truth for what layout to render

@shawnborton do you agree?

[shawnborton]

Totally agree with that Vit, cc @Expensify/design for the gut check too.

[dannymcclain]

100% agree with Vit and Shawn.

[BrtqKr]

Hey, since most of the things I'm doing atm are just adjustments to the core part, I wanted to give a quick update on how it looks right now. Currently, the navigation is being rendered correctly in the split variant. Regarding the previous question, I mostly meant the tablet breakpoint, but overall it should be quite easy to change afterward. The video below presents a split variant for width >= medium size breakpoint. As you can see, the styling is mostly done, but I'm still trying to properly handle overlays and some more unique places, such as search. I've also cleaned up the breakpoint conditions in multiple places.

The next steps I'm going to take would be:

1. Finish overlays
2. Experiment with an alternate split stack structure to determine proper state persistence while resizing
3. Test animations
4. Clean up the breakpoints
5. Optimizations if necessary

I'll try to provide you with a full version sometime in the next week

Simulator.Screen.Recording.-.iPad.10th.generation.-.2024-09-20.at.00.02.29.mp4

[mountiny]

Thanks @BrtqKr! Great to see the progress, please try to post some update every day you work on this, even if there is not much to show visually.

To confirm, are your changes based on the updates from @adamgrzybowski and @WojtekBoman to refactor some of the navigation logic for bottom tabs history persistence? I think you said yes before but in general i assume we want to base this pr on top of it, so we do not have to do more work later

[BrtqKr]

Sure, sorry for that, I've been switching between nav and rules tasks recently, so it wasn't consistent enough to give anything detailed.

Regarding the update for today - I've been working on the custom style interpolator for the modal screens. Everything is related to the animations while transitioning between the report and rhp. I'm making some progress, but I'm somewhere in the middle - there some bugs, which are probably related to the nested stacks, but I'm trying to confirm this

[adamgrzybowski]

BTW just to confirm, yes it's based on our changes for the bottom tabs.

[BrtqKr]

I've finished the Overlays part, moving to the alternate split stack structure part. Also, we've been testing rendering two screens in the navtive-stack and it will probably require some adjustments, but @adamgrzybowski will be taking care of that.

[BrtqKr]

@mountiny , We've been verifying with @adamgrzybowski and @WoLewicki how those changes could be applied if the PR including native-stack gets merged and we've noticed a couple of things. Firstly, the split stack we've been mostly worried about seems to be working as expected, but we had to slightly adjust the split stack structure. Unfortunately, there are some issues when trying to include slide-in animations for the modals, which would be slightly weird if the original intent was to have a native experience.

There are some ways to approach this. Here's a list of options we've considered:

1. We could create a modal that would appear without any transition, then just apply the slide for the content using reanimated. This is basically writing our own stack with effects, which is quite ugly and might be annoying to maintain afterward.
2. We could just assume that the modal appears with fade, or something different, but as I stated before, this isn't the native experience we could expect from the modal.
3. There's an option to keep it in the state from the native stack PR, that is keep is as a full-screen modal. But since we'd like to include horizontal layout in the conditions, this is probably not an option.
4. We might want to keep some of the modals as a standard stacks, just for the sake of visual flexibility.

We'd probably suggest option 4, but there might still be some other problems related to the native stack we might need to consider later.

[mountiny]

Sounds good, lets just see how the options will play out with the bottom tabs + native stack in

[BrtqKr]

Had to take care of the extension ticket today. I'll be testing option 4 some time tomorrow or on Wednesday.

[BrtqKr]

Still focused on the share extension.

[BrtqKr]

Had some time to start applying the solution, but it's still work in progress, not seeing any issues with this approach so far though

[BrtqKr]

@mountiny, overall the rendering of the native screens seems to be working in combination with the standard ones, but regarding the modals - we've verified that there might be a risk with rendering increasingly larger parts of the stacks without applying native stack, so before we go further we wanted to confirm if this approach is acceptable.

1. We'll need to verify if the RHP as a standard stack with Report split stack written using native stack screens is working as expected. The main issue was the usage of the cards in the native stack and lack of possibilities for customizing modals. As far as we've checked this is unlikely this approach would work, but we'll try to push it slightly further
2. If there is no chance the first point would work, this might be necessary to rewrite the whole root stack to the previous state and avoid using native screens in there entirely, just to get the customizable modal handling - this is the main reason I prefer to ask before we dig any deeper, because this seems like a very impactful change especially while having native stack PR being worked on in parallel

We still believe option 4, that is avoiding native stack usage for some of the stacks would be the correct way of handling this scenario, but we wanted to make sure you're aware of where this might lead us.

[mountiny]

@BrtqKr, thanks for the update; we are hoping to get the native stack PRs merged soon, so we will be able to see soon. I would say you can try to pull the native stack changes and work based off that, but if you think that its better to wait for those changes to land on main and only then dig deeper, I can put this on hold too