Organization and Naming Standards for Projects

Question

Organization and Naming Standards for Projects

After exploring the Repeating module name for each module component issue, we have decided to adopt the organizational recommendations outlined in the Best Practice Recommendations for Angular App Structure blog post. This approach has been implemented in a small internal application used for measuring connection quality.

The current structure of the project includes:

$ tree -L 1
.
├── app-config-service.js
├── app-config-service_test.js
├── app-connection-service.js
├── app-connection-service_test.js
├── app-controller.js
├── app-controller_test.js
├── app-countdown-directive.js
├── app-countdown-directive_test.js
├── app-footer-directive.js
├── app-footer-directive_test.js
├── app-footer-service.js
├── app-footer-service_test.js
├── app-math-service.js
├── app-math-service_test.js
├── app-stats-directive.js
├── app-stats-directive_test.js
├── app-status-directive.js
├── app-status-directive_test.js
├── app-status-service.js
├── app-status-service_test.js
├── app-time-directive.js
├── app-time-directive_test.js
├── app.css
├── app.js
├── bower_components
├── config.json
├── countdown.html
├── footer.html
├── img
├── index.html
├── ping
├── stats.html
└── status.html

This setup, with a mix of directives, services, partials, controller, and other files all grouped under a single module, is becoming difficult to manage and work with due to the high number of files involved.

Considering that everything is contained within a single module, would it be beneficial to transition to a component-oriented approach? Should we introduce separate directories for services, controllers, directives, and partials in this simple application? Or does the "Organized by feature" method only prove effective for large-scale applications?

javascript angularjs naming-conventions

Answer 1

Answer №1

You mentioned that you planned to "adhere to the suggestions outlined in a blog post about Best Practices for Structuring Angular Apps", however, it appears that your implementation deviates from those guidelines...

As per the recommended methodology, each component or feature should reside within its own directory (nested under a main directory like components).

Advocated by Gil Birman and discussed in both the aforementioned blog post and on Repeating module name for each module component, organizing directories based on features (e.g., having a directory like foo-feature for related directives, services, controllers, partials, etc.) is deemed more sensible than grouping them based on type.

It's crucial to note that these are mere guidelines (rather than strict rules) and serve as a guiding principle rather than an exact formula to dictate where each file should be located (e.g., considering a directory like components/lib/, deciding whether a service belongs in a feature's directory or a generic components/common/ directory, etc). You must grasp the essence of these guidelines and tailor them to suit your team's preferences.

Situations may arise where there is uncertainty regarding the placement of a file. In such cases, engaging in discussions with the team, making a collective decision, and proceeding accordingly is common practice. While this might occur frequently initially, over time, such instances will diminish.

With that in mind, it would be expected that your directory and file structure closely resembles the following (keeping in mind potential scenarios where certain services could be more universal/utility-oriented):

app/
|___ app.css
|___ app.js
|___ app-controller.js
|___ app-controller_test.js
|___ bower_components
|___ config.json
|___ index.html
|
|___ components/
|    |___ common/ or util/
|    |    |___ config-service.js
|    |    |___ config-service_test.js
|    |    |___ connection-service.js
|    |    |___ connection-service_test.js
|    |    |___ math-service.js
|    |    |___ math-service_test.js
|    |
|    |___ countdown/
|    |    |___ countdown.html
|    |    |___ countdown-directive.js
|    |    |___ countdown-directive_test.js
|    | 
|    |___ footer/
|    |    |___ footer.html
|    |    |___ footer-directive.js
|    |    |___ footer-directive_test.js
|    |    |___ footer-service.js
|    |    |___ footer-service_test.js
|    |
|    |___ img/
|    |    |___ ...
|    |
|    |___ stats/
|    |    |___ stats.html
|    |    |___ stats-directive.js
|    |    |___ stats-directive_test.js
|    | 
|    |___ status/
|    |    |___ status.html
|    |    |___ status-directive.js
|    |    |___ status-directive_test.js
|    |    |___ status-service.js
|    |    |___ status-service_test.js
|    |
|    |___ time/
|         |___ time-directive.js
|         |___ time-directive_test.js
|
|___ misc/
     |___ ping

