Design of Angular project structure

Question

Design of Angular project structure

Building an app in Angular involves consuming various APIs and providing options for users to select, which are then recorded and sent back to the server.

The design of the app is structured as follows:

All common logic is placed in the Main Controller, with other options separated into different controllers that act as children of the main controller.
The Main Controller retrieves all necessary data required to run the app, which is then accessed by all child controllers.
To ensure that the data is loaded before execution, promises are attached to the scope so that child controllers are aware when the data is available.
Data updating functionalities within child controllers have been moved to the main controller to consolidate updates that occur on a single object.
Communication between child and main controllers is facilitated through emitting/broadcasting events. When an update occurs in a child controller, it emits an event with data that is captured and processed by the Main Controller for updating.

MainController {

  $scope.loaded = DataService.get();
  $scope.userOptions = {};
  $scope.$on('update',function(){
   updateUserOptions();
  })
}

ChildController {

  $scope.loaded.then(function(){
    //all logic of child controller
  }

  $scope.onselect = function(){
    $scope.$emit('update',data);
  }
}

Some questions to consider:

Is utilizing events between controllers considered good practice?
Is attaching promises to scope beneficial for child controllers?
Would incorporating services improve the code structure?

javascript angularjs architecture

Answer 1

Answer №1

Based on my personal experience, I recently took on the task of revamping the architecture of a single page application that I developed.

Here are some insights from my experience:

Is it beneficial to use events between controllers? In my opinion, utilizing events is a versatile approach to sharing information between controllers, even when they have isolated scopes (using methods like $broadcast or $emit). This strategy follows the Observer design pattern. Alternatively, services can also be used instead of events for data sharing. It's important to exercise caution when using $rootScope, as all $scopes inherit from it.

Is it advisable to attach promises to scope for child controllers? Understanding how scope inheritance works is key in handling this issue without running into property shadowing in JavaScript. Transferring logic from scope.loaded within ChildController to a service like

ChildService</code would contribute to better code organization and facilitate reusability. Segregating business logic through services rather than controllers aligns with good design principles.</li>
<li><em>Will incorporating services enhance my code quality?</em> Refer back to my previous response regarding this question.</li>
</ol>

<p>To further bolster the architecture, I delved into the angular style guide authored by John Papa, which provided valuable insights.</p>

<p>I suggest the following modifications:</p>

<ol>
<li><em>To ensure data loading, I utilize promises attached to scope. However, I propose emitting a custom 'loaded' event from MainController using <code>$scope.$emit('loaded')

. Subsequently, I advocate utilizing

$scope.$on('loaded', function(){})

in ChildController to manage the event.

Transfer the updateUserOptions function to a service and only inject it into the necessary controllers.

Hopefully, these suggestions prove to be useful!

Answer 2

Based on my personal experience, I recently took on the task of revamping the architecture of a single page application that I developed.

Here are some insights from my experience:

Is it beneficial to use events between controllers? In my opinion, utilizing events is a versatile approach to sharing information between controllers, even when they have isolated scopes (using methods like $broadcast or $emit). This strategy follows the Observer design pattern. Alternatively, services can also be used instead of events for data sharing. It's important to exercise caution when using $rootScope, as all $scopes inherit from it.

Is it advisable to attach promises to scope for child controllers? Understanding how scope inheritance works is key in handling this issue without running into property shadowing in JavaScript. Transferring logic from scope.loaded within ChildController to a service like

ChildService</code would contribute to better code organization and facilitate reusability. Segregating business logic through services rather than controllers aligns with good design principles.</li>
<li><em>Will incorporating services enhance my code quality?</em> Refer back to my previous response regarding this question.</li>
</ol>

<p>To further bolster the architecture, I delved into the angular style guide authored by John Papa, which provided valuable insights.</p>

<p>I suggest the following modifications:</p>

<ol>
<li><em>To ensure data loading, I utilize promises attached to scope. However, I propose emitting a custom 'loaded' event from MainController using <code>$scope.$emit('loaded')

. Subsequently, I advocate utilizing

$scope.$on('loaded', function(){})

in ChildController to manage the event.

Transfer the updateUserOptions function to a service and only inject it into the necessary controllers.

Hopefully, these suggestions prove to be useful!

Answer 3

Answer №2

Is it recommended to utilize events for communication between controllers? While not ideal for primary data sharing, events can be used to notify about system events like when data is ready.

Would using promises attached to scope for child controllers be beneficial? It's advised against due to the potential for causing various issues related to scope inheritance.

How can implementing services enhance my code? Implementing services can definitely improve the structure and efficiency of your code.

If I were in your position, here's what I suggest:

Create a dataService - responsible for managing all incoming and outgoing data. This service caches data upon request (saving the promise is sufficient) and broadcasts a 'dataReady' event via $rootScope whenever new or refreshed data is available. Controllers and other subscribers can listen for this event to retrieve the updated data. Additionally, the dataService handles data updates and can broadcast events via $rootScope when data changes occur, prompting subscribers to query the service for updated information.

Utilize directives over controllers - use directives with isolated scope to pass data between them through attributes. By doing so, you ensure that each directive receives only the necessary data instead of everything. Directives can communicate with one another using attributes, services, broadcasting/emitting events, or requiring their parents/siblings if they closely collaborate.

Answer 4

Is it recommended to utilize events for communication between controllers? While not ideal for primary data sharing, events can be used to notify about system events like when data is ready.

Would using promises attached to scope for child controllers be beneficial? It's advised against due to the potential for causing various issues related to scope inheritance.

How can implementing services enhance my code? Implementing services can definitely improve the structure and efficiency of your code.

If I were in your position, here's what I suggest:

Create a dataService - responsible for managing all incoming and outgoing data. This service caches data upon request (saving the promise is sufficient) and broadcasts a 'dataReady' event via $rootScope whenever new or refreshed data is available. Controllers and other subscribers can listen for this event to retrieve the updated data. Additionally, the dataService handles data updates and can broadcast events via $rootScope when data changes occur, prompting subscribers to query the service for updated information.

Utilize directives over controllers - use directives with isolated scope to pass data between them through attributes. By doing so, you ensure that each directive receives only the necessary data instead of everything. Directives can communicate with one another using attributes, services, broadcasting/emitting events, or requiring their parents/siblings if they closely collaborate.

Answer 5

Answer №3

Is it advisable to utilize events between controllers?

Avoid using events between controllers as it will be phased out by Angular JS 2.0. Additionally, relying on events often results in a convoluted mess of interactions that are difficult to comprehend and troubleshoot. Instead, opt for utilizing services to share data between controllers. By injecting the same service into multiple controllers, the service can store the data, allowing the controllers to bind to it and stay automatically synchronized. I have elaborated on this concept in a blog post.

Is it recommended to attach promises to scope for child controllers?

Avoid attaching promises to scope for child controllers. It is more preferable to use promises and resolve data within services. Refrain from using $scope altogether and instead embrace the controllerAs syntax. The usage of $scope was deprecated even in Angular JS 1.X due to the various issues related to scope inheritance.

Will incorporating services enhance my code quality?

Absolutely! Leveraging services for all logic and data manipulation is highly beneficial. Reserve controllers solely for UI interactions and delegate other tasks to services. Additionally, consider utilizing ui-router for effectively managing the state of your application.

Answer 6

Is it advisable to utilize events between controllers?

Avoid using events between controllers as it will be phased out by Angular JS 2.0. Additionally, relying on events often results in a convoluted mess of interactions that are difficult to comprehend and troubleshoot. Instead, opt for utilizing services to share data between controllers. By injecting the same service into multiple controllers, the service can store the data, allowing the controllers to bind to it and stay automatically synchronized. I have elaborated on this concept in a blog post.

Is it recommended to attach promises to scope for child controllers?

Avoid attaching promises to scope for child controllers. It is more preferable to use promises and resolve data within services. Refrain from using $scope altogether and instead embrace the controllerAs syntax. The usage of $scope was deprecated even in Angular JS 1.X due to the various issues related to scope inheritance.

Will incorporating services enhance my code quality?

Absolutely! Leveraging services for all logic and data manipulation is highly beneficial. Reserve controllers solely for UI interactions and delegate other tasks to services. Additionally, consider utilizing ui-router for effectively managing the state of your application.

Answer 7

Answer №4

Instead of directly answering your questions, I have some additional comments to share. In my opinion, the approach you mentioned may not be the most effective way to build angular applications.

Placing all common logic in the Main Controller and separating other options into different controllers as children of the main controller.

It is advised against by angular style guides to include common logic in controllers. Controllers should strictly focus on view-related logic such as data binding and validation. By reducing the amount of code within a controller, you enhance reusability. Moving more logic into services results in a more scalable application.

Solution: My suggestion is to create a service for fetching data from the server and then inject this service into controllers when needed. This method also improves dependency management by clearly identifying which controllers require specific services.

Avoid nesting controllers whenever possible, as Angular monitors all active scopes and reevaluates them during each $apply() loop.

Solution: Refer back to #1 and utilize services instead of relying heavily on the main controller.

Implementing promises attached to scope to ensure data is loaded, signaling to child controllers that the data is available.

Utilizing promises for data retrieval is a good practice, but it is cleaner to store them in a service rather than the main controller.

Moving the data updating functionality of all child controllers to the main controller due to all updates occurring in one object.

Child controllers using emit/broadcast to communicate with the main controller. When an update occurs, a child will emit an event containing data that the main controller captures to perform the update.

Solution: Opt for a service with an update function over events. Events are more challenging to debug and manage, requiring event handlers to be unregistered upon controller destruction. Using functions/promises rather than events is typically a more reliable approach.

Answer 8

Instead of directly answering your questions, I have some additional comments to share. In my opinion, the approach you mentioned may not be the most effective way to build angular applications.

Placing all common logic in the Main Controller and separating other options into different controllers as children of the main controller.

It is advised against by angular style guides to include common logic in controllers. Controllers should strictly focus on view-related logic such as data binding and validation. By reducing the amount of code within a controller, you enhance reusability. Moving more logic into services results in a more scalable application.

Solution: My suggestion is to create a service for fetching data from the server and then inject this service into controllers when needed. This method also improves dependency management by clearly identifying which controllers require specific services.

Avoid nesting controllers whenever possible, as Angular monitors all active scopes and reevaluates them during each $apply() loop.

Solution: Refer back to #1 and utilize services instead of relying heavily on the main controller.

Implementing promises attached to scope to ensure data is loaded, signaling to child controllers that the data is available.

Utilizing promises for data retrieval is a good practice, but it is cleaner to store them in a service rather than the main controller.

Moving the data updating functionality of all child controllers to the main controller due to all updates occurring in one object.

Child controllers using emit/broadcast to communicate with the main controller. When an update occurs, a child will emit an event containing data that the main controller captures to perform the update.

Solution: Opt for a service with an update function over events. Events are more challenging to debug and manage, requiring event handlers to be unregistered upon controller destruction. Using functions/promises rather than events is typically a more reliable approach.

Answer 9

Answer №5

Is it advisable to utilize events between controllers?

An issue with your current setup is that it relies implicitly on the hierarchy of your controllers, as the event emitted can only be caught by scopes higher up in the hierarchy. This not only creates an implicit connection that developers need to remember but also limits the extensibility of this feature.

Alternatively, injecting a shared service into all required controllers would make the connection between controllers explicit and documented, making their positions in the hierarchy independent. This approach would simplify the maintenance of your architecture and make testing easier as well.

You could still implement an observer pattern using a service.

Is it recommended to use promises attached to scope for child controllers?

The concern about polluting scopes mentioned in other responses is valid. It's better to limit the number of objects attached to your scope and utilize objects as bundles of variables instead of directly attaching all variables to the scope. (For more insights on this, refer to discussions on "always having a . in your bindings".)

(Of course, avoid bundling variables blindly just to reduce their number; try to identify meaningful semantic connections between variables that can be bundled together.)

Will incorporating services enhance my code quality?

Based on the aforementioned responses, the answer seems to be yes. There are additional benefits as well, but due to space constraints here, I won't delve into them now.

In conclusion, the issues pointed out above may not be major concerns in your current code base, but if you aspire to have the best possible architecture, there is certainly room for improvement.

Answer 10

Is it advisable to utilize events between controllers?

An issue with your current setup is that it relies implicitly on the hierarchy of your controllers, as the event emitted can only be caught by scopes higher up in the hierarchy. This not only creates an implicit connection that developers need to remember but also limits the extensibility of this feature.

Alternatively, injecting a shared service into all required controllers would make the connection between controllers explicit and documented, making their positions in the hierarchy independent. This approach would simplify the maintenance of your architecture and make testing easier as well.

You could still implement an observer pattern using a service.

Is it recommended to use promises attached to scope for child controllers?

The concern about polluting scopes mentioned in other responses is valid. It's better to limit the number of objects attached to your scope and utilize objects as bundles of variables instead of directly attaching all variables to the scope. (For more insights on this, refer to discussions on "always having a . in your bindings".)

(Of course, avoid bundling variables blindly just to reduce their number; try to identify meaningful semantic connections between variables that can be bundled together.)

Will incorporating services enhance my code quality?

Based on the aforementioned responses, the answer seems to be yes. There are additional benefits as well, but due to space constraints here, I won't delve into them now.

In conclusion, the issues pointed out above may not be major concerns in your current code base, but if you aspire to have the best possible architecture, there is certainly room for improvement.

Answer 11

Answer №6

Responses:

Sorry, but it's on its way to becoming obsolete.
The $scope feature is already outdated.
Using services is highly recommended. They offer the flexibility to share data and functionality among different components such as controllers.

Answer 12

Responses:

Sorry, but it's on its way to becoming obsolete.
The $scope feature is already outdated.
Using services is highly recommended. They offer the flexibility to share data and functionality among different components such as controllers.

Design of Angular project structure

Answer №1

Answer №2

Answer №3

Answer №4

Answer №5

Answer №6

Similar questions

How can I intercept/manage the back button of the browser in React-router?

Issue with Material-UI tab when using a datatable within it's content

jQuery AJAX File Upload problem in Internet Explorer

Using controllerAs in an AngularJS directive allows for multiple instances to be created, each with the

Inject parameters into the templateUrl property of an Angular component

Error: Cannot call method rewriteRequestUrl in _this7._config.server in React native version 0.64.1

Tips on choosing JSON data to show on an HTML page

Expanding a collection of text inputs on-the-fly (HTML/JavaScript)

Customize form input using Javascript prior to inserting into database

Error encountered: Unable to invoke module in AngularJS using Karma and Jasmine

Issues with sample AJAX request functionality

Deprecated: Asynchronous XMLHttpRequest on the primary thread is no longer supported

Why does the control skip the onreadystatechange function for the ajax object?

Enhance your list items with images by leveraging the power of Angular Js

When retrieving data from Select2, a string is being returned instead of an

Exploring Firefox webpage data with JavaScript or browser extensions

What methods are available for modifying nodes generated dynamically?

The absence of an 'Access-Control-Allow-Origin' header on the requested resource prohibits access from the origin 'localhost:8080'

Struggling to dynamically resize 2 boxes using JavaScript

What is the proper method for implementing respond_to with JSON data?