[wp-trac] [WordPress Trac] #36995: Support for Service Workers

[WordPress Trac]

#36995: Support for Service Workers
-------------------------+-------------------------------------------------
 Reporter:  bhubbard     |       Owner:
     Type:  feature      |      Status:  new
  request                |   Milestone:  Future Release
 Priority:  normal       |     Version:  trunk
Component:  General      |  Resolution:
 Severity:  normal       |     Focuses:  javascript, administration,
 Keywords:  needs-patch  |  performance
-------------------------+-------------------------------------------------
Changes (by westonruter):

 * keywords:   => needs-patch
 * version:  4.6 => trunk


Comment:

 After a [https://wordpress.slack.com/archives/C5UNMSU4R/p1518046743000204
 good conversation] in #core-js I want to put forward a plan for adding
 service worker (SW) support in core. Before we can actually start
 leveraging service workers we need to first start supporting them. By
 support I mean core needs a framework for core, themes, and plugins to
 coordinate their respective SW needs (e.g. caching and push
 notifications). The key that highlights the need for this is the fact that
 two service workers cannot be installed and running at the same time
 ([https://stackoverflow.com/a/36004941/93579 so]). While
 [https://github.com/w3c/ServiceWorker/issues/921 eventually] multiple
 service workers may be able to run concurrently in the same scope, the
 only other alternative I'm aware of is to require layering on a middleware
 library on top of the service worker. I don't think that core should
 require using a middleware.

 So I'm proposing a lightweight framework for core to facilitate the
 registration of multiple service workers. Core can create the endpoint and
 when that endpoint is requested then core can respond with the
 concatenated service worker scripts. I think we can create an API that
 follows the same design of `WP_Scripts` family of scripts, with the key
 differences being:

 1. Scripts are registered with filesystem paths as opposed to URLs.
 2. Each script needs to indicate the service worker scope, the default
 being `/`.

 So a function like this:

 `wp_register_service_worker( $handle, $path, $deps, $ver, $scope )`

 (The `$ver` is probably irrelevant here and could be removed since there
 is no need to cache-bust URLs.)

 Here's a couple examples of calls:

 {{{#!php
 wp_register_service_worker( 'foo-front', plugin_dir_path( __FILE__ ) . 'js
 /front-sw.js', array(), 'v1', '/' );
 wp_register_service_worker( 'foo-admin', plugin_dir_path( __FILE__ ) . 'js
 /admin-sw.js', array(), 'v1', '/wp-admin/' );
 }}}

 At the `wp_print_footer_scripts` action a new function like
 `wp_print_service_workers()` can then run which loops over the registered
 service workers to get a set of all the scopes. Then given the registered
 service workers' scopes, the service workers can be installed via:

 {{{#!php
 <script>
 if ( navigator.serviceWorker ) {
         navigator.serviceWorker.register(
                 <?php echo wp_json_encode( wp_get_service_worker_url(
 $scope ) ); ?>,
                 { scope: <?php echo wp_json_encode( $scope ); ?> }
         );
 }
 </script>
 }}}

 Here `wp_get_service_worker_url( 'wp-admin' )` could return a URL like
 `/wp-service-worker.js?scope=/wp-admin/`, with that path being registered
 via `WP_Rewrite`. When the client then fetches this SW URL, this request
 would be served by WordPress PHP. The response would be handled by taking
 the requested scope and obtain all registered service workers with that
 scope and output their concatenated scripts in the order that their
 declared dependencies require.

 The `wp_register_service_worker()` function would be a wrapper around
 `WP_Service_Workers::add()`, where `WP_Service_Workers` is a subclass of
 `WP_Scripts`.

 Thoughts?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36995#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform