Skip to content
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

Update ChatMessage component to use new components and styles #325

Open
h1divp opened this issue Feb 10, 2025 · 3 comments
Open

Update ChatMessage component to use new components and styles #325

h1divp opened this issue Feb 10, 2025 · 3 comments
Labels
Frontend 🖥 Issues corresponding to the frontend/client. Good first issue Good for newcomers Improvement Important changes made that are not described by an optimization or refactor

Comments

@h1divp
Copy link
Collaborator

h1divp commented Feb 10, 2025

In order to implement sent-message and message-grouping logic for our UI we will first need to make a couple of small graphical changes. Here is our current design:

(current)
Image

Planned design:
Image

I forgot to change the profile picture of the second user here, but you get this idea.

In order to complete this, there are a few objects/styles I think we should refactor to:

  • a general msg object:
    • literally just is an object representing one piece of received or sent message text. Can show line breaks.
    • Holds all extra data currently defined by the Message type.
      • One small update will be needed for this type: author should be changed from a string to a User type in order to neatly include displayName and profilePicture data. Further, the User type should include a userId string. That way both profile pictures and display names will be able to be updated after a message is sent or received.
  • a msg-header object:
    • In a sequence of messages by a user, the first message will have a message header prepended in the chat FlatList. This header will take the displayName and profilePicture data from the first message in this sequence.
  • a msg-sent style:
    • After a user sends a message, and before it has been acknowledged by the server (through the client receiving an ack status) all self-created msg objects should also have this style applied.
    • It can simply just be an opacity: 50% to show that the message hasn't been received by the server yet.

As this will make messages more modular, further changes to profile data, the addition of reactions, etc will become much easier.

Make sure to reference this issue in your PR in order for this to be marked done.

@h1divp h1divp added Frontend 🖥 Issues corresponding to the frontend/client. Good first issue Good for newcomers Improvement Important changes made that are not described by an optimization or refactor labels Feb 10, 2025
@h1divp h1divp moved this to Unassigned in Echologator Project Board Feb 10, 2025
@h1divp
Copy link
Collaborator Author

h1divp commented Feb 10, 2025

Also, the font for the display name is called Quicksand and I'm pretty sure its already part of the project if it needs to be included
https://fonts.google.com/specimen/Quicksand

The font used for the other text is called Inter

@h1divp
Copy link
Collaborator Author

h1divp commented Feb 17, 2025

Note: we will be performing an update to switch to a ui library for more cohesive styling. The breakdown of components will likely stay the same, but the actual design will be different

Please wait for an updated figma mock design before asking to be assigned to this issue

@AlexanderWangY
Copy link
Collaborator

AlexanderWangY commented Feb 18, 2025

Why don't you store a enum MessageStatus for the different states?

In fact you might format it

enum MessageStatus { SENT, ACKED, ERROR, }

and for the connected/header messages + replies (possibly later)

enum MessageType { PARENT/NORMAL, CHILD, REPLY, }

So your final message may be

interface Message { ...Message fields, MessageStatus, MessageType }

And then to render it based on what each kind is you just use ternaries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Frontend 🖥 Issues corresponding to the frontend/client. Good first issue Good for newcomers Improvement Important changes made that are not described by an optimization or refactor
Projects
Status: Unassigned
Development

No branches or pull requests

2 participants