refactor(ui): convert WorkflowsList + WorkflowsFilter to functional components

[agilgur5]

Partial fix for #9810
Partial fix for #11740

Motivation

• Completely refactors out all remaining deprecated code from the UI codebase! 🎉
  • In particular, removal of BasePage should unblock upgrading react-router
    • BasePage was old enough that it used the private context API before React had an official context API (the official context API is ~5.5 years old and this API is even older 😬 )
    • Follow-up to refactor(ui): migrate Reports to functional component and split files #11794 and refactor(ui): migrate UserInfo to functional component #11793 which removed the other remaining uses of it
• Newer, more modern, more future-proof, and cleaner hooks, async/await, optional chaining, and Array.includes syntaxes
• Heavy simplifications and optimizations to the codebase, making it easier to read and running more efficiently
• Several bugfixes as a result of this too

Modifications

Changes are similar in structure to #11794, in case that helps review

Removals

• Remove deprecated BasePage
  • BasePage + this.queryParams -> location prop + URLSearchParams
• Remove deprecated and unused Query component entirely
  • stumbled upon it searching for Consumer usage (there are a few left, mostly in process of being refactored in other PRs)

Bugfixes

• Labels were reset to none when one was supposed to be removed, which was not quite correct behavior
  • fixed to just add or remove the selected label
• URL params would grow infinitely with duplicate phases etc
  • fixed to be 1-to-1

More Subtle Bugs

• There were a few subtle bugs due to accidental in-place changes to Maps

  • React typically relies on immutable state (see also libraries like immer that are commonly used for this), so an object must be cloned first before one can make changes
  • Rewrote these with clones or fresh objects instead, which actually simplified the code a bit

• I stumbled upon some subtle bugs due to useEffect dependencies having objects, which can fail the referential equality check

  • Often that can just result in an extra request, but sometimes it could results in changes or requests not happening
    • Fix these scenarios by using primitive equivalents (such as toString() on a string array, or using individual primitives in an object)
    • There are a handful more in the codebase that use larger objects (like workflow), but I didn't touch those more complicated ones (at least for now)
  • Some of these were in code in these components, and others I found in other components, including one I refactored too
    • TagsInput had a bug on a bug. One from previous code, and one was a reference equality check I screwed up in a refactor, that had the underlying bug
      • props.tags was shadowed with stateful tags, which was not necessary and caused complications as well as made it easy to make bugs like these
        • props.onChange doesn't have to be optional as all uses of the component set it
        • with these two combined, we can just remove the shadowing entirely and use pure props, simplifying a good bit in the process

• (Also were several cases of shadowing mid-refactor, but those are not visible in the PR diff)

Optimizations

• Some state, like batchActionDisabled, could actually be entirely derived, so do that instead of using state

  • and throw a useMemo on top of that too

• Do all client-side filtering without requiring a refetch

  • previously the date filters in particular only ran on refetch and so relied on one happening for a date change, despite that not needing to go through the server at all
  • same if the number of retrieved workflows is beyond the pagination limit
  • we can just not render these filtered workflows instead, saving a whole network trip
    • can confirm that date filter changes no longer cause a new request
  • this did require a bit of refactoring to use filteredWorkflows instead of workflows for a few comparisons
  • this simplified the ListWatch logic a good bit, which made it easier to convert to an effect (see below)

Effects

• rewrite fetchWorkflows as an effect instead of a callback, similar to previous refactors and other parts of the codebase

  • it's also responsible for synchronizing state with the API, matching an explicit use-case of effects
  • this allows for some pretty significant optimizations
    • fetchWorkflows does not need to set a bunch of state variables -- once those state variables are updated, they will trigger a new fetch
      • so just set the newly changed variables and the state will be synchronized automatically by the effect
      • changeFilters is no longer needed as a wrapper function since fetching is automatic and does less setting now
        • also remove an unnecessary changeFilters call in the WorkflowToolbar's load function
          • if any batch actions are performed, the ListWatch will automatically pick them up, so there is no need to refetch
            • tested and made sure of this too
    • saveHistory no longer has to be in a callback, and can have a more optimized effect for itself as well

