Refactoring the book manager frontend to resolve unresponsive page
Context
While investigating the client side performance issues on the book manager (the investigation triggered by the permissions issue #1471 (closed) ), I ran the experiment of turning the permissions off completely to see what difference that would make. That led to me noticing that the client side cannot handle very large amounts of data, becoming completely unresponsive.
I tried to isolate the issue outside of the app (in storybook) to make sure that none of this was related to the backend, or the permissions layer, or any other kind of client side calculations that are triggered by the server data arriving. The idea was to try to render 9000 book components. The result is that it took around a minute to render those components (without taking into account the time it would take for the server to respond) .It does work fine if I render the simplest of components (think of the list rendered on Bookshelf that has links only), but when we add more UI elements, drag and drop etc it becomes quite taxing on the browser.
The main takeaway here is that we should not be rendering thousands of components at once, as this is too big a load for a browser tab to process all at once.
Proposal
The proposed plan of action here is this:
- Rewrite the tree (ie. the nested chapter list) to make it lighter and more performant
- Start with all parts collapsed (as we’ve already agreed) and only make the call to the server to grab what’s nested when the user clicks on the expand icon
- Remove the possibility of an expand all button. If we get the data for each nested part only when explicitly requested, we’ll end up with potentially dozens (or even hundreds) of requests firing on the server. We’ll also end up with a potentially huge list to render at once again. We can maybe revisit this point once all this is done.
- Refactor to delegate a lot of the heavy lifting that the client currently does to the server
I have tried an experiment with a newly-implemented tree of 100 parts with 600 nested chapters each and the UI seemed to work fine in isolation. But some of the work will also come down to reducing the amount of calculations on events such as selections, disabling buttons etc.
Design
Design remains the same, with some improvements
Acceptance criteria
-
A large list of 100 parts (parent and child parts) with 600 nested chapters inside each part should open within a few seconds after receiving the data from the server and should be responsive to users actions - example micad
in Bookshelf repository and by all supported BCMS MVP users in their native environments
Definition of ready
-
BCMS User Story / Context has been well defined -
The priority of the user story is specified and agreed -
Digital assets added (design, database scheme, mockups etc if relevant) -
Coko Technical Proposal approved by NCBI -
Testable Acceptance Criteria approved by NCBI -
Estimate of effort to complete (time or points) -
The issue has been broken down into development tasks (if necessary) -
Requirements Clarified -
The product owner and development team agree that the user story is ready for development -
NCBI adds “Dev_Ready”
Definition of done
-
All coding tasks are finished and implemented by Coko -
All unit / end-to-end tests are written and implemented Coko -
QA approved by Coko -
Deployed and tested on “ncbidev” (by Coko team) -
Deployed and tested on “ncbi” (by NCBI team) -
Deployed and tested by NCBI in NCBI environment (required to test micad
-
NCBI confirms Acceptance Criteria Met
Implementation
Alternative approaches (if applicable)
Scheduling
-
Milestone is linked -
Iteration is linked -
Dependencies: ("None" or list issue numbers if relevant) -
Development estimate is added to issue time tracking (120 hours: 80 on frontend and 40 on backend)