There are 4 posts tagged angular.
It all started with such promise.
You carefully chose how to structure your application. You picked a build system, or not, based on your experience and the community. You planned, and thought, and planned some more.
But then something happened: you made a choice. It seemed like the right choice at the time. You were sure! Well, pretty sure. I mean, how bad could it be if you were wrong, right? … Right?
If you write Angular apps you spent a lot of your time making decisions for your users.
You decide what they will see, and when.
You decide how the app responds to their interactions.
I often struggle knowing which is the right decision.
Like most developers, I spend time seeing what others are doing and try to cherry-pick the good stuff. What follows are some resources that I’ve come across that really help me make better decisions.
The Angular 1.4 release introduced a lot of breaking changes. You might have had trouble upgrading your 1.3 apps (if you even decided to try).
There’s a good run-down on how to migrate your code in the Angular docs. We’ll cover some of the same ground here but also dive into some extra approaches for adjusting your code, as well as some cases I’ve run into where I’ve had to support both 1.3 and 1.4.
Angular UI Bootstrap‘s $modal service has a
$scope argument that lets you assign it whatever $scope you want, so if you wanted your
modal’s controller to use the same $scope as your parent controller you could do that.
But what if you don’t want to use $scope? What if you’re using controllerAs
and you want to keep your code all scope-less, neat, and tidy?
Luckily there’s an alternative. You can send your data to the modal as resolves. Resolves first appeared with ngRoute, as a way to make sure information was available to a route’s controller before the view was initiated. It prevents elements shifting around in your view as data would otherwise be loaded after the view shows up. It also keeps common data-loading tasks out of your controller.
