Aurelia custom element async life cycle event

I saw a really good conversation in the Aurelia/framework Github issue queue that I wanted to save for later.  https://github.com/aurelia/framework/issues/367#issuecomment-198104416

From Rob Eisenberg:

We can't provide this (async promise life-cycle events) across all components. It would be a disaster for performance and would no longer map in any way to web components. 

If you don't care about web components, you can use the new CompositionTransaction: http://aurelia.io/docs.html#/aurelia/templating/1.0.0-beta.1.1.2/doc/api/class/CompositionTransaction 

Simply have that injected into your component constructor and then call enlist() this will return you a CompositionTransactionNotifier: http://aurelia.io/docs.html#/aurelia/templating/1.0.0-beta.1.1.2/doc/api/interface/CompositionTransactionNotifier 

You can call done on that when your async operation is complete. The global composition will wait to attach until after you are done.

How do I wait for async data for an Aurelia custom element?

JSON Web Token payloads

I really like the JSON Web Token (JWT) technology for Single Page Application (SPA) user authentication.  I started off quite excited about storing things like permissions and other user profile data in the JWT.  My initial thoughts around JWT is that it was a good ‘state’ variable to hold user profile information on the client side.

The problem with that idea is that it is hard to expire and update a JWT if the user changes their display name or gets new permissions/claims.  If your SPA client is using the JWT payload to hold this mutable (server side mutable) information, your client won’t be updated in a timely manner - it will have to wait for a new JWT to be issued.  It is a little mean to require the user to logout and back in again to be able to use their new permissions or see their new display name show up on the web application.

Don't get me wrong, I'm not talking about concerns of the client side manipulation of the JWT payload.  I don’t trust anything from the client side.  Anything coming from the client has to be checked/validated on the server.  I know the new permissions really matter on the server side, but I would generally only allow users to see functionality that they are permitted (not that they can’t hack the front end code and do whatever they want on the front end - they just would not be able to complete the transaction on the server).

Aurelia delegate vs trigger

Great StackOverflow answer: Aurelia delegate vs trigger question

Aurelia change event Firefox woes

In the continuing adventures of Firefox vs other browsers (see Aurelia Firefox and Input fields), I was watching a checkbox using a change.trigger() to update the checkbox selection state for a search facet.  I noticed in Firefox that the change event checkbox selection value was pre-change vs Chrome and other browsers where the selection value was post-change.

Gitter Aurelia conversation discussed the issue and approach to fix it.

Using change.delegate gives the change event time to finish processing before it's handled.  I'm a little concerned about timing issues still as this doesn't seem deterministic, but it's working pretty well now.