Add support for sharing an eventID and loading context around that event ID in the timeline

[wesbillman]

This feature seems to be broken in the console and will need to get fixed.

The idea is that you can view the timeline and click on events, which will give unique urls for that event id like http://localhost:8892/events?id=11 (this should probably something like http://localhost:8892/timeline?event_id=11 in the future as well. When this url is shared, it should open the timeline with this eventId at the top and previous events shown below it.

Related to #2489

[deniseli]

reminder to also include filter state in the query params

[deniseli]

Dumping some disparate thoughts here before I lose them:

Instead of fudging deployment and module together as the same concept, we should figure out whether we want to model this as "a module has deployments" where deployments are children of a module, or "module is an attribute of a deployment" where everything is done at a deployment-level.

For some use cases (e.g. testing out verb calls), users really won't want to have to be aware of deployments; they just want care about module+verb+related decls. For the timeline/events view, we probably do want to be deployment-centric, since that's what the events relate to the most.

Possibly, we could:

• In the modules page, the module is the first class concept, and deployments are just some additional info you see on each module's page, but you don't really need to understand deployments to use anything in the module tree.
• In the timeline page, we can filter by both module and deployment - not just one or the other.
• In the graph tab, I pending discussion, we could build out a full deployment-centric view that really shows how the actual running artifacts/resources/whathaveyou are working together. Lots of thoughts on this in https://hackmd.io/7mVpD_HaT0WcF7zTjH0Vsg?view.
• In the infra tab, naturally, we would want to see things through the deployments lens, not modules. I imagine we'd want this to show very similar information to the graph tab, but in list view instead of graph view. Graph view can be designed to aid in discoverability of specific relationships/ratios that we target, vs list view can be more like "user knows exactly what they want, doesn't want to hunt around a big complex viz, they just need to go to this big list/table view and drill down to exactly what they want to do very quickly"

[deniseli]

Hmm maybe graph and infra tab should actually reuse the same "artifact viewer" child pages - e.g. you can click on a db in either view and see the exact same page on it.

That extends to the other top-level pages as well. e.g. if you click a past verb call to see all its details (e.g. response json) from either the modules view or the timeline view, you should probably get the same component.

For all the child pages that are shared across top-level pages, we should have a good think about building them as modals, so the user can still see the parent view underneath for navigating back. But also modals are so 2010. fwiw, the only 2 real reasons designers started to hate modals were because it (1) reduced screen real estate and (2) wasn't mobile friendly. But these days, the fashion is more to just waste screen real estate on whitespace anyway. So the trend away from modals was worthless in the end anyway. And we aren't going for mobile support on this anyway, and if we somehow really needed mobile support, I seriously hope we'd come up with a better approach than trying to shoehorn the console into fully supporting both device types on its own. idk, will think about it. Probably, if we really do have a lot of content to show, we should make it a full page, but if the content isn't expansive enough to justify it, a modal feels more appropriate.

Separately, a better way to put this is probably "logic-centric" vs "deployment-centric"? Not sure. Just dumping lots of thoughts here

[deniseli]

Nah those response bodies are enormous actually, so we'll probably want full page...

[deniseli]

If we're going to share components for each item type, I wonder if we should also share link components to each of those shared components. Then we could add some styling to make it easier to skim the view for a particular deployment or resource or decl or whatever you're looking for, and it'd be easier to build additional useful "peek" functionality on to of that. e.g. if you hover over a deployment ID anywhere within the console, you get a tiny hover card that tells you its status, load, etc. And then if you click, it takes you to the page.

[deniseli]

DeclLink is already basically this, just generalized across all decls, and without a hover card.