Comment 14 for bug 1806087

Gave this some testing time, and overall, it looks and works very well. Given that it is "experimental", I have pushed it to master to make feature cutoff, but I think it needs at least a couple fix-ups. To avoid possible coordination issues at this stage, I am leaving the bug open to possibly handle things here, at least through 3.3.0. Here are a few issues:

1) If the user has a "default" tab which is not implemented in the new interface, e.g. "Holdings View", the back button is broken due to the auto-forward. A simple solution would be to perhaps land on the tab with a "This interface is not yet implemented" note plus a manual link for jumping to the old interface. Thoughts?

2) Similar issue for the "edit" link on copies. You land on an Item Details page, then immediately bounce to a volume editor. This again breaks the back button. One solution might be to open this in a new tab similar to other interfaces, but avoiding the "bounce" would be even better.

3) The browse code has been duplicated for expediency, but we should look for ways to reduce or eliminate this duplication before letting this sit too long (and potentially drifting apart). There is hope for driving some of the EGCatloader code through this new Search service code as a shared back end.

All these issues aside, this seems like a great step forward. Thanks, Bill and Kyle!

Finally, I know there are concerns about how this might add an extra burden for supporting both the TPAC and this new interface. Overall, I feel like the benefits of a proper Angular catalog for the staff client are undeniable, so in some ways the real question is not whether we should add an Angular catalog, but whether the needs for a mostly-JS-free OPAC are still strong enough to keep TPAC as our primary public face.

Sincerely,
Dan