fabbricadigitale / proauth.js Goto Github PK

• serviceWorker's registration path should be configurable (via client's settings)
• end-users should be able to opt-out auto-registration

The console.log used to warn the user about the unsupported synchronous XHR to warnings, using console.warn.

Also accordingly change the the Jasmine spies on them within the xhr-patched.js test file.

Since some of the checks run after a timeout (at the moment 1000ms) after a request is started, we cannot be sure the request was completed, and the test may fail.
This happens a few times, but it shouldn't.

As soon as possible I plan to send our tests on various browsers.

Please help me to define a minimum compatibility matrix.

Refs #7 and #8.

cc @fabbricadigitale/openinnovation.

We need to well define packages scopes and usages.

Rationale

proauth could be used in many ways. Devs could just use it as a standalone library (ie. just adding a <script src="proauth.js></script>) or could bundle it within their apps.
Anyway, some requirements must be met:

1. The proper built file must be chosen (eg. some browsers need transpiled code)
2. Choose the operational mode (default or legacy), usually at runtime because it may depend on feature detection
3. If default mode is chosen, the serviceWorker controller must be included

To make it easy to implement such decisions we must explain in detail where, when, and how provided packages should be used.

Packages

• client src/client.js should be always included in page context by legacy or default. They should import it directly, because it's an always required dependency. client does nothing until the legacy or the default is bootstrapped. End-users should not include include within the page client directly, but in some edge cases they could import it within their own bundle
• legacy src/legacy.js should be included in page context. It loads the legacy stuff and bootstraps the client.
• default src/default.js should be included in page context. It can register the serviceWorker (optionally, opt-out) then when the serviceWorker is ready it bootstraps the client.
• service-worker src/service-worker.js should run within the serviceWorker context. It's required when the default mode is being used. End-users could use it directly by importing it in their serviceWorker installation, or could use default that's register it automatically.

Bundles

Thus, just the following bundles are needed:

• legacy that can be included in page by <script> or imported by end-user app bundle
• default that can be included in page by <script> or imported by end-user app bundle
• service-worker that can be registered as-is (by default) or imported by end-user serviceWorker bundle

IMHO, for any other customisation end-users should import sources not bundles.

Currently, the normal operation mode (i.e. using the ServiceWorker) is not yet implemented.

The legacy mode behaviour should be replicated using the ServiceWorker.

Actually, the internal loader has been removed.
An alternative could be to use an external library to decide which operational mode should be used (so which package file should be loaded).

One for the default library, the other for the legacy one.

This way will be more straightforward to understand compatibilities and to create 2 different browser-support matrices.

To achive this simply use the different saucelabs sub-accounts.

• Merge feature/docs
• Generate diagram images and link within the docs
• Explain how to use packages
• Explain how to use proauth.js with ServiceWorker
• Install section
• Configuration section
• Move the releasing section away from README
• Contributing docs

Sinche the libraries are first bundled (via rollup) and then singularly transpiled (via babel) we lost the sourcemaps (generated in the first phase when BUILD_ENV is set to develop).

1) doesn't refresh tokens concurrently
     Proauth client
     Expected 2 to be 1.
    at test/unit/client/Client.js:244:23
    at <anonymous>

This is likely a race condition

Using Safari 9 under Mac OS El Capitan (10.11) and making an XHR, results in no network request done and in a JavaScript error that complains about the fact that _extendableBuiltin2.apply is not a function.

The strange thing is that _extendableBuiltin2 is a function itself (maybe this is a babel-plugin-transform-builtin-extend bug?).

Using fetch the behaviour is different: the network request is done, but the promise is not resolved.