I wrote an attribute restricted Angular directive (restrict:'a') that adds features to textarea. It makes no sense to apply it to any other type of element.
Adding a if (element.nodeName == 'TEXTAREA') { is really dirty and unreliable.
I tried to add require: textarea to it but it does not work and I get this error: Error: No controller: textarea
Question: Is there any cleaner way to properly apply this restriction?
EDIT: Additional constraint following the first answer.
I want to avoid using a template in this directive as I want to be able to use several directive of this type. Here is an example of what I'd like:
<textarea splittable shared mergeable></textarea>
When using your own directive (eg my-textarea) with restrict: 'E', replace: true, any additional attributes will get carried over to the root-element of the directive, even other attribute directives. So:
<my-textarea splittable class="foobar"></my-textarea>
could be rendered as:
<textarea splittable="" class="foobar"></textarea>
with splittable being executed.
demo: http://jsfiddle.net/LMq3M/
So I think using your own directive is realy the cleanest way to handle this.
In my opinion there is no need to add such controls as they just tend to add complex code when the real issue is human error.
Just document what the purpose and usage is for the directive.
The idea is you give your directive a unique name, like myDirective and you can use it in HTML as such.
<body>
<my-directive></my-directive>
</body>
The directive will replace the tag with the template you provided in the directive controller. Which could be in your case a simple textarea element with added properties.
I recommend watching this video to clearly grasp the concept of directives.
http://www.youtube.com/watch?v=xoIHkM4KpHM
Related
Hi please explain reason for following three scenarios as I am unable to know why is this happening -
1)
<div ng-controller="myctrl">
<p>something for DOM manipulation</p>
</div>
2)in route I write
('someroute',{
templateUrl : "mytemplate",
controller : "myctrl"
});
mytemplate:
<div>
<p>something for dom manipulation</p>
</div>
3)
<div ng-include="mytemplate" ng-controller="myctrl"></div>
with template being same as above
The controllers in all the above scenarios are same, and in all of them I am just trying to select p tag of DOM by writing angular.element('p'). But this seems inconsistent. It works very well in 2nd scenario, it never works in 3rd scenario and I am not sure about 1st sccenario. Can someone explain which method is best for dom selection/manipulation, as I have to add a class to this 'p' tag on hover.
I am not understanding which gets initialized first- controller or partial?
Manipulating DOM inside controllers is discouraged. Quote from Best Practice - Dom Manipulations:
Dom Manipulations should not exist in controllers, services or anywhere else but in directives.
If you only need to style elements on hover, using the p:hover CSS selector would be enough without touching the DOM. ng-class and ng-mouseover can help you if you really want the class.
For more complex scenarios, you may want to write your own directive. You can check the article above for a guide to do that.
Load order from the first case: HTML first. Directives like ngController are loaded after parsing the HTML. Therefore the HTML already exists when the controller is loaded.
Load order for the second case: I'm not sure about it. You may check documentation for ngRoute or uiRouter depending on the router you are using.
Execution order for the third case: Controller first. The directive ngController have higher priority than the ngInclude directive. Therefore, the controller is loaded first.
Quote from ngController documentation :
This directive executes at priority level 500.
Quote from ngInclude documentation :
This directive executes at priority level 400.
In AngularJs ng-enabled directive is not provided. Is there any proper reason to not providing that directive in the framework, because we are having both ng-show and ng-hide when you can just use ng-hide to achieve our goal.
It wouldn't be nice just to check
ng-enabled="attribute.value === true"
instead of
ng-disabled="!(attribute.value === true)"
it will increase the readability of the code.
The reason why there is no ngEnabled directive in Angular is rather semantical - there is simply nothing corresponding to it in HTML specification. At the same time there is already ngDisabled directive that works with disabled attribute. For the same reason, there is no ngUnchecked directive, because there is already ngChecked that sets/removes checked attribute.
Now, the reasonable question: why we have both ngShow and ngHide then? Well it's just for convenience in this case I guess, because having both ngShow and ngHide is not more confusing than ngShow alone, but at the same time it's very handy to have both.
I am not missing an ng-enabled directive at all and I think it would add little to nothing to the framework.
Inputs are enabled by default and HTML inputs also do not have an enabled attribute, just a disabled. The angular directive sets the HTML disabled attribute, but after evaluating an expression.
You can just write
ng-disabled="!attribute.value"
I think it is pretty readable.
TLDR: Use angular-enabled instead.
The core team expressed their view in this this comment: https://github.com/angular/angular.js/issues/1252#issuecomment-49261373
They will not abide a feature request just because it has many +1-s in order to keep the core bloat free.
However, if you still want to have ng-enabled functionality, btford has created this handy little module just for you:
https://github.com/btford/angular-enabled
Angular sets the disabled attribute based on the result of the expression in ng-disabled. There is no enabled attribute in HTML5 so ng-Enabled wouldn't work.
This line worked for me.
ng-disabled="!attribute.value"
Not that this is an answer to the question of Why but for those who want to write their own directive, here you go. BTW it's in coffeescript.
.directive 'ngEnabled', [
'$parse'
($parse)->
dir =
restrict: 'AC'
link: ($scope, elem, attrs)->
getter = $parse attrs.ngEnabled
$off = $scope.$watch ->
getter $scope
, (val)->
elem.attr 'disabled', !val
$scope.$on '$destroy', -> $off()
]
http://plnkr.co/edit/F4RG2v859oFtTumvgoGN?p=preview
I am using a third party lib with the following custom attribute directive:
angular.directive('snapDrawer', function () {
'use strict';
return {
restrict: 'AE',
...
So if the attribute "snap-drawer" is found in an HTML element the directive implementation has a match and fires, for example:
<div snap-drawer></div>
I am using Angular 1.3 which has an "AllOrNothing" approach to ng-attr where if the value conditional is undefined then the attribute does not render like so:
<div ng-attr-snap-drawer="{{data.addSnapDrawer}}"></div>
100% fact this works, the value of data.addSnapDrawer in my controller is undefined and the snap-drawer attr does not render in the DOM
I have verified that Angular 1.3 does this AllOrNothing approach with ng-attr here: What is the best way to conditionally apply attributes in Angular? (take a look at Mathew Foscarini's answer)
BUT what does render in the DOM is:
<div ng-attr-snap-drawer="{{data.addSnapDrawer}}" class="snap-drawer snap-drawer-left" style=""></div>
So, unbelievably, the angular.directive('snapDrawer') is matching to "ng-attr-snap-drawer". How can this be, I am really shocked that AngularJS, in all its glory, has a bug like this.
I cannot find anything online. I cannot set snap-drawer="false" I need it to not appear in the DOM, which I achieved by upgrading from Angular 1.2 to 1.3.
This is old, but I stumbled upon something very similar. https://github.com/angular/angular.js/issues/16441 - angular authors made it this way.
You need to devise a different way (depending on your usecase) to conditionally apply directives (e.g. use ng-switch and have two versions of the HTML; one with the directive and one without, or have a terminal directive with high priority that evaluates the expression during the linking phase, applies the necessary directive(s) and compiles the element).
I have been developing an advanced web-based GUI in AngularJS. Recently, I decided to use the call document.getElementsByClassName() (I hate using element collecting methods, but here I had to use one) and my boss flipped his lid for accessing the document element. He says that I "need to use only Angular calls for everything", even for element collection! Is there an "Angular way" to collect elements by class name? If so, which way is better to use within the Angular framework? Please provide reasons why. Thanks!
UPDATE: Why I need to use an element collector...
So, I really wish I didn't have to do this, but I do...
I am using a third-party directive that I found online called the Bootstrap DateTimePicker. Its pretty cool and very nice looking, yet it might have a bug...
First, I make a directive bound to an attribute, stating that the element I pass in is meant to be a "DateTimePicker". I then pass that element to the DateTimePicker function.
When invoked, this function creates a new div with absolute positioning and appends it to the body of the page.
Now, I open a dialog in my GUI that has a table in it. On each row of the table, I have two DateTimePickers: one for end-date and one for start-date.
My problem is that, once I leave my screen and the elements which the DateTimePickers were bound to are destroyed, the DateTimePickers still remain! If I open the dialog box again, it creates a ton more of these divs as well!
Until I could determine a true solution to this issue, I decided to use the element collector as a temporary quick-fix. I grab all of the elements with the datetimepicker class and perform a:
elem[i].parentNode.removeChild(elem[i]);
Not having your exact use case but knowing that you are attempting to aggregate elements by class name in your controller makes me agree with you boss. Think of the controller as an object which exposes data and and services to your declarative html page. The data is bound into the markup for presentation and possible modification. THe services are usually wrapped in functions on your controller which are then tied to event handling directives like ng-click or ng-change. These services should operate exclusively on your data and never touch the DOM. If you need to modify a DOM element in your declarative markup then that should be done through directives like ng-class etc.
In any case, It would be useful to know what you are trying to accomplish so as to give you a better idea of the "angular way" to approach the problem.
Well, I have my answer. This does not solve the question "Grab all elements with a certain class name without touching the document element" yet it does solve my problem and eliminates my need to use document.getElementsByClassName.
First of all, it turns out that every element using the DateTimePicker directive have an element.datetimepicker("remove") function.
I use a directive for each DateTimePicker:
components.directive('DateTimePicker', function() {
// Requires bootstrap-datetimestamp.js
return {
restrict: 'E',
replace: true,
scope: {
dateTimeField: '='
},
template:
'<div>' +
'<input type="text" readonly data-date-format="yyyy-mm-ddThh:ii:ssZ" data-date-time required/>'+
'</div>',
link: function(scope, element, attrs, ngModel)
{
var input = element.find('input');
input.
datetimepicker(
{
//stuff
})
.on('changeDate', function(ev)
{
//more stuff
});
...
Directive drastically shortened for the sake of your eyeballs...
I then need to remove the DateTimePicker and the input it is bound to from the DOM on destruction of the dialog box that the input is a child of. To do so, I added this to my directive:
scope.$on("$destroy",function handleDestroyEvent()
{
input.datetimepicker("remove");
input = null;
});
And it works! The DateTimePicker gets removed, the DateTimePicker's handles to the input are cleaned up, and I've marked my input for the GC! WooHoo! Thanks everybody!
If you include jQuery in your project before AngularJS, Angular will use jQuery instead of jqLite for the angular.element function. This means you should be able to use jQuery's selectors for finding / referencing DOM elements.
I've created a custom directive that has contains related inputs and dropdowns. I've also used an isolate scope to properly bind the outer scope to the inner scope to assist with two databinding, and this also allows me to use the same directive multiple times on the same page. All works well up to this point. My next question is how to handle validation within the directive.
I no longer can use something along the lines of
ng-show="formName.controlname.$invalid && !formname.controlname.$pristine"
for the following 2 reasons,
My directive should not have to worry about the external form.
Because i'm using the same directive twice on the same page, using the syntax formName.controlname would actually map to two different controls.
Some ideas on this would be helpful at this point. What am I missing here?
You should definitely not make your directive depend on the form name. What you should do instead is to provide a parent form directive dependency so you can use its controller in your directive link function:
.directive('yourDirective', function() {
return {
require: '^form',
link: function(scope, element, attrs, formController) {
// use formController.$errors object
}
};
});
Probably you should do the validation in your directive.
Create a copy of the two-way bound scope members (assuming these are bound to the form inputs) to check pristine-ness and undo-ability.
Thanks for the feedback, but I discovered that using ng-form meets my requirement.
So in my directive mark up I added:
<div ng-form="[some name]">
.......
</div>
Doing this allowed me to continue to use the ng-* attributes.
Now I can do this in my directive:
ng-show="somename.controlname.$invalid && !somename.controlname.$pristine"
It is self contained so I don't have to worry about crossing any boundaries. I can add the control over and over again and validation stays intact per directive.