PWA features

[maximromanyuk]

Can I use PWA features with create-react-app, such as manifest, service workers? Where to put manifest?

[maximromanyuk]

@gaearon, what you think about PWA features? It is possible?

[gaearon]

I'd be interested in supporting that. I just don't know enough / don't have enough time to work on this. If somebody could lead this effort and write up a proposal for how that would work I’d be thrilled!

[bashmakoff]

Here is a good PWA analyzer

[fleischie]

What about this project as a starting point? (As well as the before-mentioned of course.)

[jasanst]

Previously discussed here #192

[gaearon]

I'm often getting confused about which technologies exactly are being marketed under the "PWA" umbrella. Can I ask somebody to make a comprehensive list? Is jeffposnick/create-react-pwa@starting-point...pwa "enough"? Is there anything we could enable by default there?

cc @addyosmani

[timarney]

Someone from this episode of JavaScript Air might be able to chime in as well https://javascriptair.com/episodes/2016-05-25

Also here's a Baseline PWA checklist
https://developers.google.com/web/progressive-web-apps/checklist

[NekR]

To be a PWA (in todays terms) you need following:

• HTTPS
• manifest.json file (with display: 'standalone' at least)
• ServiceWorker

This all need to make browsers display "Add to Homescreen" popup. Though, any website can be added manually to the home screen (in Chrome) even if it doesn't have anything from that list.

[addyosmani]

@gaearon Thanks for the ping! 🔔 The current baseline we recommend for apps trying to be a PWA is that they're:

• Responsive by default (use a viewport metatag correctly at min). You already do this.
• Can be added to the homescreen (have a valid Web App manifest and favicons. c-r-a could use some defaults here that we encourage folks to customize via docs)
• Are served over HTTPS (c-r-a would likely leave that up to the end dev)
• Provide something (ideally, meaningful) while offline via Service Worker
• Load fast over real networks (e.g 3G). It wouldn't be hard to accomplish this with what c-r-a does out of the box, however we might think about what else can be done to help folks stay fast. There's a ton that could be done to prescribe basic code-splitting and perf budgets though your thoughts on interest in that would be awesome.
• Work cross browser. This is another one of those things c-r-a does fine out of the box.

As you've noted elsewhere (e.g #1056) it looks like the loading part of this can be tackled once you've switched to Webpack 2 and use System.import().

Otherwise, happy to work on a PR for c-r-a to add PWA support or ask someone on my team to.

[gaearon]

There's a ton that could be done to prescribe basic code-splitting and perf budgets though your thoughts on interest in that would be awesome.

Once we switch over to WP2 and document System.import() support I’d like to integrate your bundle post-build "size nudge" (unless it’s already a part of WP?)

[addyosmani]

Once we switch over to WP2 and document System.import() support I’d like to integrate your bundle post-build "size nudge"

🎉 So happy to hear that. It just went into PR phase on WP webpack/webpack#3350.

[gaearon]

Call for help on adding dynamic import support: #1192

[gutenye]

Webpack 2.2 released the Release Candidate

[ianschmitz]

Looks like things are underway to upgrade us to Webpack 2 (#1291).

What's the status on this issue?

[gaearon]

If you have specific suggestions please send PRs and we'll review them! We intend to move to Webpack 2 in 0.10.

[ianschmitz]

I think i have a good sense how this could be quite easily achieved during the production build using sw-precache.

However i'm not sure how we could best manage the sw-precache build artifacts in a typical debug situation -- or if supporting the dev environment is even a requirement for this issue. I suspect there will be significant demand to develop and test with the service worker in place.

It appears we are now using a webpack plugin (HtmlWebpackPlugin) to dynamically inject the bundled scripts into index.html during development. I imagine we could store in memory and serve the build artifacts from sw-precache to achieve something similar if we detect a sw-precache-config.js in place.

[jeffposnick]

@ianschmitz, I'd be happy to assist with a sw-precache-based implementation.

Theoretically, it's the equivalent of jeffposnick/create-react-pwa@c-r-a-0.6.0...c-r-pwa-0.6.0, most likely using either the sw-precache-webpack-dev-plugin or sw-precache-webpack-plugin instead of the CLI so that it integrates alongside the other webpack plugins.

The best way I've found of dealing with the debug/local development scenario is to serve a no-op service-worker.js file when you're using a local development server against src/, and then rely on the generated service-worker.js when serving out of build/. As long as the two servers use different ports the service worker registrations won't clash, even if they're both run on localhost. sw-precache-webpack-dev-plugin might handle this automatically—I haven't fully explored it.

The main pain point that I've seen with this sort of integration in the past (c.f. web-starter-kit, polymer-cli) is explaining to developers that making an offline-first web app means that it's necessary to reload their deployed pages in order to see the latest version of a web app. This can be addressed with explicit developer-facing documentation making it clear what they should expect.

It may also make sense to bake a UI pattern like displaying a "This application has been updated. Please reload." toast into the create-react-app boilerplate HTML, since that tends to be the best way of informing users about updates. (Maybe there's already a standard React component that displays that kind of toast?)

[jeffposnick]

I had some time today to see what it would be like to add in service worker generation by modifying the webpack build inside of react-scripts, instead of running the sw-precache CLI after the build, like I was doing with create-react-pwa.

The changes aren't that bad: https://github.com/facebookincubator/create-react-app/compare/master...jeffposnick:pwa?expand=1

(I may not be following c-r-a best practices by including that extra <script> tag and manifest.json directly in the index.html.)

What makes this nicer than I thought it would be is that NODE_ENV can be queried directly from the client page, and you can avoid registering a service worker unless NODE_ENV=production.

Some things that would still be needed, beyond what's currently in that diff:

• Explanatory README text to help developers understand what it means to deploy an offline-first web app to production. (E.g., changes aren't visible immediately; it takes a reload to display the latest content.)
• Related to that, an out-of-the-box React component that could display a toast which let end users know that the web app has been updated by the service worker, and that they should reload to get the latest version.
• Instructions on how to modify the SWPrecachePlugin configuration if they need to add in runtime caching of non-local resources, or the navigation fallbacks needed to support the non-History API (i.e. <react-router>) use case.

CC: @addyosmani

[jeffposnick]

I've made a few more additions, including documentation that I hope will help developers unfamiliar with offline-first web apps understand what's going on.

https://github.com/facebookincubator/create-react-app/compare/master...jeffposnick:pwa?expand=1 is the current state of things, and I'm going to take another few days to test out some edge cases and re-read through the documentation I wrote before filing a formal PR and soliciting feedback there.

[ianschmitz]

Looking great @jeffposnick!

Have we thought about how we may handle the case where the developer removes the PWA features from the index.js? Do we still want to spit out a service-worker.js into the build directory?

Let me know if I can help at all with the PR!

[jeffposnick]

@ianschmitz my current thinking was to continue building the service-worker.js, because I didn't see a clean way of turning that part off. It won't add any runtime overhead if it's not being used.

But I've added more info the README about not doing the initial registration in the first place, and additionally provided some code for uninstalling a previously installed service worker, for folks who would prefer not to make use of the service worker.

I've got a "dummy" PR to solicit feedback up at jeffposnick#1 prior to filing a PR against this official repo.

[gaearon]

Relevant: #1728

[RohovDmytro]

Relevant #2089