Avoid double refresh on service worker update

[novaknole]

I've gathered some really great questions and i hope you can answer those.

All these questions emerged from the fact that I want to reflect new changes from service worker in one refresh from user's browser. Please look through this. Let me know what things I said wrong if I did of course.

I appreciate it. I know this should be on stackoverflow instead of being here, but it takes weeks to get an answer on stackoverflow. Let's begin.

Let's say I have a service worker registration directly in my main.js file. (I don't register it in the load event). Now, user opened our website for the first time. So install and activate event will happen. In install, we put things in Temporary cache and in activate, we remove the REAL cache's data and move temp cache into the real one.

Question 1) I use skipwaiting in service worker's install event and we updated the app.

When I use skipWaiting and only have 1 tab, and registration of the new service worker is directly in my js script without load event , and then I update service worker code and refresh the page, is it possible for something like this to happen : => i have 20 requests, and 10 requests got made before new service worker install/activate event and now because of skipWaiting, activate took place which means it killed old service worker and now, another 10 requests got made, but looks like these 10 requests won't go to new service worker's fetch as the page had started loading before the new service worker got activated, so those 10 requests will end up going to network without any service worker at all. and I don't see any danger if user has 1 tab open while using skipWaiting. Real issue with skipWaiting is when user has more than 1 tab open and he refreshes second tab , it might break first tab.

Now, the worse thing with this is that ONE REFRESH is not enough for a user to see the new changes, as some of the fetch events could be called from the old service worker which returns them from cache.

Do you agree with what I said in this question?

Question 2) I use skipWaiting and clientsClaim and we updated the app.
I don't know why people use clientsClaim. It looks like to me that we can't rely on it. It's said that clientsClaim is great to let the service worker take control of the page immediatelly. So the first visit should activate fetch listener. but now, It's 80% possible that some requests won't go to service worker's fetch events, because activate event got late (Who knows why). So i know clientsclaim could be also used for run-time caching, but for some requests, for the first visit, it won't be called. So what? It's killing me that people still explain it and they still don't understand it. Even @jakearchibald says it's not good.

Do you agree with me what i said in Question 2)

Question 3)
I use Jake Archibald's solution to update service worker and let the user see the changes . Jake refreshes programatically with window.location.reload after user refreshes. So this case also refreshes 2 times, but user only refreshes once. Here is how @jakearchibald does it:
jakearchibald/wittr@task-update-notify...update-interaction#diff-18fb79d8e23051a8d357ce7db95ff2f0

The issue with this scenario is When user refreshes, I know that he can see a button where it's says: 'new changes , would you like to update'? and after clicking, we refresh the page. So in a nutshell, we still have 2 refresh but a cleverer one. but still, Does this say that it's not possible to reflect the change in one refresh ?

clientsClaim won't help me with that. It's not reliable at all.

Do you agree with me in Question 3?

Question 4) Any ideas or assumptions from your side with only one refresh possible ?