-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Service Workers - Consolidated issues list #2554
Comments
Pinging the experts - @jeffposnick @addyosmani @gaearon @geelen @sethbergman @goldhand |
The first |
The fact that service worker code can get cached is the single greatest reason not to enable them by default. The majority of developers won't realize they have to configure caching headers on the file to prevent browser caching the service worker logic and being unable to update their site in any way for end users. Next top issue is caching index.html by default. |
I found a project that I believe implements service workers fantastically. It happens to be using the Aurelia framework. The project is one I'm sure many of you are familiar with: gist.run. I put together a gist of the main implementation of service workers in this project here. On a side note, if you don't have the chrome extension Octotree installed, you must get it right away. It's incredible. Why am I talking about this? I'm going to give you a link to the gist.run repo and you'll be able to navigate the file tree of the repo without reloading the page. Here's some additional reading and resources for those in a bind: This is a complex new piece of technology that is going to be great for mobile / offline resource caching, especially for those with low bandwidth. It's just going to take time for the browsers and API's to sync up to make it what it's really supposed to be. I'm going to look further into how gist.run implemented it with Aurelia and go from there. 🍻 |
I am wondering if we could implement a cache busting technique to solve some of these issues while browser support and the spec is still in flux. Every time a new bundle is created, we are already creating a new service worker. The service worker could have its own hash. This would bust the cache and solve SWI3. Then with a modified version of PR #2551, where we reload the page if no service worker is found, we could instead show an empty white page while a fetch request is done to the service worker.
This would then solve SWI2 that the user sees old content. It also avoid them being told they need to refresh to see the latest content (currently odd behaviour for a normal browsing experience) Showing a 'white screen' is standard browser behaviour when loading a page, so the use doesn't see anything strange. We also get any improvements in chrome where it may have a pre-parsed version of your app for faster loads. The obvious disadvantage here is that you can't get 'instant loading' from the offline version of the app, because at least one request has to be completed (or fail) before the app is loaded. I think this would be a good trade off between expected experience, solving developer issues, and solving caching issues. However, I am not sure that we can actually find out the filename of the currently saved service worker. Any idea @jeffposnick? If it's not possible, there might be another way to check if a service worker is the same or difference to the currently saved one. Update Added a proof of concept on how this could be done. PR #2563 |
Yeah that's what you want to do. It's essentially an app shell that renders first paint while other requests/ promises resolve behind the scenes. Polymer explains this in detail. The decision comes to which assets to cache by default. |
Thanks for your continued work exploring the pain points and potential solutions, @ro-savage! I've been maintaining a similar document, heavily drawn from the experience of the I'll add in some comments/feedback to the new and existing PRs that you've linked up to. (FWIW, it does look like there's been some movement on getting no-cache by default for the service worker script implemented in Chrome, hopefully in the Chrome 61 timeframe.) |
@jeffposnick that document looks good. I'll see if there is anything to add. And good news on the no-cache. @jeffposnick @sethbergman Is there currently a way to tell if the registered service worker That is, we can tell if the service worker is new/updated from A The use case here, follows on from #2563. Which hides content until the app is sure the content has not been updated. The PR does this by giving each service-worker at unique file name, but it'd be better if there was another way to tell. Secondly, is there a way to refresh the content the service-worker is showing on the browser other than reloading the page? (And even better if any file received from browser cache was not parsed again) |
Hi @ro-savage, just to be sure, would #2551 solve issues where one is serving two apps on the same URL but with different paths? For example I am serving a CRA app on https://myfoo.com and the docs in https://myfoo.com/docs, which are served by the same static server from different static servers. The app forces a reload on the Great work on improving the PWA experience on CRA by the way ❤️ |
@ro-savage thanks for maintaining this list! |
@jeffposnick Could you please take another look at this list, note which issues are still relevant and which aren't, which have solutions (merged or unmerged) and which don't, and whether you know of any other issues based on feedback in #2398 and other threads? |
Here's an update on the various issues that I'm aware of, mentioned in this thread or elsewhere. Please ping this thread with anything I'm missing and I'll provide a similar update.
Quick discussion: 3. remains a serious pain point for Chrome users, 2. has some potential for being fixed if developers are willing to adopt the UX introduced by that PR, and 7. can be addressed by the open PR (while losing some offline-first functionality). It's worth noting that if the decision is made to disable service workers by default and making them opt-in, a fairly clean way of doing so would be to change to call |
Thanks for the write up and feedback @jeffposnick. I've been tracking and reading #2398, and the strong feedback that has appears has been to turn SW off by default. As @jeffposnick suggested, having It fixes all the issues that people encounter with it while allowing people to use it very easily, without configuration when they understand the implications or want to experiment. SW should/can be used in certain circumstances but until that becomes the majority of what people are using React / CRA for it should be off by default because it interferes with standard practise and expectations of people building webapps. |
👍 Bikeshedding, but as a developer something like // index.js
// change this to true if you want to register a service worker (see https://[CRA docs])
registerServiceWorker(false);
// registerServiceWorker.js
export default function register(registerServiceWorker) {
if ('serviceWorker' in navigator) {
if (registerServiceWorker === false) {
unregister();
return;
}
if (process.env.NODE_ENV === 'production' ) {
...
}
}
} Sounds like a neat way to solve the problem without breaking existing behaviour but giving an easy way to nuke the serviceWorker for those that upgrade with minimal code changes. I can send a PR for this if wanted 🐈 |
Is there some up-to-date information on Firebase caching of |
Is there a |
Re: @petetnt, I'm not sure if a Re: @gaearon, see #3659 (comment) regarding Firebase caching Re @johnfliu818, there's a lot of material in the README, though it might not be as visible as it could be: https://github.com/facebookincubator/create-react-app/tree/master/packages/react-scripts/template#making-a-progressive-web-app |
@jeffposnick like I said, mostly just bikeshedding 😃 That said, import { unregister } from './registerServiceWorker.js';
...
// some comment
unregister(); does feel like a pretty weird default, especially to someone opening the Passing a boolean is backwards compatible, it's a single-to-zero word change for everyone using CRA and I guess (IMHO) it does bring more clarity. /🚲 🏠 |
Sure, that works too. The other points still stand though. |
For 3, how about cache busting using url params like this? |
Re: @anshul's comment, cache busting the |
Debugging a cache problem is annoying, especially when you are not aware there is a cache turned on somewhere. It's the type of things you want for your worst enemies. I really think default service-worker to be off (instead of trying to fix it via cache busting) is the right choice. On a lighter note :) |
I decided to try creating a PR to disable service worker by calling Normally I'm opposed to boolean function arguments but in this case it might be the best option. The main problem is that if you import both |
I'm happy to defer to the approach preferred by folks closer to the |
I gotta say, working with this service worker over the last year, on multiple CRA projects, that it's been harder to track and read all these issues and make sense of anything than it has been to work with the sw in the first place (which is saying a lot). These awesome features have been dangling in front of our faces; and with it enabled by default, we try and work and sweat to even understand wtf is going on... because we aren't gonna remove these awesome features; oh no, we are good devs and we always get it working. right? Wrong, we just get so mad at CRA that our only solace is a cigarette and an espresso. This service worker issue is a complete disaster. |
For people finding this looking to use a production build served by express without ejecting, in a project that serves an /api route for example, you will have to run 2 servers on 2 ports, one for your data, and one to serve the build of the app alone. the service worker will always hijack all routes if served from a root scope. There is no way to configure the service worker to ignore routes without ejecting, as the relevant whitelisting options are not exposed in any way that I can see. Someone correct me if I'm wrong. Without building and serving, there is no way to know or feel what errors this would cause, so keep this in mind and save yourself my extreme frustration |
* WIP disable service worker by default (#2554) * Updated service worker registration * Readd default export in registerServiceWorker.js * Updated comments about using Service Worker * Call it serviceWorker * Nits
We’re moving forward with making service-workers opt in in the next major release. I hope this is a satisfactory conclusion for most users. We can revisit this in a year or two. |
@gaearon Am I right in thinking that there's no TODOs for the service worker spec here? |
@theenoahmason There is a #3029 to release your pains. |
@piotr-cz that seems reasonable, though very restricted. Seems to me the best solution would be to add a key to package.json not unlike I got around the issue by serving the built app on its own server, which works just fine. |
@theenoahmason The CRA maintainers are hesitant to add new configuration properties to not complicate the package so adding an exclusion for BTW I'm too serving API from different domain then build. |
* WIP disable service worker by default (facebook#2554) * Updated service worker registration * Readd default export in registerServiceWorker.js * Updated comments about using Service Worker * Call it serviceWorker * Nits
From the original post:
It's bad form to comment on a closed issue, but... I wanted to let folks who have previously run into issues due to You can read more at https://developers.google.com/web/updates/2018/06/fresher-sw |
* WIP disable service worker by default (facebook#2554) * Updated service worker registration * Readd default export in registerServiceWorker.js * Updated comments about using Service Worker * Call it serviceWorker * Nits
This is a consolidation of issues and fixes service workers in CRA.
For general discussion of service workers see issue #2398
Last updated: 18/06/2017 00:10:00 GMT
address:host
.PR #2551 attempt to address this by auto reloading non-service worker apps.
PR #2426 attempts to address by showing a toast notifying user to refresh.
Eventually browsers should force no-cache on service workers, but this is only implemented in firefox currently. In the mean time, only fix is to ensure no-cache is set on service-worker.js
SW Spec Issue, Firefox ✔, Chrome ✘
PR #2563 is a proof of concept how this could be addressed in CRA.
There is currently no fix for this.
There is currently no fix for this. Developers must know of this behaviour an plan for it. Due to the fact users aren't allowed to fully configure the service worker, they won't ever be able to cache API data and images (I think? @jeffposnick).
A developer can store data in
localStorage
and load that initially / if offline.registerServiceWorker.js
is updated to fix issues, it will not be updated for current users of CRA. Breaking the 'as long as you don't eject you always have the latest features'Currently no PR but we could move the logic out of registerServiceWorker.js and add it to
react-scripts
config folder.Please feel free to add any issues that you have encounter using CRA with service workers enabled.
The text was updated successfully, but these errors were encountered: