Angularjs - File organization for large project

Asked

Viewed 2,346 times

1

my doubt is not related to codes properly, but on how to better organize the project files.

I know that this is a question that has neither the right answer nor the best answer. But as I am developing a project now where I am facing several areas and functions, I would like to know from you what tips or guidelines you can give to improve this organization and not get lost among so many files in the future.

Currently I own an organization in this style:

-js  //Arquivos Js necessários para rodar o app
    --angular.min.js
    --angular-animate.min.js
    --angular-local-storage.min.js
    --angular-touch.min.js
    --oc-lazyload.min.js
    --ui-router.min.js

-App //escrito por eu mesmo
    --controller    - todos os controllers
    --directives    - todos os directives
    --factory       - todas as factorys
    --app.js        - configurações principais (router, filter, config)

-Lib //modulo de terceiros
    --ngMask.min.js
    --ngTooltip.min.js
    --ngMap.min.js
    -- [..etc..]

However, after a few lessons I learned more about modularizing the code and also managed to do the lazyload of files. That is, much of the code I own, I will be able to segment according to the area. For example:

Currently my webApp has 3 distinct areas:

  • User: anyone who registers on the site;
  • Moderators/Attendants: people who attend, check, mess with some restricted areas of the company;
  • Administrators: Control flow of sales, reports, etc.

For this I’m thinking of using the lazyload, to improve the safety and speed of webApp, since I will only load the module that is really necessary for that particular view. But that’s when it gets complicated.

In a quick structural sketch that I drew up, this is the structure that I got:

-App //escrito por eu mesmo
    --Controller
        ---ctrl-admin.js
        ---ctrl-empresa.js
        ---ctrl-comum.js
    --Directive
        ---dire-admin.js
        ---dire-empresa.js
        ---dire-comum.js
    --Factory
        ---fact-admin.js
        ---fact-empresa.js
        ---fact-comum.js
    --Config
        ---config.js
    --app.js //config da rota, autenticação, etc.


-Lib
    --main  //Arquivos Js necessários para rodar o app
        ---angular.min.js
        ---angular-animate.min.js
        ---angular-local-storage.min.js
        ---angular-touch.min.js
        ---oc-lazyload.min.js
        ---ui-router.min.js

    --modulos   //lib de terceiros, secundárias (tooltip, ngImago, etc.)
        ---main     //principais - comum a todos - (escritas por eu mesmo)
            ----ngLogin.min.js //processa login
            ----ngCart.min.js //carrinho de compras
            ----ngAlert.min.js //notificação de pedidos, mensagens, novo ticket, etc.

        ---sec      //secundarias - modular - (de terceiros)
            ----ngMap.js - somente carrega em view X
            ----ngMask.js - somente carrega em view Y
            ----ngTooltip.js - somente carrega em view Y, view Z
            [.. etc ..]

As you can see, this structure starts to get a little 'messy' and it takes a lot of care as I can start to lose myself, especially as some of these files (or large majority) will need to go through a concat/uglify.

And it needs to be separated because, for example, the files ctrl-admin, dire-admin and fact-admin, will only be loaded in views regarding administrators (controlled by ocLazyLoad).

Would you have any suggestions? Best Practice? Suggestion or some guide I can study and improve this structure?

angularjs

2 answers

3


The first point I would like to address is with regard to libs, most of the current Angular projects, use the dependency manager bower, the bower is responsible for controlling the libs versions of the project, and saves them by default in the folder bower_components, therefore, this distribution of libs you are making is different from the common and probably more difficult to maintain.

As you said, there is no right and wrong in this case, but I believe, that it would be better to separate your controllers, services and things like, by modules rather than by type, so you can better group what is part of a particular angular module.

As for the name of the files created by the application, a strong recommendation is that each file has its name, plus one '.' and its type, example: cadastroUsuario.ctrl.js, usuarios.module.js, cadastroUsuario.service.js, this allows within a given module, you can easily identify the file, and even write automated tasks based on these names.

These are simple organizational recommendations, in addition there are also code recommendations, the following guidelines present both, one is from Todd Motto and the other from Jhon Papa, both very well known in the angular community.

https://github.com/toddmotto/angularjs-styleguide

