Log4brains logo

Dedicated routes for sub-resources (drawers,modals etc..)

Sep 23, 2022

DRAFT

[all]

Context and Problem Statement

  • We want to have dedicated routes for managing sub-resources
  • In some cases the sub-resource UI is just on top of the main resource UI (e.g drawer, modal, etc...), in these cases we want to seamlessly reuse the main resource UI and implicit state
  • How can we achieve this?

Decision Drivers

  • parent ui reusability
  • easy data flow to the resource part
  • straightforward routing
  • scalability

Considered Options

  • nested routes using outlets
  • nested routes within the main resource page
  • separate routes

Decision Outcome

Chosen option: nested routes within main resource page, because it allows us to easily pass down props to the nested routes, while at the same time allowing us to reuse the parent UI and state

Positive Consequences

  • We allow for resource part to have its dedicated route, resulting in clear separation and shareability of url

Negative Consequences

  • Routing might not be obvious to oversee as it's a bit scattered between the components
  • There is more work to be done as opposed to keeping drawer state locally/query param

Pros and Cons of the Options

Nested routes using outlets

Parent is only responsible for rendering an Outlet component, the Outlet will render the matching child component, or none if its exact match on the parent, the outlet is a bit limiting in cases where we need to pass data to it

  • Good, because it allows us to have the routing in one central place consisting only of Route components
  • Bad, because it is a bit harder to understand
  • Bad, because the Outlets do not support checked props and instead we need to rely on outletContext which is harder to track
  • Bad, because the outlet context is shared between all the child routes, which may result in mess as we add many child routes

Nested routes declared in the parent page

Parent route matches on a wildcard, renders its main ui and declares a element which might render a child component if there is a match.

  • Good, because we have full control over the rendering of the child routes as a simple react component
  • Good, because the data flow to the child is easy and controlled
  • Good, because it's easier to understand and follow
  • Bad, because the routes are scattered, resulting in a bit worse overview of the routing situation

Separate routes

  • Good, because its completely separate
  • Bad, because data sharing is really hard
  • Bad, because UI reusing needs to be done with composition, increases complexity
  • Bad, because it's harder to maintain state in the parent
  • Bad, because all necessary data will need to be fetched again

Guidelines

  • When the data that we have in the main resource UI is enough for the sub resource UI to function, we pass it along via props
  • When the data that we need in the sub resource UI is more detailed than what we have in the main resource UI, we fetch it separately in the sub resource UI, using probably a different query