Uploaded image for project: 'Stripes'
  1. Stripes
  2. STRIPES-589

Quest: Route-based architecture in modules



    • Story
    • Status: Closed (View Workflow)
    • P3
    • Resolution: Done
    • None
    • None
    • None
    • None
    • Stripes Force



      React Router v4 is built on the concept of "dynamic routing": https://reacttraining.com/react-router/core/guides/philosophy

      Dynamic routing provides a lot more flexibility than "static" routing, but can easily lead to traps where data fetching and URL management can happen at any point in the component tree.

      Scattered <Switch>/<Route> components lead to:

      • more server requests, since data fetching can happen at any point; instead we'd like to batch them up with formats that can describe relationships like JSON API or GraphQL
      • URL state management conflicts; what happens when more than one component wants to mutate query params?
      • a lack of flexibility; FOLIO modules attempting to use components with <Switch>/{{<Route>}}s from a central library are locked into to the URL structure defined there, meaning they often have to just eject from the shared components
      • focus accessibility issues; modules need the ability to control focus in appropriate ways for assistive technologies


      Instead we want FOLIO UI modules to be composed of sharply defined route container components. It's much closer in approach to static routing.

      UI modules would 100% own their own routing. Routing is glue code - it creates bonds between atomic components. When we try to share a molecule like <SearchAndSort>, it becomes nearly impossible to bond to other structures or make adjustments to the composition. It's much easier to construct a variety of complex structures out of simpler atoms. Like routing, focus management, global state, and data layer connections are also glue code. We shouldn't consider glue code to be reusable.

      Current state

      • UI modules have components. Some are purely presentational, and some are container components that connect to the data layer.
      • stripes-smart-components provide shared container components with glue code like routing and data layer connections.

      Desired state

      • Every UI module has a src/routes directory that contains all of the URL-linked container components needed for the module. None of a module's components outside of this directory are aware of any global state management (like redux), data layer / server communication (like stripes-connect), or routing (react-router). All components outside of src/routes receive data through props and pass back up actions to the routes. Data down, actions up.
      • stripes-smart-components no longer exist: purely presentational stripes-components provide all the needed atoms without any glue code: https://issues.folio.org/browse/STCOM-298

      Rules for routing-based architecture

      <Switch> and <Route> are only used in src/index.js of FOLIO UI modules.

      • <Switch> and <Route> do not appear in any shared component library.
      • <Switch> and <Route> do not appear in any presentational view components in UI modules.
      • <Switch> and <Route> do also appear in stripes-core, simply to direct to the appropriate UI module.

      Only route components found in src/routes communicate with the data layer or server.

      • Only route components are container components.
      • All other components are essentially agnostic of the data layer used by a module.
      • No components outside of src/routes use redux connect() - they aren't container components.

      The shared component library is free of glue code.

      • The concerns are separated: state management, data layer, routing configuration, etc. are all handled by modules themselves.


      TestRail: Results


          Issue Links



                Unassigned Unassigned
                cherewaty Jeffrey Cherewaty
                0 Vote for this issue
                5 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases