Deeplinking to Releases Drawer List (Global Drawer)

[billyvg]

For the new Releases Drawer, we want to be able to deep link into the drawer. There are currently two ways to open up the drawer:

• Clicking a link to a specific release (not implemented yet) opens up the drawer and shows some details about that release. This is pretty straight forward in terms of linking.
• Clicking a release bubble on a chart opens up the drawer and displays the chart from where the bubble was clicked on (but zoomed into the bubble’s date boundaries) and a table of the releases within that bubble. The table is straight forward in terms of linking, it is the chart that is a bit more complicated and will be the focus of this ticket.

There are also currently two entry points (i.e. the views that contain the charts that will open the drawer) where you can link to/open the global drawer: Insights and Issue Details.

Problem

We need a method to represent a single chart via URL parameters so that we can render the chart inside of the Global Drawer. We currently need to render two (+ possibly more in future) different chart components that take in a variety of props that can be tricky to serialize into URL params.

Potential Solutions

1. Serializing props to URL parameters

For each chart, we could determine the unique parameters it needs to be able to render the chart and use them directly in the URL. This will probably mean a lot of data being saved to the URL. This also might be hard to maintain as we add more charts.

1a. Map props to an ID

Instead of preserving all props in the URL, we could instead give each chart a unique id and use that to map to the props required to render the chart. We would need to refactor our current charts to make sure they render using the same method so that the chart logic does not get desynced.

2. React Context

Views that render a release-enabled chart would need to register a rendering function w/ a release drawer context. We could then pass an id unique to that chart in the URL parameters for the Global Drawer to use for context lookup. This means that the drawer would need to wait for the chart to register/render on the page before it can render in the drawer. It also means that the chart cannot render independently of the page. This isn’t currently a concern, but could be if we wanted to be able to render the releases list outside of clicking on a release bubble.

[getsantry]

Routing to @getsentry/product-owners-releases for triage ⏲️

[gggritso]

Wow, this is really hard! I'm trying to tease apart all the factors here by working backwards from what I think a good future is.

---

Firstly, I think we want IDs in the URL, rather than parameters for the panel chart. I think we want to avoid having users deal with long URLs, potentially getting them wrong, potentially creating impossible charts, etc. With IDs we can store configurations in the code, which will let us update those configurations, make sure that the graph on the page always matches the panel, etc.

Supporting argument 1: Having an ID per chart is probably good for us. That would let us store chart legend selection in localStorage, for example, and manually unsync series between charts if we want.

Supporting argument 2: Having an ID per chart is how Dashboards work. If/when we introduce release panels in Dashboards, those charts will get their configs from the widget rather than the URL, otherwise someone might change a widget and then a link to the widget's releases would have a bad, old configuration.

Supporting argument 3: Configurable Release Health charts are using this kind of approach already, assigning unique names to chart components, so they can be moved around the page. Charts like having IDs!

Counter-argument 1: parameters in the URL are more flexible, and probably simpler. Each chart only needs to store a few parameters in the URL (yAxis, query, etc.) so it's probably not that hard to serialize those in practice.

Counter-argument 2: The date bounds of the release for the panel have to be in the URL, so there's going to be at least some URL serialization anyway

---

Secondly, I think we want each chart to be independent of the main page. I think. Coordinating the rendering and/or the data loading with the main page seems like it's be really hard? You tell me. A good end result here would be that the chart in the panel loads fast, independently of the page, and I'm still stuck on having it load a higher data resolution than the main page. This'll probably be a lot of work.

Supporting argument 1: There is some appetite for having charts load their own data, and some charts already do (all the new Release Health charts, some of the landing page charts). When charts load their own data, it usually improves perceived performance if some charts are able to load faster than others.

Counter-argument 1: It'll be for real a lot of work to do this, and probably with some strange gotchas.

Counter-argument 2: Supporting multiple chart types will be annoying for sure. That said, we're working hard to reduce the number of chart types, and are making headway, so maybe this won't be that bad?

[billyvg]

I did two quick PoCs (#89045 and #88864) - and the former is what we will be doing. It's cleaner and has some small benefits with existing usage of the widgets, but mostly we want the flexibility in the future for deeplinking directly to widgets.

Next steps:

• Refactor existing insights widgets into self-contained widgets that handle their own data fetching. We will need a convention for naming as we will need to dynamically load the widgets based on a unique id/string. e.g. chartId/Name == component name == filename.
• Add an optional id prop on TimeSeriesVisualizationWidget`. This will be used to generate links to the chart (e.g. in Releases Drawer). This will be optional until all charts are converted.
• Create a <WidgetLoader> that accepts an id and dynamically imports the widget that renders a chart [with data]. We'll need to think about loading (and error) states here. If we use a spinner for the dynamic import, that means once the module is loaded, we'll have another + different spinner for data fetching. The two spinners will look like it's stutter if they are not perfectly synced up (they won't be).
  • Widget loader will need to be able to load the Insights widgets AND <EventGraph> in Issue Details
• Refactor <EventGraph /> so that we can use only the chart and add a data-fetching wrapper around it for Release Drawer e.g. we can only pass groupId (do we need eventId as well?)
• Refactor Insights widgets so that they can accept non-pageFilters params when necessary. e.g. in Releases Drawer, we have a smaller timeframe to show
• Links to open the Releases Drawer need to include a chartId (+ possibly chart type? e.g. insights vs event graph). Assuming that not all Insights widgets are converted, we'll want to be able to render the chart if id is available, otherwise keep previous behavior.
• Eventually all Insights widgets will be loaded via <WidgetLoader>
• Add lint rule to disallow directly importing TimeSeriesVisualizationWidget (or rather the LineSeries, etc wrappers around it)