• convert saveHistory to an effect, similar to previous refactors and other parts of the codebase

  • this one just has many query params and logic therein, so it's quite a bit longer than usual
    • and also includes saving localStorage saves as well
  • and had to modify the historyUrl helper function to also be able to take a URLSearchParams object
    • it didn't quite handle multiple values per key, so this is a bit of workaround for that
    • this function does a bit too many things and may be good for refactoring later -- it is now at least consistently used everywhere

Simplifications

• Refactor WorkflowFilters props and onChange function to individual change functions

  • the previous onChange function was a catch-all but only ever used to change one variable at a time
  • now that state is mostly in singleton primitves, this is much more natural and is mostly clean pass-through
    • any change func previously only affected one variable anyway, now it is explicit and less confusing (I definitely made some mistakes with that before)
    • this should be more efficient too, as it doesn't attempt to change all variables now and doesn't rely on equality checks for that to be efficient

• Refactor out several setSelectedWorkflows(new Map<string, Workflow>()) to a clearSelectedWorkflows function

  • so as to not repeat all the map creations etc
    • less error prone as well as it's a bit tedious to type out and as a result easy to mistype (first-hand 😅 )

• consolidate functions that are used once in saveHistory to just in-line directly in saveHistory

  • which helped a bit with all the variable passing and shadowing issues

Renaming Variables

• Rename selectedPhases + selectedLabels to just phases and labels
  • shorter and matches other parts of the codebase, such as CronWorkflowsList and Reports (that follow a similar code structure too)
• Rename currentlySelected to newSelections
  • more conventional as well as aligned with other parts of the codebase and this file (this variable was a bit of an odd one out for some reason)

Compatibility changes

• Due to above renames and use of localStorage, some tiny backward-compat code was needed, see in-line comments
• Similarly I added one piece of forward-compat to an old version -- i.e. if you upgrade then downgrade
  • I discovered this as a really hard to figure out runtime bug (causing the entire UI to fail) when I changed branches and eventually realized it was localStorage causing the bug -- or rather the previous code's expectations that localStorage would return all variables and not possibly undefined

Other Fairly Straightforward Changes

Similar to previous refactor PRs:

• this.props -> props argument

• this.state -> useState

• constructor -> initial state

• methods, getters, setters -> inner functions

  • some methods were static, so further moved them out of the component and into module-level
  • reorder various functions as inner functions must be ordered by usage, whereas methods do not

• render functions to just directly in the main render

• private variables, some getters -> inner variables, sometimes memoized

  • some of these were also constant (not relying on props or state), so just moved up to module-level as well

• componentDidMount -> useEffect

• componentWillUnmount -> useEffect disposer

• replace Consumer HoC with useContext hook

• .collectEvent -> useCollectEvent

• promise chains -> newer async/await syntax

• consts assigned to anonymous functions -> named functions

• fix a random typing issue that popped up -- workflow.status.phase is a WorkflowPhase, not a NodePhase

  • all existing type checking passes

Verification

Tested locally quite extensively and repeatedly. Tested batch actions and selections. Tested phase, label, template, cron, and date filters. Tested watch functionality.

Misc Notes

This was an absolute monster of a PR to write (see also the 13 commits over several days) and is the most complex component in the codebase as far as I can tell.
Getting ~600+ lines of very stateful and effectful code to be semantically equivalent was a challenge in and of itself, but had that working on like 3rd try. It did make my head hurt to figure out how to rewrite everything equivalently.
Then all the refactors, simplifications, optimizations and bugfixes came (some of which found or introduced new bugs that needed fix), which also made my head hurt after I kept finding more and more things to fix.
The new state of things is a good bit cleaner and reads fairly straightforwardly though (the past version took a bit to wrap your head around as there were some unexpected code paths). Hopefully this makes it much easier to modify in the future and for new contributors to get familiar with at least 😅

I'm also totally gonna take a break from front-end for a bit after this monstrosity and focus more on CI/build and back-end

[toyamagu-2021]

Great work!
I've left a comment, but everything work fine.

[toyamagu-2021]

It would be great if we have unit tests for extraSearchParams in ui/src/app/shared/history.test.ts.

[agilgur5]

Oh good point! I forgot it had unit tests.

That being said I do think this function should be refactored a bit, so it may not be worth adding more tests at this time for something that will change. I intended extraSearchParams as more a hacky interim workaround.

Should definitely revamp the tests when this gets refactored!