-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for sharing an eventID and loading context around that event ID in the timeline #2404
Comments
reminder to also include filter state in the query params |
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:
|
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 |
Nah those response bodies are enormous actually, so we'll probably want full page... |
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. |
|
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 likehttp://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
The text was updated successfully, but these errors were encountered: