Skip to content

batches: add UI to the preview page to handle UI publication state

Warren Gifford requested to merge aharvey/preview-publish-ui into main

Created by: LawnGnome

This is part six of #18277 (closed). (This is also the big one.)

This PR extends the functionality of the batch spec preview page to allow for changeset specs without explicit published fields to have their publication state controlled from the UI. When one or more changeset specs meet this requirement, the preview page now gains an extra set of checkboxes that can be used to select changeset specs that will be published (either for real or as drafts) when the appropriate option is selected from the dropdown button that replaces the Apply button in the alert.

How this looks

Default view with nothing selected

The default apply action still works the same way as before:

image

The dropdown with no changeset specs selected:

image

The dropdown with changeset specs selected:

image

Implementation notes

The preview page was extremely loosely coupled previously: the alert component (which has the Apply button and also invokes the backend mutation to apply the batch spec) knew very little about the state of any other components on the preview page. Now, though, it needs to be able to track the state of any filters that have been applied, along with knowing which changeset specs have been selected.

Initially, I looked at uplifting the mutation into BatchChangePreviewPage, along with the state management. This quickly became unwieldy, though: we have many layers of components on the page, which interact in interesting, often indirect ways (for example, the filter options previously went via URL parameters through FilteredConnection).

Instead, I've added two new contexts, which are provided at the BatchChangePreviewPage level and then consumed where needed in its descendants:

  • MultiSelectContext, which tracks the state of the checkboxes, including whether all/visible/individual checkboxes have been selected.
  • BatchChangePreviewContext, which tracks filter and pagination state, along with overall connection stats that are required across multiple components.

These contexts provide getters and setters for their internal state, which are used by the relevant descendant components.

Checkbox mania

The checkbox UI is patterned after the bulk operation checkbox UI we have on the actual batch change page. That page couples the checkbox state into the BatchChangeChangesets component, which is much more tightly coupled; I used that as inspiration for MultiSelectContext, which decouples the checkbox state. Behaviourally, there shouldn't be any significant difference between the two pages.

In the longer term, we may want to consider refactoring BatchChangeChangesets to reuse MultiSelectContext. It also might not be worth the effort. :man_shrugging:

Merge request reports