Skip to content
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

fix(iOS): header left and right layout on fabric #2248

Merged
merged 6 commits into from
Jul 19, 2024

Conversation

alduzy
Copy link
Member

@alduzy alduzy commented Jul 16, 2024

Description

This PR fixes the header layout mismatch when updating both headerLeft and headerRight options simultaneously using navigation.setOptions.

Fixes #2231 .

Changes

  • Forced subview to re-layout when updating layoutMetrics
  • added Test2231.tsx repro

Screenshots / GIFs

Before

Screenshot 2024-07-16 at 12 05 14

After

Screenshot 2024-07-16 at 12 04 49

Test code and steps to reproduce

  • Use Test2231.tsx repro

Checklist

  • Ensured that CI passes

@alduzy alduzy requested review from tboba and kkafar July 16, 2024 10:07
@alduzy alduzy changed the title @alduzy/fabric header left and right layout fix fix(iOS): header left and right layout on fabric Jul 16, 2024
Copy link
Member

@kkafar kkafar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks promising, I just left a question on "whys".

If you're to spend too much time investigating then I think it is not worth it & feel free to say so.

One general note: add link to this PR in comment above the line you added, because it is definitely not obvious why the line should be there.

@@ -72,6 +72,7 @@ - (void)updateLayoutMetrics:(const react::LayoutMetrics &)layoutMetrics
self);
} else {
self.bounds = CGRect{CGPointZero, frame.size};
[self.superview layoutIfNeeded];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so we now trigger layout in the native superview (this is one of system views, beyond control of react) every time we receive a new frame from react.

The solution itself is ok & if it helps I'm for it, but do we have understanding why does it not work without this change? Especially that we do not have such code on Paper & I believe it works fine there?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it does work fine on paper. It looks like the bounds of the subview are set properly but then the frame is given the old values unless we trigger a re-layout of the superview.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you check what happens if you disable view recycling on header subviews in this PR? Im speaking with context of this issue on which we debated earlier today: #2232

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be the same issue of the views being swapped due to recycling pool working in stack manner.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turning off recycling does not fix this issue

Copy link
Member

@kkafar kkafar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, after playing around with this & seeing no other solution I think we should proceed.

@alduzy alduzy merged commit 5cd3b11 into main Jul 19, 2024
5 checks passed
@alduzy alduzy deleted the @alduzy/fabric-header-left-and-right-layout-fix branch July 19, 2024 13:38
alduzy added a commit that referenced this pull request Sep 27, 2024
## Description

This PR fixes the incorrect position of the custom header items when
updating more than one option at the same time. The proposed solution
let us remove the previous fix for a similar problem:
#2248 which
only fixed the issue on fabric.

Fixes #432, #2231.

## Changes

- forced re-layout of the navigation controller when subviews are
updated
- removed previous fix
- updated `Test432` repro

<!--

## Screenshots / GIFs

Here you can add screenshots / GIFs documenting your change.

You can add before / after section if you're changing some behavior.

### Before

### After

-->

## Test code and steps to reproduce

- use `Test432` and `Test2231` to test this fix on both architectures.

## Checklist

- [x] Included code example that can be used to test this change
- [x] Ensured that CI passes
alduzy added a commit that referenced this pull request Oct 7, 2024
## Description

This PR intents to fix header subviews incorrect layout when changing
tabs.

The previous solution did layout the subviews correctly in the test
cases, but triggered an undesirable `layoutIfNeeded` when going back
from tab to tab. In such case the navigation layout happened without
updating subview's layout metrics.

Moving the logic to subview resolves the issue as the re-layout is now
triggered only when subview's layout metrics are updated.

Related fixes from the past:
#2316,
#2248

## Changes

- combined `Test2231.tsx` with `Test432.tsx` to create comprehensive
test case
- moved re-layout logic to subview

## Screenshots / GIFs

### Before
![Screenshot 2024-10-04 at 10 10
15](https://github.com/user-attachments/assets/1a8a747e-fe1d-4b03-ba63-1891732d7d77)

### After
![Screenshot 2024-10-04 at 10 09
37](https://github.com/user-attachments/assets/68b3554f-d67d-47f4-946d-ace60e1bbf83)


## Test code and steps to reproduce

- Use `Test432.tsx` repro

## Checklist

- [x] Included code example that can be used to test this change
- [x] Ensured that CI passes
ja1ns pushed a commit to WiseOwlTech/react-native-screens that referenced this pull request Oct 9, 2024
## Description

This PR fixes the header layout mismatch when updating both `headerLeft`
and `headerRight` options simultaneously using `navigation.setOptions`.

Fixes software-mansion#2231 .

## Changes

- Forced subview to re-layout when updating layoutMetrics
- added `Test2231.tsx` repro


## Screenshots / GIFs

### Before
![Screenshot 2024-07-16 at 12 05
14](https://github.com/user-attachments/assets/37a5a77d-1cd5-457f-901e-9dd5b4065a8f)

### After
![Screenshot 2024-07-16 at 12 04
49](https://github.com/user-attachments/assets/025db807-ef6d-46f2-b4c0-cd9f06e03d93)

## Test code and steps to reproduce

- Use `Test2231.tsx` repro

## Checklist

- [x] Ensured that CI passes
ja1ns pushed a commit to WiseOwlTech/react-native-screens that referenced this pull request Oct 9, 2024
## Description

This PR fixes the incorrect position of the custom header items when
updating more than one option at the same time. The proposed solution
let us remove the previous fix for a similar problem:
software-mansion#2248 which
only fixed the issue on fabric.

Fixes software-mansion#432, software-mansion#2231.

## Changes

- forced re-layout of the navigation controller when subviews are
updated
- removed previous fix
- updated `Test432` repro

<!--

## Screenshots / GIFs

Here you can add screenshots / GIFs documenting your change.

You can add before / after section if you're changing some behavior.

### Before

### After

-->

## Test code and steps to reproduce

- use `Test432` and `Test2231` to test this fix on both architectures.

## Checklist

- [x] Included code example that can be used to test this change
- [x] Ensured that CI passes
ja1ns pushed a commit to WiseOwlTech/react-native-screens that referenced this pull request Oct 9, 2024
## Description

This PR intents to fix header subviews incorrect layout when changing
tabs.

The previous solution did layout the subviews correctly in the test
cases, but triggered an undesirable `layoutIfNeeded` when going back
from tab to tab. In such case the navigation layout happened without
updating subview's layout metrics.

Moving the logic to subview resolves the issue as the re-layout is now
triggered only when subview's layout metrics are updated.

Related fixes from the past:
software-mansion#2316,
software-mansion#2248

## Changes

- combined `Test2231.tsx` with `Test432.tsx` to create comprehensive
test case
- moved re-layout logic to subview

## Screenshots / GIFs

### Before
![Screenshot 2024-10-04 at 10 10
15](https://github.com/user-attachments/assets/1a8a747e-fe1d-4b03-ba63-1891732d7d77)

### After
![Screenshot 2024-10-04 at 10 09
37](https://github.com/user-attachments/assets/68b3554f-d67d-47f4-946d-ace60e1bbf83)


## Test code and steps to reproduce

- Use `Test432.tsx` repro

## Checklist

- [x] Included code example that can be used to test this change
- [x] Ensured that CI passes
kkafar pushed a commit that referenced this pull request Oct 25, 2024
## Description

This PR fixes the incorrect position of the custom header items when
updating more than one option at the same time. The proposed solution
let us remove the previous fix for a similar problem:
#2248 which
only fixed the issue on fabric.

Fixes #432, #2231.

## Changes

- forced re-layout of the navigation controller when subviews are
updated
- removed previous fix
- updated `Test432` repro

<!--

## Screenshots / GIFs

Here you can add screenshots / GIFs documenting your change.

You can add before / after section if you're changing some behavior.

### Before

### After

-->

## Test code and steps to reproduce

- use `Test432` and `Test2231` to test this fix on both architectures.

## Checklist

- [x] Included code example that can be used to test this change
- [x] Ensured that CI passes

(cherry picked from commit bc95fa4)
kkafar pushed a commit that referenced this pull request Oct 25, 2024
## Description

This PR intents to fix header subviews incorrect layout when changing
tabs.

The previous solution did layout the subviews correctly in the test
cases, but triggered an undesirable `layoutIfNeeded` when going back
from tab to tab. In such case the navigation layout happened without
updating subview's layout metrics.

Moving the logic to subview resolves the issue as the re-layout is now
triggered only when subview's layout metrics are updated.

Related fixes from the past:
#2316,
#2248

## Changes

- combined `Test2231.tsx` with `Test432.tsx` to create comprehensive
test case
- moved re-layout logic to subview

## Screenshots / GIFs

### Before
![Screenshot 2024-10-04 at 10 10
15](https://github.com/user-attachments/assets/1a8a747e-fe1d-4b03-ba63-1891732d7d77)

### After
![Screenshot 2024-10-04 at 10 09
37](https://github.com/user-attachments/assets/68b3554f-d67d-47f4-946d-ace60e1bbf83)

## Test code and steps to reproduce

- Use `Test432.tsx` repro

## Checklist

- [x] Included code example that can be used to test this change
- [x] Ensured that CI passes

(cherry picked from commit 91d89c4)
kkafar added a commit that referenced this pull request Dec 6, 2024
…2552)

## Description

> [!note]
> This issue seems to concern only old architecture. See below for
description of Fabric situation 👇🏻

This PR aims to fix a bug described below 👇🏻 and at the same time
balancing on the thin edge of not introducing regressions regarding:
#2316, #2248, #2385.

### Bug description

See `Test2552`. 

The flow is as follows: 

1. we have tab navigator with nested stack navigators on each tab (A &
B),
2. In `useLayoutEffect` we schedule a timer which callback changing the
subview elements,
3. before the timer fires we change the tab from A to B,
4. wait few seconds fot timer to fire,
5. go back to A,
6. notice that the subviews are laid out incorrectly (video below 👇🏻)


https://github.com/user-attachments/assets/2bf621a7-efd4-44cf-95e1-45a46e425f07


Basically what happens is we're sending `layoutIfNeeded` to navigation
bar before subviews are mounted under navigation bar view hierarchy.
This causes "isLayoutDirty" flags to be cleaned up and subsequent
`layoutIfNeeded` messages have no effect.

## Changes

We now wait with triggering layout for the subview to be attached to
window.

> [!note]
> TODO: possibly we should call the layout from `didMoveToWindow` but I
haven't found the case it does not work without the call, so I'm not
adding it for now.

> [!note]
> Calling layout on whole navigation bar for every subview update seems
wrong, however the change is subview change can have effect on other
neighbouring views (e.g. long title which need to be truncated) & it
seems that we need to do this. Maybe we could get away will requesting
it only from UINavigationBarContentView skipping few levels, but this is
left for consideration in the future.

> [!important]
> I do not understand why we need to send `layoutIfNeeded` and
`setNeedsLayout` is not enough, but not sending the former results in
regressions in Test432. Leaving it for future considerations.

### Fabric 

The strategy with setting screen options inside timer nested in
useLayoutEffect seems to not work at all on new architecture. My
impression is that the timer gets cancelled every time the screen loses
focus (tab is changed). I do not know whether this is a bug on our side,
or maybe it should work this way or it is Fabric bug. This should be
debugged in future.


## Test code and steps to reproduce

Test2552 - Follows the steps described above ☝🏻 

Test432 - Follow the steps from issues described in mentioned issues
:point_up:

## Checklist

- [ ] Included code example that can be used to test this change
- [ ] Updated TS types
- [ ] Updated documentation: <!-- For adding new props to native-stack
-->
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx
- [ ]
https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx
- [ ] Ensured that CI passes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong layout when updating headerLeft and headerRight on new arch
2 participants