[Html 5] SharedWorker: examples of use
In Html 5, a whole zoo of “features” has already been bred, and, I think, there are already a few people left who know the whole “Html 5” completely. I think less than a percent of you have heard of some kind of “SharedWorker”.
')
This is a kind of session, only on the client. And in addition, not just a session as a repository, but a session as a living process.
You can use them to communicate between tabs of the same site.
Also, I suppose, now a website can be considered up-to-date only if it has a so-called “push”: pushing updates from the server directly into the browser to the client. In order to implement such a push, you need to establish a WebSocket connection on the page. In addition, each tab of your site will create its own connection via WebSocket.
This increases the load on the server, and the connection itself takes some time (in Chrome, about a couple of seconds on Node.js on localhost). We can try to reduce the load by making sure that all the tabs in the client browser use one common WebSocket connection. And these SharedWorkers will help us in this.
The other day, I myself somehow figured out how it all works (which is complicated by the fact that you can’t do such a debugging with a simple alert: it can easily not start if she doesn’t like something, or even swears). To simplify working with this thing, I wrote a library - shared worker.js .
Next to it, you can see a simple example of the implementation of communication between tabs (the example folder) and an example of push implementation (the websocket example folder). In Chrome, all examples run only from under the web server; just opening them from the hard disk will not work (such a flaw in Chrome; ayaks to local files in Chrome will not work either). The example with websockets requires the execution of the
Works in Chrome and Opera. Does not work in FireFox. More details .
When I tried to google this topic, nothing was found. I didn’t find any normal examples either ( the only one that was found , to put it mildly, dirty, and there is not a word about "Inclusion" without which you can’t write a real application - just an academic example). Now, seekers can find this in google.
Navigation on the site in this case will need to write on ajax'e (for example, as done by Vkontakte), because if you, for example, open the tab with the site, and in it you simply go to another page of the same site via a normal link, then the current SharedWorker is destroyed and a new one is created. This is logical: when you go to a new Url, even on the same site, you first destroy the page from which you are moving, and only then the page to which you are going is created.
In the current Api SharedWorkers, there is a “connect” event, but there is no “disconnect” event, and therefore the “peers” array in the “shared worker.js” library cannot clean itself out of closed tabs — it will continue to consider them open. This will not lead to any errors, it is just a flaw in the current Api SharedWorkers.
What is it?
')
This is a kind of session, only on the client. And in addition, not just a session as a repository, but a session as a living process.
Why this may be needed?
You can use them to communicate between tabs of the same site.
Also, I suppose, now a website can be considered up-to-date only if it has a so-called “push”: pushing updates from the server directly into the browser to the client. In order to implement such a push, you need to establish a WebSocket connection on the page. In addition, each tab of your site will create its own connection via WebSocket.
This increases the load on the server, and the connection itself takes some time (in Chrome, about a couple of seconds on Node.js on localhost). We can try to reduce the load by making sure that all the tabs in the client browser use one common WebSocket connection. And these SharedWorkers will help us in this.
How it works?
The other day, I myself somehow figured out how it all works (which is complicated by the fact that you can’t do such a debugging with a simple alert: it can easily not start if she doesn’t like something, or even swears). To simplify working with this thing, I wrote a library - shared worker.js .
Next to it, you can see a simple example of the implementation of communication between tabs (the example folder) and an example of push implementation (the websocket example folder). In Chrome, all examples run only from under the web server; just opening them from the hard disk will not work (such a flaw in Chrome; ayaks to local files in Chrome will not work either). The example with websockets requires the execution of the
npm install ws and node server.js .Where does it work?
Works in Chrome and Opera. Does not work in FireFox. More details .
So little?
When I tried to google this topic, nothing was found. I didn’t find any normal examples either ( the only one that was found , to put it mildly, dirty, and there is not a word about "Inclusion" without which you can’t write a real application - just an academic example). Now, seekers can find this in google.
More about links
Navigation on the site in this case will need to write on ajax'e (for example, as done by Vkontakte), because if you, for example, open the tab with the site, and in it you simply go to another page of the same site via a normal link, then the current SharedWorker is destroyed and a new one is created. This is logical: when you go to a new Url, even on the same site, you first destroy the page from which you are moving, and only then the page to which you are going is created.
Disadvantages of api
In the current Api SharedWorkers, there is a “connect” event, but there is no “disconnect” event, and therefore the “peers” array in the “shared worker.js” library cannot clean itself out of closed tabs — it will continue to consider them open. This will not lead to any errors, it is just a flaw in the current Api SharedWorkers.
Source: https://habr.com/ru/post/154639/
All Articles