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.

Saturday, August 29, 2015

Dynamic input list in Aurelia

I struggled with getting this dynamic form pattern figured out in Aurelia so I'm sharing it here for myself in the future and others that might find it useful.

The features needed are:
  • Automatically add new blank input fields at the end of the list as needed
  • Allow the removal of any items from the list at any point
  • Allow changing any items in the list of inputs

Given lots of help from the Aurelia Gitter channel especially by Jeremy Danyow (@jdanyow) and Io Sulfur (@iosulfur) who created several Plunkrs zeroing in on the right solution, we came up with this approach as demonstrated in the Plunkr below.

Anytime you change the blank item field at the end, it will add another empty input field at the end. If you click on the 'X' button, it will remove that item.

Demo Plunkr

The key things to note in the app.html listing below are that the 'items' in line 6 must be your actual array.  If this is in a nested repeat.for loop and items is made available from the parent repeat.for, this approach will not update the original array only the one that is local to the repeat.for context.

The change.delegate on line 8 adds the blank line using the current index value of the repeat and the change event.  You'll see how they are used in the app.js file below.

The click.delegate very simply removes the input field by splicing out that item from the items array.


The first thing to do is to add a blank item at the end of the items array before we even present it to the View in line 7 of app.js

The addBlank function first sets the current item (based on the $index value passed from the change.delegate function) to the and then blanks out the  We blank out the as otherwise that value gets added to the end of the list of input fields.

We then check to see if the last input field is empty or not, and if it returns true, we push an empty string onto items.  (Note: if anyone can explain why you get the instead of the empty '' string unless we reset the, please post it in the comments - because I've not been able to figure it out.

The removeItem is pretty self-explanatory - so that's all.  Thanks for reading, hope it is useful.

Added (2015-08-30) :  When I tried this with an object as the item, I didn't need lines 12 and 13 in app.js.