CODEWITHSUNDEEP
javascriptangularjsweb-applicationssingle-page-applicationdirectory-structure
Bolza
Bolza

Reputation: 1944

Meaningful Directory Structure for a Webapp

So in my case i have an angularJS application but i think this question really applies to any Single Page App.

I'm using a component structure as described in various articles like this, and this.

So let's suppose i have a structure like the one in John Papa's example

app/
    app.module.js
    app.config.js
    app.routes.js
    directives.js
    layout/
        shell.html      
        shell.controller.js
        topnav.html      
        topnav.controller.js       
    people/
        attendees.html
        attendees.controller.js  
        speakers.html
        speakers.controller.js
        speaker-detail.html
        speaker-detail.controller.js
    sessions/
        sessions.html      
        sessions.controller.js
        session-detail.html
        session-detail.controller.js  
    services/       
        data.service.js  
        localstorage.service.js
        logger.service.js   
        spinner.service.js

Here's some questions about what's the best way (by your experience) to follow this paradigm, what can go wrong and how to avoid future problems with the directory structure posing that we are talking about a big application that will change and become bigger with time:

Upvotes: 1

Views: 1424

Answers (1)

Okazari
Okazari

Reputation: 4597

I'll ask with my own experience so some may agree or disagree but it is of course opinion based for everyone.

First have a look at my own angular structure (pretty similar to the exemples):

  /
  - app/
      - feature/
          - {featurename}/
               - controller/  // -> Put here all your MyFeatureController.js files
               - directive/   // -> List of components relative to this feature
               - service/     /* -> Utilities mostly SomethingService.js 
                                 returning promises from back end calls
                                 and SomethingElseHelper.js used to factorize 
                                 all the business logic */
               - template/    // -> Partial HTML files that are not user final view
               - view/        // -> All the views
                              //    Theses are used as endpoint in your routing

That's pretty much all. On big application it can be adapted with some sub-features. I always have a common/ (working as a feature) folder for shared stuff. Mostly directives, services, templates for header, footer, menus and their controllers.

If you want a specific example you can have a look at a personal project's code i'm working on.

To answer your questions :

  1. In programmation i first always code as specific as i can. If i realize that something is duplicated i'll refactor it and generalize it. I work the same in the structure. If a service is only used in a feature, it should be in the feature folder. If this service start to be useful in some other features i'll move it to a common level.
  2. In my opinion if you got something like this : admin/speakers and peoples/speakers i would think about what are my real features. I mean the client features. Do you give control on peoples and admin ? Then i would go with your the upper proposition or do you give control on speakers ? in this case i would go with something like this : speakers/admin and speakers/people Note that it will really depend on your features.
  3. Since i'm working with a feature structure yes. i would definitely go for it. Ending with this if needed : item/detail/ and item/list/

Hope it helped you. If you want some more explanation about my way of structuring a project, feel free to ask.

PS : An other interesting post about this

EDIT : Today i use a variant of this, due to coding apps as components (with angular 1.5)

Upvotes: 1

Related Questions