I am using angular seed project
https://github.com/angular/angular-seed
where should I put the services and directives ?
This is really totally up to you but there are some good recommendations on project structure here: https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub
Typically my structure looks something like
app\scripts\user.js
app\scripts\todo.js
Where User.js would have a service and possibly multiple controllers in it... if the file gets too large then I break it up into parts.
The problem with grouping all services together and all controllers is that the services and controllers typically have a relationship (functionally). When you want to re-use the service/controller you are typically going to use them together, when editing one you usually need a reference to the other. This makes it easiest to find things and not have 1000 js files to include and manage in the dependencies and script inclusions.
Also when it comes time and you want to make a bower component out of one of the sections it's easier to see which parts need to be pulled out.
You can make a folder for each under app, so your project tree will look like this:
app/directives
app/services
Related
I'm using ui-router/stateProvider to load various views for a single page app. Additionally I'm following what appears to be best practice for structuring code by breaking my code into components so I have, for example;
Index.html
\Components
\Component1
\page1.html
\page1.css
\page1-controllers.js
\page1-directives.js
\Component2
\page2.html
\page2.css
\page2-controllers.js
\page2-directives.js
I have quite a few different views/components (10+) and my question really relates to how to manage the loading of the js files (and the CSS files for that matter). I can put the JS files all in tags in the index.html file and all works fine, but looks a bit messy as it is a very long list.
So my question is: How should I manage the inclusion of the various scripts for each view; should they all remain in the index.html file or is there a better way of managing them, such as loading only when each view is called via the ui-router?
Many Thanks
I think that you need to use RequireJs, I will include a couple of sites with the documentation that explain how implement that.
http://www.javascripthtml.com/load-dynamically-javascript-file-in-angularjs-with-requirejs/
https://cdnjs.com/libraries/backbone.js/tutorials/organizing-backbone-using-modules
For css you may want to add a single class to each view then use a single css file for all views. I keep the css organized into modules for easy access. This will also help load times as it will require less requests.
For js I would create a universal js file that contains any code that is required for ALL views, then create individual js files for individual views. There really isn't a "right" way per se but preferred ways depending on the developers you work with. Keep it simple and easy for other developers to read. :)
I have the same problem as you, I think that the only solution for us is to add the script in the "index.hmtl" page.
I'm developing a web-application with angular and this will be used for different customers. Each customer has his own needs (specific functionality) and style (css). A lot of the functionality is shared though.
What I'm looking for is a total solution to keep this project clean and maintainable. The code will be running on the local server of each customer and the customers shouldn't see the specific code for the other customers (with other words, something like grunt should have filtered the deployment).
What I had in mind:
Define different tasks in grunt to watch, build, etc per customer
Define parent controllers (~inheritance) and parent views to share functionality
Use a subfolder for each customer
e.g. views:
app/views/general/home.html (loads main.tpl.html)
app/views/customer1/main.tpl.html
app/views/customer2/main.tpl.html
e.g. controllers:
app/scripts/controllers/general/...
app/scripts/controllers/customer1/... (extends general controllers)
e.g. css
app/styles/general/...
app/styles/customer1/...
Grunt will select only the files relevant for the customer and should remove the customer-related paths. (e.g. both app/views/customer1/ and app/views/customer2/ should go to app/views/customer, which is loaded by app/views/general/home.html)
A big disadvantage will be that the app/views/general/home.html will have a reference to unexisting file while developing. The same goes for index.html where I need to include the controllers from the target dist folder, not from the project folder structure (while developing). Which makes everything a bit less readable and logical.
Do you think this is a good approach? Are there optimizations or alternatives coming to mind? Do you know of any grunt modules or angular modules aiding for such set-up?
Thanks in advance!
One approach you could use is to run a basic node server that will store and serve up, using a rest call, the user preferences. So you would save user specific settings such as layout, etc and update these in a simple JSON file stored on a local or remote node server.
I feel like there is relatively little documentation on the "best practices" of how one should go about organizing AngularJS code. For example, in many of my web pages, i.e.
index.php
profile.php
editprofile.php
There are often many factories and methods that I need repeated. For example, profile.php,, editprofile.php, and index.php all need the factory userDropdown (to get the top navbar dropdown menu). However, some of them need "modified versions of factories". For example:
index.php needs a way to get all the users and their information
profile.php needs a way to get some users information
editProfile.php needs a way to get only one user information
What I mean is that (and the above was a poor example), is that often many .js files needs some modified "child" of a "parent" factory. I find it hard to scale my application because profile.php, index.php, and editProfile.php all refer to their own factories and methods, not a base file. Changes, improvements, errors, found in one factory and is corrected, will not propagate into other files (which I find very frustrating). I also don't want to write /copy/paste services and factories over and over again. Other issue I've had is that:
X.js file need some providers that Y.js file doesn't. However, both needs providers A and B, but X needs C and Y needs D. Is it bad for me to use the same "factory" and providers" for both of them (i.e. inject A, B, C, and D into both of them?) That's the problem I see with having a base factory of a factory to serve a lot of .js files. How much space or inefficiency is it to define providers or injectable services that you don't use?
How do I accomplish some scalable angularJS code to do this, or how do you guys go about organizing your angular code? And also, what about repeating HTML templates (i.e. repeating HTML code that needs to be used in almost every page? I've heard of some service called $templateCache but couldn't figure out how to use it.)
https://github.com/johnpapa/angular-styleguide This also has an example app but seriously read through his guidelines they seem to be exactly what you are looking for and have been a great resource for me as I've been learning to build bigger angular apps.
I saw a similar question on the Google groups and also here on Stackoverflow. Both times the question was not answered. The code in this file doesn't make it very clear about what exactly it does and how it is used. Also it's not clear from the Angular documentation.
Can someone explain how this is used. Also can this be used along with Require.js?
Angular loader allows your angular scripts to be loaded in any order.
As angular-seed project shows us, Angular loader does not have any specific api, you just put it at the top of your index file (so that it's executed first) and then proceed to load your application files anyway you prefer.
But, the most important thing for your use case is that you don't really need angular loader at all. RequireJS also allows your files to be loaded in any order, but it also provides you with many other features that angular loader just isn't made for.
So, yes, you may use it with RequireJS, but you don't need to, because it becomes redundant.
Angular modules solve the problem of removing global state from the application and provide a way of configuring the injector. As opposed to AMD or require.js modules, 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.
http://docs.angularjs.org/tutorial/step_07#anoteaboutdiinjectorandproviders
It allows for you asynchronously load files when bootstrapping your angular application. A good example is the angular-seed project that has an index-async.html file that does this.
index-async.html
This is useful for using other libraries that load in modules asynchronously.
See angular-async-loader:
https://github.com/subchen/angular-async-loader/
To async load following components:
List item
controller
services
filter
directive
value
constant
provider
decorator
So, I'm in the midst of my first major project with Angular. I have one controller that is doing a ton of the legwork, and it's reached the point where it's thousands of lines of JavaScript.
I'd like to break this up somehow, but I can't seem to find a solid example anywhere. The code is mostly made up of functions used to do calculations on objects, so directives and modules don't seem like the right answer, but I could be wrong there.
How are you guys organizing code in your large Angular projects? Should I just suck it up, or is there a sane way to split this into easy to scan files?
I suggest putting at least some of those objects and their related calculations into services, then inject the services into your controller(s). See the Sticky Notes Part 1 blog entry for an example of a service that encapsulates some data and provides methods to access/manipulate that data.
See if you can break up your controller into multiple controllers, one for each view. A view can be as large as a page, or just some chunk/block on a page.
To quote from a google group post I saw recently: "I prefer to think of angular controllers as dumb apis/configs for my views and leave all the heavy lifting to services." -- reference
There are a few things that you need to ask yourself when you are in a controller.
Are you doing any DOM manipulation in the controller? This is a definite NO. Dont ever do that. It always belongs in the directives department.
Are you writing any Business Logic in your controller? That too is a NO. Your Business logic should in most cases exist in a Service. That is the right place for it.
Now, have a look at your controller. Is it devoid of these 2 things and still larger than 1000 lines? It is highly unlikely, but even if it somehow is happening, then consider breaking down your controller into smaller controllers. This breaking of controllers have to be done based on the view.
To sum things up, your controller is just a place where you glue up the business logic and your views in the HTML. It should technically never contain anything other than these glues.
I usually create a Util factory (seems to be the way to go now in Angular rather than services) and have it return any shared logic as a set of methods.
https://gist.github.com/lamba/c275f5f010090632209e