ANGULARJS Project actual Combat! 01: module Partitioning and directory organization

Recently, I have been fortunate to dominate a typical web app development. This project is a typical CRUD application from the product level, so I did not hesitate to implement it with the Grunt + boilerplate + angularjs + bootstrap + D3 + Requirejs architecture. Angularjs as early as last June, I was in touch, applying it to individual pages of the lab project, and also recommending it to the Cloud Division project team in November at Sina. Project team boss Chenghui and other people are very technical sensitive people, boldly adopted my recommendations, will be used in the original use of dojo developed project front-end module. However, since the front-end module is large and has been developed for a long time with dojo, Angularjs was also applied on some pages and submodules, and was completely refactored before I left Sina. Although I have also done some ANGULARJS plug-ins and other things, but eventually did not use ANGULARJS complete a large-scale project experience. So this lab has given me a whole project, and regardless of the benefit geometry, for a person who has a love for the front end, this is an opportunity to complete the ANGULARJS project from scratch, and how can I let go. I want to use the blog to record the time, for later use.

Developing large JavaScript applications and doing several demo pages The biggest difference is that you need to have a clearer understanding of the first file organization and module partitioning. It took me a lot of time to deal with the work earlier. Therefore, the first article on the module Division and Directory organization, this aspect of my experience is not much, the shortcomings please point out.

Project requirements and resource assessment

No module partitioning is necessary and universal, and module partitioning is based on a thorough assessment of project requirements, resources at hand (employee resources, time resources, and material resources), and decisions are made on the basis of a large number of paradigms. So let's take a general look at the project requirements I took over. This is a typical B/s architecture of the reporting system software. Requires users-service desk-staff-system administrator four-level role architecture, for different roles, display different interface, each interface contains sub-pages of about 20, sub-pages overlap each other. Requirements require the system to have sufficient stability, general concurrency. The front-end requires a sense of design, adequate aesthetics, rapid response to some specific statistical content has a corresponding visual presentation. No need to support IE6. After the project is formed, as a software installation deployment, two development possibilities are small. Human resources, plus I work there are three, one of the front-end skilled workers a (i), have a certain development experience of one, write code general visualization program operation of a good practical work. Time resources of approximately 3 people * 60 working days.

According to the project requirements, the project from the user role can be divided into four large modules: Users, service desk, staff, system administrator. Most page logic is simple and easy to divide. For duplicate sub-pages, a common module can be created separately. Considering the manpower aspect, 2/3 is the non-skilled worker, the art design staff basically did not (originally I was, but now the workload does not allow me to do this), the project quantity is tight, therefore requests the design the workload to minimize. The use of the Technology and Module division to be as easy as possible, reduce duplication of labor, improve concurrency efficiency. Because the front-end staff more, the background is relatively simple, so the overall architecture, backstage only need to provide rest-style API, the focus of work forward, the front desk responsible for the implementation of the main logic module.

Front-end initial architecture design

After confirming the requirements and resource assessment, my next job is to review the various projects using ANGULARJS and Google related documents on GitHub. Some of the project on GitHub gave me a big inspiration, and they were:

• Https://github.com/angular/angular-seed
• Https://github.com/zhangdiwaa/angular-coffee-AMD-seed
• Https://github.com/elsom25/angular-requirejs-html5boilerplate-seed
• Https://github.com/mz121star/NJBlog (a blog program written using MONGODB+NODEJS+EXPRESS+ANGULARJS)
• Https://github.com/zhangdiwaa/ng-grid (a grid plugin based on the Angularjs write)

Based on these references, I designed the initial technical route:

Briefly describe:

Web server is using node. js. With automated tools, grunt does some work such as end-to-end testing, code compression, and merging.