Answer 2

You mentioned that you planned to "adhere to the suggestions outlined in a blog post about Best Practices for Structuring Angular Apps", however, it appears that your implementation deviates from those guidelines...

As per the recommended methodology, each component or feature should reside within its own directory (nested under a main directory like components).

Advocated by Gil Birman and discussed in both the aforementioned blog post and on Repeating module name for each module component, organizing directories based on features (e.g., having a directory like foo-feature for related directives, services, controllers, partials, etc.) is deemed more sensible than grouping them based on type.

It's crucial to note that these are mere guidelines (rather than strict rules) and serve as a guiding principle rather than an exact formula to dictate where each file should be located (e.g., considering a directory like components/lib/, deciding whether a service belongs in a feature's directory or a generic components/common/ directory, etc). You must grasp the essence of these guidelines and tailor them to suit your team's preferences.

Situations may arise where there is uncertainty regarding the placement of a file. In such cases, engaging in discussions with the team, making a collective decision, and proceeding accordingly is common practice. While this might occur frequently initially, over time, such instances will diminish.

With that in mind, it would be expected that your directory and file structure closely resembles the following (keeping in mind potential scenarios where certain services could be more universal/utility-oriented):

app/
|___ app.css
|___ app.js
|___ app-controller.js
|___ app-controller_test.js
|___ bower_components
|___ config.json
|___ index.html
|
|___ components/
|    |___ common/ or util/
|    |    |___ config-service.js
|    |    |___ config-service_test.js
|    |    |___ connection-service.js
|    |    |___ connection-service_test.js
|    |    |___ math-service.js
|    |    |___ math-service_test.js
|    |
|    |___ countdown/
|    |    |___ countdown.html
|    |    |___ countdown-directive.js
|    |    |___ countdown-directive_test.js
|    | 
|    |___ footer/
|    |    |___ footer.html
|    |    |___ footer-directive.js
|    |    |___ footer-directive_test.js
|    |    |___ footer-service.js
|    |    |___ footer-service_test.js
|    |
|    |___ img/
|    |    |___ ...
|    |
|    |___ stats/
|    |    |___ stats.html
|    |    |___ stats-directive.js
|    |    |___ stats-directive_test.js
|    | 
|    |___ status/
|    |    |___ status.html
|    |    |___ status-directive.js
|    |    |___ status-directive_test.js
|    |    |___ status-service.js
|    |    |___ status-service_test.js
|    |
|    |___ time/
|         |___ time-directive.js
|         |___ time-directive_test.js
|
|___ misc/
     |___ ping

Answer 3

Answer №2

How Modular Design Reflects the Functions of Our Brain

Even with a small project, I find it beneficial to organize the code into separate modular folders. This approach simplifies the process of locating and working on specific code segments, as programmers typically focus on one module at a time.

For instance, I may spend an hour concentrating on the footer module, which encompasses both directives and services housed in the footer directory. Conversely, it's unlikely that I would dedicate an hour solely to working on various directives in their respective folder without addressing any services.

The Convenience of Transferring Code Across Projects via Modular Design

When commencing a new project, regardless of its scale, my initial step usually involves extracting modules from previous projects. The use of modular architecture streamlines this process, making it straightforward and instinctive.

Naturally, if a module holds significant reusability value, it is advisable to package it as a bower module. However, most small modules are likely to undergo customization tailored to each individual project.

Answer 4

How Modular Design Reflects the Functions of Our Brain

Even with a small project, I find it beneficial to organize the code into separate modular folders. This approach simplifies the process of locating and working on specific code segments, as programmers typically focus on one module at a time.

For instance, I may spend an hour concentrating on the footer module, which encompasses both directives and services housed in the footer directory. Conversely, it's unlikely that I would dedicate an hour solely to working on various directives in their respective folder without addressing any services.

The Convenience of Transferring Code Across Projects via Modular Design

When commencing a new project, regardless of its scale, my initial step usually involves extracting modules from previous projects. The use of modular architecture streamlines this process, making it straightforward and instinctive.

Naturally, if a module holds significant reusability value, it is advisable to package it as a bower module. However, most small modules are likely to undergo customization tailored to each individual project.

