Is shared services right way to implement DRY in angular 2?

Question

I am looking for implementing ERP frontend in angular 2. I have my exisiting implementation in codeigniter HMVC structure.From which I have converted all models/controllers calls in to REST APIS.

The older structure was reusing lots of view component for CRUD operations in modules such as CRM, Accounting, Transactions etc etc.

I have doubt that is there any way to achieve the same pattern in Angular 4 with more optimization.

I have looked at shared services and it looks very promising. In short I am looking for correct modular structure in angular which somehow helps me to convert old HMVC codeigniter module structure.

If you need more implementation regarding new and old structure. Let me know.

Answer 1

I highly recommend following the Angular.io style guide for structuring an Angular application. These guidelines favor simplicity through consistent application of the LIFT principle over the traditional approach to organizing code such as grouping related components into separate folders (i.e. having a model layer, a services layer, etc). This will allow your application to scale over time as it evolves from a very simple application with fewer than ten files to more full-featured complex applications with over hundreds or even thousands of files.

https://angular.io/guide/styleguide#application-structure-and-ngmodules

Highlights:

1. Follow the LIFT principle consistently when making decisions on folder structure or file location.
2. Follow the Folders-by-Feature principle (each folder represents a feature in the Application domain, and each feature has a module which packages components, directives, pipes and services).
3. Leverage barrels (i.e. index.ts that re-exports modules, services, models, etc) from feature folders. This will help keep the modules modular, and easier to separate modules into its own published packages later if needed.
4. Have a Core module, intended to be imported by the AppModule, whose purpose may include registering app-wide services with the root injector. Leverage the forRoot and forChild convention to ensure services are close to the module where they are used (LIFT), while still allowing them to be registered as app-wide singletons.
5. Have one or more Shared modules, intended to be imported by Feature modules. Its purpose is to expose components, directives, and pipes that can be re-used across the application. Avoid singleton services in Shared modules (intentional singletons are Ok).
6. Be aware of deeply nested import statements - this is an obvious code smell, and a sign that you are likely violating the LIFT principle. Re-factor your code to follow points #1-5.
7. Avoid having all models in one folder, all services in another folder, etc. This violates LIFT and makes it more difficult to locate code related to a particular feature and challenging to separate code into re-usable packages in the future.

Here is a compliant example folder structure:

https://angular.io/guide/styleguide#overall-structural-guidelines