Markdown formatting toolbar for rich text fields.

Review Request #11004 — Created May 15, 2020 and updated

hxqlin
Review Board
master
0cf11a5...
reviewboard

This patch adds a markdown formatting toolbar for rich text editors.
The formatting-related buttons add the corresponding syntax to the
selection if one exists, or just inserts the syntax and positions
the cursor. This applies to the bold, italic, strikethrough, ordered
and unordered list, and code buttons. If the selection begins and ends
with the same syntax as the button being pressed, the syntax is removed.
For example, if the bold button is pressed and the selection is already
bolded, the bold syntax is removed.

For the insert link button, if there is a selection, the selection
becomes the text to display for the url. Otherwise, it inserts syntax
for a link with a text to display placeholder. For the upload image
button, it opens a dialog to upload an image. A reference to the image
is added to the editor.

Manual testing only so far.

Loading file attachments...

Description From Last Updated

I think it'd look nice to have this show up within the editor. Kind of like in Asana. By having ...

chipx86chipx86

Col: 36 Functions declared within loops referencing an outer scoped variable may lead to confusing semantics. ($, _)

reviewbotreviewbot

This bit looks a bit weird; it's for the upload image button, which is different from the other buttons because ...

hxqlinhxqlin

The button that toggles the rich text attribute is a bit tangled up in inlineEditorView so I wasn't sure how ...

hxqlinhxqlin

Col: 36 Functions declared within loops referencing an outer scoped variable may lead to confusing semantics. ($, _)

reviewbotreviewbot

Col: 36 Functions declared within loops referencing an outer scoped variable may lead to confusing semantics. ($, _)

reviewbotreviewbot

Since we're in the final stages of this, it'd be nice to move this into rb/css/ui/formatting-toolbar.less and to use our ...

chipx86chipx86

It's best not to override the function. Instead, let's bind it when we pass it to the constructor below.

chipx86chipx86

To stay consistent, the pattern we normally use is: this._$toolbar.$el.appendTo(this.$el);

chipx86chipx86

Two blank lines between top-level classes or functions.

chipx86chipx86

Option arguments should be documented in an Option Args section, following Args. These work just like other arguments, listing names, ...

chipx86chipx86

Can you have this wrap? You can separate it into a chain of jQuery statements.

chipx86chipx86

Element building should happen in render().

chipx86chipx86

This can be one line, since we're not chaining.

chipx86chipx86

We currently avoid for .. in, due to Babel's expensive, verbose transpilation. Can you convert this to a standard for ...

chipx86chipx86

Missing quotes around ${id}, to make the tag valid.

chipx86chipx86

The .addClass should be indented 4 spaces.

chipx86chipx86

I think this can be consolidated a bit, and updated to be more explicit at the same time. How about: ...

chipx86chipx86

Let's name buttonInfo options instead, and add an Option Args section so it's clear what's allowed by the caller. Also ...

chipx86chipx86

We're largely moving to .on() instead of shortcuts like .click() for clarity (and to avoid some issues with edge cases ...

chipx86chipx86

For a setter, "Set the position of the cursor" would be more correct. This also isn't specific to emphasis.

chipx86chipx86

We fetch this._codeMirror multiple times. Let's pull it out into a variable to reduce lookups.

chipx86chipx86

"Toggle"

chipx86chipx86

A few notes: You'll need to escape these. You should use double backticks around these, instead of quotes. The backtick ...

chipx86chipx86

I don't think the term "emphasis" is quite right. In Markdown, it can refer to bold/italic, but not strikethrough or ...

chipx86chipx86

Let's pull this._codeMirror out into a local variable here as well. We access it a lot.

chipx86chipx86

The * should all align.

chipx86chipx86

We don't use [..., ...] = ... syntax in our codebase, because Babel transforms that into some lengthy code. Let's ...

chipx86chipx86

I want to dive into this regex with you, because I'm not confident it'll do what you want. Let's take ...

chipx86chipx86

The asterisks should align.

chipx86chipx86

Formatting isn't quite right here. This should look like: const newSelection = selection.replace( new RegExp(...), '');

chipx86chipx86

More cases of this regex. I count 3. Once we figure out what it should be, we should have a ...

chipx86chipx86

Asterisks should align.

chipx86chipx86

Seeing inconsistency on indentation. Can you make sure this is correct all throughout?

chipx86chipx86

Same note as above with the [..., ...] = ... syntax.

chipx86chipx86

THis can be a single-line comment.

chipx86chipx86

This can be a singline line comment.

chipx86chipx86

This can be a single line comment.

chipx86chipx86

This line is too long. Can you wrap the second parameter to the next line>?

chipx86chipx86

No blank line here.

chipx86chipx86

This needs a "Returns" section.

chipx86chipx86

"Find"

chipx86chipx86

We access this._codeMirror many times. Let's pull it out into a variable.

chipx86chipx86

Let's make this: for (let curToken = codeMirror.getTokenAt(cursorStart, true); curToken.string !== ' ' && groupStart.ch !== 0; curToken = codeMirror.getTokenAt(groupStart, ...

