This diff expands on the partition matrix's "click to show runs" behavior so that clicking a step in a particular day shows you all the runs of that day annotated with the state of that particular step and a link to go directly to the logs with the step filter applied.
In the spirit of trying to load as little data as possible, the UI no longer loads the data required for the RunTable until you click on a particular step and open the runs modal. To render the table with the additional column showing the stats of the clicked step, it blends the data from the original query (which fetched all the per-step stats, but less info about the runs), with the full run data. This is /slightly/ awkward, but the API doesn't provide us with a great way to fetch the runs with stepStats about a single step. I am also using the partition run tag to query for the runs, which may be the first time Dagit is assuming the existence of that tag.
I also spent some time cleaning up the Partition view React components to make it easier to do more performance related refactoring soon. In retrospect it cluttered this diff a bit but it should make subsequent diffs smaller and more isolated I think!
- I moved some supporting custom components to their own files in src/partitions. I'm a fan of keeping small custom components in the same file until they're used elsewhere, but PartitionView was getting out of hand.
- I gave the partition matrix and the graphs on the page distinct GraphQL fragments and rolled them up into the root query so that it's easier to trace where fields we're fetching are used. This revealed a few fields we weren't using and a few that are only needed for the pipeline-wide expectation results + materializations graphs, which we might cut soon.