In getting used to module patterns and components I am trying to figure a better way to style an angular app. A question that I cannot explain to myself fully is...
What is the difference between a component and a module in angular js?
Components have life cycles. With the exception of children they seemingly stand alone.
From the Angular documentation:
A Module is "a container for the different parts of your app – controllers, services, filters, directives, etc."
A Component is "a special kind of directive that uses a simpler configuration which is suitable for a component-based application structure."
Components are supported from Angular 1.5 on and are provided as a way to bridge the gap between the Angular 1 approach and the Angular 2 approach.
You can think of the Module as the library that holds all of your components. For example, imagine you have a set of components for displaying information about restaurants. You may have a location component, details component, menu component, etc. You would put all of these components in your Restaurant Module. Then users could import your Restaurant Module and have access to all the cool Restaurant components.
When I discovered Components I actually had trouble differentiating them from Directives. Although, the Angular docs do provide a good comparison table here:
https://docs.angularjs.org/guide/component
Related
I develop in Angular 2+ for quite a while using Angular Material, but the documentation of AngularJS Material is more complete and wide then the one to Angular 2+, there is a way to use AngularJS Material components in an Angular 2+ project? More specific on Angular 6
You will have to run both frameworks simultaneously to make it work. While that certainly is possible, it usually isn't desired, especially if there isn't a clear separation between where the AngularJS application and the Angular 2+ application ends and begins (for instance as there would be if you're migration an AngularJS application to Angular 4). AngularJS components, spread around an Angular 2+ application doesn't seem like a desirable situation.
Here are some additional issues:
Component names may clash
Routing may interfere with each other
Communication between AngularJS components and Angular 2+ components is difficult
I have two suggestions.
Either do away with the AngularJS dependency and clean up after the former co-worker.
Or, create thin wrapper components around Angular2 Material components, that has the same name and signature as the AngularJS material components. This is only possible if the components work somewhat similarly.
I recommend the first suggestion, since the latter might only be plausible for the most simple components.
I am slowly converting an AngularJs Application to Angular. I am following the hybrid app approach in the documentation here: https://angular.io/guide/upgrade#using-upgrademodule-with-angular-ngmodules
If I have a universal service, like a logger, can I share a single instance of that service between two downgraded components that are being treated as individual directives by angularJS? Currently I declare it in the providers array of both components individually, because there is no overall parent component since each downgraded component is its own Directive loaded into angularJS as needed, but I'm pretty sure this means I will have two separate instances running in my application and would like to avoid that if possible.
I am using angular-ui-router with my angular 1.3 app. I am looking to upgrade it to angular 1.5. What are the best options for routing in angular 1.5? Shall I continue with angular-ui-router or shall I move to something like angular-new-router. Please suggest. Also, If there is a documentation for easy migration, it will be helpful.
Routers in angular
As mentioned earlier, the two mainstream routers for angular.js is ngRoute an ui-router. There is the new router which is part of angular 2.0 - Although it promises amazing features, I currently do not recommend adoption of it and angular 2.0 until it's stable and because of stories like this and issues like this.
Read before upgrading
"Upgrading" to the newest stable release of any library is most alwasy preferable. But before you do; you should read the release notes for every single version up to the version that you're upgrading.
Check the migration guide
Google is working on improving their angular documentation. The migration documentation however is particularly good. Take a look at it here
Depending on the status of your project you might want to stick with the ui-router as angular 1.5 is backwards compatible with all your modules and the upgrade should be smooth (read the docs though, including the upgrade to 1.4).
On the other hand, Angular 1.5 is meant to bring us close to the concepts and architecture of Angular 2 and web components (which are now thought of as the future of web development) so it's a step on the learning curve that most ng1.x developers should take.
Angular 1.5 allows you to write your app in a component based fashion with a different routing mechanism, having routes/URLs load components that you defined instead of loading partials.
Routes can now be embedded in child components (say you have a Users module which has a /list, /details/:id/:slug, /edit/:id routes/sub-components and this Users module can be attached to whatever URL from your app: /users, /admin/users/ while keeping its internal routing mechanism. Your base app will have non-terminal routes for this kind of components (specified with /... meaning it will leave the consequent routing to the component itself).
Also, you can have multiple active routes at once (i.e. think modals, as in Gmail where you can look at a message and have the Compose popup and then navigate to the message list while still having the Compose popup open).
Routing events are now hooks that you can implement in your own component so you can do your resolves locally (fetch data, check for user rights, etc), taking care of destroying stuff, specify whether the component should be reused or reinstantiated, etc.
Bottom Line
In Angular 1.5 the new routing mechanism is based on components instead of states/views so your app needs a refactor towards this concept in order to fully benefit from it.
Currently looking at upgrade paths from Angular 1 -> Angular 2 and one things we've done with our Angular 1 work is reuse some of our components on public facing non-app pages.
These pages are effectively static HTML (though they are rendered by Rails) and then some Angular 2 components are dropped into the page in places. This worked from with Angular 1, we simply bootstrapped the document element with a module that provided the directives and components we needed. There is no routing at all.
With Angular 2 it looks like it is all or nothing. You declare a single root component and everything is rendered through that. This would be a big shift for us and I'd like to avoid changing how we are doing things on these public facing pages.
Is it possible at all to just use Angular 2 components as needed in static HTML pages or will we need to move to a single root element SPA design?
In a nutshell, what I'm asking is if it is possible to have a mix of static content with dynamic angular components sprinkled within, or must all angular components live within a single root element on the page?
So this is simpler than I originally thought. In the Angular 2 docs it has some specific wording around bootstrapping multiple apps.
Bootstrapping Multiple Applications
When working within a browser window, there are many singleton
resources: cookies, title, location, and others. Angular services that
represent these resources must likewise be shared across all Angular
applications that occupy the same browser window. For this reason,
Angular creates exactly one global platform object which stores all
shared services, and each angular application injector has the
platform injector as its parent.
Each application has its own private injector as well. When there are
multiple applications on a page, Angular treats each application
injector's services as private to that application.
So it seems clear that this is intended to be possible and that multiple apps share service resources which is what I would hope for.
I've done some trivial tests with multiple bootstrapped components and it works fine. One thing I have not yet tried is bootstrapping an Angular 2 attribute directive for use outside of Angular 2 components. I suspect that won't work and that bootstrap only works with Components and not Directives.
In terms of guidance, I would suggest that Angular 2 is not really designed for sprinkling behaviour throughout a static page and probably should not be used that way. Rather, while you may have multiple sections of your paged defined by multiple apps, that components should make up nearly all of the document/interface.
we simply bootstrapped the document element with a module that provided the directives and components we needed. There is no routing at all
That's exactly how I'm currently using Angular2. See the example at https://github.com/niczero/ng2-es5-file-upload/blob/master/demo/index.html -- some of my 'static' pages are generated by perl in the same way you are using ruby.
As an aside, being able to use your modules both ways is much easier if you embrace Universal Module Definitions
I am from Asp.Net world, trying to understand what an Angular State mean.
What is an Angular State? Is it similar to an ascx component in Asp.Net? Is it a sub page? Is it similar to a workflow state?
I heard many people talking about it, and I have been trying to search for articles which explains what a state is or does, but cannot find a good one for the beginner.
Do any of you know any good article? could you please help me to grab/understand the concept of angular state? thanks a lot. :-)
The reference is not to Angular itself but to an Angular Module called Angular UI.Router. This module allows you to turn your Angular application into a State Machine, and handle what appears on the view based on these states, rather than only on the URL parameters. Many people consider this an essential Angular Module, and far more functional than the default $routeProvider.
The best reference for all the $stateProvider
features is the github repository wiki.
From the documentation for the AngularJS UI-Router,
A state corresponds to a "place" in the application in terms of the overall UI and navigation.
A state describes (via the controller / template / view properties) what the UI looks like and does at that place.
States often have things in common, and the primary way of factoring out these commonalities in this model is via the state hierarchy, i.e.
parent/child states aka nested states.