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?”. Continue reading “Choosing the Right Front End Tools”
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:
Last week, Google released the newest version of their Angular framework, Angular 4.0. The biggest changes seem to be around creating smaller builds and faster code. Our Solutions Group has several Angular 2 applications in production that we have already upgraded to Angular 4, and I am happy to report that the upgrade was smooth in each case.
If you are wondering if upgrading to Angular 4 is a good idea, I have put together a list of potential questions to help you decide.
Last Friday (3/24) the Angular CLI was released as version 1.0. Our team has been using the CLI for production Angular applications since last August. As the numerous beta and RC versions were released we would update our applications accordingly. There were a few bumps along the way when a new release introduced a breaking change, but for the most part the upgrade path was pretty smooth.
I actually wrote about the Angular CLI a few months ago when it was still in beta. Now that the CLI has reached 1.0 status, I thought it would be a good time to review how we are using the CLI, and what we see as the main benefits.
I ran into a scenario the other day in an Angular 2 app I am working on where I needed to show the same page/route, but with different data and parameters. Without getting into the specifics of my app, the scenario was analogous to this:
I am viewing a page that shows customer contact details. The route pattern could be something like “/customers/:customerId/contact/:contactId”. On the customer contact detail page, we also show a list of links for other contacts with the same customer.
Last week, I mentioned I would be leading a Lunch and Learn for our colleagues at Total Quality Logistics (TQL). We’ve been working with Angular 2 since August 2016, so we have a fair amount of experience with it and want to share our knowledge with other members of the tech community.
The presentation went great—we had well over 50 people in attendance! As attendees munched on IBS-provided sub sandwiches, I spoke about what’s new with Angular 2.