AngularJS: To Directive or not Directive?

29 Nov 2014, by Moe in Developer

I seem to be running into this issue a lot, whether something needs to be a directive or just logic in a controller. I like to do a “is it a directive test?” first to really find out if it should be a directive. This consists of a few questions I like to ask so let’s start with the most obvious one.

Will this functionality be reused?
So this is a fairly straight forward question, typically asking the product owner whether we will see the feature again in the future on a different Story. If we get a no, then I stop right here, no need to inquire any further and waste time, the functionality should not be a directive. However, if we are planning on reusing the functionality, then great, we move onto the next question.

Will the reused instance be the same or similar?
Now we need to evaluate whether the next time we use the directive, if it will be the same. Again, we go to the product owner and ask them first. After getting our answer we need to ask the developers to see if it really is the same or not on the technical side. Let’s say the product owner states that the usage will be similar but not exactly the same, at this point we ask the developers if they think the directive should be customized to fit the similar functionality in or decide it’s not similar enough and would defeat the purpose of creating a directive. Moving on, let’s say that future usage is exactly the same to get to our next question.

Are we going to need some setup logic in our controller to handle the directive and is it worth it?
This question is directed to the developers and is mostly a judgment call. Let’s say our directive needs a certain type of list data to work correctly and not each screen is going to have that data readily available in the same format. Do we need to create custom logic each time we need to use it because the data is different? Do we need to handle the data returned differently when saving for example and creating more custom logic? Should the directive be documented somewhere so when the next developer tries to use it, they know how to setup the data? Basically, it’s a judgment call here and varies case by case.

Is it worth the extra effort?
Keep in mind, creating a directive has its caveats, it is non-trivial, and typically will have some unforeseen pitfall involving a complex use case that was assumed to be handled correctly. We need to decide based on the time it will take to create the directive whether it’s worth the additional time it takes compared to programming it directly. We need to weigh all of these factors and make a decision on whether or not we still need to create a directive.

If we found that the answers to the above questions are acceptable then we can move forward with creating a directive. Otherwise, we saved ourselves a lot of time fiddling with something that shouldn’t exist in the first place. Creating well written, reusable directives is not to be taken lightly, you could find yourself stuck in a hole creating workarounds for them leading to flaky code because we are already too invested into the directive and wherever it’s plugged in. That is why it’s important to evaluate the need for a directive before investing too much time and effort only to realize you never reuse it or have to handle each case separately with specialized code for each case.

  • I got to say this was dead on, whoever you work under needs to give you a raise (period).