Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the way notSupported works #15

Open
tejacques opened this issue Mar 14, 2015 · 4 comments
Open

Change the way notSupported works #15

tejacques opened this issue Mar 14, 2015 · 4 comments
Assignees
Milestone

Comments

@tejacques
Copy link
Owner

If crosstab.notSupported is true, crosstab should work by only handling events processed on it's own tab, and always believing that it is the master tab, and that it is the only tab. This way, logic doesn't need to be duplicated, you can always rely on the events firing from within a tab. This will also allow crosstab to be used on mobile without issue, it basically just acts as a fancy event emitter.

@tejacques tejacques added this to the Version 0.3.0 milestone Apr 3, 2015
@tejacques tejacques self-assigned this Apr 7, 2015
@jay-w-opus
Copy link

getLocalStorageRaw(util.keys.FROZEN_TAB_ENVIRONMENT) returns object that indicates a frozen tab environment, however, when I delete all related info in the localstorage and reload the page, the library works as fine. This shows a fail-fast design without recovery. This is expected?

@tejacques
Copy link
Owner Author

There is not currently a recovery attempt. The idea is if you're on a device that can't actually talk between tabs (like a mobile device), it should fail fast in subsequent attempts so there isn't additional latency spent waiting for a response that will not come.

It wouldn't be too difficult to add a check that the data in localStorage under that key is "fresh", like within either minutes or hours, but the original intent was that if it ever failed to setup correctly, something is wrong or unacceptable with the ability to communicate via localStorage across tabs, and therefore it shouldn't be used.

The library is still pre-1.0 so any ideas and suggestions are welcome.

@jay-w-opus
Copy link

The situation(recoverable) I found just break the original design intent. Therefore I feel it is necessary to allow a recovery attempt some time after the last "FROZEN" situation was verified.
Alternatively, what was mentioned in this ticket could also work. It will change the design of the library to be "best effort and not guaranteed". For my use case(detect crosstab logout and make proper page redirect), I really won't handle the frozenEnvironment exception besides logging it.

@tejacques
Copy link
Owner Author

In v0.3.0 there is a 10-minute timeout period on these, as well as treating the tab as a local-only master instance when it is not supported (so essentially an event emitter, but with some extra functionality).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants