component of front-end Web Application (ii) Xu Fei

Component of Web application (ii)HTTPS://GITHUB.COM/XUFEI/BLOG/ISSUES/7Management and control platform

In the previous article we mentioned the general idea of component, which is mainly about what external means we need to control the entire development process after doing so. From a variety of perspectives, it is necessary to establish a collaborative platform for the development stage in the face of large-scale front-end development teams.

What are we going to do on this platform?

1. HTML fragments

Why do we manage HTML fragments? Because there are interfaces to use them, when these fragments are more, there needs to be a place to manage them, to retrieve them, to preview them, and to see a general description.

This should be a relatively simple part of the whole process, supposedly, there is a directory structure, and then the rest is a single HTML fragment file, which can solve the problem of storage and retrieval, but we have to consider more.

How are the existing HTML fragments used? This is certainly a similar way to include these fragments in a particular tag, either front-end or back-end, with the first question:

Given that interface A and interface B refer to fragment C at the same time, how did he know that the interface A and B would be affected when a developer modifies the content of the fragment C? A more reluctant approach is full-project lookup, but this is not enough in many cases.

If our HTML fragment exists as a standalone public library, it is no longer possible to solve this problem through in-project lookups, because no matter a or B, as long as he is not in the project space of fragment C, it is impossible to pursue.

This is when many people ask two questions:

1. What is the meaning of cross-project interface fragment reuse?

   If our product is for a small area, its complexity does not need to be divided into multiple project parts to collaborate. It is important to maintain consistency in scenarios in which the scenario is faced with a large industry, where each project is a sub-product and may be a number of joint deployments in the future. For example, we have a basic configuration interface, in a number of sub-products to use, if each development of a, its operating style is likely to be inconsistent, the impression is not professional. Therefore, it is necessary to collect the common interface fragments for the business parties to select and use them.

2. Modify C, provide only instructions, but do not notify A and B, do not update their version in real-time, and then decide how to upgrade, how?

   This will have a problem, each time there is a small feature upgrade, the code is the most easily synchronized merge, so there will be "continuous integration" this concept, if it is always accompanied by an upgrade, the overall upgrade costs should be as far as possible, the cost should be apportioned to the usual, like the peasant woman raised piglets, the pig every day to hug, Do not feel the difficulty, even if you grow up can still hold a move.

Now the problem is very clear, there must be a way to manage this dependency, it is clear that the existing version of the repository is certainly not able to control these, so only in the periphery to do some processing.

We establish a management platform, in addition to managing the version of the entity files, and also the relationship between them. There are two ways in which this relationship can be collected: manual configuration, Code analysis.

Manual configuration is a way of comparing soils, and developers are going to manually configure their dependencies on this system every file they submit. For code analysis, to parse the file's inclusion rules each time the file is submitted, find out the exact file. Both have pros and cons, the former is more stupid, but easy to do, the latter on the code format requirements are relatively high, to consider more cases.

Our interface is often not so simple, HTML fragments may also have layers, for example:

Interface A contains fragment B, but fragment B itself contains fragment C, so this dependency is hierarchical and needs to be considered at design time.

2. JavaScript module

The management of JavaScript code is better than HTML fragments because of many of the industry's solutions. However, they still do not resolve the issue of reverse notification when a dependency changes.

So we still have to manage their dependencies in the platform like HTML fragments. As a result, each JavaScript module explicitly configures its own other modules, which form a complete set of views through this one-way relationship.

