-
-
Notifications
You must be signed in to change notification settings - Fork 540
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
enableFreeze cause useIsFocused stop working #1198
Comments
I can confirm this behaviour, but I think it's expected, isn't it? When screens freeze I assume them to not to render at all which actually makes calling |
Currently, I'd like to refresh the content when a tab is focused. So I need Maybe you're right @marhaupe . That mean |
Thanks for effort to make this feature. Same issue here, I use |
Isn't this the point of freezing the screen? You disable rendering when it's not focused. |
After using it for some time we found some edge cases in our app where we rely on |
Can you clarify the issues? Does it not trigger when you refocus? |
Update the data then user refocus the screen:
Another case is I'm doing periodical fetches each minute, I'm stopping them then |
That’s interesting. I wonder if that use case would be better solved with |
I have the exact same pattern in my app. I'd expect the react state to still be updated but just not render/update views. |
Hi @Titozzz, @r0b0t3d, @nandorojo, @marhaupe, and @tomasmozeris Thank you so much for participating in this discussion. It helped a lot! I think we've finally figured out how to overcome this issue and the solution is quite simple. We disable freeze for the first render so the Could you guys confirm the solution works by testing the code in your app eg. by installing
or swapping the whole That would be amazing! 🙌 |
This looks great! I can confirm that our logic that e.g. unmounts a |
@kacperkapusciak it works for me too 🚀. Thanks |
Any one noticed that it's not working with stack, it's solved for me with tabs but not stack |
EDIT ok I solved this by adding a timeout.
solves the problem but it doesn't sound like the right thing to do. |
Looking at that code for the delayed freeze, it's actually not concurrent safe (executing side effects in a render function, that could get thrown away). A more proper fix would be something like this: diff --git a/node_modules/react-native-screens/src/index.native.tsx b/node_modules/react-native-screens/src/index.native.tsx
index edcd032..78aba2b 100644
--- a/node_modules/react-native-screens/src/index.native.tsx
+++ b/node_modules/react-native-screens/src/index.native.tsx
@@ -1,4 +1,4 @@
-import React from 'react';
+import React, {useEffect} from 'react';
import {
Animated,
Image,
@@ -152,13 +152,11 @@ function DelayedFreeze({ freeze, children }: FreezeWrapperProps) {
// flag used for determining whether freeze should be enabled
const [freezeState, setFreezeState] = React.useState(false);
- if (freeze !== freezeState) {
- // setImmediate is executed at the end of the JS execution block.
- // Used here for changing the state right after the render.
+ useEffect(() => {
setImmediate(() => {
setFreezeState(freeze);
});
- }
+ }, [freeze])
return <Freeze freeze={freeze ? freezeState : false}>{children}</Freeze>;
} FWIW: This does fix the problem for us with Native Stacks and useIsFocused firing properly |
@amadeus your fix is also working for us. Do you want to open a PR maybe? |
Hmmm - I came up with this exact solution, but in my case it drastically effects performance when moving between tabs. It is only marginally better than not freezing at all. Has anyone else used react-freeze with @react-navigation/bottom-tabs? It works great, just can't figure out how to react to isFocused in a performant way 😭 BTW - I don't think there is any need to use setImmediate in the above solution - I think setting of the state alone is identical. |
This fixed it for me too! Why is this not merged in still and why is the ticket closed? 👀 |
Finally got around to opening up a PR for this here: #1980 |
## Description Executing side effects in render is usually considered bad manners in react land, and given concurrent rendering could have unexpected results if renders are thrown away. ## Changes This change makes it so setImmediate fires in an effect, and also cleans up after itself if for whatever reason the callback isn't fired. (although I think it's probably not possible with how setImmediate is implemented) ## Screenshots / GIFs N/A ## Test code and steps to reproduce We (at Discord) ran essentially this patch for probably over a year now without issue and figured it might be good to give back. Here's an issue related to it: #1198 ## 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
## Description Executing side effects in render is usually considered bad manners in react land, and given concurrent rendering could have unexpected results if renders are thrown away. ## Changes This change makes it so setImmediate fires in an effect, and also cleans up after itself if for whatever reason the callback isn't fired. (although I think it's probably not possible with how setImmediate is implemented) ## Screenshots / GIFs N/A ## Test code and steps to reproduce We (at Discord) ran essentially this patch for probably over a year now without issue and figured it might be good to give back. Here's an issue related to it: software-mansion/react-native-screens#1198 ## 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
…#1980) ## Description Executing side effects in render is usually considered bad manners in react land, and given concurrent rendering could have unexpected results if renders are thrown away. ## Changes This change makes it so setImmediate fires in an effect, and also cleans up after itself if for whatever reason the callback isn't fired. (although I think it's probably not possible with how setImmediate is implemented) ## Screenshots / GIFs N/A ## Test code and steps to reproduce We (at Discord) ran essentially this patch for probably over a year now without issue and figured it might be good to give back. Here's an issue related to it: software-mansion#1198 ## 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
Description
In bottom tabs, when enabling
enableFreeze
,useIsFocused
is not triggered when screen blur.Screenshots
Steps To Reproduce
Home
andSettings
Settings
, addconst isFocused = useIsFocused()
Settings
screen,isFocused
updated totrue
(this is correct)Home
,isFocused
stilltrue
Expected behavior
At step 4,
isFocused
inSettings
should befalse
Actual behavior
At step 4,
isFocused
inSettings
istrue
Reproduction
Platform
I just checked on iOS, not sure about other platforms
Workflow
Package versions
The text was updated successfully, but these errors were encountered: