With 930 facilities in the database, when trying to enter Edit User page, "Aw, Snap!" error shows up on Chrome.
It seems to work on Firefox, but the page dims and takes a lot of time to load.
Facility endpoint should return minimalistic representation (name & UUID is all that should be required) - find a best option for this (request param, separate endpoint?)
Attach performance numbers when ticket is finished (compare payload size before and after)
I'd like to discuss this issue, as I'm not 100% sure where we want to start optimizing. The root of the problem is that we shouldn't be loading all the facility objects at once, so the solution is to update the UI.
I'd like to find other similar issues, and find a generalizable solution. My gut says the solution is to make the select element load data on-demand, meaning when a user clicks "select facility" we will use the paginated facilities API.
There is already a ticket that "should" solve this issue. The ticket talks about making an endpoint that just returns Facility Names and UUIDs (instead of these larger items)
mentioned this ticket and will find and link the tickets so this ticket can be checked afterwards
Per discussion with Nick and Mary Jo, we are optimistic this will be fixed by (in progress already).
When that ticket is done, then we can re-test this to see if we still have an "Aw Snap" error.
The screen no longer hangs and the list of facilities contains only names and UUIDs.
I've checked the performance statistics and before request response had 72.8KB and it took 2.45s on good 3G internet.
Now request response has 28KB and it takes 1.34s on good 3G internet.
It was tested on Chrome browser using throttling and on 1006 facilities from our demo data.