angular Tag

A couple of weeks ago I attended ComponentsConf 2019 in Melbourne, Australia. This conference focuses on JavaScript frameworks and libraries, and I was pretty excited to attend it. This is because over the last year I have been working on a component library to be shared across a number of projects. It needs to work in everything from Drupal to Angular, and we're still trying to find the best foundation to build it on. A conference that is framework-agnostic seemed like a good place to learn more about the options that are available.

Disclaimer: this approach won’t be suitable for everybody, please factor in your particular requirements before using it.

The Why

Towards the end of 2018, our client started to move our codebase from AngularJS to Angular 7+ (now 8). While this, in itself, is a great move, it completely broke our A/B testing capabilities. (What's A/B Testing?) Implementing deep changes  to our Angular applications would be much more challenging. The methods we used to amend code on bootstrap of AngularJS applications are no longer available in Angular2+. If you are interested in A/B testing in AngularJS applications, you can read about our previous approach and Adobe setup. While some A/B testing can, and should, be done from the backend, this article will focus on the frontend approach.
It was early morning rush hour on Friday, June 22nd, and the Melbourne winter sun shone on my face. I was attending Angular Conf Australia, being held at South Wharf. Arriving with just enough time to spare, I looked around the conference venue and had a quick chat with some of the participants. After a slight delay, the conference kicked-off with a quick thanks to sponsors and supporters. In this post I'm going to give you a rundown of what I saw next.

Every couple of months I'm in a meeting where a couple of developers start arguing about which HTTP status codes to use in their RESTful API, or where they decide to not use HTTP status codes at all and instead layer their own error-code system on top of HTTP.

In my experience, HTTP status codes are more than adequate for communicating from servers to clients. Furthermore, it's preferable to stick with this standard, because that's what most client and server-side HTTP libraries are used to dealing with.

When it comes to which status code to use, the truth is that most of the time it doesn't matter, just so long as it falls within the correct range. In this post I'm going to outline what the important ranges are, and when you should use each one.

If you control both the client and server, these guidelines should do just fine. If you're writing a more generic RESTful service where other people are writing the clients, you may have to be a bit more nuanced. Either way, this rule-of-thumb is a good starting point to work towards the simplest solution possible for your particular problem.

[caption id="attachment_6264" align="alignnone" width="500"]berlin_-_old_and_new A clash of the old-school and new-school[/caption] Over the last couple of years at Shine we’ve built a number of Single Page Apps (SPAs) for large businesses. An app we recently built had to integrate with Oracle Access Manager (OAM), an Identity Management System (IDM) from everybody's favourite enterprise software company. In this post I'm going to talk about a strategy that we used to successfully work around mismatches between the way that SPAs and OAM do things.
blindfold I recently did some preliminary work adding accessibility support to an existing Angular application. At the start of this work I knew very little about website accessibility, and I suspect the evolution of my thinking during the process would be common amongst other developers who have been in the same situation. Specifically:
  1. Initial annoyance at having to do it
  2. Slow progress reworking sections of markup
  3. Growing satisfaction that the app was becoming accessible to a broader audience
  4. The realisation that the codebase itself was actually better off for the process
In this post I’ll talk about the 3 things that I’ve done so far during this journey to an accessible Angular app: accessible icons, keyboard navigation and finally, ARIA support.