Develop Reference

Angular 2 project filestructure

If I am creating an Angular 2 application from scratch, is interoperability of modules, components, directives, ect. affected by folder structure if the filepaths of the 'imports' are adjusted accordingly (assuming only files containing these things are the only thing we're shuffling). For example, I decide to have folders such as 'components', 'services', 'styles', 'main' (for root module+component), as opposed to having all of the mentioned thigs in one folder...I could divide those things any which way I wanted as long as 'import {'#blahblah'}' reflected relative position in directory appropriately?

First, if you are creating a new Angular application from scratch, I'd highly recommend using the Angular CLI: https://github.com/angular/angular-cli. If you do, it has its own thoughts on the project file structure.
Second, if you put the templates and styles in the same folder as the associated component, you can simplify your code and use relative paths.
Other than that ... you are free to set up your file structure anyway you wish.

You can, but you should not. Dividing project files by type instead of feature is considered as bad practice, see https://angular.io/guide/styleguide#style-04-07

As it being already stated here you can use Angular CLI to start your project having all best practices in place and to check out Angular styleguide that give you some more details/theory on that.
However it is also very important to get your project logical structure right for that you can check this repo as example (FYI it is build with Angular CLI) and that ng-conf talk by #DeborahK also checkout this article on the same matter.

Large AngularJS application design

I need advise on designing an AngularJS application with multiple complex modules and based upon the user role the module gets loaded after authentication & authorization. Some users could have access to one simple module and some could have dashboard and some could have access to 2+ modules.
There are lot of directives we have identified which can be reused across different modules. During the design phase we have identified the following things that should exist and we have answers for some of the below items, but we still need advice from experts:
A Module could have
Partials
Controllers
Directive
Services
Exception handling (HTTP Status code or Business errors)
Logging (With line number, from which function)
May also need to save the logged info in the server
Should have the ability to turn on and off logging
custom widgets via factory class (Reused in other modules)
Shared Directives (isolated scope)
Shared Modules
Shared Utilities (sorting, filtering, etc.)
Enumerators as per master data
Constants via singleton
Authentication (CSRF)
offline storage
REST services
Event handling for dispatching from one module and handling it in other
UI of the application looks like, a fixed menu bar on the top of the page with a drop down navigation on top left with multiple links depending on the user's role. When the user clicks on a link the corresponding module should get loaded in the page. There has to be an empty project which is manually bootstrapped and loads the other modules at run-time.
Our approach is to have the following folder structure:
app
assets
css
lib js
images
common components
directives
utilities
authentication
Service proxy to hold the $resource calls
Enums
Constants
Model
entity json (example customer, product, etc.)
business Module A
Partials
Directives
Services
Controllers
business Module B
business Module C
index.html
Requirejs config file
So my questions are:
How can a service inside a module talk to other module?
Module should be developed and run independently?
How the communication between module can be handled with transferring data?
How to integrate all the above elements, particularly exception handling, logging?
Developers should understand the convention we have defined?
What method to call for logging, sending info between module?

I recommend to include yeoman into your workflow and use a generator for your project, that makes a lot easier the way that you structure your app, specially if you are working in a team.
earlier this year people from angular released a document with best practices for your app structure, I'd recomment you to read it, being said that there's a generator based on those best practices named cg-angular which I totally recommend.
I'll quote from cg-angular site:
All subgenerators prompt the user to specify where to save the new
files. Thus you can create any directory structure you desire,
including nesting. The generator will create a handful of files in the
root of your project including index.html, app.js, and app.less. You
determine how the rest of the project will be structured.
regarding to your questions:
How can a service inside a module talk to other module?
you can create a folder for directives/ and services/ you are going
to reuse in different modules.
Module should be developed and run independently?
you can have several modules inside an app (you could load them as
needed, maybe using require js but this is offtopic)
How the communication between module can be handled with transferring data?
Use services to pass information between controllers, in different
modules
How to integrate all the above elements , particularly exception handling, logging?
you can do a generic error handler and a generic http interceptor for
all the modules
Developers should understand the convention we have defined?
use a generator they are opinioated and they give the order and the
conventions you need for a team.

Lots of good questions to be asking; they appear to be in two major groups -- the first is a question of code structure and the second is about metrics (logs, etc.).
How can a service inside a module talk to other module?
You should ideally be using directives for your modules. This way you can leverage the ability to link controllers via the require property. Here is a page on sharing data between directives and controllers.
Module should be developed and run independently?
I assume you're thinking about unit testing. Yes, your modules should ideally be as tightly-scoped as possible in order to make testing easier.
How the communication between module can be handled with transferring data?
This is where services are typically used. Note: services, factories and providers all mean the same thing in AngularJS, they're just declared in slightly different ways. Pick whichever one you're most comfortable with.
How to integrate all the above elements , particularly exception handling, logging?
Logging is a separate issue. The beauty of AngularJS is that you can very easily augment existing parts of the framework in order to add functionality or behaviors as you see fit. You do this using decorators. Here is an example of exception logging that I think will cover any use cases you might be interested in
Developers should understand the convention we have defined?
The answer to this is always the same: communication is how they know. Developers need to socialize the convention otherwise you'll never get buy-in.
What method to call for logging , sending info between module?
Answered above.

Code Organization in Large AngularJS and JavaScript Applications
Many developers struggle with how to organize an application's code
base once it grows in size. I've seen this recently in AngularJS and
JavaScript applications but historically it's been a problem across
all technologies including many Java and Flex apps I've worked on in
the past.
The general trend is an obsession with organizing things by type. It
bears a striking resemblance to the way people organize their
clothing.
Piles on the Floor
Let's take a look at angular-seed, the official starting point for
AngularJS apps. The "app" directory contains the following structure:
css/ img/ js/ app.js controllers.js directives.js filters.js
services.js lib/ partials/ The JavaScript directory has one file for
every type of object we write. This is much like organizing your
clothes into different piles on the floor. You have a pile of socks,
underwear, shirts, pants, etc. You know your black wool socks are in
that pile in the corner but it's going to take a while to dig them
out.
This is a mess. People shouldn't live like this and developers
shouldn't code like this. Once you get beyond a half-dozen or so
controllers or services these files become unwieldy: objects you're
looking for are hard to find, file changesets in source control become
opaque, etc.
The Sock Drawer
The next logical pass at organizing JavaScript involves creating a
directory for some of the archetypes and splitting objects into their
own files. To continue the clothing metaphor, we've now invested in a
nice mohaghony dresser and plan to put socks in one drawer, underwear
in another, and neatly fold our pants and shirts in still others.
Let's imagine we're building a simple e-commerce site with a login
flow, product catalog and shopping cart UI's. We've also defined new
archetypes for Models (business logic and state) and Services (proxies
to HTTP/JSON endpoints) rather than lumping them into Angular's single
"service" archetype. Our JavaScript directory can now look like this:
controllers/ LoginController.js RegistrationController.js
ProductDetailController.js SearchResultsController.js directives.js
filters.js models/ CartModel.js ProductModel.js SearchResultsModel.js
UserModel.js services/ CartService.js UserService.js ProductService.js
Nice! Objects can now be located easily by browsing the file tree or
using IDE shortcuts, changesets in source control now clearly indicate
what was modified, etc. This is a major improvement but still suffers
from some limitations.
Imagine you're at the office and realize you need a few outfits
dry-cleaned for a business trip tomorrow morning. You call home and
ask your significant other to take your black charcoal and blue
pinstripe suits to the cleaners. And don't forget the grey shirt with
the black paisley tie and the white shirt with the solid yellow tie.
Imagine that your significant other is completely unfamiliar with the
your dresser and wardrobe. As they sift through your tie drawer they
see three yellow ties. Which one to pick?
Wouldn't it be nice if your clothing was organized by outfit? While
there are practical constraints like cost and space that make this
difficult with clothing in the real world, something similar can be
done with code at zero cost.
Modularity
Hopefully the trite metaphors haven't been too tedious but here's the
recap:
Your significant other is the new developer on the team who's been
asked to fix a bug on one of the many screens in your app. The
developer sifts through the directory structure and sees all the
controllers, models and services neatly organized. Unfortunately it
tells him/her nothing about which objects are related or have
dependencies on one another. If at some point the developer wants to
reuse some of the code, they need to collect files from a bunch of
different folders and will invariably forget code from another folder
somewhere else. Believe it or not, you rarely have a need to reuse all
of the controllers from the e-commerce app in the new reporting app
you're building. You may however have a need to reuse some of the
authentication logic. Wouldn't it be nice if that was all in one
place? Let's reorganize the app based on functional areas:
cart/ CartModel.js CartService.js common/ directives.js filters.js
product/ search/ SearchResultsController.js SearchResultsModel.js
ProductDetailController.js ProductModel.js ProductService.js user/
LoginController.js RegistrationController.js UserModel.js
UserService.js Any random developer can now open the top-level folder
and immediately gain insight into what the application does. Objects
in the same folder have a relationship and some will have dependencies
on others. Understanding how the login and registration process work
is as easy as browsing the files in that folder. Primitive reuse via
copy/paste can at least be accomplished by copying the folder into
another project.
With AngularJS we can take this a step further and create a module of
this related code:
1 2 3 4 5 6 7 8 9 10 11 12 13 var userModule =
angular.module('userModule',[]); userModule.factory('userService',
['$http', function($http) { return new UserService($http); }]);
userModule.factory('userModel', ['userService', function(userService)
{ return new UserModel(userService); }]);
userModule.controller('loginController', ['$scope', 'userModel',
LoginController]); userModule.controller('registrationController',
['$scope', 'userModel', RegistrationController]); view
rawUserModule.js hosted with ❤ by GitHub If we then place
UserModule.js into the user folder it becomes a "manifest" of the
objects used in that module. This would also be a reasonable place to
add some loader directives for RequireJS or Browserify.
Tips for Common Code
Every application has common code that is used by many modules. We
just need a place for it which can be a folder named "common" or
"shared" or whatever you like. In really big applications there tends
to be a lot of overlap of functionality and cross-cutting concerns.
This can be made manageable through a few techniques:
If your module's objects require direct access to several "common"
objects, write one or more Facades for them. This can help reduce the
number of collaborators for each object since having too many
collaborators is typically a code smell. If your "common" module
becomes large subdivide it into submodules that address a particular
functional area or concern. Ensure your application modules use only
the "common" modules they need. This is a variant of the "Interface
segregation principle" from SOLID. Add utility methods onto $rootScope
so they can be used by child scopes. This can help prevent having to
wire the same dependency (such as "PermissionsModel") into every
controller in the application. Note that this should be done sparingly
to avoid cluttering up the global scope and making dependencies
non-obvious. Use events to decouple two components that don't require
an explicit reference to one another. AngularJS makes this possible
via the $emit, $broadcast and $on methods on the Scope object. A
controller can fire an event to perform some action and then receive a
notification that the action completed. Quick Note on Assets and Tests
I think there's more room for flexibility with respect to organizing
HTML, CSS and images. Placing them in an "assets" subfolder of the
module probably strikes the best balance between encapsulating the
module's asset dependencies and not cluttering things up too much.
However I think a separate top-level folder for this content which
contains a folder structure that mirrors the app's package structure
is reasonable too. I think it works well for tests as well.
Please have a look at the below link,
https://blog.safaribooksonline.com/2014/03/27/13-step-guide-angularjs-modularization/

Durandal and MVC4 Areas for multiple SPAs

I have a internet application mvc4 with areas, for my organization each area represent a SPA and through "Manage NuGet Package" I installed "Durandal 1.2.0", "Durandal Transitions 1.2.0" and "Durandal Router 1.2.0". I organized the folders and quit the "views" and "viewmodels" from folder "App" of Durandal and put the new views in folder "VIews" of mvc4 area for example:
Areas-->NewArea-->Views-->ControllerFolder-->views-->shell.html
Then I put the '"viewmodels" in "Script" folder for example:
Scripts-->NewArea-->ControllerFolder-->viewmodels-->shell.js
Scripts-->NewArea-->ControllerFolder-->main.js
Then I changed paths for JS of durandal, for example in main.js:
define(['../../../App/durandal/app',
'../../../App/durandal/viewLocator',
'../../../App/durandal/system',
'../../../App/durandal/plugins/router',
'../../../App/services/logger'],
And I changed main.js in the next line:
viewLocator.useConvention('viewmodels', '../Areas/NewArea/Views/ControllerFolder/views');
But that configuration of folders fails because the next line calls various times the module "viewLocator" in its definition and rewrite the configuration of "useConvention" with default value:
app.setRoot('viewmodels/shell', 'entrance');
That behavior only happen when the folders "views" and "viewmodels" don't stay under "App" folder of "Durandal".
Please help me, how to have various SPAs in the same project?

You might want to consider your deployment strategy. For example, if you need to optimize this app, both SPAs will end up in the same file. However, instead of having them both under the app folder, you can make separate folders, and give each SPA it's own main.js file.
In more advanced scenarios, you may create a "bootstrapper" app that loads one or another of the SPAs. The bootstrapper would contain code that is common to both SPAs. But each SPA (and the bootstrapper) can be optimized independently.
There are many options. Mainly, consider your final deployment strategy and that will help guide you here.
Also, the issue you have above is probably related to the fact that the standard conventions may not work in your setup, and you would need to override some functions with your own mapping.

I ran into the exact same problem this morning. I originally formatted the project to be:
app/spa1/viewmodels
app/spa1/views
app/spa2/viewmodels
app/spa2/views
Using this structure I hit the exact same wall you did. After reading your post, I restructured the project to be:
app/viewmodels/spa1
app/viewmodels/spa2
app/views/spa1
app/views/spa2
Using this structure, navigation works fine. I set up three SPAS and was able to navigate all three. The other benefit of this structure is that you are now following the standard convention so you don't have to configure the view locator. Just make sure the main.js file for each spa uses:
app.setRoot('view models/spa1/shell), app.setRoot('view models/spa2/shell), etc.
Finally, by structuring this way, you move the main.js files up the structure which eliminates the ../../../ in all your defines.
I hope this helps.

Backbone-RequireJs boilerplate for component based large web-projects

We have a large web project, where we need components which can talk to each other which can be put in a central repository of components for different projects.
Using reuirejs and Backbone for the modular development. Went through different boilerplate available for backbone and requirejs, but none matched my requirement. So I have created following directory structure. It can be explained as follows.
---resources
|---custom-components
|---mycomponent
|---js
|---views
|---models
|---collections
|---css
|---templates
|---mycomponent.js
|---mycomponent2
|---js
|---views
|---models
|---collections
|---css
|---templates
|---mycomponent2.js
|---libraries
|---backbone
|---underscore
|---jquery
|---jquery-ui
|---jqueryplugins
|---jcarouselite
|---thirdpartyplugins
|---page-js
|---mypage.js
|---mypage2.js
resources directory will contain all the resources. Under that we will have 4 directories as mentioned.
libraries, jqueryplugins and thirdpartyplugins are obviusly the directories for the name they say.
page-js directory will contain the actual main-js which will be used inside our html file as requirejs data-main attribute.
Custom-component is where all widgets created by us will reside, as you can see it has a js file with same name as that of the component, which will be entry point of this widget. This directory also has directories for js, css and templates. CSS and templates will be loaded by text plugin and CSS plugin respectively. Js directory will contain all the backbone code to make this widget work.
Custom components will be asked by main-js residing in page-js.
Coming to what I need.
1. I want experts to have review this directory structure in perspective of large web projects, where you will need to share your widgets with other teams. suggestions are welcome.
2. My each custom-component will define a module, which will have dependencies within package structure as well as outside package structure. I want to know, if there is any way to use r.js to optimize only my custom widget dependency within package structure and let the plugins and libraries optimized separately.
3. I am developing single page ajax application, so I will be asking modules on demand so I need to cleanup modules and widgets when I dont need them, is there any way for cleaning up I should be aware of?

About the directory structure
As a directory structure pattern, I highly recommend using directory structure of cakePHP. it's really robust as in words!! I'm running multiple apps (one of them is as big as Groupon) and it works just like a charm.
You may need to tweak it a little because, you know, cake is a PHP framework and yours is a javascript one.
Here is the cake's awesome MVC directory structure:
Please note that you may host thousands of apps on a single cake installation. so if you're interested, what are you waiting for? go to their site and read their docs.
About the cleaning up techniques
Well, here is one of the downsides of the Javascript which I don't like. there is no real way to destroy a OO module like in Java or C++. here we don't have such things like C++'s ~ destructors.
For many years, programmers use module = null to free up memory from un-used codes.
Take a look at these also:
Can dynamically loaded JavaScript be unloaded?
Loading/unloading Javascript dynamically
How to unload a javascript from an html?
Hope it helps and good luck on designing your app ;D

Probably I'm late in answering this, but anyway let me share my views here, incase someone else finds it useful.
Your directory structure looks alright. It is always a better design to keep your business components self contained in to a particular directory. I will not recommend Cake MVC structure which break the Open Close Principle. Also have a look at the directory structure recommended by http://boilerplatejs.org which is a reference architecture for large scale JavaScript development.
I do not get the question very clear. when r.js is run it will optimize all JS files it find in the directory (exclude possible) and then create a single script by going though the dependency tree. In production you only need that single script (plus locale files if i18n plugin is used)
Read my blog post below. It might give you some hints: http://blog.hasith.net/2012/11/how-much-multi-page-single-page.html

What's the recommended way to organise big sproutcore projects?

I'm just taking a look at Sproutcore (gem version 1.6.0.1) to see what I can do with it.. so excuses for the beginner questions...
I've gone through the tutorial and looked at the doc mini-site.
I'm wondering how I should organise my source code files. After building the really simple todo app I've already got one messy monolithic javascript file that contains a model, some views, some view controllers, etc.. i can't picture this scaling well.
I've noticed that if I add another js file it is automatically inserted into the project when I load the app in a browser but I'm second-guessing what order those files go in - alphabetically my file (test.js) should have been included before todos.js but it wasn't.
What's the recommended approach to organise a larger scale app; are there some guidelines for this?
Couldn't see anything on the sproutcore website, strangely enough..
What if I want to share models between apps, is that possible too ?
Thanks

The helper tools should arrange the files for you. Granted, you might not use them. Here is the folder structure I have from a project I did a while ago
So under the root project directory, there is an apps dir, a frameworks dir, and a Buildfile and README (the other stuff you see is not necessary for sproutcore).
In the apps dir, you see the main app (sudoku in this case) directory. Under it, you see, directories that directly relate to the objects you are going to create -- datasources, controllers, models, views, states, etc....If you put more than one app in the apps dir, you can access both from localhost:4020/, i.e. localhost:4020/app1 vs localhost:4020/app2
I didn't expand the frameworks dir, but in it are all the frameworks the project uses. So if you want to modify sproutcore, you can put the version you use in frameworks, and the build tools will use that version. It is a good idea to make your model layer its own framework, so you can use it with other projects if you want. You model framework should be completely decoupled from the rest of the app; it should expose an API that any client app will use.
You can further create other directories under these directories at your discretion. For example, if you have a complicated application around a Person model, you can create person directories under models, views, controllers, etc, and then put your code in their.
Note that if you have a PersonController object, the file name would be person.js according to convention, but that's up to you.