Initial v2 infinite load implementation#289
Merged
oliverchang merged 7 commits intogoogle:masterfrom Feb 6, 2022
Merged
Conversation
this is horrific but is required to wrap rows in <turbo-frame>, as it is invalid html to have something wrapping <tr>s inside a <tbody>/<table> context
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces an initial "infinite load" (as opposed to "infinite scroll") implementation on the vulnerability table, replacing the previous placeholder pagination.
It does not attempt to fix other known issues with the table e.g. columns aren't complete, width goes out of bounds, etc.
Notes
This implementation adds no additional custom JS by taking advantage of
<turbo-frame>, part of the pre-existing dependency on Turbo, which replaces only itself—and not the full page—with an updated version upon request load.For example, the HTML in
/list?page=1looks like the following:Similarly, the HTML in
/list?page=2looks like the following:Note how everything is nearly the same, except
ids attached to the<turbo-frame>.When clicking the link on page 1, this is intercepted by
<turbo-frame id="vulnerability-page-2">, which fetches/list?page=2and looks for a frame with the same id. It then replaces itself with those contents.Hence the resulting rendered HTML of:
Ignoring the existence of
<turbo-frame>, we can also see how this HTML would enable navigation even in web browsers without custom elements support.Known issues
<table>does not support<turbo-frame>wrapping table rows. This is invalid HTML. Adopting this solution was only possible by first rewriting the vulnerability table using<div>and<span>elements, and using CSS to display it as a table, and ARIA markup for proper screen reader support.<turbo-frame>to not affect the structure of the table, we take advantage ofdisplay: contents;so that the rendered structure of the page is as if all table rows had the same parent.Further reading