chipx86chipx86

You can use -= here.

chipx86chipx86

You can use -=.

chipx86chipx86

We can pull this._codeMirror out into a local variable.

chipx86chipx86

"Insert"

chipx86chipx86

"Markdown"

chipx86chipx86

Let's pull this._codeMirror out into a local variable.

chipx86chipx86

All arguments to a function should align.

chipx86chipx86

This line is too long. Also, we prefer to keep logic out of the ${...} references in format strings. Let's ...

chipx86chipx86

These lines are too long. Let's wrap: const precedingText = codeMirror.getLineTokens(...) .filter(...) ...

chipx86chipx86

This line is too long. Let's do: codeMirror.setSelection({ ch: ..., line: ..., }); And use alphabetical order on the keys.

chipx86chipx86

Same notes as above with the expression and line lengths.

chipx86chipx86

We avoid for ... of syntax due to Babel transpiling this into an expensive block of code. Let's just use ...

chipx86chipx86
Checks run (1 failed, 1 succeeded)
flake8 passed.
JSHint failed.

JSHint

hxqlin
  1. This doesn't quite have everything from the project description just yet. I'm not sure if the current implementation is easily open to modification by extensions though so I thought I'd just put up an initial review request to see if there's something big.

  2. This bit looks a bit weird; it's for the upload image button, which is different from the other buttons because it's an input hidden in a label. It needs the _uploadImage function from RB.TextEditorView but also needs access to the input element to get the file. There must be a nicer way to do it but I'm not sure how.

    1. How about registering .rb-c-formatting-toolbar__image-btn change in events: {...} to _onFileUploadChanged, and having the event handler logic there? That'd keep this code generic.

  3. 
      
hxqlin
Review request changed

Change Summary:

Change the markdown checkbox to a button that toggles markdown in the field when clicked.

Commit:

-8d2d3792ceaaaae09015e69fd4101ae426c8ad84
+057181aa978c1126ce8f7a75a71f0997ce0825b5

Diff:

Revision 2 (+462 -8)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 passed.
JSHint failed.

JSHint

hxqlin
  1. 
      
  2. The button that toggles the rich text attribute is a bit tangled up in inlineEditorView so I wasn't sure how to pull it out to display on the right hand side of the text field where I think it'd also look better in line with the rest of the buttons in the toolbar.

    1. Sorry I haven't gotten back to you. There are ways we can lay this out to address this. Feel free to ping me on Slack and we'll talk about it! :)

  3. 
      
hxqlin
hxqlin
Review request changed

Change Summary:

Revert attempts to change the Enable Markdown checkbox to a button and add a more robust implementation for toggling list syntax.

Commit:

-057181aa978c1126ce8f7a75a71f0997ce0825b5
+4f57506f709277300f195691732553dea3d26cd0

Diff:

Revision 3 (+510 -2)

Show changes

Checks run (1 failed, 1 succeeded)

flake8 passed.
JSHint failed.

JSHint

