I’ve seen people use it by mistake, not understanding how exactly it works and when you should (or shouldn’t) use it. There are also situations where it makes things more explicit and clearer. Let’s dig in!
An example: a password input component
Say we want to create a very simple component that’s used to enter a password. It has all the needed validations, and we’d like to use it throughout our app, wherever the user needs to enter a password.
Our first pass might look something like this:
1 2 3 4 5 6 7 8 9 10
This simply creates a password
input element and allows us to specify a placeholder if it’s empty.
Here’s how you’d use it in a template:
1 2 3
Pretty straightforward, but can you guess what’s bothering me?
placeholder attribute will almost always be a simple string – why does every user of our component need to wrap it in quotes?
Are we saying it would also be acceptable to pass a non string value, like an object?
For exactly this purpose we have the
@ binding – it allows us to specify that we want to receive the string value of the attribute.
bindings definition in our component so
@ makes the password box component a bit slicker:
1 2 3
Angular will now plainly take the value of the DOM attribute (which is always a string) and pass it along to our component.
What if you need the string to be dynamic?
Just because we’re using
@ binding doesn’t mean we will always have to stick with static strings.
For example, we can make the placeholder dynamic:
1 2 3
Angular will automatically interpolate that string whenever
$ctrl.user changes, and that change will be reflected in our password box component!
This is a little gem in Angular that’s worth knowing: it allows us to write easier-to-use components, and provides explicitness. A win-win!
Do you have an existing Angular 1.x app that makes you worried about its future?
You don’t want your app to be left behind and become legacy code.
But it’s not easy clearing the time to learn Angular 2.
And who has the energy to convince management that you need to change frameworks, delay your schedules and do the Big Ol’ Rewrite?
But what if you could make sure your app keeps its options open?
What if you could make it future-proof, all the while shipping features like a boss?
You’ll work in a codebase that uses the latest and greatest, have easy maintenance and happy stakeholders!
The Future-proof Angular Guide can help you get there.
With this no-fluff course you’ll learn how to quickly adapt your existing Angular 1.x app to the latest components paradigm, as you go about your regular work.
You’ll gradually turn your app into something that is modern and idiomatic, converting directives and getting rid of controllers.
And then, once your app is shaped The Right Way™, you’ll be able to keep shipping like a boss, and have your options open.
Sign up to be notified when the course is ready (and get more of these pragmatic Angular posts in the meantime).