They don't say it directly in that document, although it came up (if i
remember correctly) in some of the discussion around that document. It is,
however, strongly inferred when they talk about each directory containing a
"module definition file".

The basic idea for doing it that way is (from my perspective), if you have
a module defined across multiple files, then you have to worry about
execution order as well as things like having a dependency declared in the
module declaration that's needed in another file somewhere. Furthermore, if
you find that you've got a module that really needs to be organized across
several files, it *probably* could be broken into submodules effectively.

All of that is mostly in the name of organization of large projects with
more than one contributor. It's clearly not a written-in-stone thing, and I
don't know if the yeoman generator has been updated to reflect this
practice, as I stopped using yeoman.

e

On Sun, Sep 14, 2014 at 12:29 PM, Spiros Mouzakitis <
[email protected]> wrote:

> Many thanks for your answers!
>
> Eric can you please quote where the best-practices document says no more
> than one file per module?
> I can't seem to find it that in the document
>
> thanks,
> Spiros
>
>
> Τη Κυριακή, 14 Σεπτεμβρίου 2014 6:45:22 μ.μ. UTC+3, ο χρήστης Eric
> Eslinger έγραψε:
>>
>> Personally, I mostly follow the best-practices document outlined here:
>>
>> https://docs.google.com/document/d/1XXMvReO8-
>> Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/mobilebasic?pli=1
>>
>> Specifically, no more than one file per module, application routes are
>> sub-modules, and everything is stored together in a folder.
>>
>> So:
>>
>> app/
>> app/app.js (main init code, defines angular.module('app')
>> app/app.html (top-level template)
>> app/_app.scss (why not?)
>> app/app.test.js
>> app/people/people.js (defines angular.module('app')
>> app/people/ <all needed templates in this route, plus a sass partial>
>>
>> and so on. I have a separate top-level folder for
>> modules/
>> modules/draftEditor/ .js .html .scss etc, defining angular.modules('
>> trellisDraftEditor')
>>
>> all my standalone directives are defined with trellis- prefixes. It's a
>> bit verbose, but that's the name of the project I'm working on right now.
>> Sometimes if I'm being careful, I'll do app.modulename as a submodule if
>> and only if the module/directive only makes sense in the context of this
>> local app (say, it's a widget for displaying app-specific information). If
>> it's a reusable directive, I'll remove the prepend.
>>
>> The major benefit to this is organization. I have a fairly large SPA with
>> about 5 top-level routes, many subroutes, and a lot of embedded directives.
>> I know where to find each (and not in some fooController file that's
>> flat-listed in /controllers), I can lift an entire directive or route in or
>> out of the application more easily, the test files are where they need to
>> be, and so forth.
>>
>> This doesn't work all that well with SASS, there's no easy way to make
>> that automagical. So instead, I just have in my main.scss a bunch of
>> @include "app/app" type declarations. Someday I'll get that to get
>> automated maybe with a gulp-inject task.
>>
>> If my project were small (say ~ 5 controllers and maybe 3 custom
>> directives), it wouldn't matter. But I feel like breaking things down in
>> the source code directories helps a lot for my sanity.
>>
>> At the end of the day, the files all get shoved through ng-annotate and
>> minimized and concated anyway, so the production system just has one big JS
>> file. But development is easier this way.
>>
>> e
>>
>>
>> On Sat, Sep 13, 2014 at 12:14 PM, Spiros Mouzakitis <[email protected]
>> > wrote:
>>
>>>
>>> Hi all,
>>>
>>> I have seen some posts here and books (e.g http://www.amazon.com/
>>> Mastering-Web-Application-Development-AngularJS/dp/1782161821) that
>>> strongly suggest in keeping one file per module for various reasons (e.g.
>>> issues on testing).
>>> On the other hand i have seen some other people that like to organize
>>> their controllers (in separate files) under the same module.
>>>
>>> Which of the following would you choose?
>>>
>>> *structure A*
>>>
>>> app.js  - angular.module('"GradesApp',[ 
>>> GradesApp.controllers.mainControllers,
>>> GradesApp.controllers.StudentControllers, 
>>> GradesApp.services.StudentServices]
>>> - new module
>>>
>>> controllers/mainController.js   - angular.module('GradesApp.
>>> controllers.mainControllers',[]) - new module
>>>
>>> controllers/StudentController.js   - angular.module('GradesApp.
>>> controllers.StudentControllers',[]) - new module
>>>
>>> ......
>>>
>>> *or structure B*
>>>
>>> app.js  -   angular.module('"GradesApp',[]) - new module
>>>
>>> controllers/mainController.js   - 
>>> angular.module('GradesApp').controller......
>>> - reference to existing module
>>>
>>> controllers/StudentController.js   - 
>>> angular.module('GradesApp',)..controller......
>>> reference to existing module
>>>
>>> In big projects of course structure B could be also new module per for
>>> e.g. GradesApp.Controllers, but mainController and studentController would
>>> refer to the same module -> GradesApp.Controllers.
>>>
>>> In my humble opinion structure B is much, much cleaner. It would
>>> surprise me that a language would encourage having a lot of controller
>>> definitions under the same file. And generally a project structure that is
>>> largely affected by physical files.
>>>
>>> What do you think it is the best approach?
>>>
>>> many thanks
>>> Spiros
>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "AngularJS" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/angular.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "AngularJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/angular.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

Reply via email to