I am little confused to differentiate between Component vs Controller. How Controller replaced with component in angular 2? I read about component:
In Angular, a Component is a special kind of directive that uses a simpler configuration which is suitable for a component-based application structure.
This makes it easier to write an app in a way that's similar to using Web Components or using Angular 2's style of application architecture.
Advantages of Components:
simpler configuration than plain directives
promote sane defaults and best practices
optimized for component-based architecture
writing component directives will make it easier to upgrade to Angular 2
When not to use Components:
for directives that need to perform actions in compile and pre-link functions, because they aren't available
when you need advanced directive definition options like priority, terminal, multi-element
when you want a directive that is triggered by an attribute or CSS class, rather than an element.
from AngularJs Documentation
Also, Read difference between Directive vs Component
But I am implementing same logic in component which we are doing in controller.
So can someone explain about the same? And How to think about the architecture of the application in component perspective over controller.
I would not differentiate them from the perspective of architecture of the application as you ask. It is pretty much the same concept, that is rebranded and made easier. Long story short you can think of it as the same type of entity.
I suppose component is easier for people to grasp than controller even though it fits in MVC, being the last "C". Often it's a bit easier to reason about a component as an element of the UI. One can think of the whole UI consisting of multiple components each doing its little job to create the whole picture and thus the name fits better from the point of view of Angular team I guess. I like component better as well.
Controller (Angular 1.x), is replaced with the component class in Angular 2, because now we have ES6 classes.
ES6 classes, combined with Typescript, makes very easy for stuff like dependency injection.
Template is there in both Angular and Angular 2.
From: https://kw-angulardart.appspot.com/tutorial/05-ch03-component.html (This version of the tutorial uses AngularDart version 0.10.0.). Could be outdate, but might be helpful too?
The key difference between components and controllers is that the inner structure of components are isolated from their surroundings and can be thought of as black boxes.
Components create their own scope hierarchy that is invisible from the outside world. They don’t have direct access to the app’s scope, nor does the app have direct access to a component’s scope.
Components isolate their views from their surroundings by creating a shadow DOM. Using a shadow DOM allows components to be used anywhere without suffering from things like CSS name collisions.
Related
I have made an angular element directive for both header and footer. Header directive contains cart element functionality and my accounts feature. Is there anything wrong about making it as a directive?
Is it the angular way or best practice of using the power of directive?
Angular 1.5 introduced the Component (https://docs.angularjs.org/guide/component) which mostly serves as a replacement for a directive (https://docs.angularjs.org/guide/directive). At the very least, you can achieve most of the things (I'm not entirely sure if it serves as a complete replacement) that a directive can do. Components seem to be more structured and is more conducive to component based development (with a name like 'component' that shouldn't be too surprising :P).
If you need to write something that would be the equivalent of an Angular directive restricted to 'A' then you should probably still use a directive, otherwise for most other cases, writing a component will serve as a better idea. I like to think of a directive as a "decoration" as of Angular 1.5.
As for your question of "is it wrong to use directives" - the answer is "no, probably not, but using a component is a more accepted practice for most things with Angular development these days".
Hope that helps!
I am finding it difficult to understand the real difference between components and directives. I now understand that components are a much easier concept.
So having this in mind, is there any reason to continue to use directives when using AngularJS 1.5?
Maybe I am missing the real context here, but it appears that components provide an easier API.
So what reason would I have to continue using a directive?
Angular 2 states that everything is a component, so working towards an easy migration from 1.5 to 2, would it not make sense to only use components going forward?
In the past I have used directives for creating, for example, an auto lookup textbox, there is no reason why I shouldn't do this now inside a component right? And then I can re-use this component inside other components I create?
Just copying the angular docs, since they put it in the best way I can think.
Understanding Components
In Angular, a Component is a special kind of directive that uses a
simpler configuration which is suitable for a component-based
application structure.
This makes it easier to write an app in a way that's similar to using
Web Components or using Angular 2's style of application architecture.
Advantages of Components:
simpler configuration than plain directives
promote sane defaults and best practices
optimized for component-based architecture
writing component directives will make it easier to upgrade to Angular 2
When not to use Components:
for directives that rely on DOM manipulation, adding event listeners etc, because the compile and link functions are
unavailable
when you need advanced directive definition options like priority, terminal, multi-element
when you want a directive that is triggered by an attribute or CSS class, rather than an element
more reading:https://docs.angularjs.org/guide/component
I will try to explain using a high-level perspective, inspired by this article(Angular 2: The Difference Between Components and Directives). It says Angular 2 but is also useful in the AngularJs context.
Directives
In Computer Science there is the concept of ‘Directive Pragma’. According to Wikipedia:
“In computer programming, a directive pragma (from "pragmatic") is a language construct that specifies how a compiler (or assembler or interpreter) should process its input. Directives are not part of the language proper”
This aligns well with the description given by the AngularJS docs:
“At a high level, directives are markers on a DOM element (such as an attribute, element name, comment or CSS class) that tell AngularJS's HTML compiler ($compile) to attach a specified behavior to that DOM element (e.g. via event listeners), or even to transform the DOM element and its children.”
So, what directives basically do, is to give instructions to the (Angular) compiler, in order to alter the DOM or its behavior.
Components
Components in AngularJS are a special directive; they try to mimic web components, as the AngularJS documentation states:
In AngularJS, a Component is a special kind of directive that uses a simpler configuration which is suitable for a component-based application structure.
This makes it easier to write an app in a way that's similar to using Web Components or using the new Angular's style of application architecture.
When to use what?
Personally, I use components unless there is a good reason not to.
Some of those reasons are given in the AngularJS docs for components:
for directives that need to perform actions in compile and pre-link functions, because they aren't available
when you need advanced directive definition options like priority, terminal, multi-element
when you want a directive that is triggered by an attribute or CSS class, rather than an element
Another way to put it:
Directives are the mechanism by which we can attach behavior to elements in the DOM.
Components are a specific type of directive that makes it possible to utilize web component functionality - encapsulated, reusable elements available throughout our application.
Possible conclusion
I think the question is not that good once you understand that a component is a directive. The two concepts are not trying to solve the same problem. Components are rather an extension that allows directives to be used in order to build component-based web applications.
Going deeper
Todd Motto share's his knowledge about this topic in this little GIST.
A Directive decorates the DOM, it adds behavior and extends existing DOM. When you use a .component(), you create DOM, when you use .directive() you decorate DOM, that is the mindset
I know that this topic was discussed many times but I'm still not quite sure if I'm doing things right..
Many on-line resources embrace directives as a building blocks of the angular applications, in the same time many resources emphasize re-usability of the components. Anyway from my experience when I build typical app, there is not much things to re-use, usually each component has single role and it is used in the single place. As I understand angular, one of the main concepts is to provide semantic DOM, and in order to achieve that we can use directives. So when I build an angular app usually I create a set of directives and combine them in the views.
In my apps in the most cases all the DOM manipulation can be done using the build in directives. Most of my directives has a template and a controller, I do not need to use link function. In most of the resources in the internet I can read that I should use link function when creating directives. But this seems to be far more complicated code... . What is the benefit of the link function if I don't need any fancy DOM manipulations that are beyond build-in directives ?
tldr; I build my apps using directives with controllers and put them into views, is this a right approach ?
I've been developing in Angular over a year now on an enterprise level application and my team has gone by a standard of creating directives if you are using that same element more than once. It saves time, saves the DOM trouble, and makes it easy to create separate, testable pieces of code.
We've created directives for many listing items that use ng-repeat. Pretty much every ng-repeat we have is iterating over a directive to create true isolate scope in our elements' functionality. It's one of the most powerful features in AngularJS when done right and conforms to the standards of Object Oriented Programming where you can really make your applications use abstraction to the finest degree. Here's a wiki link on abstraction.
A couple of hours ago Twitter released Flight, a component-based framework for JavaScript. Its components are plain DOM elements and communicate through plain DOM events, which its really nice.
I just wonder... can I combine this with AngularJS? If I understand both frameworks correctly I can create "new" elements with AngularJS which could be use by and contain Flight components. And these components can be populated with data by AngularJS.
To put it another way: I could AngularJS like I normally would, but the directives are "decorated" Flight components. (Use Flight to create views and use AngularJS for everything else.)
Would that make sense? If not... I don't get the purpose of Flight :(
I understand you want to do the following: Decorate AngularJS directives with Flight components and Flight views.
You could probably create these Flight components within a directive and gain an advantage from the data-binding Angular offers. However, judging from the following:
"Flight enforces strict separation of concerns.
When you create a component you don't get a handle to it. "
It seems like Flight does not promote that you speak to these components via data-binding.
Furthermore, directives can be seen as components themselves already. And as for creating views, in AngularJS the DOM is already the view, what reason specifically would you have to use Flight views on top?
Also since the AngularJS is not subscribed to the events that Flight uses it has no way of knowing when the DOM has been modified (I am not sure of this please someone more knowledgeable correct me if I am wrong).
As for making sense. It does not look like Flight is meant to solve the same problems as Angular. I think AngularJS directives solve the same problem as Flight components, but offer a lot more.
I just started to learn AngularJS and struggle with some concepts of AngularJS. It would be great if somebody could explain me some points...
I understand that ng-click is technically not the same as onclick (see here), but both are placed in the markup. I thought that would be a "bad practice"? Why is this one of the core concepts of AngularJS, if most people say this is "bad"? I thought it would be better to select the DOM element from JavaScript and not to place logic in the markup.
If ng-click is the right way to react to click events in AngularJS what should I do with other DOM events? I see that there are several other directives like ng-mouseover, but not all DOM events have a AngularJS equivalent. How would I handle a 'drop' event in AngularJS (hence in the AngularJS way - not the normal way)? To be clear: I want to drag a file into my webapp.
Thank you very much,
Pipo
Why is this one of the core concepts of AngularJS, if most people say this is "bad"?
Well, people who really like Unobtrusive JavaScript might say it is bad. Angularians (and those with a flex background) see value in the more declarative approach.
"Angular is built around the belief that declarative code is better than imperative when it comes to building UIs and wiring software components together... By declaratively describing how the UI should change as your application state changes, you are freed from low level DOM manipulation tasks. -- Overview doc
See also Don't the data attribute options used in Bootstrap, Angular.js, and Ember.js conflict with Unobtrusive Javascript principles?
what should I do with other DOM events?
Write your own directives to listen for them (or find one that someone else has already written). Angular gives you the power to extend what the browser can do -- by writing your own directives.
Update: in the comments below, Tim Stewart mentions AngularUI's ui-event, which lets you bind a callback to any event not natively supported by Angular.
By nature, Angular requires elements in the markup in order to function properly. Further, those elements must be "compiled" each time they change, for the most part. So, it's already somewhat "obtrusive" irrespective of the JavaScript. You can't simply replace the markup, and have everything auto-bound for you like you can with something like jQuery.
Strictly speaking, unobtrusive JavaScript:
1. separates structure and behavior, in order to make your code cleaner and script maintenance easier
2. preempts browser incompatibilities
3. works with a clean, semantic HTML layer
(Wikipedia)
That's not Angular, for sure. In order to achieve the two-way binding on everything, they chose to make custom binding points in the DOM, as opposed to using a class name or ID the way that jQuery would do. (A somewhat non-standard approach, but it obviously works.)
But the real way to think of it is this: Basically each controlled section of your markup is not really straight HTML anymore anyway. It's really more of a template now, and as such requires interaction with the engine that is preparing it for rendering. As such, the traditional rules of unobtrusiveness don't really apply... (FWIW, I'm a huge fan/user of the jQuery.on() function to bind elements to events automatically when the element is added to the page. Very clean and flexible, IMHO, and I do wish there was a similar mechanism in Angular. I like adding a class to items in multiple locations on the page that invoke the same event handler automatically. Having a single place to go change code is a good thing. but I digress...)
For me, the bigger issue is that of progressive design. Does the web page work without JavaScript enabled at all? Does anyone really care about that? Hmmm...