I've been trying to find the best way to create a modular, scalable angular application. I really like the structure of projects like angular-boilerplate, angular-app, where all the related files are grouped together by feature for partials and directives.
project
|-- partial
| |-- partial.js
| |-- partial.html
| |-- partial.css
| |-- partial.spec.js
However, in all these examples, the template URL is loaded relative to the base url, not relative to the current file:
angular.module('account', [])
.config(function($stateProvider) {
$stateProvider.state('account', {
url: '/account',
templateUrl: 'main/account/account.tpl.html', // this is not very modular
controller: 'AccountCtrl',
});
})
This is not very modular, and could become difficult to maintain in large projects. I would need to remember to change the templateUrl path every time I moved any of these modules. It would be nice if there was some way to load the template relative to the current file like:
templateUrl: './account.tpl.html'
Is there any way to do something like this in angular?
The best way to do this now is using a module loader like browserify, webpack, or typescript. There are plenty of others as well. Since requires can be made from the relative location of the file, and the added bonus of being able to import templates via transforms or loaders like partialify, you don't even have to use template urls anymore. Just simply inline the Template via a require.
My old answered is still available below:
I wrote a post on exactly this subject and spoke on it at our local Angular Meetup. Most of us are now using it in production.
It is quite simple as long as your file structure is represented effectively in your modules. Here is a quick preview of the solution. Full article link follows.
var module = angular.module('myApp.things', []);
var all = angular.module('myApp.things.all', [
'myApp.things',
'things.someThing',
'things.someOtherThing',
'things.someOtherOtherThing',
]);
module.paths = {
root: '/path/to/this/thing/',
partials: '/path/to/this/thing/partials/',
sub: '/path/to/this/thing/sub/',
};
module.constant('THINGS_ROOT', module.paths.root);
module.constant('THINGS_PARTIALS', module.paths.partials);
module.constant('THINGS_SUB', module.paths.sub);
module.config(function(stateHelperProvider, THINGS_PARTIALS) {
stateHelperProvider.setNestedState({
name: 'things',
url: '/things',
templateUrl: THINGS_PARTIALS + 'things.html',
});
});
And then any sub modules or "relative" modules look like this:
var module = angular.module('things.someThing', ['myApp.things']);
var parent = angular.module('myApp.things');
module.paths = {
root: parent.paths.sub + '/someThing/',
sub: parent.paths.sub + '/someThing/sub/',
partials: parent.paths.sub + '/someThing/module/partials/',
};
module.constant('SOMETHING_ROOT', module.paths.root);
module.constant('SOMETHING_PARTIALS', module.paths.partials);
module.constant('SOMETHING_SUB', module.paths.sub);
module.config(function(stateHelperProvider, SOMETHING_PARTIALS) {
stateHelperProvider.setNestedState({
name: 'things.someThing',
url: "/someThing",
templateUrl: SOMETHING_PARTIALS + 'someThing.html',
});
});
Hope this helps!
Full Article: Relative AngularJS Modules
Cheers!
I think you'll eventually find that maintaining the paths relative to the js file will be harder, if even possible. When it comes time to ship, you are most likely going to want to concatenate all of your javascript files to one file, in which case you are going to want the templates to be relative to the baseUrl. Also, if you are fetching the templates via ajax, which Angular does by default unless you pre-package them in the $templateCache, you are definitely going to want them relative to the baseUrl, so the server knows where to find them once your js file has already been sent to the browser.
Perhaps the reason that you don't like having them relative to the baseUrl in development is because you aren't running a server locally? If that's the case, I would change that. It will make your life much easier, especially if you are going to work with routes. I would check out Grunt, it has a very simple server that you can run locally to mimic a production setup called Grunt Connect. You could also checkout a project like Yeoman, which provides a pre-packaged front end development environment using Grunt, so you don't have to spend a lot of time getting setup. The Angular Seed project is a good example of a Grunt setup for local development as well.
I've been chewing on this issue for a while now. I use gulp to package up my templates for production, but I was struggling to find a solution that I was happy with for development.
This is where I ended up. The snippet below allows any url to be rewired as you see fit.
angular.module('rm').config(function($httpProvider) {
//this map can be defined however you like
//one option is to loop through script tags and create it automatically
var templateMap = {
"relative.tpl.html":"/full/path/to/relative.tpl.html",
etc...
};
//register an http interceptor to transform your template urls
$httpProvider.interceptors.push(function () {
return {
'request': function (config) {
var url = config.url;
config.url = templateMap[url] || url;
return config;
}
};
});
});
Currenly it is possible to do what you want using systemJs modules loader.
import usersTemplate from './users.tpl';
var directive = {
templateUrl: usersTemplate.name
}
You can check good example here https://github.com/swimlane-contrib/angular1-systemjs-seed
I had been using templateUrl: './templateFile.tpl.html but updated something and it broke. So I threw this in there.
I've been using this in my Gruntfile.js html2js object:
html2js: {
/**
* These are the templates from `src/app`.
*/
app: {
options: {
base: '<%= conf.app %>',
rename: function( templateName ) {
return templateName.substr( templateName.lastIndexOf('/') );
}
},
src: [ '<%= conf.app %>/**/{,*/}<%= conf.templatePattern %>' ],
dest: '.tmp/templates/templates-app.js'
}
}
I know this can lead to conflicts, but that is a smaller problem to me than having to edit /path/to/modules/widgets/wigdetName/widgetTemplate.tpl.html in every file, every time, I include it in another project.
Related
I am trying to read environment variables in http get calls
$http.get('http://' + $location.host() + ':8080/api')
I want to be able to read the environmen variable and use it as the http rest server in teh above API call, as follows
$http.get('environmental_variable ':8080/api')
Note: I dont know the environment variable until runtime So I cannot have the value before hand to use it as a constant
There are lots of examples showing how you can put your settings into different files or constants. Most of these work, but miss the point.
Your configuration settings are not part of your code!
Apart from the 'Hello World' examples, your deployment should be carried out by a CI/CD server and this should be responsible for setting your configuration settings. This has a number of benefits:
1) You are deploying the same code to different environments. If you deploy code to a test environment, then you want to deploy the same code to your production environment. If your servers have to rebuild the code, to add the production configuration settings, you are deploying different code.
2) Code can be shared without giving away your API details, AWS settings and other secret information.
3) It allows new environments to be added easily.
There are lots of examples out there on how to do this. One example is www.jvandemo.com/how-to-configure-your-angularjs-application-using-environment-variables
There are no such things as environment variables in the browser.
The $location service is always going to get your current URL. I guess your API might live on a different host.
It's possible to simulate environment variables by storing configuration in an Angular constant.
app.constant('env', {
API_URL: "http://someurl.com:8080/api"
});
Then you can inject this constant into your other providers.
app.controller('MyController', function($http, env) {
$http.get(env.API_URL);
});
Here's a decent article on best practices with constants. The article favours not using constants, as it's useful to be able to modify the configuration without having to rebuild the code.
The way I normally handle this is to move all the instance configuration details out to a config.json file, then load it with $http when I bootstrap my application.
For instance, you might have a config file like this.
{
apiUrl: "http://someurl.com:8080/api"
}
Then an Angular service that loads it.
app.service('Config', function($http) {
return function() {
return $http.get('config.json');
};
});
Then other services can get hold of the promise, that will expose the config when resolved.
app.controller('MyController', function($http, Config) {
Config()
.then(function(config) {
$http.get(config.apiUrl);
});
});
I strongly suggest you to use a library for setting environment variables. You can use angular-environment plugin to do that: https://www.npmjs.com/package/angular-environment
Here's a example
angular.module('yourApp', ['environment']).
config(function(envServiceProvider) {
// set the domains and variables for each environment
envServiceProvider.config({
domains: {
development: ['localhost', 'acme.dev.local'],
production: ['acme.com', '*.acme.com', 'acme.dev.prod'],
test: ['test.acme.com', 'acme.dev.test', 'acme.*.com'],
// anotherStage: ['domain1', 'domain2']
},
vars: {
development: {
apiUrl: '//api.acme.dev.local/v1',
staticUrl: '//static.acme.dev.local',
// antoherCustomVar: 'lorem',
// antoherCustomVar: 'ipsum'
},
test: {
apiUrl: '//api.acme.dev.test/v1',
staticUrl: '//static.acme.dev.test',
// antoherCustomVar: 'lorem',
// antoherCustomVar: 'ipsum'
},
production: {
apiUrl: '//api.acme.com/v1',
staticUrl: '//static.acme.com',
// antoherCustomVar: 'lorem',
// antoherCustomVar: 'ipsum'
},
// anotherStage: {
// customVar: 'lorem',
// customVar: 'ipsum'
// },
defaults: {
apiUrl: '//api.default.com/v1',
staticUrl: '//static.default.com'
}
}
});
// run the environment check, so the comprobation is made
// before controllers and services are built
envServiceProvider.check();
});
Then you can get the right variable based on what environment your application is running:
var apiUrl = envService.read('apiUrl');
Cheers!
I'm part of a team developing an AngularJS application and right now I'm working on modifying the Gulp build script. Part of my task is prepopulating the template cache (up till now we have been loading the templates as the routes/directives needed them).
The Gulp task is basically:
var templateCache = require('gulp-angular-templatecache');
gulp.task('cache-templates', function(){
var dest = destinationPath,
src = sourcePath;
return gulp.src(src)
.pipe(plumber())
.pipe(templateCache('templates.js', {root: './templates/'}))
.pipe(gulp.dest(dest));
});
The problem I am getting is that gulp removes the "./" from the root. For instance:
$templateCache.put("templates/foo.html","<div>some html</div>");
in stead of
$templateCache.put("./templates/foo.html","<div>some html</div>");
The module is loaded correctly into app.js and declared as a dependency, and if I do put the "./"'s as a prefix manually, after building, everything works fine. So could you please tell me how to force Gulp to include the "./" prefix in my root?
Note: Every other prefix works fine, it just removes the "./". I would prefer it if I could solve this from within the Gulpfile, without having to modify the templateUrl's in my directives and $routeProvider, because the application is rather large and that would only be asking for trouble. Thanks! :)
What you can do is use gulp-replace and replace 'templates/' with './templates/'.
Old Answer
In the options that you pass to template you can provide a base function
.pipe(templateCache('templates.js', {root: './templates/', base: baseFn}))
you can modify the file-path there
var baseFn = function (file) { return './' + file.relative; }
i would like to consolidate the url base for my RESTFul API in a single place in my app built with Sencha Touch. Where is the best place i can put it?
There is a obvious option to store it in localStorage, but is this a good practice ?
When I want to support MVC structure I create file Config.js and put it in application tree in the following place:
in Config.js:
Ext.define('MyApp.config.Config', {
singleton: true,
config: { /** here you can put any objects of your choice that will be accessible globally**/
baseURL : Ext.os.is.Android ? 'http://live_url_here.com' : 'http://localhost/testing_locally',
topBannerUrl : 'http://some_url/banner.png',
anotherGlobalParam : true
},
constructor: function(config) {
this.initConfig(config);
return this;
}
});
Those config parameters will be visible in the whole application.
You may get them:
MyApp.config.Config.getBaseImgURL(); /* returns 'http://some_url/banner.png' */
MyApp.config.Config.getAnotherGlobalParam(); /* returns true */
or set:
MyApp.config.Config.setBaseImgURL('new_url');
MyApp.config.Config.setAnotherGlobalParam(false);
This solution may be especially handy when your project requires many configuration parameters.
I hope it will work for you as well.
Always keep your url base in a seperate file like util.js(utility.js). Your file path should be app > util > Util.js. You can keep your common functions like animateItem, showLoading/hideLoading, custom functions, etc over here so that you can use the same function throughout the app. To load this file in your app do this:
app.js
Ext.application({
name: 'HelloWorld',
requires: [
'HelloWorld.util.Util'
],
view: []
})
For best practices in sencha touch you can see this: Sencha Touch Blog
+1 for Anubis recommendation.
Something like this:
Ext.define('MyApp.Const', {
statics:{
url1:'....',
url2:'....'
}
})
Then you can access your urls with:
MyApp.Const.url1
Of course you must require Const class but you don't need to instantiate it.
I have an AngularJS application and in the future, some developers in other teams will develop modules that will be installed as parts of it. So I defined the folder structure as below.
www/
index.html
app.js
modules/
modulesA/ -- will be copied when module A was installed
moduleA.js
moduleA.css
moduleA.partial.html
modulesB/ -- will be copied when module B was installed
moduleB.js
moduleB.css
moduleB.partial.html
Now I have a problem. When user installed module A, how to let AngularJS (and the application) load JS and CSS under its folder? Is there any library can load JS and CSS by folder so that I can put the code in index.html likes
<script src="/modules/**/*.js"></script>
<link src="/modules/**/*.css"/>
Otherwise, I have to add some placesholders in index.html and change the content when user installed a module, something like
<script src="/app.js"></script>
<!-- $$_JS_$$ -->
<link src="/app.css"/>
<!-- $$_CSS_$$ -->
AngularJS doesn't support what you want, but you could take a look at build tools such as Grunt or Gulp that let you "build" your application for you. In your case, these tools can look for CSS files and concatenate them into one single file. This way your index.html does not have to change if you ever add new modules.
GruntJS: http://gruntjs.com/
GulpJS: http://gulpjs.com/
Personally I use GulpJS, since it seems to be much faster & I found it easier to configure:
Included my configuration file below.
For example, the task "styles" will compile every css file it finds in the folders I specified, concatenate them, and drop them in the distribution folder.
Since there is an initial learning curve on how to use these tools, you can always integrate gulp or grunt at your own pace. For now you could let it build your css files & later expand it by concatenating JS as well and do various other tasks. In my opinion, its worth learning as it saves you so much time & effort.
var gulp = require("gulp");
var concat = require("gulp-concat");
var html2js = require("gulp-ng-html2js");
var sass = require("gulp-sass");
var clean = require("gulp-clean");
var streamqueue = require("streamqueue");
var ngDepOrder = require("gulp-ng-deporder");
var paths = {
"dist": "../server/staffing/static/",
"vendor": ['vendor/underscore/underscore.js',
'vendor/angular/angular.min.js',
'vendor/angular-route/angular-route.min.js',
'vendor/restangular/dist/restangular.min.js',
'vendor/angular-animate/angular-animate.min.js',
'vendor/angular-bootstrap/ui-bootstrap-0.7.0.min.js',
'vendor/angular-bootstrap/ui-bootstrap-tpls-0.7.0.min.js',
'vendor/angular-ui-router/release/angular-ui-router.min.js',
'vendor/angular-bootstrap-colorpicker/js/bootstrap-colorpicker-module.js',
'vendor/momentjs/min/moment.min.js'],
"scripts": ['app/**/*.js'],
"fonts": ['app-data/fonts/*.*'],
"templates": ['app/**/*.html'],
"styles": ['app/**/*.scss','vendor/angular-bootstrap-colorpicker/css/*.css']
}
gulp.task("watch", function () {
gulp.watch('app/**/*.js', ['scripts']);
gulp.watch('app/**/*.html', ['scripts'])
gulp.watch('app/**/*.scss', ['styles']);
})
gulp.task("default", ["clean"], function () {
gulp.start("scripts", "vendor", "styles", "fonts");
})
gulp.task("clean", function () {
return gulp.src(paths.dist, {read: false})
.pipe(clean({force: true}));
})
gulp.task("vendor", function () {
gulp.src(paths.vendor)
.pipe(concat("vendor.js"))
.pipe(gulp.dest(paths.dist + "js/"));
});
gulp.task("scripts", function () {
var stream = streamqueue({objectMode: true});
stream.queue(gulp.src(paths.scripts)
.pipe(ngDepOrder()));
stream.queue(gulp.src(paths.templates)
.pipe(html2js({moduleName: "templates"})));
return stream.done()
.pipe(concat("app.js"))
.pipe(gulp.dest(paths.dist + "js/"))
});
gulp.task("styles", function () {
gulp.src(paths.styles)
.pipe(sass())
.pipe(concat("staffing.css"))
.pipe(gulp.dest(paths.dist + "css/"))
})
gulp.task("fonts", function () {
gulp.src(paths.fonts).
pipe(gulp.dest(paths.dist + "fonts/"))
})
Check out the angular generator for Slush, it does what I think you want using gulp-bower-files and gulp-inject. You specify your app dependencies using bower, and these are collected and injected by gulp using gulp-inject, which then injects in your index.html the proper link/src/style tags that look very much like your own examples above. Modules' JS and CSS is also collected, minimized, concatenated and injected as well. It also compiles partials and injects those into $templateCache.
I have used it to automatically include dependencies from sub-folder modules/views using a project layout similar to yours.
Note that all your vendor dependencies will need to be bower packages that specify their dist files using the 'main' attribute in bower.json. Some packages do not do this properly, but it's easy to fork the package and add them yourself then point bower at your updated repo.
In my application we are using RequireJs and Backbone
So a typical model might look like the following in a separate file so we can attempt to modularize this application better:
define([
'Require statements here if needed'
],
function() {
var toDo = Backbone.Model.extend({
// Model Service Url
url: function () {
var base = 'apps/dashboard/todo';
return (this.isNew()) ? base : base + "/" + this.id;
},
// Other functions here
});
return toDo;
});
Right now we keep each model and collection in its own file and return the Model/Collection as above. The bigger the application gets the harder it is to keep the files and naming convention straight. I would like to combine similar collections/models together into 1 file and maintain the modularity.
What is a good way to achieve this? Or should I stick with them in separate files and get a better naming convention? If so, what do you use for your naming convention between similar Collections/Models?
This is the way I structure my application :
I have a javascript path, which I'm minifying on demand by the server when client access "/javascript", so I have only one script line in my index.html :
<script src='/javascript'></script>
My directory structure of /javascript is the following :
application.js
router.js
lib/
lib/jquery.js
lib/underscore.js
lib/backbone.js
lib/require.js
lib/other_libraries.js
views/
views/navigation.js
views/overlay.js
views/content.js
views/page
views/page/constructor.js
views/page/elements
views/page/elements/constructor.js
views/page/elements/table.js
views/page/elements/form.js
views/page/elements/actions.js
collections/
collections/paginated.js
All those files are minified and loaded from client in the first request. By doing this I have a lot of my code already loaded in my browser before the application makes any requests with RequireJS.
On my server I have a directory, which is also public, but is for dynamic javascript loading and templates ( it is accessed by demand from the application at any given time ). The directory looks like this :
dynamic/
dynamic/javascript
dynamic/javascript/pages
dynamic/javascript/pages/articles.js
dynamic/templates
dynamic/templates/pages
dynamic/templates/pages/articles.hb
dynamic/templates/pages/items.hb
When my server requests "/templates/pages/articles.hb" the server returns JSON object which looks like this :
{ html : "<div class='page' id='articles'>blah blah blah</div>", javascript : "javascript/pages/articles.js" }
And when my client app receives "javascript" property in the returned JSON object it triggers a RequireJS request
if ( typeof json.javascript === string ) {
require([ json.javascript ], function(constructor) {
window.app.page = new constructor();
});
}
In the dynamic/javascript/pages/articles.js I have something like :
define(function() {
var Model = Backbone.Model.extend({});
// Collections.Paginated is in fact the Collection defined by /javascript/collection/paginated.js
// it is already loaded via the initial javascript loading
var Collection = Collections.Paginated.extend({
url : '/api/articles'
});
// Views.Page is in fact the View defined by /javascript/views/page/constructor.js
// it is also already loaded via the initial javascript loading
var articles = Views.Page.extend({
collection : Collection,
initialize: function(options) {
this.collection = new Collection();
});
});
return articles;
});
Pretty much that's it. I have minimum requests with RequireJS, because every time you hit require('something.js') it makes a request to the server, which is not good for your application speed.
So the exact answer of your question ( in my opinion ) is : You should make your initial loaded files separated as much as possible, but later loaded files with requireJS should be as small as possible to save traffic.