I am currently writing a big Ember.js application. I know Ember.js is quite monolithic but I wanted to drift a bit from this and create modules that I would plug in my application.
I have no problem with component-only modules or those kind of things. My big issue is to import new routes in my Ember-cli application.
Usually I would have my App.Router and I could create App.xxxRoute whether I define the route in app/routes/my-route.js or in lib/myModule/routes/my-route.js.
With the Ember-cli ES6 Module syntax, the routes taken into account are only the ones from the app/routes folder and as there is no global scope anymore, I can't attach the routes coming from my module to my main application.
This is a bit of a pain.
I have tried a lot of things, ranging from trying to add my routes to the Ember.Router.router.recognizer manually (does not work) to creating the routes files in app/routes and exporting the ones from my modules for each of one of them (but it creates a lot of useless files).
The easiest solution would be to be able to add a directory to the ember-cli path loader or whatever it's called but I'm open to any suggestion.
Thanks a lot.
The approach that I would take is to build an add-on, as mentioned in the comments.
And maybe, depending on your needs, add some initializers that inject objects and anything you like to all your routes or controllers in your app.
See: Dependency Injection & Service Lookup
For an example of an add-on that uses initializers you can check Ember Simple Auth
Related
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.
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/
I have begun using ember app kit and heave read through its guides. However I having trouble wrapping my head around the differences between a regular app and this way that Ember App Kit structures the various bits using ES6 modules instead of stuffing everything into a global variable used as a namespace (e.g. App).
I found that this aspect is not very clearly explained:
How does Ember apply its magic in auto generating models, views, routes, and controllers?
Where does it expect to find them?
What naming conventions should I follow?
If I have created a template, route,or controller, and Ember does not find/ detect it, and just generates a default one in its place, how do I find out where it is looking; or otherwise debug in this situation?
How is any of this different in the standard Ember app development, as compared to development using Ember App Kit?
Much appreciated in advance!
EDIT (20140506):
These resources explain ES6 modules and EAK really well:
A brief overview: eviltrout: getting started with ES6
An entire series of posts: [toranb: http://toranbillups.com/blog/archive/2014/04/06/Building-your-own-ember-app-kit-lite/), with an ES6 modules specific one
I actually did a blog series on this very topic just a few weeks ago. I start with a basic (globals) ember app and transform it over 8 different posts.
Part 1 - Introduction
Part 2 - Concatenation (introducing Grunt)
Part 3 - Handlebars template precompilation
Part 4 - ES6 modules
Part 5 - JSHint
Part 6 - Watch + Live Reload
Part 7 - Testem
Part 8 - Deployment
In the end, you have a Gruntfile w/ tasks just like EAK (but you've built it all by hand -one step at a time)
Stefan Penner does a pretty good job of explaining modules on Ember App Kit's site, but to summarize:
Ember App Kit uses the ES6 Module Transpiler to convert all your app's Ember classes into AMD modules. In "normal" Ember development, you assign classes as properties of your app...
App.IndexController = Ember.Controller.extend(...);
But with EAK, you write your modules in ES6 syntax:
export default Ember.Controller.extend(...);
The transpiler will use the file name as the basis for its module name (assuming that it's saved at app/controllers/index.js:
define('controllers/index', Ember.Controller.extend(...));
Ember App Kit then uses a custom resolver to look up modules using AMD, rather than looking for them as camel cased properties of your App. (I don't have the rep to post another link, so google for ember-jj-abrams-resolver.)
If Ember looks for a module and doesn't find it, it behaves the same way it does outside of EAK.
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.
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.