Skip to content
This repository has been archived by the owner on Sep 27, 2024. It is now read-only.

Amend mention message html output #716

Merged
merged 12 commits into from
Jun 13, 2023

Conversation

artcodespace
Copy link
Contributor

@artcodespace artcodespace commented Jun 12, 2023

This PR makes it so that when you translate a mention to "message format" html then the following rules are applied:
- if it's an at-room mention, only output the raw text @room
- if it's a room or user mention, output the mention as <a href="...">display_text</a>

It also does a little bit of TS work so that we can use the lib function in TS code and makes a couple of tweaks to the example app for testing.

@codecov-commenter
Copy link

codecov-commenter commented Jun 12, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: +1.69 🎉

Comparison is base (b431568) 88.38% compared to head (0fab533) 90.07%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #716      +/-   ##
============================================
+ Coverage     88.38%   90.07%   +1.69%     
============================================
  Files           146       81      -65     
  Lines         17003    14261    -2742     
  Branches        789        0     -789     
============================================
- Hits          15028    12846    -2182     
+ Misses         1785     1415     -370     
+ Partials        190        0     -190     
Flag Coverage Δ
uitests ?
uitests-android ?
uitests-ios ?
unittests 90.07% <100.00%> (+1.98%) ⬆️
unittests-android ?
unittests-ios ?
unittests-rust 90.07% <100.00%> (+0.05%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
crates/wysiwyg/src/composer_model/mentions.rs 98.52% <100.00%> (+0.09%) ⬆️
crates/wysiwyg/src/dom/nodes/mention_node.rs 100.00% <100.00%> (+2.79%) ⬆️

... and 66 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@artcodespace artcodespace marked this pull request as ready for review June 12, 2023 15:21
@artcodespace artcodespace requested a review from a team June 12, 2023 15:21
Copy link
Contributor

@aringenbach aringenbach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great

Copy link
Contributor

@jonnyandrew jonnyandrew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

// use the display text or the presence of a `data-mention-type => at-room` attribute to decide the mention type
let new_node = if text == "@room".into()
|| attributes.iter().any(|(k, v)| {
k == &S::from("data-mention-type") && v == &S::from("at-room")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's an @room mention if and only if there is an occurrence of @room in the text making this condition redundant

Copy link
Contributor Author

@artcodespace artcodespace Jun 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great - I wanted to think that was the case but wasn't sure. Updated in e8bd655

@@ -77,7 +77,16 @@ where
let (start, end) = self.safe_selection();
let range = self.state.dom.find_range(start, end);

let new_node = DomNode::new_mention(url, text, attributes);
// use the display text or the presence of a `data-mention-type => at-room` attribute to decide the mention type
let new_node = if text == "@room".into()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually this logic could be shared with the HTML parsing logic (#695 / #692). So we could add a note here to remind us to update when it's ready.

|| attributes.iter().any(|(k, v)| {
k == &S::from("data-mention-type") && v == &S::from("at-room")
}) {
DomNode::new_at_room_mention(attributes)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this function is able to create an @room mention, we might want to reconsider the API, and either:

Alternatively, we could add a new function so that we have:

  • do_insert_mention(text, url) // with mandatory args
  • do_insert_at_room_mention()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd be tempted to go a different way and have this function call DomNode::new_mention with url, display_text, attributes as we currently have and then have MentionNode::new create either a room, user, or at-room mention as appropriate.

What do you think to that solution?

If you're happy with me adding a note as the work may be further informed by the WIP mentions utils work (which is what I'm picking up next), I'll do that and address in that subsequent PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have this function call DomNode::new_mention with url, display_text, attributes as we currently have and then have MentionNode::new create either a room, user, or at-room mention as appropriate.

Yeah that makes sense. I still think the API could be more self explanatory in terms of URL being optional, and some documentation of that behaviour if we do keep a single function for both. But happy for that to be addressed in a later PR

attributes.push(("href".into(), "#".into())); // designates a placeholder link in html
attributes.push(("contenteditable".into(), "false".into()));

self.fmt_tag_open(tag, formatter, &Some(attributes));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this tag be <span> (or <mention>), rather than <a>?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the time being keeping everything as <a> - there's a separate issue for moving to a custom html tag type here to try and keep these PRs small and digestible

Comment on lines +86 to +87
} else {
DomNode::new_mention(url, text, attributes)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When trying to insert an invalid mention, should the editor still do that? I'm wondering if it could return an error result and/or fall back to DomNode::new_link().

It might not be possible to do without being able to parse mentions but could be worth adding a note

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good question, and for now I believe we don't have a way of telling if it's valid or not. Will add a note to handle that (after parsing gives us that ability).

@sonarcloud
Copy link

sonarcloud bot commented Jun 13, 2023

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@artcodespace artcodespace merged commit 6b3425e into main Jun 13, 2023
@artcodespace artcodespace deleted the alunturner/amend-mention-message-html-output branch June 13, 2023 09:37
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants