UIIN-2095 - Getting issue details... STATUS
Description
- Implementation sometimes conflicts with Inventory search requirements/implementation
- Development due to these conflicts makes Browse implementation painful with numerous defects
- 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:
- move Search and Browse common logic to separate utilities and constants
- 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 - split manifest logic into Search and Browse
- 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