Answer 5

Answer №3

If you're just starting out, I suggest utilizing the project organization framework provided by yeoman generators:

This method follows a component-oriented approach and comes with various generators that help organize code in its proper place, create unit tests, maintain consistent file naming conventions, configure grunt build processes, and more.

The typical project structure using this approach would resemble the following:

Adopting a structured approach is beneficial even for simpler applications to avoid code chaos. While it's easy to get lost in tangled code, starting off organized is key. However, as your project grows, you may encounter limitations with handling multiple modules efficiently with standard yeoman generators.

Answer 6

If you're just starting out, I suggest utilizing the project organization framework provided by yeoman generators:

This method follows a component-oriented approach and comes with various generators that help organize code in its proper place, create unit tests, maintain consistent file naming conventions, configure grunt build processes, and more.

The typical project structure using this approach would resemble the following:

Adopting a structured approach is beneficial even for simpler applications to avoid code chaos. While it's easy to get lost in tangled code, starting off organized is key. However, as your project grows, you may encounter limitations with handling multiple modules efficiently with standard yeoman generators.

Answer 7

Answer №4

It has been pointed out by ExpertSystem that your current directory structure does not align with the best practices outlined in this blog: Best Practice Recommendations for Angular App Structure.

I agree with ExpertSystems and Gil Birman on the importance of a modular approach to designing the app structure. Angular itself follows a modular structure, so whether you have multiple modules or a single Angular module, it is essential to consider the functionality you are catering to. For example, if you have a 'CountDown' functionality, it should have its own dedicated structure.

Significance of Modular Structure:

1. Code Maintenance: As your code grows, so do your maintenance costs. Having a modular structure allows for easier identification and debugging of errors, leading to faster solutions.

2. Development Ease: By splitting functionalities between developers and assigning them to specific folders, conflicts can be minimized and development streamlined.

3. Faster Reviews: Breaking down the app into functional components enables quicker and more efficient code reviews.

4. TDD Implementation: A structured approach supports Test Driven Development (TDD), enhancing code quality and maintainability.

Distinguishing Development and Production Structures:

During development, organize the structure based on functionality. To optimize performance in production, consider concatenating, minifying, and obfuscating files using tools like GRUNT. I will provide an example GRUNT file for reference, which can be automated during deployment through continuous integration tools like Jenkins.

Answer 8

It has been pointed out by ExpertSystem that your current directory structure does not align with the best practices outlined in this blog: Best Practice Recommendations for Angular App Structure.

I agree with ExpertSystems and Gil Birman on the importance of a modular approach to designing the app structure. Angular itself follows a modular structure, so whether you have multiple modules or a single Angular module, it is essential to consider the functionality you are catering to. For example, if you have a 'CountDown' functionality, it should have its own dedicated structure.

Significance of Modular Structure:

1. Code Maintenance: As your code grows, so do your maintenance costs. Having a modular structure allows for easier identification and debugging of errors, leading to faster solutions.

2. Development Ease: By splitting functionalities between developers and assigning them to specific folders, conflicts can be minimized and development streamlined.

3. Faster Reviews: Breaking down the app into functional components enables quicker and more efficient code reviews.

4. TDD Implementation: A structured approach supports Test Driven Development (TDD), enhancing code quality and maintainability.

Distinguishing Development and Production Structures:

During development, organize the structure based on functionality. To optimize performance in production, consider concatenating, minifying, and obfuscating files using tools like GRUNT. I will provide an example GRUNT file for reference, which can be automated during deployment through continuous integration tools like Jenkins.

Answer 9

Answer №5

When structuring my projects, I like to organize them using a feature (module) based approach at the top level and a type-based approach (directives, controllers) at lower levels:

For example, in one project I have three separate root modules: home, search, and shared. These modules serve as the foundation of my application, each containing directives, services, views, less files, and more. I find it beneficial to keep related components of my application close together, which is why I group all parts of the news directive in a news folder specific to the home module. However, if the news directive were to be utilized in multiple modules (such as home and search), I would relocate the news folder to the shared directory.

