Uploaded image for project: 'FOLIO'
  1. FOLIO
  2. FOLIO-1694

RFC Routing Refactor



    • Template:
    • Sprint:
      stripes-force Sprint 55, stripes-force Sprint 57, stripes-force Sprint 58, stripes-force Sprint 59
    • Development Team:
      Core: Platform


      This JIRA is meant to sum up the different aspects of the routing/url issue that FOLIO faces in order to create a big picture view so that we can choose and describe work to move us to the best path in an iterative way.

      Browser location/history management.

      The current pattern typical among core modules is to update the Store via mutator.query.update which, eventually syncs up the url via `history.push` - the problem here is that if the history is updated again through other means (browser back button, subsequent call to history.push) the store is now out of sync, which could cause expected updates to no longer happen and break UI functionality (STCOM-302).

      mutator.query does provide nice things such as a graceful API in case only a portion of the query parameters need to be updated, but this case should be reduced to a minimum if we're able to rely on the location's path as opposed to query parameters for portions of user workflow that extend beyond the initial record search/preview.

      Ideally, there's a unidirectional flow between the browser location and state/store of the system, where the location is updated via a link or call to history API and the client state/store/rendering are updated accordingly.
      React-router can do the heavy lifting here, where components and their according state updates can be rendered through <Route> components.

      Routing re-structure to ui-module code

      Currently, routing is handled in a multitude of ways throughout modules-

      • through query parameters (edit Layers)
      • Routes that are rendered within consumed smart-components.

      Once something changes in the data layer or Routing layer, big refactors will need to take place here and the abstractions that render Routes may be incompatible.

      Proposed solution to this: Routing and data layer should live at the top level of ui-modules.
      A module can set up a Switch of Routes that each represent an independant portion of the UI that connects to a data source and *excludes * rendering of workflows that are not currently visible to the user.

      Data from these connected containers are passed as props into presentational 'view' components, and few things below this view are 'connected' to a data source.
      Additional guidance for this approach is available in STRIPES-589

      URL Structure

      URL's should contain very little of the current state of the component outside of those necessary for React-Router to render the appropriate view. Need to resolve/document sane usage of query params.

      Remove Routing in smart-components

      Smart components can function as containers, but should be rendered within separate routes within the modules, but should not supply routes themselves. These will have to be refactored and modules will have to eject from them. For the most part, non-routing code will be split among sub-smart-components which can then be imported by modules, leaving non-rigid use-cases that perform only the heavy-lifting required. As these container components are broken out, The modular pieces can be put to use within their larger molecules - these can still be used in modules for short-term legacy support, but as routing moves to the modules, these molecules will go away as well...


      Need a way to handle routing for these- these may exist as sidecars to detail views. They lean on URL structure.

      Inter-module navigation (back-links, close buttons, edit buttons, etc)

      Without manipulating history directly, ui-modules may need to pass appropriate navigational props to 'view' components. These would consist of url's to place as 'href' or 'to'. Some cases where intra-module navigation occur may require some way to hide conditionally hide 'back' links.

      Nested routes

      Spike-worthy approach to see if we should employ a nested route solution. May need to build/provide something like eholdings' Route component: https://github.com/folio-org/ui-eholdings/blob/master/src/router.js

      Routing/query on plugins

      Plugins will need further adjustment to work with module routing.

        TestRail: Results


            Issue Links



                JohnC John Coburn
                JohnC John Coburn
                0 Vote for this issue
                4 Start watching this issue



                    TestRail: Runs

                      TestRail: Cases