In the code implementation of the JavaScript module, we do not advocate the direct write dependency relationship. Many common specifications, such as AMD, often suggest that we write modules like this:

    define ([' dep1' dep2function (return modulea;});   

But our systems are industry-oriented and more demanding than this generic solution. For example, if you refactor the code one day, the JavaScript module adjusts the directory or the name, so it hurts, and he has to tweak everything that's affected, and it's going to search for replacements. Moreover, as mentioned in the section of the HTML template above, it affects the code that is dependent on it in other projects and lacks the appropriate way to notify them of the change.

So what we expect is that only the specific implementation is stored in each JavaScript module, and the dependencies are managed on our platform, so that the code that relies on it in the external project does not have to be modified even if the current module is renamed and so on. The next release of the build process will automatically kill these things.

Corresponding to the above code, we need developers to do just the implementation, that is, the part of Modulea, the outside of these dependent shells, will be in the release phase based on the configured dependencies automatically generated.

JavaScript modules can also be subdivided if needed, such as angular, which separates the Factory,controller from the directive, which facilitates subsequent processing.

Now we need to discuss the granularity of the module, we are talking about the basic granularity, each JavaScript module should be stored only a very specific implementation of things. So, there is a question, when we publish, is not in accordance with the size of the release?

Obviously not, if you do, it's likely that the complex interface will have to use more than 10 HTTP requests at a time to load up all the JavaScript code it needs, so some merging is required.

So what is the strategy for merging? On our platform, how do developers define this merging relationship? We need to define a larger-grained organization on top of the module, which is like the relationship between the jar file and the class in Java. If the developer is not explicitly configured, it can also be combined by a global policy, such as by the lowest-level directory.

This time, in the actual use of the code, you need to bring two configuration information in the past, one is to dynamically load the JavaScript file (after merging), and the second is the original module contained in each JavaScript file.

3. Unit Testing

If JavaScript modules are already well-organized, you can consider unit testing for them. Unit testing is of great importance in improving the reliability of the base unit.

In our platform, you can associate unit tests with JavaScript modules, and each JavaScript module can hang a set of unit test code that can be written online and run online.

The essence of unit testing is to write the analog code to invoke the existing module, considering that our module is JavaScript, so many ideas tend to be executed on the browser side, and for the unit test of a single module, this is not a problem.

If you want to perform unit tests of the entire system in bulk, it is different. The JavaScript code is loaded into the browser first and then executed, and many times it doesn't have to be that complicated. We could have done it on the service side.

With the ability of node. js, we can execute JavaScript code on the server, which means that the majority of the JavaScript module's unit tests are executed on the server. Of course, we may have to do a lot of things for this, for example, some libraries need to port a copy of the node version, common Ajax calls and so on.

Note that it is a prerequisite to be able to do JavaScript unit testing on the server, and the code must be layered so that the DOM cannot be manipulated at any level except the view layer. So what we're mainly testing here is all the JavaScript business logic except the view layer. What about the view layer? This is really difficult to solve, the world is not all things can automatically do, can only do the first to do, and then to consider these.

4. Documentation and example Management 4.1. Document

Now that we have HTML snippets and JavaScript modules, we need to give them more descriptive information. The simple description is obviously not enough, and we also need detailed documentation.

This detailed documentation can be generated in some way, or it can be written manually by developers. Unlike traditional offline documents, online documents are more real-time, and each time a developer changes his or her document, it does not require a full-scale build, and visitors can access his latest version in real time.

Friends who are familiar with GitHub may have been accustomed to this way, and there are some text files in the project library that end in MD format, using markdown syntax to write some documentation.

There's no question that this type of format is good for online collaboration, so we're also integrating this kind of documentation on the platform, whether it's for HTML templates or JavaScript modules, or whatever, or even as blogs, like the gitpress platform of the Moon Shadow classmate, The ability to pull text or HTML files directly from GitHub to form a blog.

In addition to navigating in an integrated form, a document should also be sent as a separate link, which allows the user to navigate like a news page. If you do it further, you can create an ebook that provides packaged offline documentation.

4.2. Example

In the process of writing code documents, it may be unavoidable to insert samples, examples have two forms, one is plain text, similar to gist, one can be run online, similar to Jsfiddle and Jsbin.

Both have their advantages, so you can do both, and the sample can be stored in a similar way to the document and should be able to run independently through a single link.

4.3. Slideshow

Sometimes we see some online slides, feel very handsome, such as reveal.js, our developers sometimes for code analysis or walk through the time to write some demos, if you can put these things with the project management, can be viewed online, it will be a good thing. So we can also consider adding a storage interface to them, or even a simple online writer.

5. Project and Catalog Management

Now, we seem to have missed something. That's what these things are, what are the organizational units to store?

Considering that our platform is to manage the entire front-end content of a large product, it should be divided into a number of projects, corresponding to sub-products, so, naturally, the project became the first level of organizational units. Under the project, there is no suspense, only the catalogue.

What does it have to do for a project? You first need to be able to configure its entity storage location. So many of the code, documents, and so forth mentioned above are ultimately stored by entities, how do they exist? Of course we can do it ourselves, in the file system, but also to consider their version management, very cumbersome, so instead of directly docking a repository, call its interface to access the file, here is configured to the repository path.

Second, to consider copying from the existing project, similar to the fork function in GitHub, but the internal processing mechanism can be slightly different, fork project default does not have to have an entity file, only when the creation of a modification or new operations to create, the rest of the original can also be quoted. The project replication feature here is considered for the project version, and there is often a case where a product version supports multiple customer projects, so this feature may be useful.

Then, consider the dependencies of the project as well. Relies on a project, meaning that it needs to use the components inside it, so the substance is the component's dependency. Providing projects that rely on this view is just some consideration for future changes.

6. Comment Management

Previously mentioned, our entire platform is designed to improve the collaboration of large front-end teams, collaboration is inseparable from communication. Any of the above functions should have the ability to communicate with each other.

For example, if developer a uses a code component A that someone else has written, he should be able to comment on some of the details in question. At the time of his comment, anyone involved in maintaining the component can receive a reminder that he can choose to come and see and answer the question. Similarly, this can be done under documentation, as well as in the example.

On the internet there are such products, used in any URL to hook up the comment Exchange system, the more famous is Disqus, we can see a lot of sites hang it, for the exchange of comments, so that users can use an account in the exchange of multiple sites. Domestic also have similar, such as more say, can use Weibo, QQ and other account login to communicate.

From the perspective of our platform itself, the possibility of introducing an external commenting system is small if it is deployed within the enterprise for process improvement. Because in the enterprise internal use, it must be hoped that the employee's account information with the work number hook, but also with the version of the Server account module integration, permissions are also easy to control.

From another point of view, when a person logs in to the system, he may receive a lot of messages, from different code or document locations, and a bit of trouble to get back to the past, we should give him a global view, so that he can be in a unified interface to answer all these questions, if he needs, It is also possible to point in to the actual location.

7. User and permission control

From the above section we have seen that this system is a relatively complex development process Control platform. In this case, each user should be able to log in and assign different permission levels.

A user who is not logged in should have some permission to view it, but cannot comment. The logged-on user can control the ability to create, modify, create, modify, catalog, code, Unit test, document, and so on, depending on the permission level.

8. Internationalized String Management

A cross-lingual Web application inevitably has to deal with internationalization, which is usually done on the server, for example, by embedding code like <% =getres (key, LAN)%> in the interface code to get the corresponding string and replace it with the interface.

This thing is to occupy the application server resources, and internationalization itself is actually a thing that has been determined before running, it is completely possible to put this process in the release phase to do it off. For example, we generate multiple copies of the code in advance for each language, just deploy it together and dynamically load a particular copy as needed.

There are a lot of clients of the internationalization of the project is to remove the resource files to the page for the storage, but this is actually not very reasonable. The first reason is that in the Web2.0 era, the concept of "page" itself has been weakened, to a single page application, the entire application is just a page, this time, the resource files to what granularity to organize it?

We mentioned that using the mv* framework to do the architecture of Web applications has a goal of component-based. The intent of the component is that a component can be used wherever it is needed. If the granularity of the resource file is small to the level of the corresponding HTML fragment and JavaScript module, the flexibility is there, the problem is that the management cost increases.

To be an industry application, the most important thing is business consistency, which includes the consistency of logic and the consistency of terminology. A word, which may appear in multiple resource files, increases the likelihood of inconsistency.

Therefore, there should be a unified terminology management platform, all the text or hints appearing on the interface must come from this platform.

9. Management of static resources

At the time of publishing the system, you need to publish the code, but also to publish the static resources such as pictures, these things should also be managed.

Static resources are available in two cases: Published with the product and referenced in the platform. For example, there is a picture, which is managed on this platform, which can be configured on a project and exported at the time of publication. This image can also be viewed or downloaded in a linked way, if a document or example inside the platform is to reference it, it is also possible.

10. Style and theme management

In a web system, styles and themes are a very important link. Style management and publishing has always been a relatively complex topic, in the early years are generally divided into block writing, and then combined, the recent years have less,sass and stylus such technologies, to solve the separation of writing and publishing.

Let's see what's the biggest problem with publishing? Is the merging of different parts. In order to be flexible, we had to take things very thin, and the HTML snippets and JavaScript modules were handled the same way. In so doing, we need another thing: these tiny things, as much as possible to cover the whole.

corresponding to the CSS, we have to do is to each of the elements that may appear in the system, categories are maintained as separate rules, to generate a global list of rules. The implementation can be different between different projects, but the name of the rule is fixed, the customization is only allowed to modify the implementation, and the rules are not allowed to be modified. If you want to add a rule that you didn't have before, you have to do so in the list of global rules.

After a style rule is managed, it can be associated or not done on the interface component. The benefit is that when you publish, you can publish only those style rules that you use, and it doesn't matter if you can accept the full amount of CSS each time you publish.

In addition to the rules, you need to consider the management of some variables, the rational use of variables in CSS, will greatly reduce the workload caused by the customization.

11. One Click Release

The fact that we've introduced such a bunch of stuff is actually adding to the complexity of publishing. Why is it?

Before, regardless of HTML, JavaScript or CSS, are handwritten, up to a minify work, released, the whole process is very simple, two scripts to take care of.

Now can be complex, first to analyze the dependency, then extract the file, then internationalized string substitution, then merge, and then code compression, the whole process is very frustrating, do not give the configuration administrator an explanation, he must come to chop people.

We have a principle: in the process of solving the problem, if a new problem is introduced, the person responsible for solving the original problem will be solved together. Now, for some intents and purposes, the complexity of the release is increased, and there is a way to fix it, at least not more complex.

So we have to integrate these processes into the control platform, do a one-click release process, all of these operations are integrated, configure the administrator to release the version of the time just click on all these things can be done. Even that, these processes can be configured to add and subtract links.

At this time we have to do with the previous version of the same convenience, can you do more things?

You can integrate JavaScript unit tests into the release phase. Because we have the JavaScript in accordance with the responsibilities of the layering, and the UI part of the isolation, you can do in the browser outside the unit test can be done, the usual time to commit the code to do, and finally in the release phase of the full amount of work, it is also very meaningful.

What is the other purpose of code dependency management? is to minimize the release, since we all manage the relationships between files, then, from the root, it is clear that what code files are used in this project can be published every time you get exactly what you need from our full-scale code base. This is the advantage that our entire control platform brings.

12. Summary

This article is more complex, and puts forward a set of management and control mechanism to solve large-scale front-end collaboration. The essence of this theory is to add a link between development and release, and to incorporate all the static resources in the Web system in addition to the services, and strengthen the existing mainstream command-line-based front-end engineering organization model.

Compared to traditional industries, such as automotive manufacturing, this segment is equivalent to the production line design, some of the components of storage is similar to the warehousing mechanism, released similar to the factory process.

The platform itself has a lot of other things to do, such as the visualization of the interface can even be done on the above, these are the ultimate goal in the long run, in the following article talk about some considerations.

In subsequent articles, we will look at how the entire front-end collaboration process can be done with this platform.

component of front-end Web Application (ii) Xu Fei