Rich Text Editor events #80
Conversation
- Add `isRichTextEditor` to existing and new composer events(Composer + SlashCommand). - Add Mention and FormattedMessage events.
- Fix typos and formatting - Add `isMarkdownEnabled` and `isPlainTextMode`
schemas/SlashCommand.json
Outdated
| "Spoiler", | ||
| "Shrug", | ||
| "TableFlip", | ||
| "Unflip", | ||
| "Lenny", | ||
| "Plain", | ||
| "Html", | ||
| "UpgradeRoom", | ||
| "JumpToDate", | ||
| "Nick", | ||
| "MyRoomNick", | ||
| "RoomAvatar", | ||
| "MyRoomAvatar", | ||
| "MyAvatar", | ||
| "Topic", | ||
| "RoomName", | ||
| "Invite", | ||
| "Join", | ||
| "Part", | ||
| "Invite" | ||
| "Remove", | ||
| "Ban", | ||
| "Unban", | ||
| "Ignore", | ||
| "Unignore", | ||
| "Op", | ||
| "Deop", | ||
| "DevTools", | ||
| "AddWidget", | ||
| "Verify", | ||
| "DiscardSession", | ||
| "RemakeOlm", | ||
| "Rainbow", | ||
| "RainbowMe", | ||
| "Help", | ||
| "Whois", | ||
| "Rageshake", | ||
| "ToVirtual", | ||
| "Query", | ||
| "Msg", | ||
| "HoldCall", | ||
| "UnholdCall", | ||
| "ConvertToDM", | ||
| "ConvertToRoom", | ||
| "Me", | ||
| "Confetti", | ||
| "Fireworks", | ||
| "Hearts", | ||
| "Rainfall", | ||
| "Snowfall", | ||
| "SpaceInvaders" |
There was a problem hiding this comment.
We should only be tracking things to answer specific product questions, what question do these answer? Also this list is unmaintainable given its infeasible to ask contributors adding commands to also need to add them in a separate repo. The existing enum entries here were to track room leave & room invite flows respectively.
There was a problem hiding this comment.
I thought it would be good from a product perspective to know which commands were actually getting used and then we could refine the commands to just those. But I will defer to product on that. @jakewb-b What do you think is useful to track?
There was a problem hiding this comment.
Also it seems sensible to me that if we are adding commands that we would track it to understand it's validity and avoid having extraneous product surface/ UX complexity.
There was a problem hiding this comment.
It would be useful to have this info, for the reasons David's given, although not essential. In practice I don't know how likely we are to come back and remove slash commands that see little usage, and if we do want to make that effort there are probably other qualitative ways we can make the decision.
So, I guess it depends on how difficult it is to maintain this vs the value it offers. My take is that I'd quite like it, but I'm not going to insist on it if it creates more problems.
There was a problem hiding this comment.
We could always add it for period of time to gather the data of how broadly/commonly slash commands as a feature is used and which commands users find most useful. Once we have answered those questions we could remove the tracking of the full set so it is more maintainable. WDYT @t3chguy ?
There was a problem hiding this comment.
Even if we don't remove old ones on Web it could inform what is valuable to add to mobile and EX.
There was a problem hiding this comment.
I appreciate the question btw, I should have been more explicit. I have added a section to the description. Maybe we should add that question to a pull request template?
There was a problem hiding this comment.
I think an enum here is infeasible, there's so many apps to keep in sync. A string is more appropriate.
There was a problem hiding this comment.
Yea that crossed my mind and I was unsure. I thought an enum might make it more obvious what differences there was across platforms and with an enum a dev could be informed at compile time what they were explicitly ignoring. But happy to go with a string.
There was a problem hiding this comment.
with an enum a dev could be informed at compile time what they were explicitly ignoring. But happy to go with a string.
For TS at least unless all the strings matched exactly (fully lowercase) the type would have to be entirely ignored
| "Snowfall", | ||
| "SpaceInvaders" | ||
| ] | ||
| "description": "The the slash command text. e.g. /me ", |
There was a problem hiding this comment.
Does this make sense @t3chguy ?
So you might nee update any reports you have that use the old format(Part/Invite)?
There was a problem hiding this comment.
Hm good point, losing historical data would not be good. Not sure what the best solution is here then.
|
Any update on this PR @langleyd ? Just asking since I am seeing it, there is no rush. |
editorenum (Legacy,RteFormatting,RtePlain) to existing and new composer events(Composer+SlashCommand).MentionandFormattedMessageevents.isMarkdownEnabledQuestions we are trying to answer with these events