Thursday, March 23, 2017

Aurelia View Engine Hook for importing enums, static variables, etc

Thanks to a query from Github user @TheNavigateur asking "Allow[ing] import of exported module items into aurelia template, to allow access to static methods, static variables, enums, type definitions, etc. "

and then Rob Eisenberg's example (issue/comments) of how to do this:

Thursday, March 17, 2016

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.

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: 
Simply have that injected into your component constructor and then call enlist() this will return you a 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?

Thursday, March 3, 2016

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).

Wednesday, March 2, 2016

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.

Wednesday, January 27, 2016

We all make our mountains and we make them as tall as we need them

Putting things into perspective doesn't seem to work well as a coping mechanism.  If we have a problem, it doesn't matter that the problem isn't a big deal to anyone else.  It only matters how large a problem it is to us.  When other people try to minimize a problem (mountain) or put it in perspective, that doesn't help to make our mountain smaller to us, it just minimizes us compared to our mountain.

Friday, January 15, 2016

Aurelia, Firefox and Input fields

I had a mis-behaving checkbox input field on Firefox.  The checkbox was working fine on Chrome and Safari - likely IE as well.  But it wouldn't stay checked on Firefox - kept resetting itself to unchecked.  For the short version, @jsobell on Aurelia's Gitter channel told me that Firefox triggers input attributes based on alphabetical order.  I had a model.bind(), checked.bind(), and change.trigger() on the checkbox in question in that order.  The change.trigger() was running last with the other browsers and first in Firefox.

It was sloppy code on my part, I should have processed everything in the change.trigger function instead of a kludge of model.bind and checked.bind with a change.trigger that was really carrying the main functionality.