Rich message rendering #24
No reviewers
Labels
No labels
bug
discussion
duplicate
enhancement
help wanted
invalid
question
suggestion
tracker
ui/ux
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: cadence/Carbon#24
Loading…
Reference in a new issue
No description provided.
Delete branch "rich-messages"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I don't know tbh, someone smarter look at this.
This adds support for rendering rich messages and creates what I think is a good way to handle events. This still needs work and even if we decide not to use this someone else can probably reuse code from this
Just going through a visual analysis of your code, I'll test it and give a full review in the future.
@ -0,0 +13,4 @@
// predicates
canGroup() {
The original idea here was that we'd have a predicate for things like whether the method can be displayed as a message group, whether it should show a timestamp, or whatever other things could affect the display based on the class. I haven't actually put this method to any use yet.
@ -0,0 +50,4 @@
}
}
function simpleEvent(filter, render) {
Not sure how I feel about a function that creates classes. Can we inherit from a base class instead?
That's a lot more verbose, which I don't really like, but sure
@ -0,0 +3,4 @@
const UnknownMembership = simpleEvent((e) => e.type == "m.room.member", (e) => "unknown membership event")
function createMembershipEvent(membership, message) {
return simpleEvent((e) => e.type == "m.room.member" && e.content.membership === membership, message)
Again here. I think a better way would be to have a base class like MembershipEvent, and then for each kind of membership we subclass it and only implement the canRender method on each.
@ -0,0 +25,4 @@
}
})
//Handle our custom tag
style: can we put spaces after // ?
To consider: highlight.js is thicc. It's almost 1MiB. Not sure if bundle size is something we care about but we should probably keep this in mind...
1 MB bundle size is kind of ridiculous. We could simply not highlight code blocks, or we could maybe inline async import the module on demand when we actually need to do highlighting, so it's out of the initial bundle.
Added lazy loading for highlight.js. It's a bit hacky and uses an eval() but it gets the job done
WIP: Rich message rendering proposalto Rich message rendering