Hatch *LocalItem API should generally be avoided

[Bill Erickson]

Evergreen 2.11

There are many uses of egCore.hatch.getLocalItem(), setLocalItem(), and removeLocalItem() in the browser client code. With the exception of the Hatch admin UI, these should all be replaced with getItem(), setItem(), and removeItem() calls.

LocalItem calls force data to live in the browser's localStorage, bypassing the Hatch configuration. The only keys that have to be stored in localStorage are the Hatch keys themselves, eg.hatch.*.

This does not affect sessionStorage items or cookies.

Files that use *LocalItem calls that probably should not, as of today.

cat/bucket/copy/app.js
cat/catalog/app.js
cat/item/app.js
cat/services/z3950.js
cat/z3950/app.js
circ/services/holds.js
services/grid.js
services/navbar.js
services/ui.js

Note that hatch.getLocalItem() is synchronous, while hatch.getItem() is asynchronous (promise-based). Existing getLocalItem() calls will need to be rearranged to handle the promises.

[Bill Erickson (berick)]

One thing to consider is data shared with embedded Dojo interfaces. These UIs have access to the browser's local/session storage, but not to Hatch. In those cases, for now anyway, we have to use the *LocalItem APIs.

[Bill Erickson (berick)]

Marking this as WON'T FIX since we are addressing these as UI's are migrated to Angular.