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

Alternatives for communication for broader support #38

Open
kayvanbree opened this issue Nov 2, 2018 · 5 comments
Open

Alternatives for communication for broader support #38

kayvanbree opened this issue Nov 2, 2018 · 5 comments

Comments

@kayvanbree
Copy link
Contributor

I've read something about other techniques to do cross-window communication. Something like this. Using a method like that would eliminate the need for polling, theoretically making the communication quicker. I have never used it though. Also, I don't know about browser support and I think 3/4 of the library would have to be rewritten.

This person had the same problem and they recommend using a BroadcastChannel. It's a simple API:

// Setup
var bc = new BroadcastChannel('test_channel');

// Broadcasting
bc.postMessage('This is a test message.');

// Receiving
bc.onmessage = function (ev) { console.log(ev); }

// Closing connection 
bc.close()

Problem is, Edge doesn't support it yet, so it's of no use for this issue. I did find a polyfill that could maybe work. It uses local storage though, so I don't know if that will work.

[edit] There's another BroadcastChannel 'polyfill' right here. This one chooses the best mode of communication based on the browser it's running on. Works on Edge, FireFox, Chrome, Opera, but it doesn't seem to work on IE11 (which I would abandon altogether). Maybe this would be a better method than pure localStorage? It's pretty damn quick.

@kayvanbree
Copy link
Contributor Author

@Nolanus Just copied this into a new issue. I don't know if it's necessary to do this, if Edge and IE11 indeed work.

@Nolanus
Copy link
Owner

Nolanus commented Nov 2, 2018

Hi,

thanks for the suggestions.
The main problem I see with the window.postMessage implementation is the need to have a reference to the other window. This requires new windows to be opened via JavaScript to get the reference, as regular a-tag links or manually opened tabs/window wont be detected.

However, the BroadcastChannel looks promising and could reduce this libraries size and complexity. I'll keep this ticket open for future research and checks when the number of supported browsers increases (namely Edge and Safari).

@kayvanbree
Copy link
Contributor Author

I think using the BroadcastChannel might be a lot faster too, since you don't need to poll anymore.

@simoneP93
Copy link

Hi,

i really like this library and i would really love it implemented with the Broadcast Channel API. Do you have any progress?

Thanks much.

@kayvanbree
Copy link
Contributor Author

@simoneP93 I don't think anyone did anything concrete for this. At this moment, my use case doesn't really need it, so I won't get any time to work on it at my work. If you'd like you could try it and create a PR.

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

3 participants