I've been working on a personal project for many years. This isn't for work and there is no money to be made. So I take my time doing the development on the project, and that means I'm still using AngularJS as my front-end UI library.
AngularJS is my "component" library where all the directives, components and services are there to "bootstrap" existing HTML from the web server. The back-end is handled with CakePHP which renders all the HTML.
There is no massive single-page app and there is no AngularJS routing. I load my UI library on each page request, and that's how I'd like to keep doing it.
I spend my day job working with Angular 5. I'm very good at it and I'm the go to guy when other developers have Angular questions.
Despite these skills I've been unable to figure out a migration path for my UI library from AngularJS to the latest Angular. Angular 2+ has been out for a couple of years and I'm still stuck with AngularJS.
Here is an example of my problem:
Take a look at the Material Angular project built with Angular 4. It's basically the same kind of library as my own UI library. It contains a collection of directives and components that you can use.
If you have a web server that responds with existing HTML and you want to use Material Angular as your UI library, then you can't. Let's take the autocomplete component as an example.
The documentation explains how to use autocomplete:
https://material.angular.io/components/autocomplete/overview
There is also a working example of the component:
https://stackblitz.com/angular/ggmpnaqqqxk
In the documentation it shows that you can use the component like this:
<mat-autocomplete>
<mat-option *ngFor="let option of options" [value]="option">
{{ option }}
</mat-option>
</mat-autocomplete>
But when you look at the working example you see the problem that I have. In their example, they have to bootstrap an entire Angular application container that is used to inject the Application HTML which has the autocomplete example.
They can't just use the <mat-autocomplete> component in an existing HTML page.
Now let's take a look at the exact same component done in AngularJS for the old Material Angular project.
It too has a component for autocomplete named <md-autocomplete> and the old version has basically the same features.
There is even a working example:
https://codepen.io/anon/pen/goLrpJ
It too bootstraps an AngularJS application, but it leaves the existing HTML intact. That allows you to use <md-autocomplete> directly in your existing HTML.
How do I create an Angular 5 application that can be used as a component library with existing HTML?
Angular Elements are supposed to address this problem in near future. As explained in detail in this write-up, they are able to provide self-bootstrapping, standalone custom elements.
Currently the issues remain unsolved that restrict the use of attributes and projected content on root component, this seriously narrows down the use of Angular components as custom elements in real-world scenarios.
I am using Yeoman to auto-generate a project using Bootstrap & Sass. The one thing I am having trouble with is changing the default structure of the project to be more modularized. The generator is here on GitHub.com
Currently the application is structured like so:
/app
/images/
/scripts/
/controllers/
main.js
app.js
/styles/
main.css
/views/
main.html
index.html
I'd rather have it separated into individual directives with a core(shared) folder, so that it would be like so:
/app/
/directives/
/home/
home.html
homeCtrl.js
home.sass
index.html
app.module.js
app.route.js
But I am having difficulty figuring out the best method of modularizing the project. Am I supposed to be creating the file structure that I want with the pre-generated application, and then edit it within the Gruntfile.js? Is there a more streamlined way of doing this, or am I SOL doing it manually?
The best and elegant way is to follow their guideline around creating a customised template which you can use to generate apps based on it.
However, if this is a one off thing you probably won't need to bother unless you want to create something decent and share it with community, so other people can use your template and create their app with modularised structure.
Even if you don't try to write your own template you can still read the guide and modify the initial template generator to change the file structure before creating the app for you.
Here is another good article around template customisation:
https://scotch.io/tutorials/create-a-custom-yeoman-generator-in-4-easy-steps
This project appears to be abandoned. The most recent change is a year ago, there are 67 issues and 18 pull requests. It's probably only generating Angular 1.x code as well, and that may not be "up to date" with current Angular 1 best practices.
You can, of course, fork the project and make changes yourself, and even take over maintenance of it, but you might be better to look at something like Angular-cli, which generates Angular2 code, and is being actively developed.
I'm currently using Sails for backend, which comes with an ejs view engine and a templating system which is rather neat. However, setting up Angular on the front end of things will get in the way of these functions.
For instance, I can no longer use templates, because if I have say <html ng-app="myApp"> inside layout.ejs Angular will never initialize.
Same thing should I include any ejs templates.
So what I have done now is created a index.html file inside my assets folder, turned off the Sails routes and layouts, and am purely working with Angular. This will do fine for my current project (except I can't make things as tidy as I'm used to, the boilerplate html need to sit there, etc.) but will it be a problem in other projects, I wonder?
In other words, what am I missing out on by not using ejs? How will I ever be able to get things from my Sails controllers into my views? Or won't I need to?
First this question is WIDE open to interpretation based on all sorts of variables.
If your using your APP simply as JSON delivering API, then in reality you don't need to use the template engine. So the basic premise of your question is valid.
However, their are still plenty of reaons to use the template engine.
For instance, you can still use EJS to setup your default layout and index page for your angular site.
For instance, I can no longer use templates, because if I have say inside layout.ejs Angular will never initialize.
This statement is completely wrong. I use server render templatse for my index page on a SPA in order to use my app version to point to updated assets and template files. That way old template files will not be cached when I update my app. Depending on the app the index page may be the only one to use the template engine as everything else will use static templates. Others I have the server render my templates using the template engine as well (for example: if I want to restrict certain aspects of my templates based on a user role.)
There are other reasons as well. You might try the Google Groups for sails as this is more of an open ended question.
https://groups.google.com/forum/#!forum/sailsjs
If you use Angular for frontend and SailsJs for the backend the best practice is to have two distinct applications which means you don't have use sails to render the views (No EJS mandatory ).
AFAIK SailsJS just need to be used as a REST API while Angular needs to render your views ( you could use http.post get put and delete to comunicate with your api).
Best Regards.
As sails.js is purely backend and Angular.js is purely frontend, they can work together nicely.
All you need to do is place your angular files and logic in
myapp/assets
folder. Assets folder is by default acessible on sails server url.
You can access it as http://localhost:1337/assets/file_name.
As for the ejs, if you are using any javascript framework like angular.js then it is not a requirement as all JSON api will be made in sails framework and angular will get data in JSON format.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm a newbie to Angular.js and trying to understand how it's different from Backbone.js... We used to manage our packages dependencies with Require.js while using Backbone. Does it make sense to do the same with Angular.js?
Yes it makes sense to use angular.js along with require.js wherein you can use require.js for modularizing components.
There is a seed project which uses both angular.js and require.js.
To restate what I think the OP's question really is:
If I'm building an application principally in Angular 1.x, and (implicitly) doing so in the era of Grunt/Gulp/Broccoli and Bower/NPM, and I maybe have a couple additional library dependencies, does Require add clear, specific value beyond what I get by using Angular without Require?
Or, put another way:
"Does vanilla Angular need Require to manage basic Angular component-loading effectively, if I have other ways of handling basic script-loading?"
And I believe the basic answer to that is: "not unless you've got something else going on, and/or you're unable to use newer, more modern tools."
Let's be clear at the outset: RequireJS is a great tool that solved some very important problems, and started us down the road that we're on, toward more scalable, more professional Javascript applications. Importantly, it was the first time many people encountered the concept of modularization and of getting things out of global scope. So, if you're going to build a Javascript application that needs to scale, then Require and the AMD pattern are not bad tools for doing that.
But, is there anything particular about Angular that makes Require/AMD a particularly good fit? No. In fact, Angular provides you with its own modularization and encapsulation pattern, which in many ways renders redundant the basic modularization features of AMD. And, integrating Angular modules into the AMD pattern is not impossible, but it's a bit... finicky. You'll definitely be spending time getting the two patterns to integrate nicely.
For some perspective from the Angular team itself, there's this, from Brian Ford, author of the Angular Batarang and now a member of the Angular core team:
I don't recommend using RequireJS with AngularJS. Although it's certainly possible, I haven't seen any instance where RequireJS was beneficial in practice.
So, on the very specific question of AngularJS: Angular and Require/AMD are orthogonal, and in places overlapping. You can use them together, but there's no reason specifically related to the nature/patterns of Angular itself.
But what about basic management of internal and external dependencies for scalable Javascript applications? Doesn't Require do something really critical for me there?
I recommend checking out Bower and NPM, and particularly NPM. I'm not trying to start a holy war about the comparative benefits of these tools. I merely want to say: there are other ways to skin that cat, and those ways may be even better than AMD/Require. (They certainly have much more popular momentum in late-2015, particularly NPM, combined with ES6 or CommonJS modules. See related SO question.)
What about lazy-loading?
Note that lazy-loading and lazy-downloading are different. Angular's lazy-loading doesn't mean you're pulling them direct from the server. In a Yeoman-style application with javascript automation, you're concatenating and minifying the whole shebang together into a single file. They're present, but not executed/instantiated until needed. The speed and bandwidth improvements you get from doing this vastly, vastly outweigh any alleged improvements from lazy-downloading a particular 20-line controller. In fact, the wasted network latency and transmission overhead for that controller is going to be an order of magnitude greater than the size of the controller itself.
But let's say you really do need lazy-downloading, perhaps for infrequently-used pieces of your application, such as an admin interface. That's a very legitimate case. Require can indeed do that for you. But there are also many other, potentially more flexible options that accomplish the same thing. And Angular 2.0 will apparently take care of this for us, built-in to the router. (Details.)
But what about during development on my local dev boxen?
How can I get all my dozens/hundreds of script files loaded without needing to attach them all to index.html manually?
Have a look at the sub-generators in Yeoman's generator-angular, or at the automation patterns embodied in generator-gulp-angular, or at the standard Webpack automation for React. These provide you a clean, scalable way to either: automatically attach the files at the time that components are scaffolded, or to simply grab them all automatically if they are present in certain folders/match certain glob-patterns. You never again need to think about your own script-loading once you've got the latter options.
Bottom-line?
Require is a great tool, for certain things. But go with the grain whenever possible, and separate your concerns whenever possible. Let Angular worry about Angular's own modularization pattern, and consider using ES6 modules or CommonJS as a general modularization pattern. Let modern automation tools worry about script-loading and dependency-management. And take care of async lazy-loading in a granular way, rather than by tangling it up with the other two concerns.
That said, if you're developing Angular apps but can't install Node on your machine to use Javascript automation tools for some reason, then Require may be a good alternate solution. And I've seen really elaborate setups where people want to dynamically load Angular components that each declare their own dependencies or something. And while I'd probably try to solve that problem another way, I can see the merits of the idea, for that very particular situation.
But otherwise... when starting from scratch with a new Angular application and flexibility to create a modern automation environment... you've got a lot of other, more flexible, more modern options.
(Updated repeatedly to keep up with the evolving JS scene.)
Yes, it makes sense.
Angular modules don't try to solve the problem of script load ordering
or lazy script fetching. These goals are orthogonal and both module
systems can live side by side and fulfil their goals.
Source: Angular JS official website
This I believe is a subjective question, so I will provide my subjective opinion.
Angular has a modularization mechanism built in. When you create your app, the first thing you would do is
var app = angular.module("myApp");
and then
app.directive(...);
app.controller(...);
app.service(...);
If you have a look at the angular-seed which is neat starter app for angular, they have separated out the directives, services, controllers etc into different modules and then loaded those modules as dependancies on your main app.
Something like :
var app = angular.module("myApp",["Directives","Controllers","Services"];
Angular also lazy loads these modules ( into memory) not their script files.
In terms of lazy loading script files, to be frank unless you are writing something extremely large it would be an overkill because angular by its very nature reduces the amount of code you write. A typical app written in most other frameworks could expect a reduction in around 30-50% in LOC if written in angular.
Using RequireJS with AngularJS makes sense but only if you understand how each of them works regarding dependency injection, as although both of them injects dependencies, they inject very different things.
AngularJS has its own dependency system that let you inject AngularJS modules to a newly created module in order to reuse implementations. Let's say you created a "first" module that implements an AngularJS filter "greet":
angular
.module('first', [])
.filter('greet', function() {
return function(name) {
return 'Hello, ' + name + '!';
}
});
And now let's say you want to use the "greet" filter in another module called "second" that implements a "goodbye" filter. You may do that injecting the "first" module to the "second" module:
angular
.module('second', ['first'])
.filter('goodbye', function() {
return function(name) {
return 'Good bye, ' + name + '!';
}
});
The thing is that in order to make this work correctly without RequireJS, you have to make sure that the "first" AngularJS module is loaded on the page before you create the "second" AngularJS module. Quoting documentation:
Depending on a module implies that required module needs to be loaded
before the requiring module is loaded.
In that sense, here is where RequireJS can help you as RequireJS provides a clean way to inject scripts to the page helping you organize script dependencies between each other.
Going back to the "first" and "second" AngularJS modules, here is how you can do it using RequireJS separating the modules on different files to leverage script dependencies loading:
// firstModule.js file
define(['angular'], function(angular) {
angular
.module('first', [])
.filter('greet', function() {
return function(name) {
return 'Hello, ' + name + '!';
}
});
});
// secondModule.js file
define(['angular', 'firstModule'], function(angular) {
angular
.module('second', ['first'])
.filter('goodbye', function() {
return function(name) {
return 'Good bye, ' + name + '!';
}
});
});
You can see that we are depending on "firstModule" file to be injected before the content of the RequireJS callback can be executed which needs "first" AngularJS module to be loaded to create "second" AngularJS module.
Side note: Injecting "angular" on the "firstModule" and "secondModule" files as dependency is required in order to use AngularJS inside the RequireJS callback function and it have to be configured on RequireJS config to map "angular" to the library code. You may have AngularJS loaded to the page in a traditional manner too (script tag) although defeats RequireJS benefits.
More details on having RequireJS support from AngularJS core from 2.0 version on my blog post.
Based on my blog post "Making sense of RequireJS with AngularJS", here is the link.
As #ganaraj mentioned AngularJS has dependency injection at its core. When building toy seed applications with and without RequireJS, I personally found RequireJS was probably overkill for most use cases.
That doesn't mean RequireJS is not useful for it's script loading capabilities and keeping your codebase clean during development. Combining the r.js optimizer (https://github.com/jrburke/r.js) with almond (https://github.com/jrburke/almond) can create a very slim script loading story. However since its dependency management features are not as important with angular at the core of your application, you can also evaluate other client side (HeadJS, LABjs, ...) or even server side (MVC4 Bundler, ...) script loading solutions for your particular application.
Yes, it does, specially for very large SPA.
In some scenario, RequireJS is a must. For example, I develop PhoneGap applications using AngularJS that also uses Google Map API. Without AMD loader like RequireJS, the app would simply crash upon launch when offline as it cannot source the Google Map API scripts. An AMD loader gives me a chance to display an error message to the user.
However, integration between AngularJS and RequireJS is a bit tricky. I created angularAMD to make this a less painful process:
http://marcoslin.github.io/angularAMD/
Short answer is, it make sense. Recently this was discussed in ng-conf 2014. Here is the talk on this topic:
http://www.youtube.com/watch?v=4yulGISBF8w
It makes sense to use requirejs with angularjs if you plan on lazy loading controllers and directives etc, while also combining multiple lazy dependencies into single script files for much faster lazy loading. RequireJS has an optimisation tool that makes the combining easy. See http://ify.io/using-requirejs-with-optimisation-for-lazy-loading-angularjs-artefacts/
Yes it makes sense to use requireJS with Angular, I spent several days to test several technical solutions.
I made an Angular Seed with RequireJS on Server Side. Very simple one.
I use SHIM notation for no AMD module and not AMD because I think it's very difficult to deal with two different Dependency injection system.
I use grunt and r.js to concatenate js files on server depends on the SHIM configuration (dependency) file. So I refer only one js file in my app.
For more information go on my github Angular Seed :
https://github.com/matohawk/angular-seed-requirejs
I would avoid using Require.js. Apps I've seen that do this wind up a mess of multiple types of module pattern architecture. AMD, Revealing, different flavors of IIFE, etc. There are other ways to load on demand like the loadOnDemand Angular mod. Adding other stuff just fills your code full of cruft and creates a low signal to noise ratio and makes your code hard to read.
Here is the approach I use: http://thaiat.github.io/blog/2014/02/26/angularjs-and-requirejs-for-very-large-applications/
The page shows a possible implementation of AngularJS + RequireJS, where the code is split by features and then component type.
Answer from Brian Ford
AngularJS has it's own module system an typically doesn't need something like RJS.
Reference: https://github.com/yeoman/generator-angular/issues/40
I think that it depends on your project complexity since angular is pretty much modularized.
Your controllers can be mapped and you can just import those JavaScript classes in your index.html page.
But in case your project get bigger. Or you anticipates such scenario, you should integrate angular with requirejs. In this article you can see a demo app for such integration.