Framwork, of course, uses ANGULARJS as the MVVM framework. Also used some UI widgets, such as Angular-ui-bootstrap, Angular-ui and I wrote the form plugin Angrid (Https://github.com/zhangdiwaa/anGrid). Because the table plug-in for the project is more important, the use of their own form of the table plug-in for easy customization (think of the table for the custom dojo plugin to vomit). In the module division, the first is to imitate the angular-seed way, using a MyApp as the program entry point, direcvtives, filters, service as a folder, the corresponding JS file storage.

The basic toolset uses jquery and Bootstrap. The advantage of bootstrap this thing is that you can quickly let people who do not understand the design can quickly develop a can see the interface, to solve the user is not picky enough. Moreover, there are many software systems in the domestic interface far better than the bootstrap look good. Here bootstrap we did not use its development package but directly used its engineering package, and abandoned less. This is done because we don't need to do much customization to bootstrap to take into account the requirements. Use the original design directly to minimize the workload of the style design. Less this thing, only in the need to change the style design very often when the ability, other times than the direct use of CSS.

The other toolset is primarily the d3,d3 of the front-end data visualization toolkit, without the need for clarification. In addition to the boilerplate alone is because this thing I really like, it is to make the HTML5+CSS3 specification of the Web program shortcut

The problem with the initial architecture design 1:ANGULARJS no mechanism such as AMD or CMD.

When I tried to continue with the existing scheme, I found that it was not going to work until the sub-modules were partitioned from MyApp. The problem is as follows: Angularjs does not have mechanisms such as AMD or CMD. From MyApp onwards, all of MyApp's dependencies must be loaded first. Although Angularjs can use routing to load templates on demand, the controller is loaded first (as shown in the following code).

$route.  When('/view1 ',{template:' partials/partial1.html ', controller:  MYCTRL1});             

My project can be divided into 4 role modules (users, service desk, office staff, system administrators), for an entry point pressure is very large, each module also has more than 20 pages, all the controller, since the module all to load it? This is obviously unscientific. Must be loaded on demand.

So I searched the internet for half a day, the first way to find the following:

$routeProvider.  When('/phones ',{ templateurl:' partials/phone-list.html ', controller  :Phonelistctrl, resolve:Phonelistctrl.  Resolve})                 

function Phonelistctrl($scope) {//do not use the tube itself, how to get how to do it }

Phonelistctrl.Resolve= {Delay: function($q) {VarDelay=$q.defer (), load = function () { $. Getscript ( '/js/xxxxx.js ' ,function () { Delay. Resolve}; Load (); return Delay.; }} /span>

This method is equivalent to using the ANGULARJS built-in Ajax method, delay loading the JS file. However, this method is not useful. It is foolish to write a lazy-loading property behind each control function, of course, you can write it to prototype or change Angularjs source, but it is likely to be a mine for another two unskilled developers. In short, delay loading controller problem a lot, especially when the display, the specific you try to know.

So I thought of require.js this AMD tool. The reason for using require.js instead of homemade seajs is not that I discriminate against domestic (in fact, I use SEAJS on a project), but because require.js is rich in documentation and there are many routines on GitHub that are suitable for teaching two other developers. In addition to the Require.js AMD mode is the same as that of Dojo's AMD on-demand mode, I have been more interested in require.js using Dojo development. So I ended up using Require.js as an on-demand load for AMD mode.

Further, there are others on GitHub based on Requirejs that dynamically load templete,controller, and directives plugins on angular routes. This is enough when the module is less clear. Https://github.com/matys84pl/angularjs-requirejs-lazy-controllers

Initial schema Design question 2: Does our program really need an entry point for an app?

In Angularjs's tutorial, you always use an ingress module (usually called MyApp) to organize your entire program. An example program such as Angular-seed,phonecat or a larger application like Njblog is an entry point. However, our projects are different from these, and are a lot more and more complex projects than they are. Since the roles in this project are strictly separate, there are four role module users, service desk, office staff, and system administrators who will not visit each other. So these 4 modules can be used to organize the program using 4 apps as an entry point. Finally add a landing module, make a decision and jump can. The most feared problem with Requirejs is that there are too many dependencies to create confusion, and this way of dividing 5 portals determines that each app's dependencies are not too much, and the entire program's functional logic is at a glance.

Although in fact, the use of an entry point, and then through the internal mechanism to determine the jump between the various modules is also feasible, but then the complexity of the program is much higher, but also to explain to the other two partners to explain half a day, so still forget it.

Initial schema Design Issue 3: Organize files by module

At the beginning, my file directory was completely organized according to the book transcription modeled angular-seed. Considering the file is more complex, so set up a few direcvtives, filters, service as a folder, storing the corresponding JS file. So the file directory looks like this:

• controllers/
  • Logincontroller.js
  • Registrationcontroller.js
  • Productdetailcontroller.js
  • Searchresultscontroller.js
• Directives.js
• Filters.js
• models/
  • Cartmodel.js
  • Productmodel.js
  • Searchresultsmodel.js
  • Usermodel.js
• services/
  • Cartservice.js
  • Userservice.js
  • Productservice.js

But is it really useful?

It seems that the files are arranged neatly, but to my partner, he still doesn't know the dependencies of these objects. Especially when it comes to reusing certain modules, he must collect relevant files from individual folders and often omit objects from certain folders.

In fact, in rapid development it is very rare to reuse a lot of code in a new project (there is a lot of repetitive code), but it is possible to reuse the entire module such as the login system.

Therefore, it is better to follow the function module to organize folders. In the end, my catalogue is arranged in this way:

• Build/(Engineering Catalogue)
  • css/
  • img/
  • js/
    • appadmin/(standalone module, beginning with app name, approximate content of each app module)
      • controller/(Controller.js of related sub-templates are stored here)
      • Directives/(the relevant directive.js are stored here)
      • Admin_app.js (app model definition and routing configuration file)
      • Admin_main.js (Requirejs's entrance and configuration file)
      • Admin_services.js (App-related service profile)
    • appcustomer/
    • apphelpdesk/
    • apprepairer/
    • applogin/
    • common/(Universal Module Library)
      • angular_filter/(some general-purpose filters)
      • Common_plugin.js (some non-angular-based but relatively important components, such as the console plugin)
    • utils/(Other components)
  • lib/(includes all third-party class libraries)
  • templete/(Sub-template folder, whose contents are categorized by module type)
    • common/
    • tpladmin/
    • tplcustomer/
    • tplhelpdesk/
    • tplrepairer/
  • 404.html
  • admin.html (Portal HTML for admin module)
  • customer.html (portal HTML for the customer module)
  • Helpdesk.html (entry HTML for Helpdesk module)
  • Login.html (entry HTML for the login module)
  • Index.html (The total entry point of the program to jump to each module entry according to the configuration)
  • Repairer.html (entry HTML for repairer module)
• Node_modules/(Grunt)
• src/(source files that are not grunt processed)
• test/(end-to-end testing)
• Gruntfile.js (Grunt)
• Human.txt
• Package.json (Grunt)
• Readme.md

Obviously, here I will JS and templete inside the files are divided into sub-folders, in the root directory of the build left a number of module entry points. This is clear enough.

There is a more radical approach, is to belong to the same module templete, CSS, JS all in a module directory, my last project is to do so. However, the previous project failed to clearly classify the general-purpose modules and functional modules, resulting in some confusion. I can't compare the pros and cons of these two divisions for the time being. At least in the current division, enough is available.

Author information: Zhang Di, communication university soy sauce male, the main research areas for networked storage, data visualization. 3 years of experience in front-end development. Personal hobby swimming, world history, art illustration, computer CG.

Source: http://community.angular.cn/A08q

ANGULARJS Project actual Combat! 01: module Partitioning and directory organization