Handling DOMStateStorage failures

[mjackson]

Currently, we just warn when calls to DOMStateStorage's saveState and readState fail. However, warnings don't really seem right here since the app will be broken.

One idea I had is that we could possibly fallback to using window.name for session storage instead of window.sessionStorage. The main limitations here would be:

• possible conflicts with other libraries using window.name. This is highly unlikely since window.name is a really obscure API, but we'll definitely want to put a caveat in the docs so people at least know about it.
• size. It looks like we're limited to 2MB.

Thoughts?

Edit: This is a follow-up to #120

[kentcdodds]

FWIW (probably not much), the angular project uses window.name as a place to store some debugging related state (defer bootstrap and debug info).

[mjackson]

Whoa, great catch @kentcdodds. Thanks for pointing that out. Can you help me understand how people use that? Is it mainly for dev?

[kentcdodds]

Pretty much soley for dev

[kentcdodds]

Basically, for perf, angular has the ability to disable dev related info. Useful for production deploys. But when you need to debug a production app, having that debug info is helpful. But you need a full page refresh to turn it on. So to store state across the page reload, angular uses window.name.

[mjackson]

Gonna close this until one of us finds time to work on it.