flutter_chat_ui icon indicating copy to clipboard operation
flutter_chat_ui copied to clipboard

Reply message display

Open moses-sichone opened this issue 2 years ago • 21 comments

How would I add a section just above the input container to display a message that is being replied to? Or is that feature already implemented?

moses-sichone avatar Jun 26 '23 06:06 moses-sichone

i also have this question ?? and also reaction buttons too, this is so far the best chat ui so far

zamirszn avatar Jun 27 '23 06:06 zamirszn

How would I add a section just above the input container to display a message that is being replied to? Or is that feature already implementedScreenshot_20230627-073355.png

you can customize the textfield then wrap it in a column with the section you want to add at the top and the textfield at the bottom

zamirszn avatar Jun 27 '23 06:06 zamirszn

How would I add a section just above the input container to display a message that is being replied to? Or is that feature already implementedScreenshot_20230627-073355.png

you can customize the textfield then wrap it in a column with the section you want to add at the top and the textfield at the bottom

Well I actually wanted to use the default textfield and not have to implement my own.

moses-sichone avatar Jun 27 '23 07:06 moses-sichone

There is no easy way of adding this and it will look broken in any case I think. This should be defined inside of the message itself, something I am trying to do in v2

demchenkoalex avatar Jun 29 '23 08:06 demchenkoalex

Alright. But if i used the customBottomWidget to implement this like @zamirszn suggested and i pass the message im replying to in repliedMessage field of the TextMessage, will the chat preview the message with the reply?

moses-sichone avatar Jun 29 '23 10:06 moses-sichone

no, it won't - it wasn't included in v1.. you will need to also build a custom TextMessage and every other message type

demchenkoalex avatar Jun 29 '23 10:06 demchenkoalex

I see, alright thanks.

moses-sichone avatar Jun 29 '23 11:06 moses-sichone

We just did a PoC with flutter_chat_ui and noticed that repliedMessage is there, but not implemented. After going over the https://github.com/flyerhq/flutter_chat_ui/issues/356 I can see it is not yet implemented. Is there any work started on this one? If it is not in near time we would love to contribute the implementation of repliedMessage. /cc @demchenkoalex

As I see the implementation, it would be to require to implement a default renderer for each message types as it is not as easy to show the replied to message. And of course implement possibility to have a specific builder for the specific message type.

peterlauri avatar Jan 20 '24 13:01 peterlauri

Hey @peterlauri the api will be completely different, if you will check the v2 branch - I will have a monorepo with a whole new implementation, more performant, extendable and customisable. I am working right now to finalise basic structure and then I plan to include replies there as well (not sure about the api yet). Current code is a bit spaghetti and I actually kinda abandoned v1 development after I started doing swipe to reply, it was just hard to evolve the package - so I started v2 from scratch with everything in mind.

demchenkoalex avatar Jan 21 '24 15:01 demchenkoalex

Hey @peterlauri the api will be completely different, if you will check the v2 branch - I will have a monorepo with a whole new implementation, more performant, extendable and customisable. I am working right now to finalise basic structure and then I plan to include replies there as well (not sure about the api yet). Current code is a bit spaghetti and I actually kinda abandoned v1 development after I started doing swipe to reply, it was just hard to evolve the package - so I started v2 from scratch with everything in mind.

Thanks for your comment. We will probably do out initial implementation based on v1. Do you plan do to most work yourself? What is your guesstimate on when you would have v2 ready? Do you need help after your basic structure is in place? Depending on what help you would look for me and my team might be able to contribute on best effort level.

peterlauri avatar Jan 28 '24 17:01 peterlauri

Hey, thanks a lot for considering jumping in with support! I do all the work myself (having quite big full time job as well) - hence everything is taking so long. Can we do it this way maybe - I will finish the new foundation layer, hopefully 2-3 weeks and then we can discuss any features you guys can contribute to (cause there will be plenty), and we can prioritise whatever you need for your product as well. Again, really appreciate your willingness to help!

demchenkoalex avatar Jan 28 '24 21:01 demchenkoalex

Hey, thanks a lot for considering jumping in with support! I do all the work myself (having quite big full time job as well) - hence everything is taking so long. Can we do it this way maybe - I will finish the new foundation layer, hopefully 2-3 weeks and then we can discuss any features you guys can contribute to (cause there will be plenty), and we can prioritise whatever you need for your product as well. Again, really appreciate your willingness to help!

