-
Notifications
You must be signed in to change notification settings - Fork 325
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
CRNS-264: Fixing issues around network recovery #544
Conversation
@@ -197,6 +197,10 @@ export type ChannelPreviewMessengerProps< | |||
'channel' | 'latestMessagePreview' | |||
>; | |||
|
|||
export const MemoizedChannelPreviewMessengerWithContext = React.memo( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Saves some re-renders!!
const rightContent = useMemo(() => { | ||
return RightContent && | ||
<View style={styles.rightContainer}> | ||
<RightContent /> | ||
</View> | ||
}, []); | ||
|
||
const leftContent = useMemo(() => { | ||
return LeftContent && | ||
<LeftContent /> | ||
}, []); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes the image flickering issue on sample app!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly minor comments, but one def needs changing
}; | ||
}, []); | ||
|
||
const handleAppStateChange = async (nextAppState: AppStateStatus) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be an issue; if you get a phone call lets say, the app state will go from active -> inactive (no connection closed), then you end call and in app, app state will go from inactive -> active (new connection), now 2x connections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now handled on js client level :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should still get the logic right tho? I.e. if we only close when going to background only open when coming from background??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If app is in inactive state for too long, websocket may still be dropped. So I think it's just better to call openConnection anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually curious if that happens, do you know?
…e into vishal/network-recovery-fix
…e into vishal/network-recovery-fix
1a71ed9
to
02a9926
Compare
@nhannah Updated PR with few more changes.
|
42ea831
to
d1c630a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just had a few comments that should be easy to answer, if it's all working think were good to go though.
<HeaderComponent loadingMore={onStartReachedInProgress} /> | ||
); | ||
|
||
const renderEmptyStateIndicator = () => ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused with the change here of moving the loading state outside the flat list? If I recall correctly the main reason to have loading in the empty state is performance related to rendering the entire list possibly repeatedly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So rendering empty state is still in flatlist, I have just separated out inline fuction. Inline functions can cause more re-renders. React documentation only gives headsup about this for ref callback function (inline vs separate function), it doesn't say any such thing about indicators. But from the discussions I can see, it's still better not have inline functions in FlatList.
For loading indicator, I had to take it out of FlatList because
- when you are in network recovery state, we show loading indicator.
- after recovery, when new results are ready, scroll doesn't start at bottom of the list if loading indicator is part of FlatList (within ListEmptyComponent).
And this seemed like a confusing UX to me.
…e into vishal/network-recovery-fix
Co-authored-by: Neil <[email protected]>
…e into vishal/network-recovery-fix
…ream-chat-react-native into vishal/network-recovery-fix
…e into vishal/network-recovery-fix # Conflicts: # examples/TypeScriptMessaging/yarn.lock # src/components/MessageList/MessageList.tsx
Submit a pull request
Dependent on #626
CLA
Description of the pull request