How Angular knows that element <app-info> refers to the appInfo directive?

Get Help Angular.js
#1

Question

How Angular knows that element <app-info> refers to the appInfo directive?

Answer

Every language has a style guide and a naming convention. For example in JavaScript we use camelCase, in plain PHP we usually use snake_case and in HTML dash-case (also called train-case) is recommended. Angular apps are written mostly in JS, but with the use of custom HTML elements and attributes. So at the level of framework design, it was kind of problematic to select one, consistent naming convention.

Angular respects style guides, that is why we can use camelCase in JavaScript and train-case in HTML. How is this possible? There is a special normalization process.

This is how AngularJS documentation describes the normalization process:

The normalization process is as follows:

  1. Strip x- and data- from the front of the element/attributes.
  2. Convert the :, -, or _-delimited name to camelCase.

That’s why element app-info refers to the directive appInfo.

9 Likes
FAQ: Directives - Directives II
FAQ: Directives - Directives I
#2

I don’t understand how associates to appInfo. How does it know to put a dash? Is it automatic when it sees the capital I and changes it to a dash with lower case?

2 Likes
FAQ: Directives - Directives II
#3

I have the same question. Why isn’t this explained at all?

1 Like
#4

@javaninja55926 @michaelkoehler2 Hey, I noticed your questions and decided to create FAQ explaining this. I moved your comments here. So, take a look above, there is an answer. Let me know if anything needs clarification :slight_smile:

5 Likes
#5

If this is the case,why couldn’t we keep it simple and use the same name accross(appInfo instead of app-info on our index html)

1 Like
#6

This is a great question.

Every framework is a product. It can be free to use, it can be open source, but it is still a product and authors want their products to be popular, so most design-wise decisions are made based on the “ease of use” basis. Just like you suggested - framework should be easy to use. So I would argue that they decided to keep it simple and using the same name would cause a lot of problems for developers, let me explain why.

When it comes to frameworks that operate simultaneously in more than one language - like Angular (JS & HTML), we have to pay attention to the specification of both languages. We often come to some sort of cardinality problem. JS is case sensitive, HTML is case insensitive.

So JavaScript and the additional tools (for example linters) allow you to create two variables named appinfo and appInfo. It might be a bad practice (as it makes the code less readable) but you are allowed to do that. And now, what happens on the HTML side of things?

In Angular names of those two variables will be transformed respectively to app-info and appinfo, two different names, great. So every valid name in JS results in the unique name on the HTML side, awesome.

Let’s take a look at your proposition, in that case, those names would not be transformed and developers would use appInfo and appinfo in HTML, but as we stated earlier - HTML is case insensitive so those names are actually equal. And that’s the problem. To make it all work you would need to create a rule that variables defined in JavaScript must be unique in a case insensitive system. But the language itself and tools created for JS (not Angular) would still allow this. You would have to create your language that would be compiled to JS, not an easy task.

Ok, but let’s assume that you don’t create your own language, you just state the rule that developers have to use unique names in a case insensitive sense. As programmes we make errors and then we fix them, that’s our job. I am sure that someone would forget about this rule (as it’s not enforced by the language and tooling) - what happens now? Someone notices that there is a bug in the system and you are assigned to fix it. Trust me, bugs that occur without any error logs or problems reported by the linter are the worst.

That’s why I believe that they went for the easier path, for them as authors of the product and for the developers as the users of the framework.

1 Like