Limit amounts of techs shown per page

[sarahfossheim]

Issue

Currently we can select an infinite amount of techs on the comparison page, and some categories have ca 300 technologies in them as well. When rendering the data for this many technologies, the page ends up loading slowly (and the visualizations hard to read).

Fix:

Main change

• The categories page is paginated, showing only 10 technologies per page.
• Previous and next buttons at the bottom of the page to navigate the results.

As a result, the following functionality also had to be added

• "Skip to main content" and "Skip to results" controls, for easier keyboard and screen reader navigation when browsing a paginated table. This shifts the keyboard focus to the filter bar and results.
• Remember which technologies are checked off across pages, through the selected parameter in the URL
  • Store checked technologies in the selected parameter of the URL
  • Remove de-selected technologies from the URL
  • When loading a new page, check the technology checkboxes based on what's in the URL
• When no technologies are checked off, the compare link takes the user to the comparison dashboard of the 10 technologies from that page

Also included

• Only the category names and technology names are fetched for populating the dropwdowns
• Minor code cleanup
• Minor design changes (eg. select button moved to the top of the page)
• Updated explanations
• Show summary of all the selected technologies, so there's a full overview across pages
• Option to remove technologies from the selection list through the summary
• Limit the technology selections to 10
• Choose amount of rows per page (10, 25, 50)

[max-ostapenko]

@sarahfossheim Somehow I get a long list of technologies again instead of pagination.

Regarding filtering, I would suggest the user to use the technologies page for a scenario like this.

[sarahfossheim]

@tunetheweb ready for review :)

Linter complains about </option>s without start tag, but they do have a start tag. Not sure what's up with that 🤔 Because of the if statement?

<select id="rowsPerPage">
    <option value="10" {% if filters.rows == "10" %}selected{% endif %}>10</option>
    <option value="25" {% if filters.rows == "25" %}selected{% endif %}>25</option>
    <option value="50" {% if filters.rows == "50" %}selected{% endif %}>50</option>
</select>

[tunetheweb]

I've hit this in the past. Think I had to do this to get round it:

<select id="rowsPerPage">
    {% if filters.rows == "10" %}
    <option value="10" selected>10</option>
    {% else %}
    <option value="10">10</option>
    {% endif %}
    {% if filters.rows == "25" %}
    <option value="25" selected>25</option>
    {% else %}
    <option value="25">25</option>
    {% endif %}
    {% if filters.rows == "50" %}
    <option value="50" selected>50</option>
    {% else %}
    <option value="50">50</option>
    {% endif %}
</select>

Which is a bit yucky, but was the only way I found to stop the linter complaining :-(

[sarahfossheim]

@tunetheweb Updated it that way and it indeed stopped complaining now, agreed it looks a bit yucky though 😕

[tunetheweb]

This also might work?

            <select id="rowsPerPage">
              {% macro setSelected(arg1) %}{% if filters.rows == arg1 %}selected{% endif %}{% endmacro %}
              <option value="10" {{ setSelected("10") }}>10</option>
              <option value="25" {{ setSelected("25") }}>25</option>
              <option value="50" {{ setSelected("50") }}>50</option>
            </select>

Not sure it's any less yucky though!

[tunetheweb]

Looks like CI is failing for other things:

• More CLS. Think you said you were working on this?
• Console error when looking at http://127.0.0.1:8080/reports/techreport/comparison

section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1 Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
    at new i (section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1:3984)
    at window.Section.initializeTable (section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1:10561)
    at section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1:10489
    at NodeList.forEach (<anonymous>)
    at window.Section.initializeComponents (section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1:10324)
    at new window.Section (section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1:10208)
    at techreport.js?v=2e9f87dae208dd8235b3164b5c8f8067:1:11203
    at NodeList.forEach (<anonymous>)
    at window.TechReport.initializeReport (techreport.js?v=2e9f87dae208dd8235b3164b5c8f8067:1:11182)
    at window.TechReport.initializePage (techreport.js?v=2e9f87dae208dd8235b3164b5c8f8067:1:10547)
i @ section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1
initializeTable @ section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1
(anonymous) @ section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1
initializeComponents @ section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1
window.Section @ section.js?v=b2a3fca9592b64aecf7569ae40b9a80e:1
(anonymous) @ techreport.js?v=2e9f87dae208dd8235b3164b5c8f8067:1
initializeReport @ techreport.js?v=2e9f87dae208dd8235b3164b5c8f8067:1
initializePage @ techreport.js?v=2e9f87dae208dd8235b3164b5c8f8067:1
window.TechReport @ techreport.js?v=2e9f87dae208dd8235b3164b5c8f8067:1
(anonymous) @ comparison:1472

[tunetheweb]

LGTM once we get CI sorted.

A few minor nits.

[tunetheweb]

Should we use encodeURI to handle other potential issue characters?

[tunetheweb]

Ditto