The Fancy Hands dashboard has seen a number of different iterations. At first, you couldn't even call it a 'Dashboard', it was merely an input field and a text area where you would write and send your request. Since then it has evolved to be more of a central place where you can create new requests, browse your old ones and see your usage statistics. With our latest iteration, the design has shifted to a more modern theme that places more emphasis on what's important to you right now. One of the biggest changes though, has less to do with the design and more to do with the way the front-end is architected.
Well… simply because we were already using it for small things on the site here and there. Last year we leveraged the framework to create a simple forum for our assistants. We also used it to rebuild our TeamWork dashboard. One of the nice things about Angular is that you can use it in conjunction with whatever framework you already have in place, and use it as you see fit.
So why use it in the first place?
One of the main benefits of Angular is it’s two way data binding system. Meaning that if something changes in the model, it will automatically get updated in the view and vice-versa. The beauty of this really begins to shine when you are able to get rid of all your jQuery code that targets certain id’s only to update some text. Instead, the views get updated seamlessly once the model is updated. You then are able to build views that automatically update to reflect the state of a model. For example, in the new Fancy Hands dashboard when you load up a request and send a reply to an assistant. What happens is the reply gets sent via an ajax call to our server, the server then responds with a JSON object containing a list of all the messages associated with that request (including the new one). We then set the newly retrieved list of messages as our model, and BAM, our view gets updated automatically with the message we just sent. No fussing around with jQuery trying to recreate the message template, the new message just appears as it should.
So what do you mean by Decoupling the Dashboard?
The main goal was to move from server side rendering of the templates to client-side. By doing this, we could keep front-end concerns out of the server-side logic as well as build a more fluid UI.
Angular, and frameworks like it, work astoundingly well when you have an API you can hit that spits back JSON. We fortunately already had most of our private API built for use with our mobile apps. With just a few tweaks here and there, our API could be used to power the entire dashboard and request pages.
Before, the process of rendering a page was like this: User sends request -> server makes appropriate database requests -> server renders values onto template -> server serves the fully rendered page. This often resulted in long wait (4 seconds + )periods between pages where the server rendered the template.
Now, leveraging Angular and our API, all of the view logic is done client side instead of server side. The flow looks like this now: User sends request -> Multiple (if necessary) ajax calls get sent to the server (API) -> Server responds with JSON -> client asynchronously updates each part of the UI as necessary. The great thing about this method is that instead of having a 4 second wait between pages, we can now instantly show the user an updated view when they click, and load in content as soon as we get it. The result is an app that feels a lot more fluid and a lot more responsive.
As an added bonus, we’re able to easily cache request data locally. Since we’re dealing with JSON objects exclusively, we can store the data we receive into localStorage and then load it up on subsequent visits. The result is a dashboard that is even faster since we don’t have to wait for the server to respond at all.