• 
      

    Convert RB.CommitView to TS/spina and Ink.

    Review Request #14105 — Created Aug. 15, 2024 and submitted

    Information

    Review Board
    master

    Reviewers

    This change converts the CommitView class to TypeScript, and replaces
    various UI elements with Ink. In particular:

    • Several icons have been switched from fontawesome to Tabler icons
      bundled in Ink.
    • The progress spinner when creating a post-commit review request now
      uses <Ink.Spinner>.
    • The confirmation dialog uses <Ink.Dialog>

    This also fixes a couple ugly interaction issues relating to what is
    happening when during the event handler. The big problem was that we
    were always creating the confirmation dialog and then handling other
    cases in the confirm handler. This meant that for commits that had an
    existing review request, we'd prompt them to create a new review request
    and then just open the existing one. For inaccessible commits, we'd
    prompt them and then do nothing. These conditions are now checked at the
    top of the click handler, so we don't prompt the user unless we really
    need to.

    • Ran js-tests.
    • Created new review requests for commits and saw that the interaction
      worked correctly for both confirm and cancel.
    • Clicked on commits with existing review requests and saw that the page
      linked directly without any prompt.
    • Verified the appearance of the new icons and spinner.
    Summary ID
    Convert RB.CommitView to TS/spina and Ink.
    This change converts the CommitView class to TypeScript, and replaces various UI elements with Ink. In particular: - Several icons have been switched from fontawesome to Tabler icons bundled in Ink. - The progress spinner when creating a post-commit review request now uses `<Ink.Spinner>`. - The confirmation dialog uses `<Ink.Dialog>` This also fixes a couple ugly interaction issues relating to what is happening when during the event handler. The big problem was that we were always creating the confirmation dialog and then handling other cases in the confirm handler. This meant that for commits that had an existing review request, we'd prompt them to create a new review request and then just open the existing one. For inaccessible commits, we'd prompt them and then do nothing. These conditions are now checked at the top of the click handler, so we don't prompt the user unless we really need to. Testing Done: - Ran js-tests. - Created new review requests for commits and saw that the interaction worked correctly for both confirm and cancel. - Clicked on commits with existing review requests and saw that the page linked directly without any prompt. - Verified the appearance of the new icons and spinner.
    292619f6593c29af18fd7eed7a85283afa3fedeb

    Description From Last Updated

    These have vertical alignment issues. I think they're across the whole row, but they're very noticeable on the clock. (May …

    chipx86chipx86

    Looks like a 1 snuck in.

    chipx86chipx86

    I remember we had a discussion before about </> vs. the full name. Do we want to revisit what we …

    chipx86chipx86

    There's some low-hanging fruit we can do to improve accessibility here. Maybe best as a new change, but we should …

    chipx86chipx86

    We access this.model 5 times. Let's pull it out into a local variable.

    chipx86chipx86

    We access this.model 5 times. Let's pull it out into a local variable.

    chipx86chipx86

    So I played with this recently. We don't want &nbsp; (we want a breaking space). Instead, due to the way …

    chipx86chipx86
    chipx86
    1. 
        
    2. Show all issues

      These have vertical alignment issues. I think they're across the whole row, but they're very noticeable on the clock. (May have been there before, but we should fix them.)

    3. Show all issues

      Looks like a 1 snuck in.

    4. Show all issues

      I remember we had a discussion before about </> vs. the full name. Do we want to revisit what we want to standardize on here? This craft template is inconsistent in which is used.

      1. I don't remember that discussion, but I think we should probably always include the full name.

      2. It was on Slack when I was first building Ink's craft/paint templates. Worth noting, there is one case where </> is a requirement, and that's when using <{SomeClass} ...> as the opening tag, referencing an explicit class to craft.

    5. 
        
    david
    chipx86
    1. 
        
    2. Show all issues

      There's some low-hanging fruit we can do to improve accessibility here. Maybe best as a new change, but we should track this (we need an Asana project somewhere for this).

      1. Added to the a11y section in our backlog.

    3. Show all issues

      We access this.model 5 times. Let's pull it out into a local variable.

    4. Show all issues

      We access this.model 5 times. Let's pull it out into a local variable.

    5. 
        
    david
    chipx86
    1. 
        
    2. Show all issues

      So I played with this recently. We don't want &nbsp; (we want a breaking space). Instead, due to the way htm works, we want this:

      <code>${...}</code>${' '}...
      
    3. 
        
    david
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to master (1e5de5f)