StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
20726806
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
3
CommunityOwnedDate
CreationDate
2013-12-22T06:17:59.587
FavoriteCount
0
LastActivityDate
2013-12-22T06:35:34.693
LastEditDate
2013-12-22T06:35:34.693
LastEditorUserId
967426
OwnerUserId
967426
ParentId
12164138
PostTypeId
2
Score
70
ViewCount
0
LastEditorDisplayName
text
Body
I beat my head against the wall on this for a couple of days, and I feel that a bit more explanation is in order. Basically, the docs mention that the separation is largely a performance enhancement. I would reiterate that the compile phase is mainly used when you need to modify the DOM BEFORE the sub-elements themselves are compiled. For our purposes, I'm going to stress terminology, which is otherwise confusing: The compiler SERVICE ($compile) is the angular mechanism that processes the DOM and runs the various bits of code in directives. The compile FUNCTION is one bit of code within a directive, which is run at a particular time BY the compiler SERVICE ($compile). Some notes about the compile FUNCTION: <ol> <li>You cannot modify the ROOT element (the one your directive affects), since it is already being compiled from the outer level of DOM (the compile SERVICE has already scanned for directives on that element).</li> <li>If you want to add other directives to (nested) elements, you either: <ol> <li>Have to add them during the compile phase.</li> <li>Have to inject the compile service into the linking phase and compile the elements manually. BUT, beware of compiling something twice!</li> </ol></li> </ol> It is also helpful to see how the nesting and explicit calls to $compile work, so I've created a playground for viewing that at <a href="http://jsbin.com/imUPAMoV/1/edit" rel="noreferrer">http://jsbin.com/imUPAMoV/1/edit</a>. Basically, it just logs the steps to console.log. I'll state the results of what you'd see in that bin here. For a DOM of custom directives tp and sp nested as follows: <pre><code><tp> <sp> </sp> </tp> </code></pre> Angular compile SERVICE will call: <pre><code>tp compile sp compile tp pre-link sp pre-link sp post-link tp post-link </code></pre> The jsbin code also has the tp post-link FUNCTION explicitly call the compile SERVICE on a third directive (up), which does all three steps at the end. Now, I want to walk through a couple of scenarios to show how one might go about using the compile and link to do various things: SCENARIO 1: Directive as a MACRO You want to add a directive (say ng-show) dynamically to something in your template that you can derive from an attribute. Say you have a templateUrl that points to: <pre><code><div><input type="text"><div> </code></pre> and you want a custom directive: <pre><code><my-field model="state" name="address"></my-field> </code></pre> that turns the DOM into this: <pre><code><div><input ng-model="state.fields.address" ...> </code></pre> basically, you want to reduce boilerplate by having some consistent model structure that your directive can interpret. In other words: you want a macro. This is a great use for the compile phase, since you can base all of the DOM manipulations on things you know just from the attributes. Simply use jQuery to add the attributes: <pre><code>compile: function(tele, tattr) { var span = jQuery(tele).find('span').first(); span.attr('ng-show', tattr.model + ".visible." + tattr.name); ... return { pre: function() { }, post: function() {} }; } </code></pre> The sequence of operations will be (you can see this via the jsbin mentioned earlier): <ol> <li>The compile SERVICE finds my-field</li> <li>It calls the compile FUNCTION on the directive, which updates the DOM.</li> <li>The compile SERVICE then walks into the resulting DOM, and COMPILES (recursively)</li> <li>The compile SERVICE then calls pre-link top-down</li> <li>The compile SERVICE then calls post-link BOTTOM UP, so my-field's link function is called AFTER interior nodes have been linked.</li> </ol> In the above example, no linking is needed, since all of the directive's work was done in compile FUNCTION. At any point, the code in a directive can ask for the compiler SERVICE to run on additional elements. This means that we can do exactly the same thing in a link function if you inject the compile service: <pre><code>directive('d', function($compile) { return { // REMEMBER, link is called AFTER nested elements have been compiled and linked! link: function(scope, iele, iattr) { var span = jQuery(iele).find('span').first(); span.attr('ng-show', iattr.model + ".visible." + iattr.name); // CAREFUL! If span had directives on it before // you will cause them to be processed again: $compile(span)(scope); } }); </code></pre> If you're sure that the elements you are passing to $compile SERVICE originally were directive-free (e.g. they came from a template you defined, or you just created them with angular.element()), then the end result is pretty much the same as before (though you may be repeating some work). However, if the element had other directives on it, you just caused those to be processed again, which can cause all sorts of erratic behavior (e.g. double-registration of events and watches). Thus, the compile phase is a much better choice for macro-style work. SCENARIO 2: DOM configuration via scope data This one follows from the example above. Suppose you need access to the scope while manipulating the DOM. Well, in that case, the compile section is useless to you, since it happens before a scope is available. So, let's say you want to pimp out an input with validations, but you want to export your validations from a server-side ORM class (DRY), and have them auto-apply and generate the proper client-side UI for those validations. Your model might push: <pre><code>scope.metadata = { validations: { address: [ { pattern: '^[0-9]', message: "Address must begin with a number" }, { maxlength: 100, message: "Address too long" } ] } }; scope.state = { address: '123 Fern Dr' }; </code></pre> and you might want a directive: <pre><code><form name="theForm"> <my-field model="state" metadata="metadata" name="address"> </form> </code></pre> to auto-include the proper directives and divs to show the various validation errors: <pre><code><form name="theForm"> <div> <input ng-model="state.address" type="text"> <div ng-show="theForm.address.$error.pattern">Address must begin with a number</input> ... </code></pre> In this case you definitely need access to the scope (since that is where your validations are stored), and are going to have to compile the additions manually, again being careful not to double-compile things. (as a side note, you would need to set a name on the containing form tag (I'm assuming theForm here), and could access it in link with iElement.parent().controller('form').$name). In this case there is no point in writing a compile function. Link is really what you want. The steps would be: <ol> <li>Define a template that is completely devoid of angular directives.</li> <li>Define a link function that adds the various attributes</li> <li>REMOVE any angular directives that you might allow on your top-level element (the my-field directive). They have already been processed and this is a way to keep them from being double-processed.</li> <li>Finish by calling the compile SERVICE on your top-level element</li> </ol> Like so: <pre><code>angular.module('app', []). directive('my-field', function($compile) { return { link: function(scope, iele, iattr) { // jquery additions via attr() // remove ng attr from top-level iele (to avoid duplicate processing) $compile(iele)(scope); // will pick up additions } }; }); </code></pre> You could, of course, compile the nested elements one-by-one to avoid having to worry about the duplicate processing of ng directives when you compile the top-level element again. One final note on this scenario: I implied you'd be pushing the definition of the validations from a server, and in my example I've shown them as data already in the scope. I leave it as an exercise for the reader to figure out how one might deal with needing to pull that data from a REST API (hint: deferred compile). SCENARIO 3: two-way data binding via link Of course the most common use of link is to simply hook up the two-way data binding via watch/apply. Most directives fall into this category, so it is adequately covered elsewhere.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhat is the difference between compile and link function in angularjs
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USTony K.
UserOwnerUserId
1. USTony K.
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.