Add table list formatter for HTML audits

[ebidel]

R: all

This adds a new <table> formatter for HTML reports which increases clarity, fixes some overflow UI bugs we had with text, and will allow us to more easily add additional extended info in the future (e.g. extra properties from the gatherers, RUM data column, etc.)

An audit uses the formatter like so:

const createTable = Formatter.getByName('table').createTable;
...
extendedInfo: {
    formatter: Formatter.SUPPORTED_FORMATS.TABLE,
    value: {
      table: createTable({url: 'URL', protocol: 'Protocol'}, resources),
      results: resources
    }
}

Notes:

• All the cells are overflow: auto so you can scroll them to reveal more of the url/code snippets
• the original results are also being returned in extendedInfo so unit testing is easier and so we have the full objects as returned by the gatherer. Might want to change this in the future b/c it does mean the JSON results will be larger than they need to be.
• This PR was getting big, so I only did 3 audits. When we're happy with this, we can move over other URLIST audits to use the TABLE formatter.

After:

Before:

[patrickhulce]

Niiiiiiiiiiiice, I was needing something like this!

[patrickhulce]

awesome stuff!

[patrickhulce]

don't need the check here for webpSavings

[ebidel]

done

[patrickhulce]

either add a check for it to be positive here or move jpegSavings = ... inside the if above?

[patrickhulce]

probably also move these out of `` strings :)

[ebidel]

done

[patrickhulce]

no changes needed to the mapping?

[ebidel]

nope. The table formatter will pull from thegroupedResults object as needed, based on the keys used in the first arg to createTable({url: 'URL', lineCol: 'Line/Col', type: 'Type', code: 'Snippet'}).

[patrickhulce]

Ah so the extra info was already in there and was being ignored by URLLIST?

[ebidel]

Yea.

[patrickhulce]

do we care about alphabetizing our rules?

[ebidel]

There's a PR that alphabetizing selectors was brought up (can't find it now), but we deemed it unrealistic without tooling.

[patrickhulce]

a-ok by me!

[patrickhulce]

nit: no ! needed, headings is Array<string> isn't it?

[ebidel]

thanks. done.

[ebidel]

PTAL

[brendankenny]

To keep formatting out of the audits (and avoiding the Formatter.getByName(Formatter.SUPPORTED_FORMATS.TABLE) monster), rather than have each audit access the createTable function, you could do something like add a

static getHelpers() {
  createTable
}

to the formatter, then have the extendedInfo be something like

extendedInfo: {
  formatter: Formatter.SUPPORTED_FORMATS.TABLE,
  value: {
    results,
    tableHeaders
  }
}

and then have createTable be applied to results in the partial to create the table at that point (and pretty could just call createTable inside itself)

WDYT?

[brendankenny]

this is a huge improvement

[brendankenny]

nit: can just do !Object<string> (since all object keys are strings)

[ebidel]

done

[brendankenny]

worth documenting these special keys in jsdoc?

[ebidel]

done. added to the function description. If we ad more one-offs, that'll be easy to doc more.

[brendankenny]

looks like you maybe expect this to be !Array<!Object>?

[ebidel]

done

[brendankenny]

maybe @return {{headings: !Array<string>, rows: !Array<{cols: !Array<*>}>}}?

[ebidel]

done

[ebidel]

PTAL. getHelpers refactor and new tests.

[brendankenny]

LGTM
┬─┬