10:28 p.m.
I can see how it would be nice. I'm a bit worried that the separate
javascript file would simply get out of date and it would also need
separate testing. We're already lacking a bit on testing of the JS adapter
in the first place and this would be yet another thing to test. Is there a
way we could simply have a config option in the current javascript adapter
that allows setting what promise to return? That way it's probably just a
few lines in keycloak.js where it's creating the promise objects to switch
between the two?
On 5 September 2017 at 05:58, Raymond DeCampo <ray(a)decampo.org> wrote:
First, if I were to integrate Promise support into the Keycloak, I
would
be leaving the current javascript adapter as is. This would be an
extension in a separate javascript file so that only developers who are
interested would get the Promise interface. Existing code using the
current adapter would be unaffected. The new code would be a wrapper
around the existing code so that maintenance would only be required if the
javascript adapter API changes.
In terms of browser support, caniuse.com[1] indicates that Promise has
broad support; only IE 11 and Opera Mini fail to support Promise. However
polyfills are available to provide support.
As far as the advantages, the main ones as I see it are: 1) using the
standard promise API makes it easier for developers new to the library; 2)
using the standard promise API makes the library more interoperable with
other libraries; and 3) ES6 Promise objects are chainable making sequences
of asynchronous calls cleaner to code.
I think the MDN page on Using Promises[2] probably makes a better argument
for than I'll be able to here. But the main thrust is that chaining makes
it so it is not necessary to have so many nested functions.
For example, suppose I am writing a javascript client for a REST API
protected by Keycloak. Since the built-in fetch() method returns a Promise
with ES6 Promises I can write:
// assume authz.updateToken() returns an ES6 Promise
authz.updateToken(5).then((token) => {
return fetch(this.ENDPOINT, {
redirect: 'error',
headers: { "Authorization": "Bearer " + token }
});
}).then((response) => {
showResult(response.text());
}).catch((error) => {
displayError(error);
});
}
Since everything is standard, any JS developer would understand the code.
Since both libraries use Promise, I can chain the promises without nesting
functions. And since both libraries use Promise, I can use catch() at the
end for unified error handling whether the error comes from the Keycloak
adapter or from the call to fetch().
[1] http://caniuse.com/#search=Promise
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/
Guide/Using_promises
On Tue, Sep 5, 2017 at 6:18 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> I don't know much about ES6 native Promises. Can you give me some details
> about it? What browser support it? What are the benefits of using that
> instead of our howegrown approach? Etc.
>
> On 4 September 2017 at 20:36, Raymond DeCampo <ray(a)decampo.org> wrote:
>
>> Hello all,
>>
>> I create a wrapper around the javascript adapter which uses ES6 native
>> Promises. (https://github.com/RayDeCampo/keycloak-promise).
>>
>> If you are interested, I can re-package it for inclusion in Keycloak and
>> create a pull request on GitHub. If you have a different process for
>> contributions, let me know.
>>
>> If you are not interested, no hard feelings.
>>
>> Thanks,
>> Ray
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>