Oh my God! This was what I needed! I have been fighting with my app for it to work properly! And Good Lord, you are here to help! Thank you very very much!
Nice interesting infos. Steve, do you know how to take token's value of a response's header??? It would be a nice subject for a video. Once again, congratulations for the channel. It helps me a lot!
thanks for this wonderfull playlist about service worker. I do have a question why when using waitUntil we have to skipwaiting in devtools? It shouldnt be automatic, i mean like clients.claim?
waitUntil is a method that we use in the code to wait for an asynchronous operation to complete. It allows us to use Promise based functions inside the event listener. The skipWaiting in the devtools is completely separate to that. Browsers, once they have a service worker installed and activated, will hang on to that original service worker until all windows and tabs that are using the service worker have been closed before activating another worker that has been installed. skipWaiting in the devtools means unregister the current active one and activate the new one.
Thank you professor Steve, i learn a lot from you. You have mention that you don't want to store the service worker file sw.js into the cache, can you explain do we really don't need to put the sw.js file into the cache, how things will be going when it goes offline without sw.js file in the cache ?
Do you have any thoughts on using Workbox for handling service workers, caching etc...? It seems to be considerably more convenient than raw coding. Are there downsides to it?
I don't like using it personally. I prefer to control what is happening myself. I know developers who do use it and like it and others who don't. It's like any framework - pros and cons, some people who like it and others that don't.
@@SteveGriffith-Prof3ssorSt3v3 Thanks! As it turns out, I am looking to do PWA stuff with WordPress and there's a plugin that is aiming to become part of the core code to allow for other plugins and themes to add their own PWA features, routes etc... It uses Workbox, so so will I!
Thank you. Great series! One question - if we just keep the staticCache name as a constant - then each time the install event happens for a new Service Worker it will just update that one static cache with the new files and it would save the hassle of creating a new Cache each time and having to delete the old caches in the activate event. So the question is why do we make the staticCache name variable (depending on the version)? Thanks
@@SteveGriffith-Prof3ssorSt3v3 thanks for your reply Steve, appreciate it. I understand why we put the cacheName in a variable - what I meant was why not just define it for e.g as const version = 1 const staticCacheName = 'staticCache' i.e without the version number attached to the cache name. As that way when the service worker version is updated it just overwrites everything in the SAME cache - instead of creating a new cache with a new name and then us having to delete the old caches later on in the activate event. Hope that makes sense :) I've tested it out this way and it works great - but just wondering if I'm missing something. Cheers
Any files that you want to be available when the site is offline, then you need to add them to the cache. If you have hashcodes for the file names then that helps to keep them unique. If there are a set number of files of a certain type that you know will exist on the site then you can do clean up operations to delete the extra ones. They will always be sorted in the order that they were added to the cache. They can be cached when the service worker is installed via an array, or they can be cached when a new file is requested. The caching of files when the service worker is installed is best for files that absolutely need to be part of your application when it runs offline.
what would happen if I set skipWaiting on the serviceworker. would it load the files from the new cache immediately or would it wait for the page to reload to load from the new cache?
skipWaiting is used within the "install" event listener function. This means that if there was a previously installed and active service worker for the current domain, then skipWaiting tells the browser not to wait for the old service worker to be replaced naturally when the user closes the browser or navigates away from the site. Instead it will run the new service worker immediately... and that includes whatever the new service worker does.
@@SteveGriffith-Prof3ssorSt3v3 Is this instantaneous? What i was trying to figure out is suppose i have an old serviceworker that gets files from cache. Now we have a new serviceworker that stops the old serviceworker using skipWaiting . Could it be possible that the old serviceworker already fetches those old files before the new serviceworker kicks in or does the new serviceworker take control before the old serviceworker gets the chance to do so?
The old service worker may have fetched the files. It doesn't really matter though. Part of the process of setting up the new service worker should be updating your cached files - add new ones, delete old ones. If the old service worker and the new one use the same cache name then the old files will be used.
@@SteveGriffith-Prof3ssorSt3v3 okay thanks a ton! actually i was helping on a project which sometimes seems to crash after pushing changes. my assumption is that since they have skipWaiting its loading old files before the new serviceworker kicks in. then after the new serviceworker kicks in when it dynamically loads the js chucks (used for code splitting) it then gets the server resource instead of the cached serviceworker resource which causes errors due to conflicts. thanks for your help!
![Kodak Black - Versatile 4 [Official Video]](http://i.ytimg.com/vi/VcP_1Ua__vY/mqdefault.jpg)
Oh my God!
This was what I needed!
I have been fighting with my app for it to work properly! And Good Lord, you are here to help!
Thank you very very much!
This code is much hardier than code laid out in other tutorials on service worker caching. Recommend!
You're a special gem! Grifffith.
Good stuff Steve! Appreciate all the information shared.
You are great teacher really
Great series so far :) Thanks for making it more understandable!
Thanks you 👍 Steve great tutorial series
thank you sir, it's imformative and fun
Nice interesting infos. Steve, do you know how to take token's value of a response's header??? It would be a nice subject for a video. Once again, congratulations for the channel. It helps me a lot!
I talk about tokens in a couple videos. Try this one first - ruclips.net/video/KJdD8pdZSo8/видео.html
Thanks.
thanks for this wonderfull playlist about service worker. I do have a question why when using waitUntil we have to skipwaiting in devtools? It shouldnt be automatic, i mean like clients.claim?
waitUntil is a method that we use in the code to wait for an asynchronous operation to complete. It allows us to use Promise based functions inside the event listener.
The skipWaiting in the devtools is completely separate to that. Browsers, once they have a service worker installed and activated, will hang on to that original service worker until all windows and tabs that are using the service worker have been closed before activating another worker that has been installed. skipWaiting in the devtools means unregister the current active one and activate the new one.
Thank you professor Steve, i learn a lot from you. You have mention that you don't want to store the service worker file sw.js into the cache, can you explain do we really don't need to put the sw.js file into the cache, how things will be going when it goes offline without sw.js file in the cache ?
The service worker gets installed in the browser. It is not needed in the cache.
@@SteveGriffith-Prof3ssorSt3v3 thank you, getting more understanding
Do you have any thoughts on using Workbox for handling service workers, caching etc...? It seems to be considerably more convenient than raw coding. Are there downsides to it?
I don't like using it personally. I prefer to control what is happening myself. I know developers who do use it and like it and others who don't. It's like any framework - pros and cons, some people who like it and others that don't.
@@SteveGriffith-Prof3ssorSt3v3 Thanks! As it turns out, I am looking to do PWA stuff with WordPress and there's a plugin that is aiming to become part of the core code to allow for other plugins and themes to add their own PWA features, routes etc... It uses Workbox, so so will I!
Thank you. Great series! One question - if we just keep the staticCache name as a constant - then each time the install event happens for a new Service Worker it will just update that one static cache with the new files and it would save the hassle of creating a new Cache each time and having to delete the old caches in the activate event. So the question is why do we make the staticCache name variable (depending on the version)? Thanks
The only reason we put the cache name into a variable is that you will commonly use the name in multiple places in your service worker code.
@@SteveGriffith-Prof3ssorSt3v3 thanks for your reply Steve, appreciate it. I understand why we put the cacheName in a variable - what I meant was why not just define it for e.g as
const version = 1
const staticCacheName = 'staticCache'
i.e without the version number attached to the cache name.
As that way when the service worker version is updated it just overwrites everything in the SAME cache - instead of creating a new cache with a new name and then us having to delete the old caches later on in the activate event. Hope that makes sense :)
I've tested it out this way and it works great - but just wondering if I'm missing something.
Cheers
@@zainsyed9811 we normally combine the version number and name into one variable so it makes a new cache when we want one.
So that mean. if i have around 100+ files of JS, CSS that mean. I have to add all of them in to the `assets` by hashcode?
Any files that you want to be available when the site is offline, then you need to add them to the cache. If you have hashcodes for the file names then that helps to keep them unique.
If there are a set number of files of a certain type that you know will exist on the site then you can do clean up operations to delete the extra ones. They will always be sorted in the order that they were added to the cache. They can be cached when the service worker is installed via an array, or they can be cached when a new file is requested.
The caching of files when the service worker is installed is best for files that absolutely need to be part of your application when it runs offline.
@@SteveGriffith-Prof3ssorSt3v3 thank u
what would happen if I set skipWaiting on the serviceworker. would it load the files from the new cache immediately or would it wait for the page to reload to load from the new cache?
skipWaiting is used within the "install" event listener function. This means that if there was a previously installed and active service worker for the current domain, then skipWaiting tells the browser not to wait for the old service worker to be replaced naturally when the user closes the browser or navigates away from the site. Instead it will run the new service worker immediately... and that includes whatever the new service worker does.
@@SteveGriffith-Prof3ssorSt3v3 Is this instantaneous? What i was trying to figure out is suppose i have an old serviceworker that gets files from cache. Now we have a new serviceworker that stops the old serviceworker using skipWaiting . Could it be possible that the old serviceworker already fetches those old files before the new serviceworker kicks in or does the new serviceworker take control before the old serviceworker gets the chance to do so?
The old service worker may have fetched the files. It doesn't really matter though. Part of the process of setting up the new service worker should be updating your cached files - add new ones, delete old ones. If the old service worker and the new one use the same cache name then the old files will be used.
@@SteveGriffith-Prof3ssorSt3v3 okay thanks a ton! actually i was helping on a project which sometimes seems to crash after pushing changes. my assumption is that since they have skipWaiting its loading old files before the new serviceworker kicks in. then after the new serviceworker kicks in when it dynamically loads the js chucks (used for code splitting) it then gets the server resource instead of the cached serviceworker resource which causes errors due to conflicts. thanks for your help!
Can you number the sequence of your associated tutorials example part 1 part 2 etc
They are in sequence in the playlist and the description of each video has its number too
i cant understand(((
If you are trying to understand the Cache API and working with files - ruclips.net/video/zq2xD-xuIG4/видео.html