Spike: UIIN-2095 Define approach to update Browse implementation for scalability

UIIN-2095 - Getting issue details... STATUS

Description

1. Implementation sometimes conflicts with Inventory search requirements/implementation
2. Development due to these conflicts makes Browse implementation painful with numerous defects
3. Challenges will be even greater as we implement additional Browse options

Goal

Propose an approach to update Inventory Search and Browse implementation that will support a more streamline implementation, scalability, and performant.

Spike results

There are two ways to separate Search and Browse: keep both in Inventory app and implement a toggle to switch between the two, and create a separate Inventory Browse module.

But before we go into that it will be useful first to get an overview of current implementation to see how the code is structured.

Current implementation

The main bulk of code is located in <InstacesList> component: https://github.com/folio-org/ui-inventory/blob/master/src/components/InstancesList/InstancesList.js

It encapsulates all of the logic and functionality that is on the Search and Browse pages (apart from some logic in manifest utils) and is more than 1100 lines long, which is way too much for a single React component. So we need to split this one huge component into smaller components/hooks.

To help get an idea of what code is common between Search and Browse, and what is specific to each of the search modes a very rough split of <InstancesList> component into two <SearchView> and <BrowseView> components was done and compared:

https://www.diffchecker.com/u39wC3iH

In the above link the left document is the Browse implementation with red code blocks are browse-specific code, and the document on the right is the Search implementation with green code blocks being search-specific code. Code that is neither red nor green is the common code between the Search and Browse implementations.

The resulting implementation will roughly consist of the red and green blocks separated into two separate components, and a third component will contain common code. I'd also suggest to implement them as functional components and use hooks to further separate business logic and presentation.

The two approaches

1. Toggle between Search and Browse

PPT slide deck that outlines proposed UI changes:

https://docs.google.com/presentation/d/1PSJyA9g9j1xmDpH8JymdLyxqeXxfoLZX23VZ-1dsx0w/edit#slide=id.p

Steps to implement:

1. move Search and Browse common logic to separate utilities and constants
2. create separate Search and Browse routes and move code from <InstancesList> into each of the routes
   To Search:
   * Creating a new instance (do we need this in Browse?)
   * In transit item report
   * Export instances in MARC
   * CQL query report
   * Fast add (do we need this in Browse?)
   * Save holdings UUIDs
   * Selecting instances
   To Browse:
   * onSelectRow logic to redirect to search
   * missed match item
   * Prev/Next navigation
3. split manifest logic into Search and Browse
4. Add Jest/RTL tests and refactor to use functional components with hooks

High level estimate: 15 days

Advantages:

• doesn't require a third module to hold common code, so fewer module to juggle when re-implementing
• one application is responsible for one domain

Disadvantages:

• code can't be exported for other modules (Charlotte Whitt mentioned would be nice for Inventory and Instance lookup plugin to use same code and a third module would help with that)

2. Separate Inventory Search and Inventory Browse apps

Steps to implement are pretty much the same, but we'll need a third module to hold common code.

Also, there will be much more code that will get moved to this third module - things like filter components and facets logic, DataContext (also things like export, in transit items etc that is in Actions menu if it's needed for Browse too) 

High level estimate: 20-30 days

Advantages:

• will have more separation of Search and Browse
• moving all this code to a third module will make it available to Instance lookup plugin

Disadvantages:

• much more code to move will require more development and testing effort
• arguably, two apps responsible for one domain seems more complicated