hxqlin
chipx86
  1. I'm excited to see this come together! Thanks for sticking with it :)

    This review looks large. Most of it are small tasks about complying with doc/syntax standards.

    There's a few bigger-ticket items:

    1. Updating the CSS to adhere to our CSS Component styles (I go into this and provide links below).
    2. Re-evaluating some regexes (we can talk about this in Slack if it helps).
    3. Placement of the toolbar.

    I'd knock out the easy things, update the change, and then we can talk about the bigger items.

  2. I think it'd look nice to have this show up within the editor. Kind of like in Asana. By having it within the confines of the text area, it more directly connects it to the content.

    I don't know how hard this is. It'll have to happen before we release Review Board 5 for sure, but I know you have a full-time job these days. If this ends up being a lot to figure out, I'm okay committing without this, and moving this work to our plate.

  3. reviewboard/static/rb/css/common.less (Diff revision 4)
     
     
     
     
     
     
     
     
     
     
     
     
     
     

    Since we're in the final stages of this, it'd be nice to move this into rb/css/ui/formatting-toolbar.less and to use our CSS component style and documentation conventions. You can see a good example of this in page-sidebar.less, and see docs here:

    1. Would the buttons then be .rb-o-bold-button, .rb-o-italic-button, etc. ? And is rb-c-formatting-toolbar__btn-group okay as is?

  4. It's best not to override the function. Instead, let's bind it when we pass it to the constructor below.

  5. To stay consistent, the pattern we normally use is:

    this._$toolbar.$el.appendTo(this.$el);
    
  6. Two blank lines between top-level classes or functions.

  7. Option arguments should be documented in an Option Args section, following Args. These work just like other arguments, listing names, types, and descriptions.

  8. Can you have this wrap? You can separate it into a chain of jQuery statements.

  9. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     
     
     
     

    Element building should happen in render().

  10. This can be one line, since we're not chaining.

  11. We currently avoid for .. in, due to Babel's expensive, verbose transpilation. Can you convert this to a standard for loop?

  12. Missing quotes around ${id}, to make the tag valid.

  13. The .addClass should be indented 4 spaces.

  14. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     
     
     

    I think this can be consolidated a bit, and updated to be more explicit at the same time. How about:

    const $buttons = this.btnGroups[id].map(
        buttonInfo => this._makeButton(buttonInfo));
    
    this.$btnGroups.push($(`<div id="${id}"/>`)
        .addClass(...)
        .append($buttons));
    
  15. Let's name buttonInfo options instead, and add an Option Args section so it's clear what's allowed by the caller.

    Also needs a Returns.

  16. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     

    We're largely moving to .on() instead of shortcuts like .click() for clarity (and to avoid some issues with edge cases that we've encountered in the past).

    This can also be combined as:

    $button.on('click', (_.isFunction(options.onClick)
                         ? options.onClick
                         : this[options.onClick].bind(this)));
    
  17. For a setter, "Set the position of the cursor" would be more correct.

    This also isn't specific to emphasis.

  18. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     
     

    We fetch this._codeMirror multiple times. Let's pull it out into a variable to reduce lookups.

  19. A few notes:

    1. You'll need to escape these. You should use double backticks around these, instead of quotes. The backtick one is tricky. Just say "or a backtick for code."

    2. You mention * for italics, but the handler for the italic button uses _. We should say that in the docs here.

    3. Much of the content in this is probably most suitable for the main doc description.

  20. I don't think the term "emphasis" is quite right. In Markdown, it can refer to bold/italic, but not strikethrough or code. How about toggleInlineTextFormat?

  21. Let's pull this._codeMirror out into a local variable here as well. We access it a lot.

  22. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     

    The * should all align.

  23. We don't use [..., ...] = ... syntax in our codebase, because Babel transforms that into some lengthy code. Let's instead pull this out as an array and then pull out the values from that.

  24. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     

    I want to dive into this regex with you, because I'm not confident it'll do what you want.

    Let's take a look at an example, using symbol='**' (as mentioned in the docs).

    1. ^[**]+|[**]+$
    2. **sometext**

    * isn't going to match the character *. In fact, it's not even valid regex by itself. What you'd need is \*\*, to get the literal characters.

    Even then, [\*\*] is equivalent to [\*], since [] is used to specify a set of possible matches for a single character. The generated regexes for bold are therefore the exact same as those for italic.

    What's the main purpose of this particular regex? To match tbe beginning or end of a line?

    If so, I'm not sure the | is going to work correctly here in all regex implementations without a containing parens (and I'm not sure the ^ or $ are guaranteed to work as part of that).

    This might be worth going into one-on-one on Slack.

  25. The asterisks should align.

  26. Formatting isn't quite right here. This should look like:

    const newSelection = selection.replace(
        new RegExp(...),
        '');
    
  27. More cases of this regex. I count 3. Once we figure out what it should be, we should have a utility function that generates it, so that we don't have to repeat it.

  28. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     

    Asterisks should align.

  29. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     
     
     
     
     
     
     
     

    Seeing inconsistency on indentation. Can you make sure this is correct all throughout?

  30. Same note as above with the [..., ...] = ... syntax.

  31. THis can be a single-line comment.

  32. This can be a singline line comment.

  33. This can be a single line comment.

  34. This line is too long. Can you wrap the second parameter to the next line>?

  35. No blank line here.

  36. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     
     
     
     

    This needs a "Returns" section.

  37. We access this._codeMirror many times. Let's pull it out into a variable.

  38. reviewboard/static/rb/js/ui/views/textEditorView.es6.js (Diff revision 4)
     
     
     
     
     
     
     
     

    Let's make this:

    for (let curToken = codeMirror.getTokenAt(cursorStart, true);
         curToken.string !== ' ' && groupStart.ch !== 0;
         curToken = codeMirror.getTokenAt(groupStart, true)) {
      groupStart.ch -= 1;
    }
    

    And same below.

    This better defines the scope and purpose of curToken and keeps the logic together as a single block of code with a clear intention.

  39. You can use -= here.

  40. We can pull this._codeMirror out into a local variable.

  41. Let's pull this._codeMirror out into a local variable.

  42. All arguments to a function should align.

  43. This line is too long.

    Also, we prefer to keep logic out of the ${...} references in format strings. Let's calculate a value separately and then include it.

  44. These lines are too long. Let's wrap:

    const precedingText =
        codeMirror.getLineTokens(...)
        .filter(...)
        ...
    
  45. This line is too long. Let's do:

    codeMirror.setSelection({
        ch: ...,
        line: ...,
    });
    

    And use alphabetical order on the keys.

  46. Same notes as above with the expression and line lengths.

  47. We avoid for ... of syntax due to Babel transpiling this into an expensive block of code. Let's just use a standard for loop.

  48. 
      
hxqlin
Review request changed

Change Summary:

Fix most docs/syntax issues and reposition toolbar inside the editor

Commit:

-ae6587d8374e533dcec10b01bb02f3c078aff5c0
+0cf11a5b41cce55c55ccb541f91e156d7060b643

Diff:

Revision 5 (+643 -2)

Show changes

Added Files:

Checks run (2 succeeded)

flake8 passed.
JSHint passed.
Loading...