Page MenuHomePhabricator

[dagit] Create workspace routes
ClosedPublic

Authored by dish on Oct 19 2020, 9:59 PM.

Details

Summary

This is a first step in the plan to add more specificity to Dagit URLs. Create workspace-level pages to serve as index pages for repositories, namespaced to /workspace paths.

  • /workspace, an overview of all loaded repositories
  • /workspace/[repo@location]/pipelines, all pipelines in a repo
  • /workspace/[repo@location]/solids, all solids in a repo
  • /workspace/[repo@location]/schedules, all schedules in a repo
  • /workspace/pipelines/[pipeline_name], either a redirect page (if only one matching pipeline name found across repos) or a disambiguation page with all matches displayed

These pages aren't currently linked anywhere in Dagit. There are several more disambiguation pages to create (solids, schedules) and I expect that it would probably be good to have a page with all partition sets for a given repo.

Screenshots and overall plan below.

Test Plan

View all pages above, verify proper rendering and behavior.

Diff Detail

Repository
R1 dagster
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Overall plan: https://elementl.quip.com/9OEPA1LhQNH8/Dagit-Namespacing-and-URLs

Workspace overview:

Pipelines for repo:

Solids for repo:

Schedules for repo:

dish requested review of this revision.Oct 19 2020, 10:04 PM

Overall this makes sense to me!

Took a stab at renaming the default repository location name in https://dagster.phacility.com/D4827 - so that would make the example in your screenshot toys_repository@toys_repository_location instead. More verbose but maybe clearer? We could also have the name actually include the file or module, but that gets really long really quickly.

I'm a little bit worried that the whole concept of a repo location isn't necc. clear to users right now though, especially when they only have a single repository in each location

js_modules/dagit/src/workspace/RepositorySchedulesList.tsx
83โ€“96

we'll want this to include the ability to turn them on/off as well at some point too (assuming that's not there currently)

Just added a couple nits, overall I think this is a huge improvement and we can incrementally improve the UI of each page as we collect feedback.

js_modules/dagit/src/workspace/RepositorySchedulesList.tsx
113

I like having this helper in place ๐Ÿ‘

js_modules/dagit/src/workspace/RepositorySolidsList.tsx
42

Might want to rm this!

js_modules/dagit/src/workspace/repoAddressFromPath.ts
3

Is the thinking that this is better than creating a single "pathHelpers.ts" with all the exports? I don't think I have a preference but I haven't seen this pattern before.

This revision is now accepted and ready to land.Oct 20 2020, 6:03 PM

I'm a little bit worried that the whole concept of a repo location isn't necc. clear to users right now though, especially when they only have a single repository in each location

Interesting -- I wonder if we could point at some docs from e.g. /workspace?

js_modules/dagit/src/workspace/RepositorySchedulesList.tsx
83โ€“96

Thanks -- I did not include that here but can add it in a followup.

js_modules/dagit/src/workspace/RepositorySolidsList.tsx
42

This is like the fourth time this has happened to me (this and debugger) in the last few weeks. I think I'm gonna put a hard lint rule on the build...

js_modules/dagit/src/workspace/repoAddressFromPath.ts
3

We could do that -- I'll keep it in mind as we add more of these. I think utility-bag modules can get a little unwieldy, but it's not a strong opinion.

dish retitled this revision from RFC: [dagit] Start adding Workspace routes to [dagit] Create workspace routes.Oct 20 2020, 7:09 PM
This revision was automatically updated to reflect the committed changes.