Angular JS directive manipulating several elements

Question

As I understand, whenever we want to do DOM manipulations in Angular JS for whatever reasons (displaying data, controlling layout behavior, and so on) we should use directives. Now there are times that some DOM manipulation over one element needs info about other DOM elements to act.

One real world example: suppose we want to resize a div to always fit all the screen. So basically the div has one defined height and we want to change this height according to the content and so on to make the div fill the screen. Usually we need to consider other DOM elements like headers and so on when making this kind of manipulation.

Another example is the following: suppose we have a login form, and at the bottom of the form we want a link to allow the user to sign up if he doesn't have an account. When the user clicks the button it should flip the form from login to sign up (usually the other form is coded and hidden). That's fine, if we add a directive on the link to do this it needs to manipulate the form div, and if we put into the form div, it needs to communicate to the link.

In these cases (and I'm really being general, that those are just two possible situations), is there a general guideline on how should we act?

I mean, we have some DOM element <A> and we want to manipulate it somehow, but to do so, we need information about another set of DOM elements <A1>, ... , <An>, so how do we deal with this with consistency?

I've thought on using require and sharing the directive controller. But this is strange, taking again the resizing example we would have <div maintain-height> being maintain-height the directive with the logic to resize this div. Then to communicate with it we would need to put in every other place that triggers a resizing some directive requiring this one. It doesn't seem natural, and in other cases I thought it feels the same.

So, when we have this kind of situation, how can we deal with it maintaing everything well written, maintainable, testable, and etc?

Answer 1

The requirement to do this may indicate an un-angular architecture. Any information you need should be in your view model, either on the current scope or on another scope that you can easily access. You can communicate between scopes by broadcasting (or emitting) messages. You could also put the data you require in a service and inject that into the controller wherever you need it.

If for some reason you must access other elements and read data directly from them you can do this in the normal jQuery / jQLite fashion within a directive. There is also the $document service.

The particular use case you describe seems strange. Why not just use CSS to handle re-sizing DOM elements?

Your other use-case (changing a form) would be handled by a scope variable such as showLogin. The two different forms are hidden or shown according to the value of that variable. Or am I missing something about your requirement?

Answer 2

All DOM manipulation should always always always be done in directives in AngularJS. To share non-DOM data between directives, use controllers and/or services.

In your first use case, I would use something like Twitter-Bootstrap to do responsive stuff. Bootstrap is a CSS framework, though it has JavaScript components in it. One of the CSS components is resizing elements to make them look good on certain screen sizes. Most classes I've seen that deal with screen size have 4 sizes: tiny screens, like smartphone screens, tablet-sized screens, small-to-medium-sized computers, and larger computers. These sizes seem to work except perhaps for sizes directly in between, which I assume are not widely implemented. These classes usually go on container elements, such as <div>s, though there are others which are meant to be attached to headers, etc.

As for your second use case, logging in is always a challenge. I'm not sure how to solve your specific case, as I have not needed to make sites extremely secure, but I would start by defining a variable for logging in in a controller, and use this to decide what login state to put the page in. The variable would make the directive which corresponds to this login state visible, and the others invisible. When the user pressed the link, it would change this variable, which would in turn change the visible directive. I know I said to always do DOM stuff in directives, but this is an edge case, and deals with scopes, which are a controller's purview.

Answer 3

The trouble with DOM dependencies within a directive is that the DOM can mutate and change as directives are compiled and linked.

As long as directives play by the rules, however, you can rely on a few things:

1. During the compilation phase, elements are compiled by walking the DOM tree from parent to child starting from the outer-most element to the inner-most element and calling their 'compile' functions in priority order (highest to lowest).
2. A directive's compile function should only modify it's children (not its parents or grandparents). The reason is that child elements have not been compiled yet so its safe to mutate them, the angular compiler will eventually walk the DOM tree and compile the modified DOM. Parent elements have already been "walked" and the opportunity to compile parent elements has come and gone. If a directive mutated its parents, it would require re-compilation, which is usually not a good idea (infinite recursion).
3. During the (post) linking phase, elements are linked in reverse order that they are compiled. This means that when a directive is being linked, its contents (or children) have already been linked and you can rely on the DOM tree of the children. Parent elements however, have not been linked yet.

So knowing this how could you design a directive that has external DOM dependencies? Well, you would need to know the final state of the DOM after compilation and linking is done. For that, I would recommend at least two directives:

1. A master directive that is placed at highest level where you can expose controller functions that can be called to get external DOM data (based on the current compiled and linked state of its DOM tree).
2. A child directive that is nested somewhere within the master directive that can be notified when the master directive has completed its final Linking phase.

Unfortunately, that does not guarantee that $watch handlers (or even a parent linking function) will modify the DOM in unexpected ways. If you know what directives are at play, you should be able to get this to work reliably.