-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Modified for FlatList #629
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
Conversation
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.
Please remove react-native-invertible-scroll-view from dependencies.
src/MessageContainer.js
Outdated
| this.setState({ | ||
| dataSource: this.state.dataSource.cloneWithRows(messagesData.blob, messagesData.keys) | ||
| }); | ||
| messagesData: this.prepareMessages(nextProps.messages) |
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 cause all chat messages to re-render every time a new message is added.
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 think we should remove prepareMessages and move set value for nextMessage and previousMessage into renderItem function
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.
My thoughts:
Its not worse than what it was with the ListView approach. Correct me if I am wrong since the old approach was rerendering the whole ListView anyway. FlatList is supposed to render only what is actually viewable anyway, and not those components that are outside the view, so we are getting an improvement right there.
I was more thinking of getting a quick fix in for now, and we can always have perf improvements later? But just my opinion.
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.
It is not the prepareMessages that will cause everything (in the view) to rerender, that will happen anyway when a new message arrives. What we can do about that is make the components being rendered pure, and allow them to be effective PureComponent-s
|
maybe you guys have some thoughts to share on this! @Kabangi @radko93 @dralletje @bartolkaruza @DavidKuennen @Ashoat |
src/MessageContainer.js
Outdated
| return output = messages.reduce((o,m,i) => { | ||
| const previousMessage = messages[i + 1] || {} | ||
| const nextMessage = messages[i - 1] || {} | ||
| o.push( { |
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.
Two small questions here:
-
It seems to me this is a lot simpler done using
.map, maybe even more performant? (Dunno if that even matters here) -
Because you merge previousMessage and nextMessage props onto the existing message, that message will be "invalidated" when matching it against existing messages (causing PureComponent or shouldComponentUpdate to always see change). I'd recommend setting
{ currentMessage, previousMessage, nextMessage }and properly usingitem.currentMessageinstead of justitemin https://github.com/FaridSafi/react-native-gifted-chat/pull/629/files#diff-bd8395a0a94eca8b61a34ec66f8a605cR102
It might be that I miss something why this is necessary, let me know :)
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.
About the second one, I see that Message isn't PureComponent yet, but I think it is still good to these optimisations already, if we want Message to be an effective PureComponent later ;)
| }; | ||
|
|
||
| if (this.props.renderMessage) { | ||
| return this.props.renderMessage(messageProps); |
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.
Is it on purpose that this is outside of the { transform: [{ scaleY: -1 }] } ? I don't think people will want to have to set that themselves, and when we go to use invert={true} on the container later, the people that do have their own { transform: [{ scaleY: -1 }] } will have to remove it again and ughhhhh hahaha :)
src/MessageContainer.js
Outdated
| renderFooter={this.renderLoadEarlier} | ||
| renderScrollComponent={this.renderScrollComponent} | ||
| renderFooter={this.renderLoadEarlier()} | ||
| style={{transform: [{scaleY: -1 },{perspective: 1280}]}} |
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.
One last thing, what is the reasoning behind using this transform ourselves, and not using inverted={true}? I'm not sure why it not in the documentation (so you may very well know something I don't) :-)
But this would solve the problem of us having to set the transform on all the items, and it would also spare us a view per item (FlatList applies inverted styles on the view it would create anyway, we introduce a new one :-/)
I understand if it is for version support: I think inverted only is supported in a couple of last version
https://github.com/facebook/react-native/blob/master/Libraries/Lists/FlatList.js#L142
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.
Inverted works only on RN 0.49 and above. Atleast for Huawei phones running Android 7
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.
Then maybe it is even a combination of the fact that inverted got added later + the perspective fix... Maybe good to wait some version before we use inverted, but still worth adding a TODO/NOTE?
Start messages at top
…fted-chat into inverted-prop # Conflicts: # src/GiftedChat.js
Inverted prop for reverse messages display order
default true
|
I've been creating #705 to have a clean history. Please let me know if I can close this one? |
|
@xcarpentier , yes, feel free to close this PR |
* r_master: Move listViewProps to the end (FaridSafi#882) chore(package): update react-test-renderer to version 16.4.0 (FaridSafi#868) chore(package): update babel-jest to version 23.0.0 (FaridSafi#869) Update and Fix Slack Example (FaridSafi#895) Remove prop removeClippedSubviews on Flatlist (FaridSafi#897) Update Chatkit readme.md Fix typos in TS Types (FaridSafi#877) Modified for flatlist (from FaridSafi#629) (FaridSafi#705) fix tabs ignore example folder Add Chatkit asset to README.md Add Chatkit banner asset chore(package): update react-test-renderer to version 16.3.2 (FaridSafi#829) Update README.md (FaridSafi#827) add image beacon to readme chore(package): update react-test-renderer to version 16.3.1 (FaridSafi#821) # Conflicts: # .eslintignore # src/MessageContainer.js
Implementation for FlatList instead of ListView component