https://github.com/johnpapa/angular-styleguide

  • Cool! After I asked, I did another search and found this: https://github.com/mgechev/angularjs-style-guide I noticed that many projects have been using the view organization structure, where each view (e.g., clients) has its files. client.ctrl.js, client.fact.js (or concatenated). What do you think of this structure? In this case, it would be even better to create micro modules for each view, if you follow this line?

  • I don’t particularly like it much, because then you remove the possibility of re-use of the view ("although this is rarely possible in the separation by modules"), but it is really of opinion, I believe that the most important thing is to define a clear form of organization, where it is easy to navigate to fix a problem, and it can be easily changed later.

  • Yes, for this particular project there will be no view sharing, but I intend to set up a standard flow for future projects. About Bower, I already used, but I didn’t like the fact of downloading all the lib, polluting the files a lot. Unless I’ve used it wrong, since I’ve never really focused on it either. Any guidance on using Bower? I have also used npm, but with the same 'poréns'. Perhaps if it were possible to take only the distribution files.

  • Downloading everything is no problem, the important thing is to generate a build only with what you need, there are many tasks of Grunt that compile only the necessary.

  • Yes, Grunt I already have familiarity. I use it for several tasks. js, Sass, css, etc.. Do you know enough about Angularjs? Would you mind contacting us for a few thoughts?

  • If it is a problem that you can not detail here by stack, you can send me in email [email protected], but if they are doubts that you can clearly expose, it is important to leave so that we can contribute to the community.

  • Now that I stopped to read the links you sent. Just for the record, they are excellent!!! It was very helpful! Thanks @Ricardo Rodrigues de Fari

  • Nothing expensive, anything we are available.

Show 3 more comments

2

My personal experience led me to adopt a structure similar to the one offered in this blog post.

In short -

Most Angular-focused tutorials mention a structure similar to this:

app/
    controllers/
        mainController.js
        otherController.js
    directives/
        mainDirective.js
        otherDirective.js
    services/
        userService.js
        itemService.js
    js/
        bootstrap.js
        jquery.js
    app.js
views/
    mainView.html
    otherView.html
    index.html

The problem is this structure works only if you have a small number of working units (like item, which is composed of a controller, a directive and a service. ) How easy is it to organize your work, or search for a file, if your project has 30, 40 or more units? (for example, I have a project with 48.)

Instead, promote a functionality-modularized structure:

app/
    shared/   // Componentes reutilizáveis ou Partials do site
        sidebar/
            sidebarDirective.js
            sidebarView.html
        article/
            articleDirective.js
            articleView.html
        account/
            accountService.js
    components/   // Cada componente é tratado como uma mini-aplicação Angular
        home/
            homeController.js
            homeService.js
            homeView.html
        blog/
            blogController.js
            blogService.js
            blogView.html
    app.module.js
    app.routes.js
assets/
    img/      
    css/      
    js/       
    libs/     
index.html

This model makes maintenance much easier, since all the parts needed to maintain a given functionality are in the same directory.

  • This is exactly why I have this doubt. I have always worked with the first example you gave of example (or very similar). I was afraid to go on, because the other examples were like his second example. Although it generates a lot of folders, it seems to be the best way. If I understand correctly, the folder components would roughly be one folder for each menu that my app has, right? and Shared for each module, e.g.: shopping cart, alerts system, etc..

  • @Correct Celsomettrinity - or, think like that: components would contain all the unit modules of your application, with subdirectories if necessary (think 'purchase order' and the children 'order list' and 'order details', for example.) Shared would contain shared modules such as services, Factories and Directives.

  • yes, perfect! But a question. This example you gave of structure, would be directed to the code dist? Because there will be 2 "versions" of the same code. The version src, raw code, and the version dist, with Concat, uglify, etc.

  • @Celsomtrindade I would maintain the same structure for both versions. Imagine that the whole structure above is inside a printer src. After Parsing the same structure is present in a Folder dist, but minificada, post-LESS, etc.

  • Yes, that’s what I figured. In this case, maybe a Concat of the files that involve the same view. In this case, it would only have home.min.js instead of home.min.js home.controller.js and home.directive.js. Thank you so much for your help. It’s very valuable to me because all I know about it is by searching on google and by the OS community.

  • @Celsomtrindade Not so - it is always a pleasure to help.

Show 1 more comment

Browser other questions tagged angularjs

You are not signed in. Login or sign up in order to post.