Rework review request fields.

Review Request #9144 - Created Aug. 22, 2017 and submitted

David Trowbridge
Review Board
release-3.0.x
5dc6c78...
reviewboard

This change does a fairly large cleanup to the JavaScript side of the review
request fields. The old way was pretty hard-coded into the
ReviewRequestEditorView: each of the builtin fields had an entry which defined
some metadata about it, and the editor would scan through those, and then scan
through any remaining fields and pull (more limited) metadata out of the
markup.

With the new model introduced in this change, each (editable) field has a
javascript view of its own which handles its interaction. There are base
classes for the existing types of fields, including plain text fields,
comma-separated multivalue fields, and multiline text fields. By default, each
of the field types defined in fields.py maps to one of these base classes,
which will fall back on the old behavior in order to maintain compatibility
with existing extensions that use them. If those field view types are
subclasses, they can add additional features such as autocomplete or
specialized saving mechanics. There's no longer any special casing between
"built-in" and "other" fields, aside from the fact that the built-in field
views specify useExtraData: false.

While I was in here, I cleaned up several related issues:
- Both the "close description" and "change description" fields used an element
with the ID #field_changedescription.
- We no longer hard-code #field_changedescription in the CSS.
- Some documentation updates and tweaks.

There's still a lot more cleanup that can be done, moving functionality from
the ReviewRequestEditorModel and ReviewRequestEditorView into the field
classes, but this change seemed like it was big enough already.

  • Ran unit tests.
  • Ran js-tests.
  • Manually tested all fields on the review request page, including rich text
    and CSV-type fields that linkified their values in various ways.
  • Manually tested an extension that added various field types.
  • 0
  • 0
  • 32
  • 28
  • 60
Description From Last Updated
Checks run (1 failed, 1 succeeded)
flake8 passed.
JSHint failed.

JSHint

David Trowbridge
Review request changed

Checks run (1 failed, 1 succeeded)

flake8 passed.
JSHint failed.

JSHint

Barret Rennie
Christian Hammond
  1. Looks great overall! Love where this is going.

    A lot of my comments actually have to do with the docs not being consistent with standards. I've marked those. Also have comments about testing.

  2. The unit testing could use more fleshing out. I know we have existing tests for the built-in fields, but we really should have tests for all the new registration support and the options for each field to ensure that the base foundation is working correctly. I know that's a lot more work, but it'll be worth it.

    1. I agree that we should have more tests for all that but must it block this change? This is pretty big already.

    2. It can wait. Just something for the radar.

  3. reviewboard/reviews/builtin_fields.py (Diff revision 2)
     
     

    "JavaScript"

    Here and all the others.

  4. Description is intended 1 space too far.

  5. This kinda reads weird. Maybe:

    The way that the review request should be closed. This can be one of <values>.
    
    This is only used if ``fieldName`` is ``closeDescription``.
    
    1. This is obsoleted by /r/9150/

  6. So this broke when originally converted to ES6. The newline shouldn't have been there, as that adds unwanted whitespace to be beginning. Mind fixing it while you're here? <%- describeText %> should be flush up against the prior <label>.

  7. Same here. There shouldn't be any newline involved.

  8. You can pass this.showBanner in directly. No need for the wrapping function.

  9. I'd like to avoid using for .. of. Babel turns it into a whole lot of pretty expensive JavaScript. Can you use a standard for .. in or _.each() instead?

  10. Missing trailing period.

  11. This should be using the standard function doc format.

  12. Second sentence should be its own paragraph. One line summary.

  13. One-line summary, standard function doc format (since we don't have properties in JavaScript and shouldn't pretend).

  14. One-line summary.

  15. What if we don't want auto-complete for the text field? Can this be optional?

    1. I'm not sure what you mean by this comment, especially on these lines. Auto-complete is only set up if the autocomplete attribute is defined.

    2. I have no idea what I was reading when I wrote that. Ignore!

  16. Can you put the property on the next line? Reads a bit better.

  17. This can use template literals.

  18. Can you expand this to say more about what this does? How it formats it?

  19. Looks like we only use draft this once. We can get rid of that variable.

  20. For each of the built-in field descriptions, can you use the label (like "Branch", "Change Description", etc.) in the doc summary?

  21. Can you use data=[] in the function definition?

  22. Can this be data=[]?

    1. That only works if data is undefined. We want to be able to handle the case where it's also null.

  23. afterEach needs to do RB.DnDUploader.instance = null. Not sure whether this change came before my cleanup, so maybe this is working around issues fixed there, but for reference, see commit 528b268.

    1. This came before your cleanup, so it just goes away.

  24. The include should be indented 2 more spaces.

  25. The include should be indented 1 more space.

  26. 
      
David Trowbridge
Review request changed

Checks run (1 failed, 1 succeeded)

flake8 passed.
JSHint failed.

JSHint

Christian Hammond
  1. Only a few comments. Looks good to me otherwise. I'll do a final pass after this.

  2. Line's too long now. Review Bot's going to yell forever :/ Would be pretty cool to have dedent allow for some character at the end of a line that says "Join the next line and ignore any leading spaces of that line."

    Maybe we can wrap right after <%-? Kinda ugly but... Less invasive.

    1. Review Bot doesn't check line length in JS files, and if it did, there would be a bunch of things that wouldn't pass muster (given that gettext calls can't be wrapped). Given that, I'd prefer to leave this as-is.

  3. As discovered recently, we'll need to wrap the file in (function() { ... })();

  4. reviewboard/static/rb/js/views/reviewRequestFieldViews.es6.js (Diff revision 3)
     
     
     
     
     
     
     
     

    This might be faster as:

    this._fieldName = this.fieldID.replace(/_(.)/g, (m, c) => c.toUpperCase());
    

    Assuming you want to strip away all underscores and not just ones precedencing a letter.

  5. reviewboard/static/rb/js/views/reviewRequestFieldViews.es6.js (Diff revision 3)
     
     
     
     
     
     
     
     

    Missing "Returns"

    This should also go after useEditIconOnly.

  6. 
      
David Trowbridge
Review request changed

Checks run (1 failed, 1 succeeded)

flake8 passed.
JSHint failed.

JSHint

Christian Hammond
  1. Ship It!
  2. 
      
David Trowbridge
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-3.0.x (c240e78)
Loading...