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.
- Do I put this widget on the left or the right?
- Do I only show one at a time, or multiple?
- Do I separate things into different sections or have a long page where it’s all available at once?
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.