search

flyerhq / flutter_chat_ui

Actively maintained, community-driven chat UI implementation with an optional Firebase BaaS.
https://flyer.chat
Apache License 2.0
1.54k stars 671 forks source link

Reply message display #466

Open moses-sichone opened 1 year ago

moses-sichone commented 1 year ago

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?

zamirszn commented 1 year ago

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

zamirszn commented 1 year ago

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

moses-sichone commented 1 year ago

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.

demchenkoalex commented 1 year ago

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

moses-sichone commented 1 year ago

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?

demchenkoalex commented 1 year ago

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

moses-sichone commented 1 year ago

I see, alright thanks.

peterlauri commented 6 months ago

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.

demchenkoalex commented 6 months ago

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.

peterlauri commented 6 months ago

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.

demchenkoalex commented 6 months ago

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!

peterlauri commented 5 months ago

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?

demchenkoalex commented 5 months ago

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.

peterlauri commented 5 months ago

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 commented 5 months ago

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.

demchenkoalex commented 5 months ago

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 commented 5 months ago

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 commented 4 months ago

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?

peterlauri commented 4 months ago

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.

Luciano-Magnus commented 3 months ago

Hello, how is this implementation?

I also need this feature

leeyisoft commented 3 months ago

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