CRNS-264: Fixing issues around network recovery #544
Conversation
vishalnarkhede
changed the title
| @@ -197,6 +197,10 @@ export type ChannelPreviewMessengerProps< | |||
| 'channel' | 'latestMessagePreview' | |||
| >; | |||
|
|
|||
| export const MemoizedChannelPreviewMessengerWithContext = React.memo( | |||
There was a problem hiding this comment.
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.
Fixes the image flickering issue on sample app!!
| }; | ||
| }, []); | ||
|
|
||
| const handleAppStateChange = async (nextAppState: AppStateStatus) => { |
There was a problem hiding this comment.
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.
This is now handled on js client level :)
There was a problem hiding this comment.
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.
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.
Actually curious if that happens, do you know?
…e into vishal/network-recovery-fix
…e into vishal/network-recovery-fix
vishalnarkhede
force-pushed
the
vishal/network-recovery-fix
branch
from
1a71ed9 to
02a9926
Compare
|
@nhannah Updated PR with few more changes.
|
vishalnarkhede
force-pushed
the
vishal/network-recovery-fix
branch
from
42ea831 to
d1c630a
Compare
| <HeaderComponent loadingMore={onStartReachedInProgress} /> | ||
| ); | ||
|
|
||
| const renderEmptyStateIndicator = () => ( |
There was a problem hiding this comment.
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.
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