Add BulkController support for shift+click behaviour

[lb-]

• Allow multiple selections or un-selections with shift+click
• Pull out activeItems getter and instead use this as a method for select all checkboxes and individual checkboxes
• Pull out ToggleAllOptions to a type and support this being passed in via a CustomEvent also, as per pattern being set up in other Controllers
• Minor refactoring to make code easier to extend, clean up of JSDoc and adjust how we set up tests to make it easier to use different html.
• Do the tests still pass? Including Jest tests for all new behaviour introduced by this PR
• Does the code comply with the style guide?
• For front-end changes: Did you test on all of Wagtail’s supported environments?
• For new features: Has the documentation been updated accordingly? N/A

additional details for testing this change

1. In bakerydemo, navigate to the form submissions listing and have at least 5 form submissions loaded.
2. Click any item near the top, now shift+click any item near the bottom. Observe that the ones in between are now selected.
3. Now select all, then click (to unselect) any item near the bottom, now shift+click any item near the top, observe that the ones in between are all un-clicked.
4. Try this a few different ways.
5. Finally, do the same, on the simple translation form (where you translate a page and you are asked if you want to translate to all other supported translations).

Recording

screencast-bulk-actions-shift-click-2023.09.06-07_54_23.webm

Context

This PR builds on the work done in #10292 & #10613 and sets up the Stimulus controller to be closer to what is needed for the full 'bulk actions' checkbox support. This PR will be one of the final pieces before that work can start.

[squash-labs]

Manage this branch in Squash

Test this branch here: https://lb-feature5836-bulk-toggle-shi-k26mj.squash.io

[lb-]

Rebased and fixed a few bugs encountered for edge cases.

[lb-]

Rebased

[thibaudcolas]

Working great @lb-, thank you! I’ve spotted minor things, which I’ll address myself as part of merging this.

[thibaudcolas]

I’m surprised this isn’t an interface, but it works :)

[thibaudcolas]

HTML element ids normally can’t start with a number. Seems to work fine here but I’ll add a letter prefix just to be safe.

[lb-]

Good call thank you, I think id can be a number but CSS identifiers cannot start with a number.

[thibaudcolas]

There are a few things I’m confused about here:

• The types say event is a CustomEvent, while the code below has an optional chaining as if this could be called without an event. But the code later accesses event.target anyway.
• Unclear why we need to pass the data via detail in addition to params. I don’t see either of those two options used in Wagtail aside from the test suite. If we did use them, the use case for detail feels very small.
• force seems like it doesn’t need a default value (but perhaps worth setting one for clarity?)

[lb-]

Thanks @thibaudcolas - yes, I can see that this is a bit confusing. I would actually love some suggestions how to do this pattern better but let me explain the goals.

The purpose of this odd syntax is so that toggleAll can be called a few ways.

1. Internally from the class if needed this.toggleAll()
2. Via a simple Stimulus action <input ... data-action"change->w-bulk#toggleAll" />
3. Via dispatching some other event to this, also via a Stimulus action <input ... data-action"some-event@document->w-bulk#toggleAll" />

However, if we want to use force, we can now do this via the actions either with our custom event or with Stimulus action params.

<input ... data-action"change->w-bulk#toggleAll" data-w-bulk-force-param="true" />

OR

<input ... data-action"some-event@document->w-bulk#toggleAll" />
// JS
document.dispatchEvent(new CustomEvent({ detail: {force:true} }));

I could not find a nice way in TypeScript to reflect these three ways of calling, along with have a shared 'options' Type (to contain that force could be X type). I would love any tips for this as this approach is super useful in many other controllers.

As for the force defaulting to null, I do not recall why, it's probably just a habit of mine to always think of the default as an intentional value. Instead of accidental undefined we are better off saying that this may not be passed in and if so it should default to something.

[lb-]

Thanks Thibaud, let me know if you would like to see any improvement to this code as a follow up PR later.