In CodeInsight after development come to an end, CTO adults find me want to put a Coding.net the front split reconstruction program, so I started to switch from state to develop a joy to be off to face the test of a spell.
Dynamic languages moment cool, code refactoring crematorium.
In any case, start with the status quo began to comb.
Coding Angular build front-end, front-end engineering or merge files using packaged way, does not introduce a modular development approach CommonJS such as a SPA website, with an increase in the size of the site, the front-end code has become increasingly bloated, development experience also plummeted, which we consider the reconstruction of reasons.
So first of all we want to know to solve the problem of reconstruction
- Code Packing split avoid all functional modules into a single package file
- The introduction of modular CommonJS achieve clearer
- Change the wheel while driving
The last point is particularly difficult to do, but it is also the key to our ability to successfully reconstruct, reconstruction is not rewritten, so how to reconstruct the existing code base, and also the current development progress and it is seamless a challenge we have to face.
The good news is that we ensure that our use of Angular code division Module with a layer of packaging, will not be too scattered. SPA website as a front-end route has been very good separation of the various functional modules. We used the Grunt, though a bit out of date, task written a bit complicated, but provides an engineered entry point.
After several rounds of discussions small partners to finalize a more reliable solution:
- According to its function refresh / resolution codes
- SPA remained as a website, according to the routing function modules lazy loading
This latter point is the core of our remodeling ideas, before we have to consider each functional module is split out a separate unit to run, but in order to ensure that "change the wheel while driving," must be a fast iterative reconstruction of course, one can not say that until complete functional module unit reconstruction over again integrated into existing code, refactoring way this will be a long and time-consuming process, and the risks are also high.
Keep the SPA, the introduction of lazy loading, we can quickly integrate this architecture adjustment to the existing code to verify the feasibility of the reconstruction process after it can be refined to each controller, so that "change the wheel while driving." .
Split function module
This step is very simple, Coding website function module has been relatively clear, such as bubbling, tasks, search, and so, we only need to establish a unified directory structure and namespace specifications to rearrange the code, thanks Angular dependence of injection mechanism, before the code logic can remain unchanged for those independent modules, this reconstruction process is essentially no risk of any introduction Regression Bugs, a reconstruction module namespace just modify it.
We agreed:
- Reconstruction of each controller, service and so on have their own namespace (specification)
- Each function module to define your own route
- Each module has a unique function module all dependent injection
Such as bubbling reconstructed structure may be like this:
tweet/
├── tweet-list.controller.js
├── tweet-list.html
├── tweet-topic.controller.js
├── tweet-topic.html
├── tweet.module.js
└── tweet.routes.js
tweet.routes.js will specify lazy loading tweet.module.js.
Webpack lazy loading
In order to do packaging code resolution, we use lazy loading, when only the navigation function module corresponding to the corresponding function module to load the code, together with the introduction of webpack CommonJS achieve the support of and Lazy Load.
Angular existing route has been well isolated functional module inlet, so we just put the file as a route entry point, as the file entry webpack package, all rely on the introduction of a document on the inlet module can use CommonJS of the way, and that is all we can reconstruct the code is automatically migrated to use CommonJS, where webpack will serve as a perfect binder, the convergence code and refactoring existing code, here a simple look at how routing is done.
./tweet/tweet.routes.js
$routeProvider.when('/pp/:region?', {
templateUrl: require('./tweet-list.html'),
controller: 'TweetListController',
title: '冒泡',
resolve: {
lazyLoader: function($q, $ocLazyLoad) {
var defer = $q.defer();
require.ensure([], function() {
var module = require('./tweet.module');
$ocLazyLoad.load({ name: module.name });
defer.resolve(module);
});
return defer.promise;
}
}
});
Angular routing support asynchronous loading, require.ensure webpack is loaded asynchronously to the internal callback function specified tweet.module.js, all dependent on the injection module tweet this function module, such as TweetListController
'use strict';
var angular = require('angular');
module.exports = angular
.module('tweet', [
require('./tweet-list.controller').name,
require('./tweet-topic.controller').name,
]);
Finally, we used the ocLazyLoad to inject this module loaded asynchronously.
grunt-webpack
The newly introduced webpack can be easily integrated into our existing development process to go inside, using the grunt-webpack can put webpack as a new task to the grunt call, so we can package build process independent webpack, and as a child the original task into the build process, without affecting the original development / publishing.
gruntfile.js
...
webpack: {
dev: {
entry: {
'routes': ['./src/routes.js'],
},
...
},
prod: { ... }
}
grunt.registerTask('server', [..., 'webpack:dev', ...]);
grunt.registerTask('build', [..., 'webpack:prod', ...]);
...
Common module
For an independent, not dependent on the rest of the module, remodeling can be very convenient, but for the common module, although you can reconstruct this module, but to change all references for this module, code involves a bit out of control a.
So we all agreed to the reconstruction of the modules will have their own namespace, for those common module, migrated to the new namespace, and it will retain the previous code until we reconstruct other functional modules to a point in time, not rely on these modules can determine the common modules are retained, go clean up, so in the early part of the code will be redundant, but to ensure the quality of our reconstruction and progress.
So far, Coding reconstruction of the front opening of the road, I believe HTTP: // Coding.net will gradually bring a better experience.