When angularJs directive is defined, we have to name it in form of 'camelCase' syntax but when we use it, we have to name it in form of 'camel-case'. Question is why this is required ?
I know that it is for avoiding naming conflicts(now/in future) but why we have to name it differently while defining and while using. Can't we define it directly in form of 'camel-case' ?
There are two reasons why it's important.
First of all, HTML attributes are not case sensitive, meaning that "someName" and "somename" is the same attribute. So the best style is to use "kebab-case" notation to separate words in attribute name. That's why we use "attribute-name" syntax for HTML attributes and tag names.
On the other hand, kebab-case names are not valid identifiers in Javascript so in order to use such names as Angular directives we would have to use verbose bracket notation. But since in Javascript world camelCase is standard de-facto for naming variables and object properties, Angular uses normalization (see source) to convert kebab-case names to camelCase, and vice versa.
Directives must have camel case names (for instance, fooBarDirective) because AngularJS converts camel case directive names to hyphen case .For instance
<foo-bar-directive>
or
< ... foo-bar-directive>
for use in HTML(which is case insensitive).
Related
If I have an attribute self.internal/freezer in a class, and I raise an error via (raise (AttributeError f"Sorry! '{attr}' doesn't exist as an attribute!")), how can I get the attribute name to render as internal/freezer instead of hyx_internalXsolidusXfreezer? For example, I already tried (hy.eval attr) with the f-string, but it still came out mangled.
Thanks to #Kodiologist in the comments linking the mangling section in hylang's syntax documentation; unamgling can be achieved via the aptly named hy.unmangle function, documented here as well.
What does M stand for in the restrict AngularJS option?
From AngularJS Developer Guide - Directives documentation I see that the:
The restrict option is typically set to:
...
'C' - only matches class name
'M' - only matches comment
But in order to avoid memorizing that C is for class and M is for comment, I would like to understand why the M is used.
I did not find anything about it on the internet. My guess is that the m is the next consonant letter in the word comment after the c and since the c is already taken by comment the m is used.
This does exactly what it says it does - allows a directive to be matched to a comment.
Thus:
directive('yourDirective', function() {
return {
restrict: 'M',
template: '<span>Something in here</span>'
};
});
Can be used like this:
<!-- directive: your-directive -->
AngularJS supports comment directives but it is best not to use them.
From the Docs:
Best Practice: Prefer using directives via tag name and attributes over comment and class names. Doing so generally makes it easier to determine what directives a given element matches.
Best Practice: Comment directives were commonly used in places where the DOM API limits the ability to create directives that spanned multiple elements (e.g. inside elements). AngularJS 1.2 introduces ng-repeat-start and ng-repeat-end as a better solution to this problem. Developers are encouraged to use this over custom comment directives when possible.
For more information, see
AngularJS Developer Guide - Directive Types
AngularJS Comprehensive Directive API Reference - restrict
For example, I have not found html page. Should I name it
1. not-found.html
2. notFound.html
What's the file name convention?
While I am not aware of a broadly adopted convention, I personally use camelCase, notFound.html. I like to do this across Angular files so notFound.directive.html for a template associated with a notFound.directive.js directive.
The one requirement in Angular to be aware of is that camelCased directive names need to be converted to "dashed" when referencing in HTML. So to reference the notFound directive in HTML you will need to reference <not-found></not-found>.
One resource that has helped me with regard to Angular conventions in general is John Papa's style guide, found here. Note that he actually suggests not-found.html, but again this specific case is up to personal preference.
If you follow the john papa angular style, it's not-found.html. But seriously, just choose the one that seems most natural to you :)
I'm using angularJS translateProvider and in the resource file i have a prefix "paragraph \u003cbr /\u003e paragraph" witch gives me. paragraph <br /> paragraph.
but what i need is a break-line (or new line) like so
paragraph
paragraph
I would appreciate the help thank.
I'm not sure that is really possible to pass unicode symbols in angular-translate. Almost same questions was in issues to that package on github: https://github.com/angular-translate/angular-translate/issues/554, https://github.com/angular-translate/angular-translate/issues/595, and answer was just to use <br> tag in translation string.
But i think, may be you can write some variable or placeholder in translation strings, and after translation in Controller / Directive, you can replace it with str.replace('SOMEPLACEHOLDER', '\n')?
You should update the Sanitize Value Strategy of the $translateProvider.
In the config phase set
$translateProvider.useSanitizeValueStrategy('escaped');
Also you should include ngSanitize as a dependency and also angular-sanitize.js.
I'm new to Angular and trying to understand what the "x-" and "data-" prefixes mean. In the directives documentation (http://docs.angularjs.org/guide/directive) it says that these prefixes will make the directive "HTML validator compliant". What exactly does this mean?
The HTML5 spec allows for arbitrary attributes as long as they're prefixed with data- like so:
<div data-myattribute=""></div>
Whereas this would be invalid HTML5:
<div myattrbute=""></div>
For more information on data- attributes, have a look here.
As for "x-" attributes, I think you mean "x:" attributes and elements, which are specific to XHTML validation...
To expand on this, if you were to (for some reason) be using XHTML, you can define custom attributes with namespacing like so (and I'm just summarizing the gist here):
<html xmlns:x="http://sample.com/mynamespace">
<body>
<div x:whatever=""></div>
<x:mytag></x:mytag>
</body>
</html>
where the URL in xmlns is really just to prevent conflicts between like elements. Also, a DTD for the custom elements and attributes could be provided for validation purposes as a part of your DOCTYPE declaration.
*behavior in browsers is going to vary with this xmlns approach.
In summary, though: With most browsers released in the last three years, or IE8+ you're not going to have to worry about any of these things. Only in very specific situations will you really care.
From the HTML5 spec: http://www.w3.org/html/wg/drafts/html/master/single-page.html
Attribute names beginning with the two characters "x-" are reserved
for user agent use and are guaranteed to never be formally added to
the HTML language.
Also:
For markup-level features that are intended for use with the HTML syntax,
extensions should be limited to new attributes of the form "x-vendor-feature", where
vendor is a short
string that identifies the vendor responsible for the extension, and feature is the
name of the feature. New element names should not be created. Using attributes for such
extensions exclusively allows extensions from multiple vendors to co-exist on the same element,
which would not be possible with elements. Using the "x-vendor-feature" form allows
extensions to be made
without risk of conflicting with future additions to the specification.