naschq / dsw Goto Github PK

There should be a way for us to require it, and use it programatically, so there could be grunt or gulp tasks, for example.

There may be an API for connecting and listening for WebSockets.
As well as a way to intercept and use data from websockets (even if the script is not using the DSW api itself).

This will allow us to use the matching values from our configured regular expression, straight into our fetch or redirect actions.

In the section "Contributing" we should have a step for npm install.

Cache API allows us to set the expiration headers.
We could add some examples using this.

We should definitely have a way to define for how long the user will stay waiting for a request before we kill it and deliver something else (like a custom page or default value).

➜  dsw git:(master) git submodule update --init --recursive
No submodule mapping found in .gitmodules for path 'boilerplate'
➜  dsw git:(master)

maybe .gitmodules file is missing?

just run again the dsw command line on your project

I'm following the docs and then suddenly I get the instruction above.
I'm confused because at this step I never used the dsw command yet.

Also, I don't get yet why do we need the dsw globally 😕

I followed the documentation and I got this error in the console when I tried to run my index.html file.
I'm missing something?

Looking at the code, the error is related to IndexDB I think:

function getObjectStore(dbName) {
    var mode = arguments.length <= 1 || arguments[1] === undefined ? 'readwrite' : arguments[1];

    var db = dbs[dbName],
        tx = db.transaction(dbName, mode);
    return tx.objectStore(dbName);
}

As of right now its "main": "./lib/dsw.js" however that file is related to the bin processes and the try and start npm scripts not the actual program itself. So when you are importing this library into a project its pulling in lib/dsw.js but it should be pulling in src/main.js.

There's something wrong in the README file on the Using it section, specifically on the 3rd step.

It is very important that we can have some unit tests (or perhaps using the lighthouse in an automated way).

Feature Request

There should be a way for developers to specify a bundle.
When fetching one url, it could then download and store in cache the "most likely to be used" files in future.

Use case:

When the user fetches the kart page, it could pre-load and cache the scripts, html and styles for the purchase screens as they are probably intending on finish the purchase.

"rules": {
  "purchaseIntension": {
    "match": "/my-kart.html",
    "apply": {
      "bundle": {
        "files": [
          "purchase.js",
          "purchase.css",
          "some-image.png",
          "purchase.html"
        ],
        "expires": "30m"
      }
    }
  }
}

It must be easy to ask for permissions, enable and trigger notifications using an API from DSW.

We could have a script to use with npm that would create the manifest itself, for Progressive Web Apps.

Perhaps it's a good thing to show what is the current browser support for Service Worker in the docs somewhere.
@jakearchibald's isserviceworkerready is a good place to get this information.

We should be able to pick a caching strategy.
Something like: keepUpToDate, networkFirst or cacheFirst

Line 44 require(finalPath) is a critical dependency. Not a huge issue but it will throw an error if users are using webpack.

There should be a panel or tool with some UX for debugging the requests.

We already can use the trace method to get the debugging information:

DSW.trace('.*', function(traceData){
    console.log(traceData);
});

All we need is a better way to show the information, and perhaps to define the traced requests.

There must be support for push notifications in the API.

The idea is to have support for defining how to store data (from requests to json files) straightly in the indexedDB, so developers can use and access it.

We can use the command npm show dsw version to know if it is running on its latest version, and ask the user to update it, if it is not.

Hi there,

Am just reviewing solutions for offline caching, and found your project, it looks great!!

I have a quick question with regards to being able to map local endpoints to remote endpoints with dsw.

For some background, our application needs to source large user assets from remote CDN stores, and was wondering if dsw provides a facility for mapping / caching assets hosted on remote domains. We have done some local testing here, and it seems technically feasible with Service Workers.

An example of what we are imagining would be..

https://local.com/bucket/video.mp4 # virtual local path

to be intercepted and rewritten as...

https://remote/bucket/video.mp4 # rewritten endpoint

where dsw would source the remote asset (via CDN) and cache the response against the virtual local path. Was looking for a configuration perhaps similar to the following.

mappings: {
   local: "/bucket",
  remote: "https://remote/bucket/"
}

Again, the DSW solution looks fantastic! Look forward to hearing back.

S

We should be able to know exactly what was the life cycle from a request.
It should tell us the rules and steps it took to get the final result.
Also, a panel for that on the page would be pretty useful.