Thank's for sharing. We implemented the feature to show a notification for the user that a new version is available! It works in production pretty nice!
It happened the same to us, we solved it with a custom service worker (with workbox). we do make a network first aproach only with de html because its contians the referencies to the new bundles and new assets (create react app generates new names on every deploy), so, the network first has a timeout in which case we assume that the user does not have a conection so its ok to show the previews version.
Offline navigation is just one of the many things you can do with Service Workers. It really depends on your application. For example, I've made one website that was heavy on images, but the images itself were not super dynamic, they could changed once every month. So we added a cache of 15 days for those images and saw a huge impact on performance and bandwidth consumption. Another thing is when you know some data won't change soon, so you can specifically cache some heavy endpoints, for example loading data that is old and doesn't change much (imagine loading user actions history from an old time). Another way I've use it a lot is to go cache first and then immediately trigger a request in the background to update it. This can make your app look really fast and while you still have the n+1 scenario, users don't need to refresh manually because you already done it. Don't give up on using Service Workers, they are easy to setup as a "all or nothing" kind of thing, but hard to really understand how it can improve your app specifically. But once you know how to take advantage of it only for the things you actually need, they can be great.
I was learning PWA and came to know that it may be fixed by cache versioning. Every time you update the content, the old version of the cache needs to be deleted, and fill the cache with new content.
Dude it's incredible how your content is synchronized with stuff that I need to learn/do. I've started using Gatsby for a static site and Prismic as a CMS for the content creators. The thing is that the project has also a dynamic app with CRA so I'm trying to convince the team to move it on Gatsby as well. And I think that a plugin or two might solve that kind of SW issue.
I also have face issues with service worker in my blog. The service worker was not updating properly. I am using workbox to create service worker, so they should be a feature to automatically purge old caches and install new service worker. And after some debugging I found out that the real culprit was cloudflare CDN which cache my old service worker. So users are not receiving new service workers. Now I purge my old CDN caches when I deployed any new updates and I think it just solve my issues.
And rightly so. If we stop service workers from infecting our system, PWAs are done for too. Good riddance. How do you disable service workers for sites other than your own?
i experienced the same issue, what I did was provided a last modified header and the service worker checked the cached version of the page and compare it to periodic requests to the static file at the server, if the cache is out of date it will remove the old file from the cache and add the new page into the cache, then prompt the user about the new update
I built a web application not so long ago using service workers and haven't had any of this grief. I added a route to the api such as "/version" that doesn't get cached and returns a version string. Every time a user loads a page it loads from the service worker, but an asynchronous js request checks the remote version against the local version. If there's a mismatch, all service workers are unregistered and the page is reloaded automatically. So when users open the app, they always have the latest content, immediately.
Service workers and spa can have a complicated relationship. Although i do believe that when something gives more work than advantages it is time to reconsider it, i think that you 'abandoned' service worker too early. Fortunately service workers are just javascript and their behavior can be changed to our needs. This issue in create-react-app repo gives an interesting strategy to your problem: github.com/facebook/create-react-app/issues/7237 . In practice you could trigger the update whenever you want. You might have to manually call a skipwaiting in certain situations or even a clients.claim().
Service Workers are a great technology, but very misunderstood and misused. Caching static files would be the last thing I would do in a Service Worker, it's dangerous. A good use case is to cache certain API calls using Workbox!
Often there will be a build process with multiple chunks and the index.html will have the references to them. However on update the browser holds to the SW index.html for dear life and therefore it keeps looking for the old build chunks, causing everything to fall apart if your build process has emptied the folder.
With the default package for Service Workers in Angular you can define which strategy you want - freshness (deliver new data) or performance (prefer Cache)
I think one way of doing that is by adding a "v2" or "v3" to your file names every time a file is updated, that's how favicons are updated but I"m not completely sure and cache invalidation is a complex topic on it's own.
I bet if I looked at your service worker's fetch event listener, it would say to simply check the cache and return that file if there is a match. So your users cached the first version they ever got, and it returned that version until the end of time. I did this myself and it was frustrating. But it's not a limitation of service workers, it's because we used service workers without the right caching strategy.
Yeah the users are loading pre cached files from whatever version they first loaded. Pretty sure you can just change the version number for the sw cache name (in the file), so the next time the page is hit the new service worker would create a new pre-cache (your updates) To get it to load from that though you also need to access the activate lifecycle of the sw to delete the previous cache version.
skipWaiting is for activating new version of the service worker script ( sw.js ), maybe just clean the cache on activating . also clients.claim sets this worker as the active worker for all clients that match the workers scope and triggers an oncontrollerchange event for the clients.
First thought when you want to split web development into pieces: front end / back end After you had an experience of adding service workers to website: full stack / service workers
Here I am 4 years later having the exact same thoughts. If users have to click on the update button all the time, it actually becomes a worse experience
Google AdSense is not the only way of monetizing your web traffic, and yetmost publishers only rely on Google AdSense. Check other ad networks as well e.g. MonadPlug, in order to monetize your traffic more thoroughly through different ad formats - push, native, pop, in-page push, etc. I use MonadPlug for all of them as it fits me for my GEO-s, but you can use any ad network you like. Definitely test MonadPlug as their payouts are among the strongest in performance marketing.
A sneaky fix is that you can change the name of your files then it forces everything to update. So usually I think just changing the name of your css file does a lot.
If you are looking for higher revenues of your traffic, better read this! I’ve tried literally every traffic monetization network, from AdSense (of course),Propeller Ads, AdNow, Adcash etc. Some of them were good for some time,but then eventually revenues dropped. However, 4 months ago, I started using MonadPlug traffic monetization network, and haven’t change it ever since as the terms and conditions were better for publishers than any othernetwork - especially in terms of CPC on push notifications and native ads, which are primary tools of my traffic revenue.
I got bit by an early version of Create React App's always on service worker. It taught me how service workers can be used to really mess with a domain name. Sell the domain name and the buyer might not even know about what that SW is doing. Ugh. Feels like SWs broke the web.
Looks like there's multiple answers in the comments, but this is why we ask to "clear cache" when we deploy, so the cached assets are the latest. Whatever infrastructure you're using should have the ability to clear the cached assets.
That seems like an unfortunate message to put out. After all, people have been working hard to try and get engineers to use service workers more in order to improve things for people who don't have the first world luxury of great internet connections everywhere. And you only mention that briefly towards the end. Personally, I don't get why people would use service workers for caching static files instead of offline capabilities in the first place. Seems preferable to me to push static files and simply use the HTTP cache (and/or SW after all, see below - but it's not a high priority). It's also important to highlight that service workers can also cache API responses - which can obviously be key for offline apps. Someone already mentioned google workbox but I would like to add that if you set it to use the strategy "network first", I really don't see how you could ever deploy a "bad" one. I guess it's mostly for offline then but the browser still uses it instead of the memory/disk cache if it gets a 304 response. I just ran some experiments with a simple app and a network first SW where the page load speed is about 10% faster from SW versus memory/disk cache.
Service workers allow you to use a site whether you have wifi or not. This can be good for some use cases and the rest can be left to browser caching. A restaurant menu or a book or a tool like ASCIIFlow could be entirely cached. As far as I know HTTP cache doesn't work if you are trying to access a resource without a connection, could be wrong about this part, though. Edit: I believe you can also schedule resources to be fetched if connectivity is lost so that a refresh isn't required.
if you were to ship a service worker that would cache the code that should update the cache, then you're in a big trouble.If you ever decided to cache your static files I think that it is a good practice to never cache javascript files at all.
I just want an online first service worker that loads the site normally and caches it, but if it fails to load the new site (because there is no internet connection for example) it insteas serves the cached version
I think you can solve that by adding hashes to the filenames of your assets (CSS, JS, IMAGES, ...) in the bundler configuration. That way every time the filenames change when releasing a new version of the websites and you won't have a problem with the cache. did you try this solution ?
My understanding was that service workers are mainly used for PWA on mobiles, when there's a chance the user does not have internet. I'm not sure how useful service workers are for websites targeted at desktops.
Yeah maybe. If you only handle JavaScript/CSS files with your SW and the files have content hashes in their names, you should be fine. You can then use the SW to prefetch the unused chunks in the background as an eager loading mechanism.
Great video! Actually I came to the same conclusions after having the same problems and stopped using it all together. It's also pretty bad that there is no easy way for the developer to clear bad service worker from the user's browser but maybe it's security issue. Also, have heard about google workbox library that does this better but it should work well out of the box - I'm not big fan of using external libraries to do simple thing. Also, heard from one developer that it's only an issue with chrome cache invalidation, but didn't want to spend more time on something that doesn't give much benefit. It's definitely something that should be worked on to make it easier to use as it hinders SW adaptation
Also when server is properly configured, browser will cache static files anyway. So as long as someone is not creating offline application, I don't see any benefit from using SW
Devtools Network Panel 'disable cache' , then just reload. Or Application Panel Clear Site Data. Old Application Cache Was terrible. Service Workers are pretty nice. About External Code.. I have read more JavaScript than I care to remember.. eventually get to a point where skimming someones library for a 'pattern' on 'technique' they employ become much easier and the benefit of external code is just learning material.
Yea the cache is embedded on the CPU, similar to RAM it’s short term memory just waiting for ( I ) to request then ( o ) will be the result of what’s rendered onto your browser window, the service worker stores your data on the cache but your code should be set to clear the cache then be ready to send fresh data upon request to prevent overloading the cache.... hard coding the JavaScript required to operate the SW.js file correctly is challenging, but if you do it right you can have an great offline experience, I say just learn more about the hard code and do it yourself so that way you know for sure your site will be fast and updated, school of hard knocks theirs no way around it!
Maybe you can just cache you images, css and js. If you add the version to the GET query (exp. ?ver=1.5.2) of their url, the uncashed html will always ask for the correct version. If a version misses from the cache it will retrieve it from the server.
I think everyone agrees that service workers are frustrating, but the control this api provides you can be insanely powerful. You can monitor and filter every single request that goes out and even mock apis per request directly in the browser. Did you call skipWaiting inside of your install event handler? The only other thing that could have kept your users out of date is if you were not deleting your existing caches. Unregister alone does not clear these caches, even though if you unregister all workers while watching application storage, the service worker piece of the pie disappears. I still do not know why or how to actually view the caches or even where they are storing the content per browser implementation, but this is something I just try to keep in consideration in testing. And under no circumstances do I ever change the cache name lol..
Can I use both serviceWorker and reportWebVitals in a react project? The tutorial I'm following along is using serviceWorker to create PWA (Progressive Web App), but the create-react-app build setup I've downloaded has reportWebVitals instead of serviceWorker. Option #1 : Should I delete reportWebVitals, and create serviceWorker file? Option #2 : Keep both! What should be done?
Wondering if you try to reload automatically every time you ship a new version of your website instead to show the popup. Can be crappy but can be a solution. Also would be good for future browser to let the service worker know when it need to refresh automatically..
Hi Ben i have a question about SW! I have an e-commerce website, and want my user to keep sending the order even if the internet is lost buy using SW and Indexed DB, the thing is that i was testing it on Chrome PC and Android, and forgot that Android WebView don't support offline synchronization, do you have any solution for that?
i guess that u need every time u deploy a new version that u make sure u r deleting the old service ( in activate eventListener ) worker because if u have 2 SWs that the old one has the priority
What if you made the service worker autoupdating? It would check an endpoint for a version string which would be the current, latest version of the SW. If the version is newer, update itself from another endpoint. If it cannot, fall back to clearing the site data on the browser itself. Et voila!
Hey Ben, learning a bit about Service Workers.... Could this problem be solved by serving the cached files and putting a call back in the service worker to request the same files from the server and diffing them to the current version, and sending the new files if they are different?
Here's an idea. Stop using PWAs altogether, then you don't ever need to bother with service workers ever again and your users get the updates whenever they visit your website without the need for some pointless app.
Great video! .. so would you suggest to use something like cloudfront to cache static files instead of service workers? (assuming you're not looking for the app to work offline)
Sorry man, but just because you don't know how to deal with service workers it's problem in it. Just simply say I don't know how to use it so I Removed
0 and my revenue from native ads has doubled! I’m thinking of fully switching to MonadPlug in terms of other ad formats as well - especially as I’ve seen that they have in-page push now
The fact that you didn't even know that your site had a service worker speaks to how these dev tools that are supposed to improve your experience actually makes you dumber as a developer because it does all this boilerplating for you. Programmers are lazy as hell.
anyoneee ??? I want to use push notifications. for that i'll need service workers. How can I approach that ? is it possible to play a notification sound on sending push notification ?
Similar thing I was experiencing with my Bingo game on game.cvfy.in . I finally removed service worker and it's working great. The application is not at all heavy so I don't quite need service worker.
No, Service Workers always run in the background and can intercept traffic going to and from the main site. Web Workers are just simple scripts which can be triggered to run off the main thread.
web workers are like threads in other coding languages you ask them to do a task in the background and returns a result then gets destroyed, service workers are like self-conscious (background) script that is always between your client side and server they intercept any request from each side and you are the one who manages what happens inside that worker like cache assets for offline use
You're missing return self.skipWaiting and return self.clients.claim in your service worker, that's why. It's not because service workers are bad. It's because you don't know how to write them correctly for your use case. If you don't want to write them yourself, perhaps use Google's workbox to at least configure them correctly. But it seems like your use case doesn't even need a service worker. For me, I like to make my websites mobile friendly and mobile networks are a lot flakier than static desktop networks.
hope this should work for the future apps, no need for clients to force reloading websites, just auto refresh (I've not tested this snippet yet, but it seems to be legit): serviceWorker.register({ onUpdate: registration => registration.unregister().then(() => window.location.reload()) })
Sorry to say that but all this problems is because you don't know well the tecnology you are using... Service-Workers are great. Took me a while to learn... There are some headers you send from your server that cleans all cache. Also cache versioning inside service-worker can do that too. Once you learn how to deal with service-worker, it is GREAT for performance online and go offline if you want to build a PWA...
So, you stopped using them due to lack of knowledge. Why bother to make a video then? You are selling SW like a bad thing when it's working as expected. If you don't know or don't like to use something, simply stop using it or learn how to use it. This video is so unnecessary.
![Introduction to Service Workers [2 of 17] | PWA for Beginners](http://i.ytimg.com/vi/gTrVzfFTr68/mqdefault.jpg)
Thank's for sharing. We implemented the feature to show a notification for the user that a new version is available! It works in production pretty nice!
It happened the same to us, we solved it with a custom service worker (with workbox). we do make a network first aproach only with de html because its contians the referencies to the new bundles and new assets (create react app generates new names on every deploy), so, the network first has a timeout in which case we assume that the user does not have a conection so its ok to show the previews version.
Offline navigation is just one of the many things you can do with Service Workers. It really depends on your application.
For example, I've made one website that was heavy on images, but the images itself were not super dynamic, they could changed once every month. So we added a cache of 15 days for those images and saw a huge impact on performance and bandwidth consumption.
Another thing is when you know some data won't change soon, so you can specifically cache some heavy endpoints, for example loading data that is old and doesn't change much (imagine loading user actions history from an old time).
Another way I've use it a lot is to go cache first and then immediately trigger a request in the background to update it. This can make your app look really fast and while you still have the n+1 scenario, users don't need to refresh manually because you already done it.
Don't give up on using Service Workers, they are easy to setup as a "all or nothing" kind of thing, but hard to really understand how it can improve your app specifically. But once you know how to take advantage of it only for the things you actually need, they can be great.
that's true they have some good use cases
I was learning PWA and came to know that it may be fixed by cache versioning. Every time you update the content, the old version of the cache needs to be deleted, and fill the cache with new content.
You can cache only some content though, I used this for image
Browsers were caching images long before service workers! Why not just use expires headers?
Dude it's incredible how your content is synchronized with stuff that I need to learn/do. I've started using Gatsby for a static site and Prismic as a CMS for the content creators. The thing is that the project has also a dynamic app with CRA so I'm trying to convince the team to move it on Gatsby as well. And I think that a plugin or two might solve that kind of SW issue.
Pretty sure its just google algorithms, I was googling service workers recently and now I get a video in recommendation feed
Thanks for this. Learning React now and I wondered about this issue as I built projects. I appreciate your logic on the matter.
I also have face issues with service worker in my blog. The service worker was not updating properly. I am using workbox to create service worker, so they should be a feature to automatically purge old caches and install new service worker. And after some debugging I found out that the real culprit was cloudflare CDN which cache my old service worker. So users are not receiving new service workers. Now I purge my old CDN caches when I deployed any new updates and I think it just solve my issues.
Man, There's so much hate in your heart when you speak about service workers, I can see it in your eyes haha
lol
And rightly so. If we stop service workers from infecting our system, PWAs are done for too. Good riddance.
How do you disable service workers for sites other than your own?
i experienced the same issue, what I did was provided a last modified header and the service worker checked the cached version of the page and compare it to periodic requests to the static file at the server, if the cache is out of date it will remove the old file from the cache and add the new page into the cache, then prompt the user about the new update
I built a web application not so long ago using service workers and haven't had any of this grief.
I added a route to the api such as "/version" that doesn't get cached and returns a version string.
Every time a user loads a page it loads from the service worker, but an asynchronous js request checks the remote version against the local version.
If there's a mismatch, all service workers are unregistered and the page is reloaded automatically.
So when users open the app, they always have the latest content, immediately.
then why use a service worker in that case? The behavior that you want seems like what happens without a service worker.
@@bawad it's a web _app_ as opposed to a website. It needs to work without internet.
gotcha, I'm used to hearing the term PWA for offline web apps
Service workers and spa can have a complicated relationship.
Although i do believe that when something gives more work than advantages it is time to reconsider it, i think that you 'abandoned' service worker too early.
Fortunately service workers are just javascript and their behavior can be changed to our needs.
This issue in create-react-app repo gives an interesting strategy to your problem: github.com/facebook/create-react-app/issues/7237 .
In practice you could trigger the update whenever you want. You might have to manually call a skipwaiting in certain situations or even a clients.claim().
interesting, I'll check that out
Service Workers are a great technology, but very misunderstood and misused. Caching static files would be the last thing I would do in a Service Worker, it's dangerous. A good use case is to cache certain API calls using Workbox!
Often there will be a build process with multiple chunks and the index.html will have the references to them. However on update the browser holds to the SW index.html for dear life and therefore it keeps looking for the old build chunks, causing everything to fall apart if your build process has emptied the folder.
With the default package for Service Workers in Angular you can define which strategy you want - freshness (deliver new data) or performance (prefer Cache)
I think one way of doing that is by adding a "v2" or "v3" to your file names every time a file is updated, that's how favicons are updated but I"m not completely sure and cache invalidation is a complex topic on it's own.
we couldnt even start and you quit. give this man a madal
hahahahahahaha
I bet if I looked at your service worker's fetch event listener, it would say to simply check the cache and return that file if there is a match. So your users cached the first version they ever got, and it returned that version until the end of time. I did this myself and it was frustrating. But it's not a limitation of service workers, it's because we used service workers without the right caching strategy.
You can prompt the user to update to the last version ... Using Workbox can help to avoid developing crucial parts of the service worker.
Appreciate you sharing your thoughts 👍
Yeah the users are loading pre cached files from whatever version they first loaded. Pretty sure you can just change the version number for the sw cache name (in the file), so the next time the page is hit the new service worker would create a new pre-cache (your updates)
To get it to load from that though you also need to access the activate lifecycle of the sw to delete the previous cache version.
Exactly. You got it
skipWaiting is for activating new version of the service worker script ( sw.js ), maybe just clean the cache on activating .
also
clients.claim sets this worker as the active worker for all clients that match the workers scope and triggers an oncontrollerchange event for the clients.
I should look into when the service worker was invalidating the cache, maybe that was the real problem
First thought when you want to split web development into pieces: front end / back end
After you had an experience of adding service workers to website: full stack / service workers
Here I am 4 years later having the exact same thoughts. If users have to click on the update button all the time, it actually becomes a worse experience
Just found you recently, great content!
Google AdSense is not the only way of monetizing your web traffic, and yetmost publishers only rely on Google AdSense. Check other ad networks as well e.g. MonadPlug, in order to monetize your traffic more thoroughly through different ad formats - push, native, pop, in-page push, etc. I use MonadPlug for all of them as it fits me for my GEO-s, but you can use any ad network you like. Definitely test MonadPlug as their payouts are among the strongest in performance marketing.
A sneaky fix is that you can change the name of your files then it forces everything to update. So usually I think just changing the name of your css file does a lot.
u don’t need to rename, just append a query string with a random value to the end of the url for the resource
Very useful real world example! thanks for sharing
If you are looking for higher revenues of your traffic, better read this! I’ve tried literally every traffic monetization network, from AdSense (of course),Propeller Ads, AdNow, Adcash etc. Some of them were good for some time,but then eventually revenues dropped. However, 4 months ago, I started using MonadPlug traffic monetization network, and haven’t change it ever since as the terms and conditions were better for publishers than any othernetwork - especially in terms of CPC on push notifications and native ads, which are primary tools of my traffic revenue.
i think 0:43 is very important point!
I got bit by an early version of Create React App's always on service worker.
It taught me how service workers can be used to really mess with a domain name. Sell the domain name and the buyer might not even know about what that SW is doing.
Ugh. Feels like SWs broke the web.
Looks like there's multiple answers in the comments, but this is why we ask to "clear cache" when we deploy, so the cached assets are the latest.
Whatever infrastructure you're using should have the ability to clear the cached assets.
That seems like an unfortunate message to put out. After all, people have been working hard to try and get engineers to use service workers more in order to improve things for people who don't have the first world luxury of great internet connections everywhere.
And you only mention that briefly towards the end. Personally, I don't get why people would use service workers for caching static files instead of offline capabilities in the first place. Seems preferable to me to push static files and simply use the HTTP cache (and/or SW after all, see below - but it's not a high priority).
It's also important to highlight that service workers can also cache API responses - which can obviously be key for offline apps.
Someone already mentioned google workbox but I would like to add that if you set it to use the strategy "network first", I really don't see how you could ever deploy a "bad" one. I guess it's mostly for offline then but the browser still uses it instead of the memory/disk cache if it gets a 304 response. I just ran some experiments with a simple app and a network first SW where the page load speed is about 10% faster from SW versus memory/disk cache.
How do you know it uses the SW cache in the case of a 304? 10% isn't really big enough to conclude anything from that.
@@JamesDoehring I didn't conclude it from the performance difference. It'll say "Served from ServiceWorker" in the devtools.
Service workers allow you to use a site whether you have wifi or not. This can be good for some use cases and the rest can be left to browser caching. A restaurant menu or a book or a tool like ASCIIFlow could be entirely cached. As far as I know HTTP cache doesn't work if you are trying to access a resource without a connection, could be wrong about this part, though.
Edit: I believe you can also schedule resources to be fetched if connectivity is lost so that a refresh isn't required.
I think it's like a black box for your input output.
There is already browser cache for that. It is also easy to completely screw up your site by shipping a buggy worker
I try to exclude index.html from cached files as it will always request fresh resources due to a hash appended on build
But you can set cache headers on your static files so your browsers caches them anyway
if you were to ship a service worker that would cache the code that should update the cache, then you're in a big trouble.If you ever decided to cache your static files I think that it is a good practice to never cache javascript files at all.
I just want an online first service worker that loads the site normally and caches it, but if it fails to load the new site (because there is no internet connection for example) it insteas serves the cached version
I think you can solve that by adding hashes to the filenames of your assets (CSS, JS, IMAGES, ...) in the bundler configuration.
That way every time the filenames change when releasing a new version of the websites and you won't have a problem with the cache.
did you try this solution ?
What about new version installation prompt's?
My understanding was that service workers are mainly used for PWA on mobiles, when there's a chance the user does not have internet. I'm not sure how useful service workers are for websites targeted at desktops.
Yeah maybe. If you only handle JavaScript/CSS files with your SW and the files have content hashes in their names, you should be fine. You can then use the SW to prefetch the unused chunks in the background as an eager loading mechanism.
Great video! Actually I came to the same conclusions after having the same problems and stopped using it all together. It's also pretty bad that there is no easy way for the developer to clear bad service worker from the user's browser but maybe it's security issue. Also, have heard about google workbox library that does this better but it should work well out of the box - I'm not big fan of using external libraries to do simple thing. Also, heard from one developer that it's only an issue with chrome cache invalidation, but didn't want to spend more time on something that doesn't give much benefit. It's definitely something that should be worked on to make it easier to use as it hinders SW adaptation
Also when server is properly configured, browser will cache static files anyway. So as long as someone is not creating offline application, I don't see any benefit from using SW
Devtools Network Panel 'disable cache' , then just reload. Or Application Panel Clear Site Data. Old Application Cache Was terrible. Service Workers are pretty nice. About External Code.. I have read more JavaScript than I care to remember.. eventually get to a point where skimming someones library for a 'pattern' on 'technique' they employ become much easier and the benefit of external code is just learning material.
Anytime I`m about to learn new technology I find Ben Awards video like `fuck ${technologyName}`
You can silently refresh the page as update available without prompt the user. A I don't think that it's a big deal especially for web apps an pwa.
Yea the cache is embedded on the CPU, similar to RAM it’s short term memory just waiting for ( I ) to request then ( o ) will be the result of what’s rendered onto your browser window, the service worker stores your data on the cache but your code should be set to clear the cache then be ready to send fresh data upon request to prevent overloading the cache.... hard coding the JavaScript required to operate the SW.js file correctly is challenging, but if you do it right you can have an great offline experience, I say just learn more about the hard code and do it yourself so that way you know for sure your site will be fast and updated, school of hard knocks theirs no way around it!
Maybe you can just cache you images, css and js. If you add the version to the GET query (exp. ?ver=1.5.2) of their url, the uncashed html will always ask for the correct version. If a version misses from the cache it will retrieve it from the server.
It's not Service Workers problem, it's particular React implementation that sucks.
I think everyone agrees that service workers are frustrating, but the control this api provides you can be insanely powerful. You can monitor and filter every single request that goes out and even mock apis per request directly in the browser.
Did you call skipWaiting inside of your install event handler? The only other thing that could have kept your users out of date is if you were not deleting your existing caches. Unregister alone does not clear these caches, even though if you unregister all workers while watching application storage, the service worker piece of the pie disappears. I still do not know why or how to actually view the caches or even where they are storing the content per browser implementation, but this is something I just try to keep in consideration in testing. And under no circumstances do I ever change the cache name lol..
The poor design of this api is also sort of a security feature actually...
Can I use both serviceWorker and reportWebVitals in a react project?
The tutorial I'm following along is using serviceWorker to create PWA (Progressive Web App), but the create-react-app build setup I've downloaded has reportWebVitals instead of serviceWorker.
Option #1 : Should I delete reportWebVitals, and create serviceWorker file?
Option #2 : Keep both!
What should be done?
using webpack we can add hashcode to static files like images and files, hash will be updated whenever there is a change in file. did you try this?
n - 1 ?
Wondering if you try to reload automatically every time you ship a new version of your website instead to show the popup. Can be crappy but can be a solution. Also would be good for future browser to let the service worker know when it need to refresh automatically..
Hi Ben i have a question about SW! I have an e-commerce website, and want my user to keep sending the order even if the internet is lost buy using SW and Indexed DB, the thing is that i was testing it on Chrome PC and Android, and forgot that Android WebView don't support offline synchronization, do you have any solution for that?
i guess that u need every time u deploy a new version that u make sure u r deleting the old service ( in activate eventListener ) worker because if u have 2 SWs that the old one has the priority
What if you made the service worker autoupdating? It would check an endpoint for a version string which would be the current, latest version of the SW. If the version is newer, update itself from another endpoint. If it cannot, fall back to clearing the site data on the browser itself. Et voila!
What's the alternative for service workers ?
Guys, just use workbox ans cache strategies
Hey,
Why didn't you choose SSG for this use case?
self.addEventListener('install', event => {
self.skipWaiting();
event.waitUntil(
// caching etc
);
});
this would fix your issue. self.skipWaiting();
skpiwaiting function wasn't working ?
I had the same thing on angular service workers
I solved it using this algo
When there's an update.. unregister() and reload. Then thats it
github.com/wgod58/create_react_app_pwaupdate
This is the sample that im talking about, it uses swConfig,
lol for a second I thought you meant service workers like a fast food worker
Hey Ben, learning a bit about Service Workers.... Could this problem be solved by serving the cached files and putting a call back in the service worker to request the same files from the server and diffing them to the current version, and sending the new files if they are different?
Possibly
yeah, watch out for rogue service workers!
Can you do one on how to promote your site?
Here's an idea. Stop using PWAs altogether, then you don't ever need to bother with service workers ever again and your users get the updates whenever they visit your website without the need for some pointless app.
What about push notifications
Is this site sitting in an S3 bucket? You may want to look into using something like CloudFront.
nope, netlify
Great video! .. so would you suggest to use something like cloudfront to cache static files instead of service workers? (assuming you're not looking for the app to work offline)
yeah I think using a cdn is a good idea
Sorry man, but just because you don't know how to deal with service workers it's problem in it.
Just simply say I don't know how to use it so I Removed
you are right
Skip waiting has still bugs );
Cant you just delete the cache by name ?
0 and my revenue from native ads has doubled! I’m thinking of fully switching to MonadPlug in terms of other ad formats as well - especially as I’ve seen that they have in-page push now
The fact that you didn't even know that your site had a service worker speaks to how these dev tools that are supposed to improve your experience actually makes you dumber as a developer because it does all this boilerplating for you. Programmers are lazy as hell.
why is this happening ha feels
Are PWA 's not all about serviceworkers? Does this mean you don't believe in that technology?
Stag files? What are you talking about?
timestamp? I can't remember what I meant by stag files
anyoneee ???
I want to use push notifications. for that i'll need service workers.
How can I approach that ?
is it possible to play a notification sound on sending push notification ?
This might be useful somehow: ruclips.net/video/HlYFW2zaYQM/видео.html
Notification sound won't be possible, cuz of the updated autoplay policy, you can have a prompt asking for reloading the page.
@@harshbhandari5549 everything is possible. I did it.
@@sagarchavan5894 oh nice! how did you managed to implement auto play notification sound ?
@@harshbhandari5549 therez an article on smashing.com
Literally cntrl + shift + r dude, not hard
How is a user supposed to know to do that?
Similar thing I was experiencing with my Bingo game on game.cvfy.in . I finally removed service worker and it's working great. The application is not at all heavy so I don't quite need service worker.
Are service workers the same as web workers?
No, Service Workers always run in the background and can intercept traffic going to and from the main site. Web Workers are just simple scripts which can be triggered to run off the main thread.
web workers are like threads in other coding languages you ask them to do a task in the background and returns a result then gets destroyed, service workers are like self-conscious (background) script that is always between your client side and server they intercept any request from each side and you are the one who manages what happens inside that worker like cache assets for offline use
Has anyone tried MonadPlug for push monetization? They have much better payouts than other networks I’ve tried and top notch support.
You're missing return self.skipWaiting and return self.clients.claim in your service worker, that's why.
It's not because service workers are bad. It's because you don't know how to write them correctly for your use case. If you don't want to write them yourself, perhaps use Google's workbox to at least configure them correctly. But it seems like your use case doesn't even need a service worker. For me, I like to make my websites mobile friendly and mobile networks are a lot flakier than static desktop networks.
hope this should work for the future apps, no need for clients to force reloading websites, just auto refresh (I've not tested this snippet yet, but it seems to be legit):
serviceWorker.register({
onUpdate: registration => registration.unregister().then(() => window.location.reload())
})
Sorry to say that but all this problems is because you don't know well the tecnology you are using... Service-Workers are great. Took me a while to learn... There are some headers you send from your server that cleans all cache. Also cache versioning inside service-worker can do that too. Once you learn how to deal with service-worker, it is GREAT for performance online and go offline if you want to build a PWA...
man just version your files
Hay quá
Maybe don’t jump on every bandwagon?
nice one !!! :)
i love u
better approach could be learn javascript and learn how to write service workers :facepalm
So, you stopped using them due to lack of knowledge. Why bother to make a video then? You are selling SW like a bad thing when it's working as expected. If you don't know or don't like to use something, simply stop using it or learn how to use it. This video is so unnecessary.
Offside mode is just a joke.
Everything is a joke if you have no idea how to use it.
A very useful joke
hahaha same thing happens to me
You may need to grow up instead of complaining about something you have no idea about.
pfh
kid
clienstClaim() and location.reload() on next router push seems to be better user experience solution IMO :>