Avoid duplicate instantiation and rendering of review UIs in diffs.

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

Information

Review Board
master

Reviewers

When rendering review UIs into diffs, we'd end up creating instances for
both the original and modified files, even if we had a UI capable of
rendering a diff. This change makes it so we look up the matching Review
UI classes first and check if it's diff capable. If so, we only create
it once and use it to render the diff. If we have some other case (such
as only having one side or the other, or having a file type mismatch),
we'll instantiate each review UI and render the column.

Looked at a diff that had attachments for binary filediffs. Saw that
review UIs were instantiated and rendered correctly.

Summary ID
Avoid duplicate instantiation and rendering of review UIs in diffs.
When rendering review UIs into diffs, we'd end up creating instances for both the original and modified files, even if we had a UI capable of rendering a diff. This change makes it so we look up the matching Review UI classes first and check if it's diff capable. If so, we only create it once and use it to render the diff. If we have some other case (such as only having one side or the other, or having a file type mismatch), we'll instantiate each review UI and render the column. Testing Done: Looked at a diff that had attachments for binary filediffs. Saw that review UIs were instantiated and rendered correctly.
7681857eefa65fa5f12849951fca7fbc1ba9eab2
Description From Last Updated

Would it be a lot of effort to add testing for this, to ensure the intended logic doesn't regress?

chipx86chipx86

Can you add typing for these while here?

chipx86chipx86

Needs to be Type[...] for now. Same below.

chipx86chipx86
maubin
  1. Ship It!
  2. 
      
chipx86
  1. 
      
  2. Would it be a lot of effort to add testing for this, to ensure the intended logic doesn't regress?

    1. This is still in flux with my plans to add support for letting ReviewUIs operate on FileDiffs. I'd like to wait to add any testing until after I'm confident it's not going to change a bunch.

  3. reviewboard/reviews/views/diff_fragments.py (Diff revision 1)
     
     
     
     
     
     

    Can you add typing for these while here?

  4. 
      
david
chipx86
  1. 
      
  2. Needs to be Type[...] for now.

    Same below.

    1. Because this is in an annotation, it works as long as we make sure to have from __future__ import annotations. It's only things that aren't in annotations (such as inheriting from Registry[Type[...]]) that still need the typing version.

    2. That's true, though I feel consistency is ideal, because otherwise it's easy to use one in place of the other in the wrong place.

      I'm looking forward to eventually moving entirely to built-in types. Until then, it'd be nice to be consistent, but I don't want this to be a blocker for this change.

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

Status: Closed (submitted)

Change Summary:

Pushed to release-7.x (9bd048f)
Loading...