README.md in serviceworker-rails-0.3.1 vs README.md in serviceworker-rails-0.4.0
- old
+ new
@@ -1,11 +1,33 @@
# ServiceWorker::Rails
[](https://travis-ci.org/rossta/serviceworker-rails)
-Use [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) with the Rails asset pipeline.
+Turn your Rails app into a Progressive Web App. Use [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) with the Rails asset pipeline.
+## Why?
+
+The Rails asset pipeline makes a number of assumptions about what's best for deploying JavaScript, including asset digest fingerprints and long-lived cache headers - mostly to increase "cacheability". Rails also assumes a single parent directory, `/public/assets`, to make it easier to look up the file path for a given asset.
+
+Service worker assets must play by different rules. Consider these behaviors:
+
+* Service workers may only be active from within the scope from which they are
+served. So if you try to register a service worker from a Rails asset pipeline
+path, like `/assets/serviceworker-abcd1234.js`, it will only be able to interact
+with requests and responses within `/assets/`<em>**</em>. This is not what we want.
+
+* [MDN states](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API#Download_install_and_activate) browsers check for updated service worker scripts in the background every 24 hours (possibly less). Rails developers wouldn't be able to take advantage of this feature since the fingerprint strategy means assets at a given url are immutable. Beside fingerprintings, the `Cache-Control` headers used for static files served from Rails also work against browser's treatment of service workers.
+
+We want Sprockets to compile service worker JavaScript from ES6/7, CoffeeScript, ERB, etc. but must remove the caching and scoping mechanisms offered by Rails asset pipeline defaults. This is where `serviceworker-rails` comes in.
+
+*Check out the [blog post](https://rossta.net/blog/service-worker-on-rails.html)
+for more background.*
+
+### Demo
+
+See various examples of using Service Workers in the demo Rails app, [Service Worker Rails Sandbox](https://serviceworker-rails.herokuapp.com/). The [source code](https://github.com/rossta/serviceworker-rails-sandbox) is also on GitHub.
+
## Features
* Maps service worker endpoints to Rails assets
* Adds appropriate response headers to service workers
* Renders compiled source in production and development
@@ -24,51 +46,183 @@
Or install it yourself as:
$ gem install serviceworker-rails
-## Usage
+To set up your Rails project for use with a Service Worker, you either use the
+Rails generator and edit the generated files as needed, or you can follow the
+manual installation steps.
-To use `serviceworker-rails` in a Rails app, install the gem as above. When
-`serviceworker-rails` is required, it will insert a middleware into the Rails
+### Automated setup
+
+After bundling the gem in your Rails project, run the generator from the root of
+your Rails project.
+
+```
+$ rails g serviceworker:install
+```
+
+### Manual setup
+
+Let's add a `ServiceWorker` to cache some of your JavaScript and CSS assets. We'll assume you already have a Rails application using the asset pipeline built on Sprockets.
+
+#### Add a service worker script
+
+Create a JavaScript file called `app/assets/javascripts/serviceworker.js.erb`:
+
+```javascript
+// app/assets/javascripts/serviceworker.js.erb
+console.log('[Service Worker] Hello world!');
+
+function onInstall(event) {
+ event.waitUntil(
+ caches.open('cached-assets').then(function prefill(cache) {
+ return cache.addAll([
+ '<%= asset_path "application.js" %>',
+ '<%= asset_path "application.css" %>',
+ '<%= asset_path "admin.css" %>',
+ // you get the idea ...
+ ]);
+ })
+ );
+}
+
+self.addEventListener('install', onInstall)
+```
+
+For use in production, instruct Sprockets to precompile service worker scripts separately from `application.js`, as in the following example:
+
+#### Precompile the asset
+
+```ruby
+# config/initializers/assets.rb
+
+Rails.application.configure do
+ config.assets.precompile += %w[
+ serviceworker.js
+ ]
+end
+```
+
+#### Register the service worker
+
+You'll need to register the service worker with a companion script in your main page JavaScript, like `application.js`. You can use the following:
+
+```javascript
+// app/assets/javascripts/serviceworker-companion.js
+
+if (navigator.serviceWorker) {
+ navigator.serviceWorker.register('/serviceworker.js', { scope: './' })
+ .then(function(reg) {
+ console.log('[Page] Service worker registered!');
+ });
+}
+
+// app/assets/javascripts/application.js
+
+// ...
+//= require serviceworker-companion
+```
+
+#### Add a manifest
+
+You may also want to create a `manifest.json` file to make your web app installable.
+
+```
+// manifest.json
+{
+ "name": "My Rails App"
+ "name": "My Progressive Rails App",
+ "short_name": "Progressive",
+ "start_url": "/"
+}
+```
+
+You'd then link to your manifest from the application layout:
+
+```html
+<link rel="manifest" href="/manifest.json" />
+```
+
+#### Configure the middleware
+
+Next, add a new initializer as show below to instruct the `serviceworker-rails`
+middleware how to route requests for assets by canonical url.
+
+```ruby
+# config/initializers/serviceworker.rb
+
+Rails.application.configure do
+ config.serviceworker.routes.draw do
+ match "/serviceworker.js"
+ match "/manifest.json"
+ end
+end
+```
+
+#### Test the setup
+
+At this point, restart your Rails app and reload a page in your app in Chrome or Firefox. Using dev tools, you should be able to determine.
+
+1. The page requests a service worker at `/serviceworker.js`
+2. The Rails app responds to the request by compiling and rendering the file in `app/assets/javascripts/serviceworker.js.erb`.
+3. The console displays messages from the page and the service worker
+4. The application JavaScript and CSS assets are added to the browser's request/response [Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache).
+
+#### Using the cache
+
+So far so good? At this point, all we've done is pre-fetched assets and added them to the cache, but we're not doing anything with them yet.
+
+Now, we can use the service worker to intercept requests and either serve them from the cache if they exist there or fallback to the network response otherwise. In most cases, we can expect responses coming from the local cache to be much faster than those coming from the network.
+
+(...more coming soon, WIP)
+
+## Configuration
+
+When `serviceworker-rails` is required in your Gemfile, it will insert a middleware into the Rails
middleware stack. You'll want to configure it by mapping serviceworker routes to
-Sprockets JavaScript assets, like the example below, in `application.rb`.
+Sprockets JavaScript assets in an initializer, like the example below.
```ruby
-# application.rb
+# config/initializers/serviceworker.rb
-config.serviceworker.routes.draw do
- match "/basic-serviceworker.js"
+Rails.application.configure do
+ config.serviceworker.routes.draw do
+ # maps to asset named 'serviceworker.js' implicitly
+ match "/serviceworker.js"
- match "/proxied-serviceworker.js" => "nested/asset/serviceworker.js"
+ # map to a named asset explicitly
+ match "/proxied-serviceworker.js" => "nested/asset/serviceworker.js"
+ match "/nested/serviceworker.js" => "another/serviceworker.js"
- match "/nested/serviceworker.js" => "another/serviceworker.js"
+ # capture named path segments and interpolate to asset name
+ match "/captures/*segments/serviceworker.js" => "%{segments}/serviceworker.js"
- match "/header-serviceworker.js" => "another/serviceworker.js",
- headers: { "X-Resource-Header" => "A resource" }
+ # capture named parameter and interpolate to asset name
+ match "/parameter/:id/serviceworker.js" => "project/%{id}/serviceworker.js"
- match "/*/serviceworker.js" => "serviceworker.js"
+ # insert custom headers
+ match "/header-serviceworker.js" => "another/serviceworker.js",
+ headers: { "X-Resource-Header" => "A resource" }
+
+ # anonymous glob exposes `paths` variable for interpolation
+ match "/*/serviceworker.js" => "%{paths}/serviceworker.js"
+ end
end
```
-`Serviceworker::Rails` with insert a `Cache-Control` header to instruct browsers
+`Serviceworker::Rails` will insert a `Cache-Control` header to instruct browsers
not to cache your serviceworkers by default. You can customize the headers for all service worker routes if you'd like,
such as adding the experimental [`Service-Worker-Allowed`](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-allowed) header to set the allowed scope.
```ruby
config.serviceworker.headers["Service-Worker-Allowed"] = "/"
config.serviceworker.headers["X-Custom-Header"] = "foobar"
```
-### Demo
-
-Check out the demo application, [Service Worker on Rails](https://serviceworker-rails.herokuapp.com/), to see various examples of using Service Workers in a Rails app.
-
## Development
-After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
-
-To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
+After checking out the repo, run `bin/setup` to install dependencies. Then, run `bin/rake` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
## Contributing
Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/serviceworker-rails. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.