Great to hear. Have been on vacation, and back to work tomorrow. Your proposal sounds great.

Question about v2: Do you expect changes to be radical from interface perspective? I'm mostly referring to the "Chat have a list of messages" concept in V1, can I assume that it will stay the same? And only minor mechanical work would be required when migrating from v1 to v2?

peterlauri avatar Feb 05 '24 12:02 peterlauri

Should be able to feed it an array still (like from firebase realtime db), however I will also have some kind of controller for insert/update/remove I think. And all other apis will be brand new. I don't think I will have any migration guide, since it will be practically impossible to cover everything. Maybe just a general guidance.

demchenkoalex avatar Feb 05 '24 21:02 demchenkoalex

Should be able to feed it an array still (like from firebase realtime db), however I will also have some kind of controller for insert/update/remove I think. And all other apis will be brand new. I don't think I will have any migration guide, since it will be practically impossible to cover everything. Maybe just a general guidance.

In our own legacy Chat API we have very similar behavior that Firebase Firestore have, that we store the messages locally, and then they get persisted. So one thought if you build the Messages model, would be to be able to mark a message as local or persisted. Similar like WhatsApp does it, "sent -> delivered"... In our case it is not really delivered, but it is persisted, that we considered to be delivered.

peterlauri avatar Feb 13 '24 20:02 peterlauri

And related to "reply to" functionality. In the V1 the API was referencing the replied to message with the message id. I don't think that will work, as that would break possibility for pagination for example, as to only with the reference of the ID, one cannot be guaranteed to have the message in memory, but might need to fetch plenty of pages (or one specific message) just for the "replied" message. In my planned API structure for replied to messages, we will have a copy of the replied to message in the message, so we can guarantee that it would be available at rendertime.

peterlauri avatar Feb 13 '24 20:02 peterlauri

hmm I don't think I will be adding the full message. Problem with this approach is if the message you reply to is updated it will not be reflected in the reply and users might be confused. I understand that to make this work you will need to update all instances of this message where it is replied to, which might be harder than fetching it separately. What are your thoughts about this?

demchenkoalex avatar Feb 14 '24 19:02 demchenkoalex

In our own legacy Chat API we have very similar behavior that Firebase Firestore have, that we store the messages locally, and then they get persisted. So one thought if you build the Messages model, would be to be able to mark a message as local or persisted. Similar like WhatsApp does it, "sent -> delivered"... In our case it is not really delivered, but it is persisted, that we considered to be delivered.

I think I had plenty of statuses - delivered, error, seen, sending, sent. My thoughts here were: sending - local message that is added to the list, but not yet uploaded anywhere, might become error sent - message sent to the backend, but no notification was triggered to notify other person delivered - message sent to the backend and other person is notified seen and error are self explanatory.

Happy to adjusts these, since they might be confusing.

I am almost done with the "architecture" so I will describe it somewhere as soon as it is ready and will make sure to tag you. Hopefully it will suit you as well (I plan to make examples for rest api/websockets/firebase maybe something else) - it should be adjustable.

demchenkoalex avatar Feb 14 '24 19:02 demchenkoalex

hey @peterlauri I think I have something feasible finally - is it possible to talk it over with you guys, hear your thoughts and maybe you will have some suggestions before I finalise it?

demchenkoalex avatar Mar 03 '24 15:03 demchenkoalex

hey @peterlauri I think I have something feasible finally - is it possible to talk it over with you guys, hear your thoughts and maybe you will have some suggestions before I finalise it?

Hi. I'll drop you an email and we can try to schedule it.

peterlauri avatar Mar 05 '24 04:03 peterlauri

Hello, how is this implementation?

I also need this feature

Luciano-Magnus avatar Apr 18 '24 22:04 Luciano-Magnus

I am so implemented, you can look at my open source project code, do not know if you want?

https://github.com/imboy-pub/imboy-flutter/blob/main/lib/component/message/message_quote_builder.dart

UI effect is a little ugly, if you have achieved a better looking UI effect, look forward to your share.

image

leeyisoft avatar Apr 19 '24 02:04 leeyisoft