-
-
Notifications
You must be signed in to change notification settings - Fork 126
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
Shared element stuck in list when navigateíng back #24
Comments
This means that the shared-element transition is still in progress. While it is in progress, it keeps the original item hidden and draws the overlay. |
Okay. Yes I also see it on Android. |
Alright. How does the rest of your navigation/stack look like? |
I'm facing a similar issue. Is there a way to know when the transitions back has finished in the origin screen? |
Any updates in this issue? |
Here's some log output that illustrates the problem. From the time the default transition starts and up until it ends, it takes almost 1 second, which is too much.
The default react-navigation-stack export const TransitionIOSSpec: TransitionSpec = {
animation: 'spring',
config: {
stiffness: 1000,
damping: 500,
mass: 3,
overshootClamping: true,
restDisplacementThreshold: 0.01,
restSpeedThreshold: 0.01,
},
}; It seems that the values are optimized for smoothness, but this also causes the spring-particle to "settle" very late, causing the problem that you witnessed. For instance, when I change the const StackNavigator1 = createSharedElementStackNavigator(
{
Main: MainScreen,
Detail: DetailScreen,
},
{
defaultNavigationOptions: {
transitionSpec: {
open: {
animation: 'timing',
config: {
duration: 350,
},
},
close: {
animation: 'timing',
config: {
duration: 350,
},
},
},
},
},
{
name: 'StackNavigator1',
},
);
|
If would be nice if someone could "fine-tune" the iOS spring config so that it settles way faster and perhaps even push a PR to react-navigation-stack for this? |
I've done some testing and found the following settings quite effective in making the spring on iOS come to a rest much faster, while not compromising smoothness. The spring settles in about 500ms, instead of 1000ms. export const iosTransitionSpec = {
animation: 'spring',
config: {
stiffness: 1000,
damping: 500,
mass: 3,
overshootClamping: true,
restDisplacementThreshold: 10,
restSpeedThreshold: 10,
},
};
// Example usage
const StackNavigator1 = createSharedElementStackNavigator(
{
Main: MainScreen,
Detail: DetailScreen,
},
{
defaultNavigationOptions: {
onTransitionStart: () => console.log('onTransitionStart'),
onTransitionEnd: () => console.log('onTransitionEnd'),
transitionSpec: {
open: iosTransitionSpec,
close: iosTransitionSpec,
},
},
},
{
name: 'StackNavigator1',
},
); Let me know whether this solves your problem @kledk ? |
@IjzerenHein Cool, I will try that out as soon as possible! |
Transition spec posted above seems to solve all of my issues. The one remaining problems is |
Hi, please create a separate issue for this and post a (slow-motion) video of the problem. |
I've issued a PR to update the transitionSpec in |
# Why When using the stack navigator on iOS, it takes a (too) long time before the `didFocus` and stack `onTransitionEnd` lifecycle events are triggered. The visual animation is typically completed well within 500 msec, but it takes around 1000 msec before the previously mentioned events are emitted. This causes problems with for instance `react-navigation-shared-element`, which relies on these events to fire in a timely manner(IjzerenHein/react-navigation-shared-element#24) # How This PR updates the resting threshold so that the underlying spring settles faster. No visual differences or differences in smoothness were witnessed during testing. ## Before Time to settle `didFocus`: **941** Time to settle `stack.onTransitionEnd`: **924** ``` 15:59:55.743 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:59:55.744 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:59:55.745 Transition start: "ListScreen" -> "DetailScreen" 15:59:56.667 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:59:56.668 Transition end: "DetailScreen" 15:59:56.685 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1 ``` ## After Time to settle `didFocus`: **529** Time to settle `stack.onTransitionEnd`: **512** ``` 15:55:00.686 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:55:00.687 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:55:00.687 Transition start: "ListScreen" -> "DetailScreen" 15:55:01.198 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:55:01.199 Transition end: "DetailScreen" 15:55:01.216 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1
I tried this on iOS, however it still does not work. I've attached some code, and a video example below. Any advice appreciated! Seems to also be related to this: #72 //Transition:
const Transition = {
gestureDirection: 'vertical',
transitionSpec: {
open: iosTransitionSpec,
close: iosTransitionSpec,
},
cardStyleInterpolator: ({ current }) => {
return {
cardStyle: {
opacity: current.progress,
},
overlayStyle: {
opacity: current.progress.interpolate({
inputRange: [0, 1],
outputRange: [0, 0.5],
}),
},
};
},
};
//Screen:
<Stack.Screen
name="PhotoView"
component={PhotoView}
options={{
...Transition,
}}
sharedElementsConfig={(route) => {
const { uri } = route.params;
return [
{ id: uri, animation: 'fade', align: 'center-center' },
];
}}
/> |
I tried the same exact solution above regarding altering the transitionSpec on iOS. However, I'm still running into the same problem with the SharedElement staying stuck in place while scrolling through a FlatList. I've even tried altering the values of the durations unfortunately, there's still no difference.
Currently, I'm using the following versions:
Anyone know what the problem may be? |
# Why When using the stack navigator on iOS, it takes a (too) long time before the `didFocus` and stack `onTransitionEnd` lifecycle events are triggered. The visual animation is typically completed well within 500 msec, but it takes around 1000 msec before the previously mentioned events are emitted. This causes problems with for instance `react-navigation-shared-element`, which relies on these events to fire in a timely manner(IjzerenHein/react-navigation-shared-element#24) # How This PR updates the resting threshold so that the underlying spring settles faster. No visual differences or differences in smoothness were witnessed during testing. ## Before Time to settle `didFocus`: **941** Time to settle `stack.onTransitionEnd`: **924** ``` 15:59:55.743 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:59:55.744 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:59:55.745 Transition start: "ListScreen" -> "DetailScreen" 15:59:56.667 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:59:56.668 Transition end: "DetailScreen" 15:59:56.685 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1 ``` ## After Time to settle `didFocus`: **529** Time to settle `stack.onTransitionEnd`: **512** ``` 15:55:00.686 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:55:00.687 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:55:00.687 Transition start: "ListScreen" -> "DetailScreen" 15:55:01.198 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:55:01.199 Transition end: "DetailScreen" 15:55:01.216 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1
# Why When using the stack navigator on iOS, it takes a (too) long time before the `didFocus` and stack `onTransitionEnd` lifecycle events are triggered. The visual animation is typically completed well within 500 msec, but it takes around 1000 msec before the previously mentioned events are emitted. This causes problems with for instance `react-navigation-shared-element`, which relies on these events to fire in a timely manner(IjzerenHein/react-navigation-shared-element#24) # How This PR updates the resting threshold so that the underlying spring settles faster. No visual differences or differences in smoothness were witnessed during testing. ## Before Time to settle `didFocus`: **941** Time to settle `stack.onTransitionEnd`: **924** ``` 15:59:55.743 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:59:55.744 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:59:55.745 Transition start: "ListScreen" -> "DetailScreen" 15:59:56.667 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:59:56.668 Transition end: "DetailScreen" 15:59:56.685 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1 ``` ## After Time to settle `didFocus`: **529** Time to settle `stack.onTransitionEnd`: **512** ``` 15:55:00.686 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:55:00.687 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:55:00.687 Transition start: "ListScreen" -> "DetailScreen" 15:55:01.198 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:55:01.199 Transition end: "DetailScreen" 15:55:01.216 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1
# Why When using the stack navigator on iOS, it takes a (too) long time before the `didFocus` and stack `onTransitionEnd` lifecycle events are triggered. The visual animation is typically completed well within 500 msec, but it takes around 1000 msec before the previously mentioned events are emitted. This causes problems with for instance `react-navigation-shared-element`, which relies on these events to fire in a timely manner(IjzerenHein/react-navigation-shared-element#24) # How This PR updates the resting threshold so that the underlying spring settles faster. No visual differences or differences in smoothness were witnessed during testing. ## Before Time to settle `didFocus`: **941** Time to settle `stack.onTransitionEnd`: **924** ``` 15:59:55.743 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:59:55.744 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:59:55.745 Transition start: "ListScreen" -> "DetailScreen" 15:59:56.667 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:59:56.668 Transition end: "DetailScreen" 15:59:56.685 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1 ``` ## After Time to settle `didFocus`: **529** Time to settle `stack.onTransitionEnd`: **512** ``` 15:55:00.686 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:55:00.687 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:55:00.687 Transition start: "ListScreen" -> "DetailScreen" 15:55:01.198 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:55:01.199 Transition end: "DetailScreen" 15:55:01.216 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1
# Why When using the stack navigator on iOS, it takes a (too) long time before the `didFocus` and stack `onTransitionEnd` lifecycle events are triggered. The visual animation is typically completed well within 500 msec, but it takes around 1000 msec before the previously mentioned events are emitted. This causes problems with for instance `react-navigation-shared-element`, which relies on these events to fire in a timely manner(IjzerenHein/react-navigation-shared-element#24) # How This PR updates the resting threshold so that the underlying spring settles faster. No visual differences or differences in smoothness were witnessed during testing. ## Before Time to settle `didFocus`: **941** Time to settle `stack.onTransitionEnd`: **924** ``` 15:59:55.743 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:59:55.744 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:59:55.745 Transition start: "ListScreen" -> "DetailScreen" 15:59:56.667 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:59:56.668 Transition end: "DetailScreen" 15:59:56.685 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1 ``` ## After Time to settle `didFocus`: **529** Time to settle `stack.onTransitionEnd`: **512** ``` 15:55:00.686 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:55:00.687 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:55:00.687 Transition start: "ListScreen" -> "DetailScreen" 15:55:01.198 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:55:01.199 Transition end: "DetailScreen" 15:55:01.216 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1
# Why When using the stack navigator on iOS, it takes a (too) long time before the `didFocus` and stack `onTransitionEnd` lifecycle events are triggered. The visual animation is typically completed well within 500 msec, but it takes around 1000 msec before the previously mentioned events are emitted. This causes problems with for instance `react-navigation-shared-element`, which relies on these events to fire in a timely manner(IjzerenHein/react-navigation-shared-element#24) # How This PR updates the resting threshold so that the underlying spring settles faster. No visual differences or differences in smoothness were witnessed during testing. ## Before Time to settle `didFocus`: **941** Time to settle `stack.onTransitionEnd`: **924** ``` 15:59:55.743 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:59:55.744 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:59:55.745 Transition start: "ListScreen" -> "DetailScreen" 15:59:56.667 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:59:56.668 Transition end: "DetailScreen" 15:59:56.685 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1 ``` ## After Time to settle `didFocus`: **529** Time to settle `stack.onTransitionEnd`: **512** ``` 15:55:00.686 [ListViewStack]startTransition, closing: false, nestingDepth: 1 15:55:00.687 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false 15:55:00.687 Transition start: "ListScreen" -> "DetailScreen" 15:55:01.198 [ListViewStack]endTransition, closing: false, nestingDepth: 1 15:55:01.199 Transition end: "DetailScreen" 15:55:01.216 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1
Anybody ever had an issue like this?
My shared element is somehow getting stuck when I navigate back to the list.
The text was updated successfully, but these errors were encountered: