Skip to content

Conversation

@Alexendoo
Copy link
Member

cc @GuillaumeGomez

  • Searching/filtering no longer creates a new history entry per keystroke/change
  • Loading a URL with a specified search query now works. The search is now stored as ?search=foo instead of #/foo, not a breaking change since this didn't work before
  • The browser back/forward actions now update the filters/search and displayed lints

The bulk of the changes are to support that last one, previously the filter state was stored both in the DOM and as JS objects. The DOM is now the single source of truth

changelog: none

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Nov 10, 2025
@rustbot
Copy link
Collaborator

rustbot commented Nov 10, 2025

r? @samueltardieu

rustbot has assigned @samueltardieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@samueltardieu
Copy link
Member

Thanks, I'll wait to see if @GuillaumeGomez has something to say about this before merging it. Cursory testing indicates that it seems to work as expected.

document.addEventListener("keypress", handleShortcut);
document.addEventListener("keydown", handleShortcut);

document.querySelectorAll(".dropdown").forEach(setupDropdown);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use onEachLazy instead of forEach. Chrome recomputes the list at every change made to the DOM.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A NodeList can be live but forEach doesn't subscribe to changes or anything like that, it's equivalent to Array.prototype.forEach.call(list, f), they are defined to be the same function

> Array.prototype.forEach === NodeList.prototype.forEach
true

querySelectorAll returns a non-live NodeList, additions/removals to the DOM are not reflected in the list like they are with e.g. childNodes. But in this case it would be fine if it were live too, the main issue to look out for with live collections is mutating the DOM while iterating

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A NodeList can be live but forEach doesn't subscribe to changes or anything like that, it's equivalent to Array.prototype.forEach.call(list, f), they are defined to be the same function

Didn't know that, thanks for the information!

<button class="reset-none">None</button> {# #}
</li> {# #}
<li role="separator" class="divider"></li> {# #}
{% for group in ["cargo", "complexity", "correctness", "nursery", "pedantic", "perf", "restriction", "style", "suspicious", "deprecated"] %}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved this code on purpose in JS to reduce the page size and also to make it empty in case user's JS is disabled.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah this change wasn't functionally required I just got annoyed at the HTML being split across files when locating class names etc

There's no difference to the page with JS disabled though since you can't expand the dropdowns without JS

It does add some size to the HTML, but they're mostly the same so they compress plenty well. Overall size wise (gzipped) this PR is +246 bytes for the HTML and -1255 bytes for the JS

Up to you @samueltardieu

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no difference to the page with JS disabled though since you can't expand the dropdowns without JS

That's part of the things I'd like to change. So better avoid doing back and forth for the same thing. ^^'

It's not really a blocker though. Just more diff in the future when I'm back to this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you @samueltardieu

If this is easy not to include this non-required change, then I would indeed prefer not to step on @GuillaumeGomez's ongoing cleanup effort.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's some manual effort but yeah revertible, I'll take one more crack at persuasion first to try and avoid it though 😄

If we hide the filter section it's not a problem if they become expandable without JS, it was meant to be hidden in the JS-less page but isn't because of a typo, with that fixed it would no longer matter

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a lot of effort to fix a typo 😆

<button class="reset-none">None</button> {# #}
</li> {# #}
<li role="separator" class="divider"></li> {# #}
{% for level in ["allow", "warn", "deny", "none"] %}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

@rustbot
Copy link
Collaborator

rustbot commented Nov 10, 2025

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants