-
Notifications
You must be signed in to change notification settings - Fork 99
Allow customisation of message previews in lists #839
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
3432039
to
5b21d5f
Compare
SDK Size
|
/// Provides message preview representation for lists. | ||
public protocol MessagePreviewFormatting { | ||
/// Formats the message including the author's name. | ||
func format(_ previewMessage: ChatMessage, in channel: ChatChannel) -> String | ||
/// Formats only the content of the message without the author's name. | ||
func formatContent(for previewMessage: ChatMessage, in channel: ChatChannel) -> String | ||
/// Formats only the attachment content of the message in case it contains attachments. | ||
func formatAttachmentContent(for previewMessage: ChatMessage, in channel: ChatChannel) -> String? | ||
} |
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 it is probably better to just use the MessagePreviewFormatter
function directly here 🤔 There is a chance we add new function here, for example, for Draft Message etc... and if we introduce a new function, it will be a breaking change.
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.
The other formatters, we use a protocol, but usually it is just one function, and for one use case. This one is a bit different, since we use it in multiple places, and there is a chance to extend it further
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's also fine like this, you can add a protocol extension with a default implementation to avoid breaking changes.
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 did consider skipping the protocol part completely, but then only added it because many existing types in Utils had it. I guess it makes sense to skip it here.
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.
OK, let's go for no protocol here
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.
Yeah the default extension is a good point, forgot about it. In that case I'm fine with both approaches 👍
|
🔗 Issue Links
Resolves: IOS-895
🎯 Goal
📝 Summary
MessagePreviewFormatter
🛠 Implementation
MessagePreviewFormatter
🎨 Showcase
🧪 Manual Testing Notes
☑️ Contributor Checklist
docs-content
repo