4

I need to continuously update/refresh my page to ensure that it is in sync with my server. Currently, I am using setInterval, but I read that serviceWorkers might solve my problem in a better way. Is it recommended to use serviceWorkers? (the background-sync seems like a good starting point.)

Or are there any other alternatives?

Ronan Boiteau
  • 9,608
  • 6
  • 34
  • 56
raksheetbhat
  • 850
  • 2
  • 11
  • 25
  • Ask yourself: How often you need new data? How is your data behaving, how fast is new data coming? How much new data per reload. How long does rendering of new data take? Depending on answers you might have to handle DOM cleanup, custom rendering to prevent constant rerender, grouping of data changes on back-end over a course of some time period etc.. Example, you have a graph that takes 0.5 sec to render but you get data updates 200 times per second. Even if you only render new data, browser will eat up resources and become sluggish over time as DOM elements explode. – DanteTheSmith Aug 07 '20 at 10:41

4 Answers4

4

After some research, WebSockets seem like the best bet to have a live refresh on a website. Websockets helps maintain an open two-way connection between the website and the server so that whenever there is an update on the server, the server can push the changes on to the website.

raksheetbhat
  • 850
  • 2
  • 11
  • 25
  • I agree with some notes: If continuously is used loosely and one actually needs refresh every 30 seconds or more there is no need to use sockets, simple interval will do. Also, if your data is constantly updating (mine is updating up to several thousands per second, not all at once) this will put your page in constant reloading state unless you handle rendering in a way that only adds new content, not reloads the old one. Then you also need a way to remove old content so you avoid DOM explosion. – DanteTheSmith Aug 07 '20 at 10:37
1

This assume to have to change many logic in your SPA and API but you can use the WebSocket protocol instead of HTTP/HTTPS.

Just have to send a notification to your React app with wss for fetch the data with your classical way in async http/https, you can store the data with Redux/Flux and it will refresh the components automatically.

  • Yes, you're right. WebSocket seems like the way to go forward. Thanks. – raksheetbhat Jan 03 '18 at 10:28
  • You have mentioned use WebSocket instead of HTTP/HTTPS. However, according to this docs, WebSocket is compatible with HTTP(S): https://docs.oracle.com/javaee/7/tutorial/websocket001.htm – raksheetbhat Jan 03 '18 at 10:29
  • Yes I misspoke about WebSocket instead of HTTP/HTTPS. It's compatible to use them both, you haven't to choose one of them, it's just not the same protocol. – Benoit Chassignol Jan 03 '18 at 10:55
  • I agree. So the handshake protocol of WebSockets is compatible with HTTP, but once the connection is established, it follows the TCP/IP protocol. – raksheetbhat Jan 03 '18 at 11:02
0

No. setInterval is the way to go.

A ServiceWorker is used to cache the contents of your application for offline use (The browser will download the site as it is defined in the serviceworker and you can use some functionality offline). However, you are not able to contact your server, since this needs internet access.

Here comes background-sync into the game. Let's imagine you have something like a chat application (web-based). You view the app the first time and in the background, all files are downloaded. After that, you are able to view the page offline and read messages which you already received. In the first place you cannot send messages, because that would need contact to the server. But with background-sync, you can schedule it for a send when the user is online the next time - so write your message only and hit send, it gets saved and will be pushed to the server the next time you connect to the internet.

I think you are accessing your server's data trough an API, and therefore neither the serviceworker, nor background-sync are used for these tasks.

Just send your server a request and update the data in the react app, as you do it right now using setInterval.

Larce
  • 841
  • 8
  • 17
0

I have a similar challenge, and I plan to try https://www.npmjs.com/package/react-refetch. My application isn't complex enough to need redux, so I'd rather avoid that.

fahrradler
  • 141
  • 1
  • 2
  • 9