How to organize Angular projects? The following article compiles and shares 5 practical tips for managing Angular projects. I hope it will be helpful to everyone! 
Front-end (vue) entry to mastery course: enter learning
As new features are released, Web apps become larger and larger. In a company's DevOps journey, this kind of release change happens every day. [Recommended related tutorials: "angular tutorial"]
In such a fast release cycle, code can quickly become unwieldy. Especially projects developed based on JavaScript , such as NextJS or Angular.
Here are our 5 best practices for managing Angular projects for maximum readability, maintainability, and scalability.
Many single application cores are code bases with bloated classes. By their nature, these bloated programs are difficult to maintain. They are fragile in the sense that changing one line of code can have catastrophic effects on the entire program. The single responsibility principle can prevent these problems.
The single responsibility principle means that a component has one and only one function.
Building applications using this approach results in a modular framework in which the application is strung together through these blocks of code.
Using this approach can make programs more readable and maintainable. It can also easily locate specified functions in the application.
To make sure your code meets this requirement, ask yourself this question:这代码是干什么的？ If your answer contains the and keyword, then you need to refactor your code into single-responsibility code.
Building and extending Angular applications is an ongoing exercise. Over time, organizing your projects using the single responsibility principle will make your applications clean, readable, and maintainable.
Modules in Angular are the implementation of the single principle. In Angular , each module represents a separate and independent functionality.
Angular provides several type modules to specify how to logically group or organize them.
Core
The Core module is an NgModule that is used to instantiate the application and load core functions for global use.
Therefore, any singleton service should be implemented in the core module. Header, footer or navigation bar are modules of this type.
All services (singleton services) that have one and only one instance per application should be implemented in the core module. For example, authentication service or user service.
Feature
Function modules represent the code that builds application functionality. For example, in an online shopping application, we would have the function of adding items to the shopping cart and a separate module for payment.
Shared
Shared modules consist of modules that can be combined to create new functionality. For example, the search function can be used for multiple functions in the platform.
Structuring your code this way makes things easier to locate and increases the chances of code reusability.
Style files can quickly become disorganized if they don't follow a common structure. General best practice pattern 7-1 pattern, which uses 7 folders and 1 file, as shown below:
App - the main folder of the project
Abstract - The abstract section, containing all variables, mixins and similar components
Core - Contains layout, reset and boilerplate code for the entire site
Components - Contains styles for all components to be created for a website, such as buttons, tabs, and modals
Layout - Contains the files needed to define the layout of the site, such as headers and footers
Pages - Contains styles for each specific page
Vendors - This optional folder is suitable for the bootstrap framework used by the project, such as bootstrap
Create a new all.scss file in each folder that contains all assignments for that particular folder.
Many services are designed to run globally. Then, in some cases, a component requires a service. Traditional coding component practices recommend the single responsibility principle.
Under this approach, services and components are written as separate projects.
But what happens when you consider removing the components of these services? What you end up with is dead code, which only makes the warehouse more cluttered. In this case, the best practice is to put the service inside the component.
This way, maintaining components and services is easier.
A nested file structure is inherently easier to navigate than a flat file system that puts all code files in one directory.
However, as the project approaches, the project's file structure can become quite complex. While this makes locating the code easier, it presents challenges when writing import statements.
When a directory structure starts to grow beyond three or four levels, import statements can become very long and difficult to read.
To solve this problem, we can configure the alias of the path in the tsconfig.json file. In this file, there is an array named compilerOptions . This is the path alias you configure in your application.
When the code is compiled, the path aliases defined in this array are replaced with real paths. The value of each path is a key-value object containing the actual path and alias.
Building and extending Angular applications is an ongoing exercise.