-
-
Notifications
You must be signed in to change notification settings - Fork 828
Conversation
- use <p> for unstyled blocks - fix return key bug - editor placeholder
@@ -0,0 +1,82 @@ | |||
import {Editor, ContentState, convertFromHTML, DefaultDraftBlockRenderMap, DefaultDraftInlineStyle, CompositeDecorator} from 'draft-js'; | |||
const ReactDOM = require('react-dom'); |
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.
You seem to have a mix of import styles here - unsure if we're planning on switching over, but we should probably at least be consistent within a file
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.
Not quite sure how that happened -- will fix.
Made quite a few comments: I think some things are probably just from it being WIP and the rest is just code style (javascript being terrible for this because there are so many ways of writing javascript). The two general things I would say are:
As per the chat on #vector-dev, the style you have is more modern, so rather than change it to match the rest of the codebase, we're going to start moving the codebase over, so let's keep your ES6 class components and annotations etc. But all the important stuff like how it's working is looking good, and it seems to be working nicely! Plus, having the bulk of the logic in a separate class is great. As per the chat on #vector-dev, the plan going forward is:
|
Hopefully made the code a little bit clearer.
Since it was not correctly extracting the selected part of the text string
Add basic Markdown highlighting
}; | ||
|
||
const MARKDOWN_REGEX = { | ||
LINK: /(?:\[([^\]]+)\]\(([^\)]+)\))|\<(\w+:\/\/[^\>]+)\>/g, |
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 guess we've done this to fit into the same model as richtext, but doing this manually with regexes rather than using the markd library feels like a major step back here. There must be lots of markdown syntax we don't support?
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.
So this *only *handles the preview that's rendered in the composer (which
for obvious reasons can't be a proper rendering) -- the sent message still
uses the markdown library.
On Mon, Jun 13, 2016 at 11:29 PM David Baker notifications@github.com
wrote:
In src/RichText.js
#292 (comment)
:+import * as sdk from './index';
+
+const BLOCK_RENDER_MAP = DefaultDraftBlockRenderMap.set('unstyled', {
- element: 'p' // draft uses
by default which we don't really like, so we're using
+});
+const STYLES = {
- BOLD: 'strong',
- CODE: 'code',
- ITALIC: 'em',
- STRIKETHROUGH: 's',
- UNDERLINE: 'u'
+};
+const MARKDOWN_REGEX = {
- LINK: /(?:[([^]]+)](([^)]+)))|<(\w+://[^>]+)>/g,
I guess we've done this to fit into the same model as richtext, but doing
this manually with regexes rather than using the markd library feels like a
major step back here. There must be lots of markdown syntax we don't
support?—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/matrix-org/matrix-react-sdk/pull/292/files/df69d1de44810d2c6d8a338be33b73ee8829d177#r66838004,
or mute the thread
https://github.com/notifications/unsubscribe/AAOlRL8py71C3WdN0zy-XEyk2avtK7rtks5qLZqZgaJpZM4IoK58
.
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.
Ah right, I see. Still doesn't feel great to have two different types of parsing for the markdown, but if it's not on the critical message path then probably ok.
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 know, I was complaining about it on #vector-dev too, but there's very
little that can be done here.
On Tue, Jun 14, 2016 at 12:13 AM David Baker notifications@github.com
wrote:
In src/RichText.js
#292 (comment)
:+import * as sdk from './index';
+
+const BLOCK_RENDER_MAP = DefaultDraftBlockRenderMap.set('unstyled', {
- element: 'p' // draft uses
by default which we don't really like, so we're using
+});
+const STYLES = {
- BOLD: 'strong',
- CODE: 'code',
- ITALIC: 'em',
- STRIKETHROUGH: 's',
- UNDERLINE: 'u'
+};
+const MARKDOWN_REGEX = {
- LINK: /(?:[([^]]+)](([^)]+)))|<(\w+://[^>]+)>/g,
Ah right, I see. Still doesn't feel great to have two different types of
parsing for the markdown, but if it's not on the critical message path then
probably ok.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/matrix-org/matrix-react-sdk/pull/292/files/df69d1de44810d2c6d8a338be33b73ee8829d177#r66845074,
or mute the thread
https://github.com/notifications/unsubscribe/AAOlRHcbqZZTJzWOzcFdS4A5Xabm-zmlks5qLaTZgaJpZM4IoK58
.
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.
Why can't you parse it to markdown then render that markdown as the preview?
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.
Because at the end of the day, it still needs to be Markdown: using rendered Markdown will strip formatting characters and mangle tables, code blocks, etc. such that it becomes more like a rich text editor than a markdown one.
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.
mangle tables, code blocks, etc
I don't see how you can sensibly display these things "as-you-type" Markdown. If we can't do all of markdown, we'll end up with a mix of some stuff that is easy to render as markdown and some stuff which is too difficult to render sensibly so we don't bother. I'm not sure I see the value in this.
If we do have a way of representing all of Markdown as you type which doesn't make me want to stab the input box, then surely we should be using the actual hooks given to us in the marked
library to implement custom Renderer
s for things like strong
, em
, codespan
, etc. This would make things a lot cleaner and doesn't introduce subtle formatting differences between our hand-crafted regex and the marked
parser. See https://github.com/chjj/marked/blob/88ce4df47c4d994dc1b1df1477a21fb893e11ddc/lib/marked.js#L857
() => true, // always return true => don't filter any ranges out | ||
(start, end) => { | ||
// map style names to elements | ||
let tags = block.getInlineStyleAt(start).map(style => STYLES[style]); |
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.
If block.getInlineStyleAt
returns a style that is not in STYLES
, then STYLE[style]
will be undefined which will populate tags
with undefined entries. This will lead to tags like <undefined>
on :43
. You need to sanity check more.
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.
While this shouldn't happen, since STYLES lists all the builtin styles currently supported, I agree that it'll be safer to check.
will the element desktop/web clients ever support simple stuff such as strikethrough, bold, italic, whatever or some simple markings colors etc for example to edit/redact/mark/highlight etc ones owns chats and text etc later in a point in time to make visually slightly visible modifications etc? i am a noob about the element chat clients (web/desktop). thanks. |
Opening this now for tracking fix to element-hq/element-web#572. There is still a significant amount of work left: