What are components in Angular 2

Question

I am new to Angular and have very little experience generating Angular JS 1.x. However my question is about Angular 2. I read about Components here and https://angular.io/docs/ts/latest/guide/architecture.html

I use TypeScript, and my question is: is it safe to say that the Component is a class (NOT @component annotation) similar to a model (as in Asp.Net MVC), since we can bind html controls to fields defined in the OR component class, more like a controller? Or is there more that I am missing?

Url 2 has a statement that says:

We define the logic of the Component application - what it does to support the view - inside the class

The above statement increases my confusion because we can do many things inside the html class. When changing the text, we can remotely check something or by pressing the button we can call the method, and all this can be defined in the component class. So what is a component limitation? Can we consider them as models or similar controllers, or both?

Please help me clarify this.

Answer 1

In fact, the component class corresponds to the implementation of your component. I mean your own processing:

• Properties correspond to the state of the component. The state may be associated with the appropriate template, if possible.
• Methods correspond to processing that can be launched from a view or used inside a component. Some methods correspond to hooks for the component life cycle (see https://angular.io/docs/ts/latest/guide/lifecycle-hooks.html ).

Thus, the component class can be considered as a mixture of controllers and areas of Angular1.

The @Component decorator is what the Angular2 component part will do. I mean participating in various functions and the mechanism of the structure and your application.

This will allow you to configure the component with different things to quote a few:

• selector
• template
• inputs and outputs (can also be configured using @Input and @Ouput
• specific suppliers
• directives / components for use in a component
• for use in component

In addition, you can see the class decorator ( @Component decorator of this type) as a kind of interceptor:

• This will make it possible to nest the dependencies of the component constructor parameters.
• This will make the component instance part of the change detection using ZoneJS. Mark gave an amazing explanation about this: What is Angular2 equivalent to AngularJS $ watch? .
• It will add metadata to the component instance according to what was configured using Reflect-Metadata.

So, the @Component decorator @Component really important to configure the component and make it part of the Angular2 mechanisms.

Note to all . I tried to describe it simply, and it fits my understanding of things, but feel free to comment on my answer; -)

Answer 2

Directives / components replace the combination of controllers, scopes, and directives from AngularJS (Angular 1).

A component is a view and its associated view controller. (Directives have no representations.) Components are how we create representations for our application and maintain these representations with (minimal) state, data, and logic.

A view is an HTML template with optional Angular syntax that controls the area of ​​the screen / display. The component provides some (subset!) Application data for presentation and processes the user interface logic for presentation. Data should not belong to components. Rather, the component should only receive links to the data needed to control the view. (This is similar to the same best practice used in AngularJS - controllers should receive data references, not have them.) Services should usually have data.

Similarly, the logic of a component should be limited by the logic needed to control the presentation (hence, the "presentation logic"). Application logic belongs to services. Other tasks also relate to services, and not to components: checking user input, logging, interacting with (web servers), etc.

So components (like AngularJS controllers) should be as thin as possible. They should handle user interaction and determine the data bindings needed for this. They should be focused on supporting the look.

Angular creates and destroys components as needed, as the user interacts with the application. Components have a life cycle, and there are life cycle hooks that we can connect to.

A component is just a class until we tell Angular about it. And we do this by adding metadata to the class.

I consider it more important to know what belongs to the component and what does not, instead of trying to determine whether it is a “controller” or “model” - these terms are so broad and excessive that I think you can force the two developers to agree on the definition of a term.

^{Some of the above suggestions are most likely copied from Angular.io docs, blogs, other SO posts, etc. I have a bunch of notes about Angular in the document, and I don't always keep track of the source links.}