The AngularJS documentation is great for getting started and for looking up specific API calls. However, it doesn't really tell you how to organize and manage your app as it grows to tens or hundreds of thousands of lines of code. I've collected here some of my observations and best practices for how to manage your sprawling application. First we'll take a look at organization, then move on to some tips on improving performance, and conclude with a brief summary on tools, servers, and build processes. While this post will focus on big apps in particular, there's a great video on YouTube from the December 2012 AngularJS meetup on best practices that's also worth checking out.
This week we’re going to look at form validation with AngularJS. Angular has several directives that support form field validation, and they’re based on theHTML5 form validators. You can specify that a field is required, a certain size, a certain type, and should match a given pattern.
I have been working a lot with Angular.js lately, and love how easy it makes it to create web applications with rich client-side functionality. It's an extremely useful asset in keeping your own client-side code lean, making it easy to separate business logic and declarative markup for anything view specific. However, it's not all roses, and I'm still struggling to find the best solutions to some problems I have encountered. One of which is a problem that exceeds the scope of Angular...
I have just been learning AngularJS and decided to build demo application that cover more techniques than the tutorial on angularjs.org. This application is only demo so it do not have complete server side, some features have the todos and there is not any test.
This demo application is some kind of automotive adverts portal, so I called it MotoAds. It has two main features:
* List of adverts – includes an advanced filtering and sorting.
* Add advert – a form with some client side field validations.
Let’s explore how to use Decorators to enhance AngularJS logging and supercharge the $log service. AngularJS has a great hidden feature $provider.decorator() that allows developers to intercept services and substitute, monitor, or modify features of those intercepted services. The decorator feature is not deliberately hidden… rather it is masked by so many other great AngularJS features. In this article, I will introduce the Decorator and show how to incrementally add functionality to the $log service… with practically no changes to your custom services and controllers.
Over the last few months, I've been digging into the Angular framework. One of the things that I really like about Angular, and hope to learn to use extremely well as I progress, is their notion of a "Directive". Directives provide a means for extending both the semantic meaning and functionality of your markup. There are many different ways to implement directives, and the documentation on the angular site is still a work in progress, so I would like to share how I've used them up to this point.
Angular.js is built from the ground up with testing in mind. In our opinion this makes Angular different from all other frameworks out there. It is the reason we chose it.
This testability is due to the feature set of Angular and the tooling available. Feature wise,dependency injection (DI), modules, directives, data binding, and the internal event loop all work together to create a testable architecture.
Angular maintains its own event loop outside the browser event loop to do dirty checking and make sure data is in sync. It will check all known objects for changes on every loop tick. This is done asynchronously. Because this loop is maintained by Angular, you can flush the queue of any outstanding request or pending change at any time, meaning you can test async code in a synchronous manner.
The test runner Karma, makes testing directives exceptionally easy. It transparently loads your templates as scripts and exposes them as Angular modules. You can use the same concept to package your app for production.
This article covers the additional changes that has been made to my angularjs-localizationservice project out on GitHub.
The new service, has the following new features:
A new directive to help improve performance and handle dynamic localized resource stringsUpdated the localize service to allow changing of the language on the flyFixed an issue with getLocalizedResourceString to be more efficient and simpler
AngularJS Directive is what we have close to Web Components at this time and is the most crucial and difficult piece in AngularJS. I’ve not found any suitable article on the web to fully understand directives behavior based on options it takes so I’m writing one. Fingers crossed!
One of the most frequently asked questions we get is when would Angular be a poor choice to use as a framework. Our default answer is usually when writing games as Angular has it’s own event loop handling (the $digest loop) and games usually require lots of low-level DOM manipulation. This is an inaccurate description as there are manytypes of games where Angular can support. Even games that require heavy DOM manipulation can use the angular framework for the static parts, such as tracking high scores and game menus.
Here are a comparison of technologies adoption, thanks to the "google trends" tool, each comparing :
angularjs tutorial (in red) vs [techname] tutorial (in blue)
The word "tutorial" help here to avoid noise signal due to ambiguous name (jsf is a too generic acronym), and it also help to detect which technology people will in adopt in the very near future (thus avoiding noise due to maintenance on an old technology).
The date following indicates when AngularJS overrun the [techname] technology.
Front-end application frameworks have given developers the tools to build client side applications with rich user experiences. Let’s say your application is built with one of these frameworks and you want to notify connected clients that something on the server has changed – how can you do that while keeping a rich user experience? This is wherePusher and angular-pusher come into play.
The Chrome web browser is Google’s custom browser. Not only is it incredibly speedy and on the bleeding edge of web development, it is at the forefront of delivering web experiences both on and off the web.
Chrome apps have access to the Chrome API and services and can provide a integrated desktop-like experiences to the user.
One more interesting differentiation between Chrome apps and webapps is that they always load locally, so they show up immediately, rather than waiting for the network to fully download the components. This greatly improves the performance and our user’s experience with running our apps.
In this article, we’ll walk through how to create an advanced Chrome application using Angular.
Welcome to the final article in a series on my experience developing with AngularJS. I learned its concepts, beat my head against-the-wall with and finally tamed it enough to create a "My Dashboard" feature for a client. For previous articles, please see the following:
Part I: The BasicsPart II: Dialogs and DataPart III: Services
The last mile of development for the My Dashboard feature was to spice things up a bit and make it look better. We hired a design company to come up a new look and feel and they went to work. Within a week, we had a meeting with them and they presented a few different options. We picked the one we liked the best and went to work. Below are screenshots that I used to implement the new design.
One of the tasks I find myself performing a lot when building Line of Business (LOB) applications is displaying dialogs. Some of the dialogs are modal (the user can’t click on the background to dismiss it) and some are non-modal. For example, I’m currently working on a LOB application that displays modal dialogs as users delete items on a page.
Angular offers several ways to interact with data from the server. The easiest way is to use the$resource factory, which lets you interact with RESTful server-side data sources. When we started the My Dashboard project, we were hoping to interact with a REST API, but soon found out that it didn't have all the data we needed. Rather than loading the page and then making another request to get its data, we decided to embed the JSON in the page. For communication back to the server, we used our tried-and-true Ajax solution:DWR.