Skip to end of metadata
Go to start of metadata

UIIN-2095 - Getting issue details... STATUS


  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


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:

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:

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:

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


  • 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


  • 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


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


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


  1. Michal Kuklis and John Coburn,  any thoughts on Denys' analysis? I like to get this done in Nolana... if possible. 

  2. Denys Bohdan thank you for putting this together. It looks great. I think I'm fine with either approach, but I prefer the second option even if it takes longer. The main reason is the UX. The inventory is already pretty complex and the browse adds another layer to it. 

    Do we know if all institutions will want the Browse option? Having two separate apps allows us for better control (by turning it on and off for a given tenant).

    The code could be more maintainable too. Inventory already has a lot of baggage and old code and will eventually need a bigger rewrite, so keeping it smaller has an advantage too. 

    This is just my subjective opinion and I think either option will be better to what we have there now.

    1. The code could be more maintainable too. Inventory already has a lot of baggage and old code and will eventually need a bigger rewrite, so keeping it smaller has an advantage too. 

      I think it's important to acknowledge that this would be a technical reason to motivate the split, rather than a product one.

  3. Hey Michal Kuklis. To answer your question about UX. 

    1. Yes, highly requested and expected by institutions. The implementation was discussed with the MM SIG and several FOLIO implementers. The availability via Inventory is also expected too. It is seen as another way to view instance records. 
    2. We also implemented a similar pattern with MARC authority app. The app allows a user to view results by browse or search. 
    1. The availability via Inventory is also expected too.

      Does that mean it should be part of the inventory app or easy to access (via links) from the inventory app?