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

1.0 RC01 side effect on tab navigation #58

Closed
Tolriq opened this issue Apr 26, 2022 · 5 comments
Closed

1.0 RC01 side effect on tab navigation #58

Tolriq opened this issue Apr 26, 2022 · 5 comments

Comments

@Tolriq
Copy link

Tolriq commented Apr 26, 2022

The fix (#55) have the side effect of now fully unloading the view models when navigating between tabs.

While the fix is normal and wanted, due to the current limitations of LazyList not proposing any proper way to delay the state restoration, this makes restoring scroll position insanely complex until they propose something.

It would be nice to have a way to opt out or a workaround for this use case.

@Tolriq
Copy link
Author

Tolriq commented Apr 26, 2022

So seems all that is missing is a function on SnapshotStateStack to be able to reorder / modify the stack.

could be a moveToFrontOrPush(item) or just a remove(item) that return the item or null that we can then push. The difficulty is to decide about the events to emit.

@adrielcafe
Copy link
Owner

I've added a disposeNestedNavigators param on TabNavigator in 1.0.0-rc02, that way you can control the disposal behavior of nested navigators inside tabs.

Please let me know if this solves your issue.

@Tolriq
Copy link
Author

Tolriq commented May 1, 2022

Thanks, this works for the need.

This is still a little too global option to address #25 but that's another story that can be workaround.

@Tolriq Tolriq closed this as completed May 1, 2022
@adrielcafe
Copy link
Owner

Indeed, I'll work on a more granular approach for #25 .

@Tolriq
Copy link
Author

Tolriq commented May 1, 2022

I have a custom tabnavigator and workaround the need, so not sure it's worth changing the API surface that late in the process.

So don't block an 1.0 release for that, it's not worth it as quite specific need.

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

No branches or pull requests

2 participants