Shulou(Shulou.com)06/02 Report--

How to understand the organizational structure of Angular project construction, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

The organizational structure of the project has just been reconstructed a few days ago, which is the second major change in the organizational structure of the front-end project, and it is also a process from "folder by type" to "folder by feature".

Why is there such a process?

Because of the growing size of the project, I may have to open three or four files at a time, such as where to modify a page. So first is the HTML of the page, then the Controller,Less, the service file of the corresponding interface, and so on. I may not have a problem with the whole project, but when I look for it, I have to recall the corresponding files, but if a new member joins in, there will inevitably be some omissions, because it is also difficult for him to determine the local changes on a page. Which files are involved.

At the beginning, when the project is built, that is, with only one page, the project is organized by file type. However, with the size of the project, and other aspects of the impact, gradually, according to the type division has appeared the sense of responsibility is not clear.

At the beginning, the structure of the project is something like this, too specific to remember, something like this:

-- static-- js-- app.js-- routers.js-- services.js-- directive.js-- controllers-- userController.js-- someModule.js-- less-- index.less-- user.less-- someModule.less-- build-- all.2014090901.js-- All.2014090901.css-templtes-index.html-user.html

The basic structure is to divide the Controller according to the function, because the Angular SPA is basically a Controller corresponding to a sub-page, and then all the js and less are merged and compressed, and loaded in the index page. Of course, some more meticulous work has been done, and here we are just talking about the prototype of the project.

What changes have been made next?

Instead of saying what changes have been made next, let's talk about what prompted us to change. Speaking of this is changing the topic, what is a stable and good document organization structure, a definition I now make is "robust and inclusive". When something changes, your current organizational structure can adapt to the new changes at a small cost, rather than overhauling the entire project or even implicating the code.

When the prototype was completed, the project grew and two task entered the process to be considered. One is about the automatic construction of the project, including the management of library files, the dependency between libraries, the compression and merging of code, as well as the version number of static resources, different code construction in development mode and release mode, and so on. Another problem is the design of URL, how to maintain a high degree of unity with the organizational structure of documents.

These two problems are quite complicated, let's talk about the design of URL first.

There are several definitions of "good URL design". You can do it on your own. I don't plan to copy Baidu encyclopedia. I think the most important thing is to be user-friendly. What is meant by URL's user-friendliness? To put it bluntly, it is easy for your URL to understand and guess. I think this design is fine, you may say who will be bored enough to remember the URL address, want to visit the collection later on.

I'm not interested in refuting this, but why can't you see that Baidu or Taobao's website has an address designed as "www.baidu.com/hsakudhkajshdgjasgdjhsgfjhsagfjhsdgfjhasgfj786347823yuisbhdufy".

The semantics of URL expresses its friendliness to users to a great extent. For example, the corresponding URL pages of "/ restaurant", "/ restaurant/new", "/ restaurant/2" and "/ restaurant/2/edit" are:

Restaurant page (list data), new restaurant page, restaurant id 2 restaurant page, restaurant id 2 restaurant editing page.

It's easy to guess, isn't it? changing 2 to another corresponding id can also access the specified restaurant page. This URL mapping should be structurally corresponding to our folder structure, that is, there should be a restaurant folder with details, new, editing and other pages and other corresponding files. Therefore, based on good URL design, we need an organizational file structure that conforms to semantics.

How does the automated build of the project involve the file structure?

Each small topic feels like it leads to something detailed and in-depth. What is the problem of project automation building to solve? This solves a lot of problems, but there are two main requirements for an Angular SPA. One is the integration of static resources, such as merge compression, and release using static resources with version numbers. The other is the recompilation of some Less files and JS files and automatic page refresh in the development process.

To put it simply, one is for release, the other is for development, and make some efforts for these two steps to be more convenient and orderly.

In the above process, both development and release will generate a lot of build files, which will also affect your adjustment of the project directory and file organization.

Newly constructed project structure

Every modification of the project involves all aspects of things, very complicated, with the growing size of the project, the cost of such modification will become higher and higher, so it is urgent to determine a good structure as soon as possible. First, give the structure of the current period:

To talk about how it is divided now, because it is SPA, there must be an index.html as the bearer of the page, app.js is the main file of angular, and app.less is the entry of all Less files.

Components is the various components of angular, including common,services,directives,filters,router,run.js (this is mainly to place some code that needs to be started and run with App, such as plug-in initialization configuration, and similar route listening processing events, etc.).

A sub-page is divided into modules according to functional modules, and the corresponding JS files of Controller and CSS files of Less are all in a folder.

All the contents in the build catalog are generated. I used Bower and Gulp to automate the construction of the project.

In this way, the directory structure is clear, the common parts are divided together separately, and the relevant files corresponding to each page are organized together, and then divided according to the functional arrangement. In this way, it is easy to find the relevant files to be modified during maintenance. Colleagues use files in build for daily development and project release, and there are two different sets of files corresponding to development and release.

This makes the whole project feel much more refreshing.

The road to project construction does not stop there.

Because of the limited space, it is still impossible to explain a lot of things together, such as the division of responsibilities of Controller, the structure of services, and how Bower and Gulp cooperate to build a complete project. After that, you may leave a shelf on Github. If you are interested, you can leave a message.

Although I feel a lot of things are not clear, but about the organizational structure, probably that's it. It's just that the construction of the project has a long way to go, and I have some ideas to share with you.

The construction of the project can only be said to have completed the primary step, if slightly better, it can be regarded as intermediate. Then it should be taken for granted that there should be a high-level or * goal, which is a framework rather than a library, which gives us a lot of room to play. Judging from the current situation, there are still things that need to be improved. I have summed up some points. Of course, these points are available for most projects:

The degree of coupling between the parts, whether to achieve deep decoupling.

Whether the responsibility of Controller is too big, not just the business, a lot of messy things are thrown into Controller, resulting in the formation of 'super controller'.

Some common things are not extracted, and the copy code is still being repeated.

The concept of MVVC, do not find that they do not have the concept of M in angular.

Use object-oriented thinking to look at the architecture and code, whether to achieve a single responsibility, open and closed.

In fact, there are still a lot of things need to be improved, and I have been slowly organizing. It can be said that a set of relatively perfect shelves have two most prominent characteristics. One is that the structure is clear and easy to maintain, because each part has a single responsibility, closed for modification, and expanded for development. Another feature is extremely efficient development, a large number of content is abstracted into common components, 70% of the code has been written, as long as write that part of the business.

If there is another important reason for us to tirelessly improve the architecture, it is not to maintain effectively when the project is getting bigger and bigger, I feel that this is the most important point, that is, through clear code and structure, reduce the cost of maintenance.

After reading the above, have you mastered how to understand the organizational structure in the construction of the Angular project? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.