# Proposed URL schema for SideTree navigation Here are some URLs we can use to help users locate entities and their views (dashboard, edit, etc.) when they make selections in the SideTree component. - /measure - works the same way it does now, an unexpanded program tree with an empty view to the right until you select a program - /measure/programs/new - the form to create a new program - /measure/programs/:id - works just like selecting a program from the tree. shows tabs, dashboard tab panel shown by default - /measure/programs/:id/dashboard - an alias for the above route. - /measure/programs/:id/edit - the current edit form for a selected program. - /measure/programs/:id/history - the history view for a selected program. If we take the above and extrapolate it to the lower levels we can take this approach preserving the hierarchy of information in the url structure: - /measure/programs/:id/buildings/new - /measure/programs/:id/buildings/:id - /measure/programs/:id/buildings/:id/dashboard - /measure/programs/:id/buildings/:id/edit - /measure/programs/:id/buildings/:id/history - /measure/programs/:id/buildings/:id/meters/new - /measure/programs/:id/buildings/:id/meters/:id - /measure/programs/:id/buildings/:id/meters/:id/dashboard - /measure/programs/:id/buildings/:id/meters/:id/edit - /measure/programs/:id/buildings/:id/meters/:id/adjustments - /measure/programs/:id/buildings/:id/meters/:id/history And assuming we still have bill accessible via the sidetree for now, their routes would be what you would expect: - /measure/programs/:id/buildings/:id/meters/:id/bills/new - /measure/programs/:id/buildings/:id/meters/:id/bills/:id - /measure/programs/:id/buildings/:id/meters/:id/bills/:id/dashboard - /measure/programs/:id/buildings/:id/meters/:id/bills/:id/edit - /measure/programs/:id/buildings/:id/meters/:id/bills/:id/history this would make the longest route (for bill dashboard) still much less than the [de facto 2000 character limit](https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers). And here's an example of what it would look like (I repeated the same `id` for simplicity) ``` https://unstable.cenergistic.net/measure/programs/9183a001-8947-456f-b09b-fbe131242396/buildings/9183a001-8947-456f-b09b-fbe131242396/meters/9183a001-8947-456f-b09b-fbe131242396/bills/9183a001-8947-456f-b09b-fbe131242396/dashboard ``` Yes that is long, and you have to scroll horizontally in most web browsers and screens to even read the whole thing, BUT it's big strength is that: 1. it could locate the entity's view precisely, loading not the just entity, but the tab panel under that entity. This makes links very shareable within for things like collaboration and troubleshooting. 2. it provides all the ids associated to that entity within the URL, making it easier on the app to fetch the data it needs immediately. If we wanted to try to make this shorter, we could go with something a little more flat like... - /measure - /measure/programs/new - /measure/programs/:id - /measure/programs/:id/dashboard - /measure/programs/:id/edit - /measure/programs/:id/history - /measure/buildings/new - /measure/buildings/:id - /measure/buildings/:id/dashboard - /measure/buildings/:id/edit - /measure/buildings/:id/history - ...and so on The downside of this is that we lose the benefit of #2. Perhaps we could go even more generalized like... - /measure - /measure/entity/new - /measure/entity/:id - /measure/entity/:id/dashboard - /measure/entity/:id/edit - /measure/entity/:id/history But this would complicate things further on the data fetching side as now the app won't know the doctype/entityType of any id for which it's fetching an entity. Personally, I'm in favor of the first approach of making the schema as verbose as possible, so the logic is easy to follow for displaying the right view and users can still share links without fully reading or even understanding the schema. It might also be nice to eventually add some query parameters to the end of the dashboard-specific URLs that reflect the state of filters.