Improve construction of ReviewUIs and show error for diff type mismatches.

Review Request #13533 — Created Feb. 12, 2024 and submitted

Information

Review Board
master

Reviewers

When instantiating review UIs for attachments with diffs, we would
create two instances, and then call set_diff_against and discard one
of them. We'd then reconstruct the second instance when rendering to set
the diffTypeMismatch field in the JS model. This also had a bug where
if the two revisions did not match in file types, we'd still always
instantiate the review UI for the "modified" version, which would then
fail in various ways on the client side depending on which particular
ReviewUI was in charge.

This change makes it so we find the ReviewUI classes for both the
original and modified files first, and compare them. If they match, we
can instantiate a single instance. If they don't, we instantiate a
generic review UI that just sets that the type doesn't match.

On the frontend, the DummyReviewableView (used for any ReviewUI that
doesn't provide their own) has been fixed up and enhanced in a couple
ways. First, the way that captions were displayed was backwards (showing
the original file caption on the right). The caption table was also not
properly styled so everything jammed up on the left. Finally, I've also
added a new error message that shows up when diffTypeMismatch is set,
to tell the user that we can't show a diff.

The particular styling rules for the DummyReviewableView are a little
ugly and just inserted into the reviews.less file. I plan to redo all
the styling for all the review UIs in a later change.

  • Ran python tests.
  • Ran JS tests.
  • Created an attachment with multiple revisions that were all images.
    Saw that individual display and diffs still worked properly.
  • Created an attachment with multiple revisions where some revisions
    were images and some were text. Saw that when I selected a diff
    between incompatible file types, I got a review UI page that showed
    the correct file revision slider and captions, and the body had the
    new error about file types not matching.
Summary ID
Improve construction of ReviewUIs and show error for diff type mismatches.
When instantiating review UIs for attachments with diffs, we would create two instances, and then call `set_diff_against` and discard one of them. We'd then reconstruct the second instance when rendering to set the `diffTypeMismatch` field in the JS model. This also had a bug where if the two revisions did not match in file types, we'd still always instantiate the review UI for the "modified" version, which would then fail in various ways on the client side depending on which particular ReviewUI was in charge. This change makes it so we find the ReviewUI classes for both the original and modified files first, and compare them. If they match, we can instantiate a single instance. If they don't, we instantiate a generic review UI that just sets that the type doesn't match. On the frontend, the `DummyReviewableView` (used for any ReviewUI that doesn't provide their own) has been fixed up and enhanced in a couple ways. First, the way that captions were displayed was backwards (showing the original file caption on the right). The caption table was also not properly styled so everything jammed up on the left. Finally, I've also added a new error message that shows up when `diffTypeMismatch` is set, to tell the user that we can't show a diff. The particular styling rules for the `DummyReviewableView` are a little ugly and just inserted into the reviews.less file. I plan to redo all the styling for all the review UIs in a later change. Testing Done: - Ran python tests. - Ran JS tests. - Created an attachment with multiple revisions that were all images. Saw that individual display and diffs still worked properly. - Created an attachment with multiple revisions where some revisions were images and some were text. Saw that when I selected a diff between incompatible file types, I got a review UI page that showed the correct file revision slider and captions, and the body had the new error about file types not matching.
7fd8745e5b4e20742ed5f85f091a45566f88c296
Description From Last Updated

'housekeeping.functions.deprecate_non_keyword_only_args' imported but unused Column: 1 Error code: F401

reviewbotreviewbot

line too long (80 > 79 characters) Column: 80 Error code: E501

reviewbotreviewbot

It looks like you didn't actually add this argument.

maubinmaubin

Can we type this while here, so it's not interpreted as a literal False?

chipx86chipx86

Can we type this?

chipx86chipx86

Let's pull this.model out into a local variable. We do an attribute lookup 10 times in this function.

chipx86chipx86

Should the quotes just be around the captions? It feels like the revision information should be outside of that. Another …

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

flake8

david
maubin
  1. 
      
  2. reviewboard/reviews/ui/base.py (Diff revision 2)
     
     
     
     

    It looks like you didn't actually add this argument.

  3. 
      
david
maubin
  1. Ship It!
  2. 
      
chipx86
  1. 
      
  2. reviewboard/reviews/ui/base.py (Diff revision 3)
     
     
     

    Can we type this while here, so it's not interpreted as a literal False?

  3. Can we type this?

  4. Let's pull this.model out into a local variable. We do an attribute lookup 10 times in this function.

  5. Should the quotes just be around the captions? It feels like the revision information should be outside of that.

    Another approach would be to mark up that information in bold or something, so it's more readily identifiable as something other than just text in this string.

  6. 
      
david
chipx86
  1. Ship It!
  2. 
      
david
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-7.x (d81af44)
Loading...