Skip to content

batches: recalculate actions on modifying publication states

Administrator requested to merge kr/publish-from-preview-4 into main

Created by: courier-new

Closes #23383 (closed).

This PR includes:

  • recalculating the actions on the backend when a publish status modification is selected
  • a small fix to #24020

Changelog entry will be included in the docs tickets.

Unfortunately, the UX for this recalculation is less-than-ideal, as it reloads the entire connection when a new publication state is applied because observables are hard. ☹️ But after spending most of the afternoon on it, I think this is best-effort for a first pass and something we certainly will have the resources to come back and improve later.

https://user-images.githubusercontent.com/8942601/129820446-97d5fe99-2ac2-4c6c-8770-020e34858c50.mov

We don't really have a pattern for changing the query parameters on the connection from outside of the FilteredConnection itself. By placing publicationStates in the dependencies array for the query callback, I'm effectively unsubscribing and resubscribing to a new observable whenever they change, which causes the loading fallback screen with the "list reloading" effect as opposed to keeping the observable and re-emitting with the new connection data.

Ideally, we just switch this component over to useConnection that allows us to tap into Apollo's cache, because background refetching is exactly what Apollo caching is good at. However, I started going down this path and found that the effort needed to migrate was pretty heavily snowballing, so I decided to abandon that effort for now.

I tried a couple other things to mitigate this and restore the background-refetching behavior, including a hacky suggestion from Erik to "poll" with repeatWhen by notifying when there's a change to publicationStates, but nothing quite worked out.

In any case, this approach is at least functional, if not pretty, and migrating to useConnection + the new way of building a FilteredConnection will almost certainly resolve this issue for us. I've filed #24059 to remember this.

Merge request reports