Since the very early days of Angular, directives have been one of the gnarliest pieces to grok and wrap your head around.
There have been countless of posts on forums and groups asking what exactly are directives and what should they be used for? And thousands of words were published trying to answer these questions.
But, most of those no longer hold true. If you’re just getting into Angular 1.x, most of what you’ll find online about the role of directives is outdated.
And if, on the other hand, you’ve been doing Angular for quite some time now, then you should know that things have changed. The community is flowing in a different direction, and you should get with it (or at least know what you’re missing out on).
The “old” thinking behind directives
In the first version of Angular, controllers were held as a very big part of the framework where most of the logic would lie.
Directives, it was commonly said, should be used only for DOM manipulation or for reusable components.
When learning Angular, you’d be told that you can wait with learning about directives, since you rarely write ones yourself. After all, with the awesomeness of Angular you don’t need to reach your hands down to the DOM on a daily basis.
And, really, how many reusable components do you write in a given week?
The new standard – directives and components for ALL THE THINGS
Over the past year, Angular 2 has matured and the migration path to it is getting clearer. With that, the Angular team have been moving Angular 1.x towards these new concepts.
We know that controllers are gone in Angular 2, and you should be killing yours.
The old/new stars are directives, mostly in their fancy new cloths as components.
And you should basically no longer be writing any controllers that are not directive-controllers or component-controllers.
Yes, even if that directive is not reusable at all and will only be used in a single place. And even though there’s no DOM manipulation going one.
The world is changed. Do not shy away from directives. Nowadays, Angular consists of UI code in directives/components and logic in services. That’s it.
What to use directives/components for
- Reusable components
- DOM manipulation
- Wrapping up non-Angular widgets
- Non-reusable components (e.g. just breaking up a bigger component to smaller pieces)
Basically, the rule of thumb is: don’t use controllers, put logic in services, everything else is in components.
Do you have a big Angular 1.x app that you’re scared will rot and become legacy code? Because 2.0 and TypeScript will soon be the new shiny yet you have all this JS code sitting there? Where will your team find the time, and management approval, to learn and move things to 2.0?
But what if you could migrate your project, incrementally, while keeping your time’s pace and shipping awesome code? What if your team could learn a bit more Angular 2 with each task? Imagine you could get to be working in 2.0 land without ever stopping your development!
I’m cooking up a self-served course that will get you there. It will allow you, on your own pace, learn Angular 2 and TypeScript bit by bit. With those steps your team will migrate your project and soon you’ll write all your new code with Angular 2, TypeScript, and won’t have to stay behind.
Sign up to be notified when the course is ready (and get more of these pragmatic Angular posts in the meantime).