This strategy aligns with the prefix-based approach discussed in this question (Repeating module name for each module component), albeit with the use of folders instead of prefixes.

Answer 10

When structuring my projects, I like to organize them using a feature (module) based approach at the top level and a type-based approach (directives, controllers) at lower levels:

For example, in one project I have three separate root modules: home, search, and shared. These modules serve as the foundation of my application, each containing directives, services, views, less files, and more. I find it beneficial to keep related components of my application close together, which is why I group all parts of the news directive in a news folder specific to the home module. However, if the news directive were to be utilized in multiple modules (such as home and search), I would relocate the news folder to the shared directory.

This strategy aligns with the prefix-based approach discussed in this question (Repeating module name for each module component), albeit with the use of folders instead of prefixes.

Answer 11

Answer №6

When embarking on a new project, it's important to consider more than just the file structure. I suggest thinking about module creation, dependency injection, and how you plan to minify your application.

An excellent resource for this is Angular boilerplate found at github.com. This boilerplate project allows you to build applications with grunt, utilize bower for dependencies, live reload your browser, and use LESS instead of CSS.

The initial structure includes:

ng-boilerplate/
|- grunt-tasks/
|- karma/
|- src/
|  |- app/
|  |  |- <app logic>
|  |- assets/
|  |  |- <static files>
|  |- common/
|  |  |- <reusable code>
|  |- less/
|  |  |- main.less
|- vendor/
|  |- angular-bootstrap/
|  |- bootstrap/
|  |- placeholders/
|- .bowerrc
|- bower.json
|- build.config.js
|- Gruntfile.js
|- module.prefix
|- module.suffix
|- package.json

Additionally, there is a helpful guide included to assist in setting everything up. Happy coding!

https://github.com/ngbp/ngbp

Answer 12

When embarking on a new project, it's important to consider more than just the file structure. I suggest thinking about module creation, dependency injection, and how you plan to minify your application.

An excellent resource for this is Angular boilerplate found at github.com. This boilerplate project allows you to build applications with grunt, utilize bower for dependencies, live reload your browser, and use LESS instead of CSS.

The initial structure includes:

ng-boilerplate/
|- grunt-tasks/
|- karma/
|- src/
|  |- app/
|  |  |- <app logic>
|  |- assets/
|  |  |- <static files>
|  |- common/
|  |  |- <reusable code>
|  |- less/
|  |  |- main.less
|- vendor/
|  |- angular-bootstrap/
|  |- bootstrap/
|  |- placeholders/
|- .bowerrc
|- bower.json
|- build.config.js
|- Gruntfile.js
|- module.prefix
|- module.suffix
|- package.json

Additionally, there is a helpful guide included to assist in setting everything up. Happy coding!

https://github.com/ngbp/ngbp

Organization and Naming Standards for Projects

Answer №1

Answer №2

How Modular Design Reflects the Functions of Our Brain

The Convenience of Transferring Code Across Projects via Modular Design

Answer №3

Answer №4

Significance of Modular Structure:

Distinguishing Development and Production Structures:

Answer №5

Answer №6

Similar questions

Trouble selecting options in hierarchical data

How can you utilize the Array submission syntax within HTML coding?

Organizing dates with Javascript

I am interested in retrieving an array

Using Angular-Resource instances throughout the entire application

The style of the button label does not persist when onChange occurs

Error: protractor encountered an unexpected issue

The "tsc" command in Typescript seems to be acting up. I've exhausted all possible solutions but

Using AJAX to dynamically load Javascript

Incorporate a fresh attribute to the JSON data in an Angular API response

Is it possible to assign a class to the initial word within a designated class?

Arranging Angular Array-like Objects

Assist with JavaScript Programming

Leveraging $scope variables to dynamically generate new scope values within an Angular controller

An uncaught runtime error has occurred: TypeError - subSector.map is not a valid function

Detecting the failure of chrome.extension.sendRequest

What are the reasons behind Jquery's decreased speed performance in Internet Explorer?

JavaScript: Obtaining the month based on the week number and year

Trouble arises with MySQL query in PHP/jQuery setup

Is my Discord.js bot malfunctioning due to incorrect indentation, despite the absence of errors?