Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are Components in Angular 2

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

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

There is a statement in 2nd Url, which says:

We define a Component's application logic - what it does to support the view - inside a class

Above statement is increasing my confusion, because we can do a lot of things inside a class which is bound with html. On text change we can remotely check something or on button click we can call a method and all this can be defined in a component class. So what exactly is the restriction of Components ? Can we treat them like models or like controllers or both ?

Please help me in clarifying this

like image 386
shrekDeep Avatar asked Feb 12 '16 06:02

shrekDeep


2 Answers

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

  • Properties correspond to component state. The state can be bound to the associated template if wich.
  • Methods correspond to processing your can trigger from the view or use internally in the component. Some methods correspond to hooks for the component lifecycle (see https://angular.io/docs/ts/latest/guide/lifecycle-hooks.html).

So the component class can be seen as a mix of Angular1 controllers and scopes.

The @Component decorator is what will make the component part of Angular2. I mean involved in the different features and mechanims of the framework and your application.

It will make possible to configure the component with different things to quote a few:

  • a selector
  • a template
  • inputs and outputs (can be also configured using @Input and @Ouput
  • specific providers
  • directives / components to use in the component
  • pipes to use in the component

Moreover you can see a class decorator (the @Component decorator is of this type) as a kind of interceptor:

  • It will make possible the dependency injection of parameters of the component constructor.
  • It will make the component instance part of the change detection leveraging ZoneJS. Mark's gave an awesome explain on this: What is the Angular2 equivalent to an AngularJS $watch?.
  • It will add metadata on the component instance according to what was configured using Reflect-Metadata.

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

Note for everyone: I tried to describe this simply and this corresponds to my understanding of things but feel free to comment my answer ;-)

like image 69
Thierry Templier Avatar answered Nov 15 '22 04:11

Thierry Templier


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

A component is a view and an associated view controller. (Directives don't have views.) Components are how we create views for our application and support those views with (minimal) state, data, and logic.

A view is an HTML template with some additional Angular syntax that controls an area of the screen/display. The component exposes some (subset!) of the application data to a view, and it handles the UI logic for the view. Data should not be owned by components. Rather the component should get references to only the data it needs to drive the view. (This is similar to the same best practice used in AngularJS -- controllers should get references to data, not own it.) Services should normally own data.

Similarly, component logic should be limited to the logic needed to drive the view (hence, "view logic"). Application logic belongs in services. Other tasks also belong in services and not in components: validating 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 define the data bindings required for such. They should be focused on supporting the view.

Angular creates and destroys components as necessary as the user interacts with the application. Components have a lifecycle, and there are lifecycle hooks that we can tap into.

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

I find it more important to know what belongs in a component and what doesn't, rather than trying to determine if it is a "controller" or a "model" -- those terms are so broad and overused that I don't think you can get two developers to agree on a definition of either term.

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

like image 39
Mark Rajcok Avatar answered Nov 15 '22 05:11

Mark Rajcok