Recently, I had the opportunity to meet with a client that was in the process of deciding on a front-end technology for their dev team to use. They already did quite a bit of research and formed some opinions about different technologies, and wanted to get our opinion about the way they evaluated their options. One point I made early on in our discussion was that there is no one “right” answer to the question of “which tool(s) should we use?”. Read more
Category Archives: Angular 2
Interactive Business Systems is now Planet Technology. Looking for a new job? We work with some of the biggest names in tech, and we’re hiring! Check out our open jobs and make your next career move with Planet.
When working with Angular Routing, it’s very useful to be able to respond to routing events – the most obvious and useful being when the route changes. In AngularJS this was accomplished with by attaching a callback function to one the “$routeChange” events on the $scope. In Angular the concept is similar but has some key (and in my opinion, useful) differences.
Once you have a reference to the Router for your application you can subscribe to its “events” observable. This observable will emit a route-event whenever applicable that you can listen for. Being an observable you can subscribe to it in multiple places, filter for the specific event you want, transform the raw event, or anything else you could do with an observable.
Most of Angular is different than Angular 1.x, but one of the idioms that stayed the same was the use of class names to identify form fields that had validation errors (e.g. ng-invalid, ng-dirty, ng-touched etc). By checking for different combinations of these classes, you can tell which fields are invalid, have been modified (“ng-dirty”), and had focus at some point (“ng-touched”). However, this had a tendency to lead to some rather verbose and messy view code just to show/hide a validation message: