Modeling Data and State in Your AngularJS Application Respect your data. Contain your state. Data and state are the foundation of your application. These two items should be absolutely respected. I’ve written about this in the past, in the context of ActionScript 3 and the Robotlegs framework. What is a Model? A model notifies its associated views and controllers when there has been a change in its state. As the “M” in MVC, model classes encapsulate your application’s data and provide an API to access and manipulate that data. An example of this might be a shopping cart. In addition to controlling access to data, models maintain the state of your application. As you can see, data and state are intimately related. Models are portable. The model is the core of your application. We’ve dug into what a model is, but if you’re like me, you are waiting to see how to actually use models within an AngularJS application, so let’s take a look at that. Exploring the Code This “everything stuffed in a controller” approach works, but we can do better.
Using AngularJS? Stop using jQuery as a crutch. Photo Credit: Timothy Tolle Have you ever heard (or said!) this: “Directives? That’s where the jQuery goes.” I definitely have. In an effort to better understand @joshdmiller’s excellent ng-boilerplate, I wanted to understand its dependency on Boostrap. Up until this point, I’ve completely ignored angular-ui-bootstrap, which is a wrapper for Twitter Bootstrap that you can use with AngularJS. From the angular-ui-bootstrap README: We are aiming at providing a set of AngularJS directives based on Twitter Bootstrap’s markup and CSS. This struck me. The only dependency that ui-bootstrap has on Twitter Bootstrap is the CSS style sheets. I was reading through some posts on the Google groups in my earlier quest to find out how to integrate Foundation into ng-boilerplate (I’m stubborn!) You can wire up some callbacks and $apply calls to make a jQuery plugin work but as Pawel said, rewriting something in AngularJS often takes less work. jQuery doesn’t have any of the binding or scope magic. P.S.
AngularJS Modules for Great Justice | Coding Smackdown TV First off I want to thank Joel Hooks of the DFW Area AngularJS Meetup Group for suggesting this topic and providing the title. “Modules provide an excellent mechanism for cleanly dividing up our code into functional areas. Angular allows us to use modules in many ways. Let’s take a look at modules and some of the approaches we can leverage to produce cleaner more manageable code.” – Joel Hooks So with that, let’s get started. As long as I have been developing with AngularJS there has always been the great best practices debate over how to structure your application. Both have their advantages and disadvantages so let’s take a quick look at each before we get into how to implement each using AngularJS. Package by Feature Package by Feature became popular in the Java development camp a few years back. Package-by-feature uses packages to reflect the feature set. A good example of Package by Feature, is the angular-sprout seed project. Package by Layer Tiny Projects <! Small Projects <!
AngularJS – usin’ $apply AngularJS is pretty neat. the simplest and most-common tasks are super-easy, but sometimes there’s some little trouble, especially if you try to do things in a less-AngularJS way. like many modern libraries, it seems, AngularJS suffers from a severe lack of accessible documentation. for example, $apply is described as follows: $apply(exp)$apply() is used to execute an expression in angular from outside of the angular framework. (For example from browser DOM events, setTimeout, XHR or third party libraries). it then goes on to completely fail to provide any actual example usage. example usages, you guys! so here’s some example usage for you: and again, if you want an entirely-AngularJS solution, directives have got you covered. best of luck to you figuring out how to use those from the documentation.
eburley.github.com angularjs.org watch, on pub sub, and you. A team I work on has been using angularjs.org’s various watch and event systems for more than half a year now, and I wanted to put out some best practices that we’ve learned from painful experience. When to use a watch: when you’re writing a directive and want data binding behavior when you’re watching a stateful service when it’s OK for the ui and state update to happen in a non-deterministic order When NOT to use a watch: when you need to orchestrate complicated data loading patterns when you’re watching the routeParams. Best practices around watches: check for newValue ! $scope . just do this: $scope . When to use pub/sub: when you need to let multiple subscribers know about an event and those subscribers need to do more than radiate information to their view. When NOT to use pub/sub: when you’re watching a simple state based service and using that to update a view. Best practices around pub/sub: there’s also a fiddle showing this in use.
Simulating Latency for AngularJS $http Calls with Response Interceptors | Brillskills When writing an AngularJS application that communicates with back-end services via XHR calls, you need to cater for the latency that will occur when users are accessing the application for real over slow connections. This usually means showing things such as loading indicators when long running requests are in progress. However, when in development, the back-end servers may be located on localhost, or another machine on the local network, leading to no appreciable delay when requests are made. To help develop and test the application, it can be useful to simulate higher latency, of say a few seconds. In this case, I don’t want to change the response in any way, I just want to delay it. The handler needs to be registered with the $httpProvider, not with the $http service itself. You can see a working example in this Plunkr. Even with the simplification of async that promises give us, there’s a bit to unpick here. The handler function takes a single parameter called promise.
Adventures in Software With Joel Hooks - @jhooks