It would be great to separate the user form the message, or at least allow to send it separately. I don't see why every message would have the user, instead of the chat itself other than within a group messages, where most cases would be just messages between 2 users in the same screen.
@tafelito I don't think it is safe to assume 1-on-1 chat is the most common use case, and even if so, why make the life of users who need group-chats that much harder?
@kfiroo I understand what you are saying, but what if you have the ability to use both options? You can either send the user to the chat or include it in the messages. So if the chat is between 2 users, there is no need to put the user in the message. Then if its a group message, you don't send the user and just use it as it is now. That way it'd add more flexibility to the chat, wouldn't it?
Thanks for your quick response
@tafelito how would you know who sent the message then? you or the other user?
regarding flexibility, i disagree, the current state provides the same functionality and and the code is the same for both cases.
@kfiroo you can always have a flag or the userId for every message. I was thinking on avoid unnecessary processing while getting the messages but I guess you are right, the cost of processing is not as much as being able to use the chat with multiple users
Anyway thanks for the clarification
@kfiroo I'm using the GiftedChat in my app where I use a Redux store. All the data in the store is normalized so I don't put the user info within the messages in the store. So to be able to retrieve the user info for every message, I have a selector where I map every message with the user. The problem I see with this, and that's why I ask you about this issue, is that the performance is actually not that good. It takes a while to load all the messages. And I'm testing with a small data set.
@tafelito Good morning :)
I have the same setup and performance are very good, can you pin point what takes a long time?
The selector? the chat first render? chat subsequent renders?
@kfiroo I'm still trying to figure it out. I tried commenting the line InteractionManager.runAfterInteractions and after that, the messages are shown right away, but the transition to the screen is very sluggish. If I keep that line, then it shows a blank screen and then renders everything, including the InputToolbar. And it doesn't matter if its the first or subsequent renders, it's always the same, and that's what confuses me, because I'm using reselect, so even if the selector takes time to process the first time, the next time should be faster. I'm even printing the recomputations, and the selectors are ok, they don't reprocess.
I'll keep digging and see what can I find. If you have any idea where to look, it'd be great!
Thanks!
The purpose of using InteractionManager.runAfterInteractions is to let the transition finish before rendering anything so I would keep that.
You can try to use my fork and let me know if you still have the problem, this is the code in my production app so I know it works well, it's also a little bit behind this repos it might not work for you
https://github.com/kfiroo/react-native-gifted-chat
I would add timing measurements to try and find the exact bottle-neck, also try to see how many times render is called, etc.
Thanks @kfiroo, I'll try to add some timing measurements.
About the renders, I can see that my component renders 1 time and the GC 2, and that makes sense because of the transition check you mentioned.
does yours works the same way? I mean, do you see a white screen and then the messages, or you see the messages right away?
@tafelito Ah I see what you're talking about.
I think the current implementation is the cause.
GC's first render happens on the first scene mount, and renders a blank page.
The second render happens only after the scene transition is over and renders the chat.
If you render a Chat with messages before the transition it drops the fps and it looks bad, if you can try to fix that it could be great! :)
I wish I had time to get to all these things..
Based on the RN Roadmap, it looks like they are working on a new Navigation library and to take out the animations from the main JS thread. Hopefully that'll do the trick.
For now, I'm gonna try to speed up a little bit, if I can, the rendering
@kfiroo I was able to get almost 60 fps on android and ios without the need of using Interaction manager. So pretty much I changed the Navigation library to ExNavigation (they are releasing a new version soon, but it was worth it) and changed the property isAnimated to true both for android and ios. Using the Animated.View allows to run the transition animations outside the UI main thread, so having that, there is no reason to wait for the interaction to finish. Everything works smoother after that and you can see the messages loaded while doing the transition instead of a white screen
@tafelito Unfortunately, the navigator used by the users are out of our control.
The Chat could be the only component in the app, rendered in the main index.js or it might be in a route somewhere inside the app.
@kfiroo yes you are right, I just wanted to leave it for other people to know if they run with the same issue. I still don't know exactly the reason why Animated is false by default in GC for Android.
@tafelito Could be leftovers from when it wasn't stable.
If the Animated api is stable in later versions of RN we should set it to true by default
@kfiroo yes I agree. I'd update to the latest RN when possible. And we can do what we said in the other thread, to keep different versions of the GC based on the RN version
Most helpful comment
@tafelito how would you know who sent the message then? you or the other user?
regarding flexibility, i disagree, the current state provides the same functionality and and the code is the same for both cases.