Comment 15 for bug 1821094

Thanks for the helpful feedback, Galen.

I've rebased my branch (user/sandbergja/lp1821094_item_status_reload_performance) and included Kyle's signoff (thanks, Kyle!) I also added a second commit that adds a new factory to the AngularJS client that provides a middle road. It divides an array of, say, pcrud calls into batches. Within a batch, all those calls will run simultaneously. The batches themselves, though, are chained sequentially -- batches wait for the previous batch to complete before starting their own work.

My idea was that it could be a stand-in for $q.all() in simple use cases throughout the AngularJS client, so I've called it egBatchPromises.all().

Switching the item status refresh from $q.all() to egBatchPromises.all() seems to provide a very similar experience to the user. I threw in a few unit tests for certain pieces of the new code, but not all of it. I checked osrfsys.log to verify that OpenSRF is receiving those pcrud calls in batches of 10. All that to say, I've done some testing, but not enough! I'd really appreciate further testing from those more familiar with backend performance testing and writing unit tests for asynchronous code. :-)