Common components for Vue2.0

Element: A set of common component library development Road

Element is the hungry ued design, hungry big front-end development of a set of desktop-side component library based on Vue 2.0. What we are going to share today is some of the ideas for developing Element.

Official website: http://element.eleme.io/#/
Github:https://github.com/elemefe/element

# # Design Purpose

Most projects originate from the needs of the business side, and Element is the same. With the company's business development, the internal start to derive a lot of back-end system, UED department also received more and more design needs, analysis of the whole process, we found the following problems:

-A growing demand for back-end product design
-Limited design resources, no way to support all lines of business
-Inconsistent use of many back-end product experiences within the company

So we decided to:

-Design a background support framework to enhance the availability and consistency of back-end systems
-Apply this framework, even without the designer to participate, can let the product or development design a good back-end system

# # Design Phase

The following is a brief look at several stages of designing Element experience.

* * Understand the business and familiar with the company's back-end products, to find common problems in business * *
The purpose of the design is for business services. The first step is to start with an internal system, to understand the various back-end systems used within the company, to abstract its components and to look for common features.

* * Focus on Business component design * *
After summarizing the usage of different components of different systems, we intend to start with the business components, because this part is a solution that is derived from the company's special needs, we think that solving these difficult problems can also bring good design guidance to other back-end products.

* * Seek Development support * *
In this step, we began to look for the company's internal development team, and then learned that different teams used different front-end framework, there is Vue, React, Angular and so on.

* * with large front end cooperation * *
The large front end as an independent front-end team, has the ability to develop the underlying tools to serve different businesses, and Vue is a very young and well-developed technology stack. UED and large front-end cooperation hit it off.

* * Direction SHIFT, focus on basic components * *
After contacting the front end, it was found that the initial direction was not correct, because the business changes too fast, even if there is a common business components, it is difficult to keep up with the changes in demand, and the basic components are all the development team need common components. At this point we begin to adjust the direction to the design of the base component.

* * Component interaction Complete, visual encapsulation, and build the main website * *
The preliminary design work is mainly by the interaction designer design, and so on to confirm all the components of the function and interaction, the beginning of the visual phase, which includes the development of color, font and other specifications, but also the main site design.

Output UI Kit file, unified design specification

The first version of the site design, where the "special components" is the business components.

* * Website Two designs * *
The first version of the site after the visual effect is not good, we have to adjust the internal, once again on the line is what you see now.

The design process is simple to go through these stages, if there are problems can continue to communicate, the following into the development phase.

# # Development Purpose

-background system lacks a complete set of base component libraries
-Vue is a relatively young technology stack within the company, hoping to do some infrastructure construction
-Enhance the company's influence in the technology community

# # development process

After entering the development phase, we have made some attempts in the overall architecture, which are shared in chronological order:
* * How to cooperate with the designer * *
After the initial development and design of the project, we refined a set of component development processes:

1. Develop according to interactive draft and Visual manuscript, keep communication with designer
2. Self-Test after development, submit to designer for acceptance after completion
3. The designer proposes to revise the opinion, according to the opinion changes
4. Complete component development, write examples and documentation for the website

* * How to manage multi-component projects * *
At the beginning of development, we were thinking about how to reduce the coupling of components to ensure that the components can work independently. The goal is to ensure that components can rely on other components, have users load only a few of them, and even install only the components they need at the time of installation. The first thing to think of is a single component repository, and the component library project is to introduce components as dependencies.

However, due to the shortage of manpower, such a mechanism causes development to be too time consuming, each component needs to be maintained and packaged separately, while maintaining the dependent version number of the component library project. We can only find another solution. Later reference was made to the management of [Babel] (Https://github.com/babel/babel) Projects: All sub-projects are placed in the ' packages/' directory, and a subproject can be used as a separate repository. Manage dependencies and releases of sub-projects through [Lerna] (Https://github.com/lerna/lerna).

In combination with the features of the project and the Babel mechanism, we reconstructed the directory structure: The component can be placed as a single item in ' Packages/', and the shared function is placed in ' src/'. The final packaging results package the entire component into a single file, packaged separately into separate files, and publish the component libraries and standalone components to meet the needs of different users.

* * How to troubleshoot custom themes * *
Developing a set of component libraries is inseparable from the need for custom themes. The class name should be friendly enough to avoid the nesting of style hierarchies, which makes it much easier to cover styles directly or to write a set of topics individually. So we manage the class name in a BEM way, and replace the attribute value with variables as much as possible, and maintain a variable file so that you can customize a set of topics by directly modifying the variables.

Considering the usage habits of different users, we did not choose less or Sass such as have their own style of the preprocessor, but chose a closer to the future standard CSS4 style of grammar, with postcss and integration of POSTCSS-BEM and Postcss-cssnext plug-ins [ Postcss-salad] (Https://github.com/ElemeFE/postcss-salad) development.

To reduce the cost of getting started with user-defined themes, we've also provided command-line tools to guide users quickly to customize a set of topics.

* * How to provide an intuitive document * *
The document is not just for the user to look intuitive, but also for the writer to write intuitively. So the simplest way is to write the document with Markdown. But there is another problem: how do you write a running example in a document? The general practice is to write the document in the Vue file so that other components can be called inside, but this violates the original intention of writing "intuitive" documents.

After several attempts to combine the features of Vue. We wrote a set of Webpack loader that handled the Markdown file, turning Markdown into Vue files, not only reducing the maintenance cost of the document, but also making it possible to run the component sample in the document.

* * Multi-lingual website How to configure and manage * *
Element at the beginning of the project did not consider the internationalization of the problem. After the project was open source, we received feedback from some foreign developers, hoping to add English documents. Shortly thereafter, a translation team in the country contacted us to contribute a complete set of English documents to Element.

English-language documentation is required to have an English-language website, which requires the modification and upgrading of the existing structure of the website, and the need for the website to be compatible with languages other than English in order to be future-oriented. For this we have done the following work:

1. Routing

The route of the official website is automatically generated according to a ' JSON ' file that records the navigation information. It is therefore necessary to add fields in this ' JSON ' file that correspond to other languages and to modify the logic generated by the route based on the new data structure.

2. Page

In addition to the official website, there are some pages about the nature of the document. These pages are more text, if you manually manage each language of the page, if you need to modify it must go to each page corresponding to the location of the editing, some cumbersome. We do this: each page corresponds to a template, the text in the template is all extracted into a language configuration file, and wrote a script to generate the final page. This allows you to edit the corresponding field in the language configuration file when you need to modify it.

3. Website components

For the "header", "footer" and other common page components, we have adopted a similar strategy as above. However, because there is less text in the component, the template is not used, but it is routed to determine what language should be displayed.

The display effect of Chinese and English websites

At this point, we have gradually perfected the technology stack. Using ES2015 and CSS4 as the development language, Lerna is responsible for managing components, using Karma with Mocha and Chai tools to do continuous integration testing in Travis CI, and finally writing documents with Markdown combined with Vue. We have even implemented the automatic deployment of Web sites and push-topic warehouse code in CI, which has improved the efficiency of development.

* * Problems encountered during development * *

Specific to the component level, in the development process inevitably encounter some problems. Here are some of our strategies, we hope to be able to stimulate the thinking and discussion.

-How to deal with the change of event distribution mechanism between parent and child components

In Vue 2.0, the ' $dispatch ' and ' $broadcast ' for event communication between parent and child components are removed. The official consideration is that the method of event flow based on the component tree structure is difficult to understand and becomes more and more vulnerable in the process of component structure expansion. However, a component library like Element has several features: first, the scenarios in which parent-child components communicate with each other are very common, such as in a form with validation, where each table item needs to be notified to the form component for validation at ' Change ' or ' blur ', and secondly, the structure of the component is relatively fixed.

For the above considerations, we have implemented a simplified version of ' Dispatch ' and ' broadcast ', and packaged them as a ' mixin ' for easy invocation when needed. The ' dispatch ' code is as follows:

Dispatch (ComponentName, eventName, params) {
var parent = this. $parent | | this. $root;
var name = parent. $options. ComponentName;
while (parent && (!name | | name!== componentname)) {
Parent = parent. $parent;
if (parent) {
Name = parent. $options. ComponentName;
}
}
if (parent) {
Parent. $emit. Apply (parent, [Eventname].concat (params));
}
}

As you can see, our implementations need to pass in ' componentname ' (defined in each component) at the time of invocation, ensuring that the event is only triggered in the correct component.

-Whether you need to customize the native events on the component for the user agent

Using ' v-on ' on custom components in Vue 2.0 listens only to custom events (that is, events triggered by the component with ' $emit '). If you want to listen to native events, you must use the '. Native ' modifier:

<mt-component @click. native= "Handleclick" ></my-component>

This way, many users who are not familiar with the Vue 2.0 syntax will find that the component binding native event to Element always does not take effect. In fact, one of the most frequently asked questions we received from Open source issue is: How do I bind a ' click ' event to the ' Button ' component?

In fact, we only need to add a line of code to solve the problem, but about whether it is necessary to allow users to directly listen to the native events there are two different views in our internal: while thinking that should follow Vue design ideas, the original event to add native, the other side that the most common is the button Click event to help users do this can reduce the cost of learning. Later, we specifically consulted Yu Yuxi himself, his view is that for some of the components of common events, you can allow users to directly listen to native events, while in the document to explain which events can be directly monitored, which events need to add '. Native ' modifier. Finally, we decided to use the "button" component to listen to the native ' click ' event from a usability standpoint, because the ' button ' would need to listen to the Click event in most scenarios for the desktop side. Now the ' Button ' supports the following two types of notation:

<el-button @click. native= "Handleclick" >click me!</el-button>
<el-button @click = "Handleclick" >click me!</el-button>

-In the process of version iteration, if the API changes, how to prompt the user friendly

In successive iterations, we try to keep the API consistent. However, in some cases, the API needs to be updated. For older users, if the removed API is used, there will be some unexpected error messages when upgrading to the new version. To help users find the source of the error as quickly as possible, we have written a ' mixin ' that introduces the ' mixin ' in the component when the component's API changes, and lists the field names before and after the change.

The core code for ' Mixin ' is:

const {props, events} = This.getmigratingconfig ();
const {data, componentoptions} = this. $vnode;
Const DEFINEDPROPS = Data.attrs | | {};
Const Definedevents = Componentoptions.listeners | | {};
For (let PropName in Definedprops) {
if (Definedprops.hasownproperty (propname) && Props[propname]) {
Console.warn (' [Element Migrating][attribute]: ${props[propname]} ');
}
}
For (let EventName in Definedevents) {
if (Definedevents.hasownproperty (eventName) && Events[eventname]) {
Console.warn (' [Element migrating][event]: ${events[eventname]} ');
}
}

The component referencing this ' mixin ' needs to add a method called ' Getmigratingconfig ' in ' methods ' to return an object containing the changed API field names and corresponding cue information:

Getmigratingconfig () {
return {
Props: {
' Selection-mode ': ' Table:selection-mode has been removed. '
},
Events: {
Cellclick: ' Table:cellclick have been renamed to Cell-click. '
}
};
}

# # Issue Processing method

We chose to use the Tower to track and process issue with GitHub. First set up several lists on the Tower: Plan, Design, Develop, and Release. The following specific procedures are followed:

-Collect feedback from all channels
-If the design is not required, the development reply
-To design follow-up, add label ' design ' to GitHub and add the task to the Tower's Plan list
-Add ' working in progress ' tab to GitHub's corresponding issue after starting the task, and drag the task into the Tower's Design list
-After the design is completed, the development takes over and drags the task into the Develop list
-Development completed, after the acceptance by the designer to push the changes to the GitHub warehouse, close the corresponding issue, and finally drag the task into the Release list

# # Summary

Element has gone through five months since the project was established. In general, this period of time is a continuous process of discovering problems and solving problems, as well as the process of each participant's own growth. At development, Vue 2.0 was in the RC phase, and we stepped on a lot of holes with its version iterations, and also gave Vue some issue, and all of them were handled by the Vue team. Thank the Vue team for their professionalism.
Since open source in September, the Element has matured with the help of the community, and we have released its first official version today. Hopefully more and more people will be able to get involved and do the Element better with us.

# # References

-[Https://github.com/babel/babel] (Https://github.com/babel/babel)
-[Https://github.com/lerna/lerna] (Https://github.com/lerna/lerna)
-[Https://github.com/ElemeFE/postcss-salad] (Https://github.com/ElemeFE/postcss-salad)
-[Https://github.com/QingWei-Li/vue-markdown-loader] (Https://github.com/QingWei-Li/vue-markdown-loader)
-Https://github.com/ElemeFE/cooking

Share a question & answer questions

Question 1: What is the official website?
Question 1: The official website is Element.eleme.io

Question 2: How do I modify the style?
Answer 2: A simple style can be modified by overwriting, and for large-scale customization, we provide a set of tools for customizing the theme, which is documented here: Https://github.com/ElemeFE/element/blob/master/custom-theme.md. Simply put, you can implement a custom theme by modifying style variables, compiling themes, and introducing themes.

Question 3:vue The author gives a set of learning Vue path, that element is the path to read the source, how can be more convenient to understand the source code, and the basic components can not meet their business when the time to write their own components?
Answer 3: Read the source code, you can first clone the project, first try the NPM run new command to create a new component, to see what one of our components contains. To understand the source of the word, you can change the code side of the test results.

Question 4: What do you think of Vue adding redux, while preserving data in two-way bindings?
Question 4: Don't quite understand what to ask.

Question 5: What does an internationalized website do, a page for each language, or a single page of unity?
Answer 5:element's homepage is a SPA, each language corresponds to a. vue file, and these. vue files are generated through a unified template and language configuration file.

Question 6: Is there a folder Loacel in the share map, is it a typo in the locale?
Answer 6: Sorry, our mistake, the figure should be the locale.

Question 7: Will the Vue2 component library be launched specifically for the mobile side?
Answer 7: Answer 7: There is currently no plan to port Element to mobile. However, we have a set of mobile component libraries: Https://github.com/ElemeFE/mint-ui, which has two versions, each compatible with Vue 1.x and 2.0.

Question 8: Where is the output of the markdown written in the Vue file? This is not part of the real effect?
In response to the combination of 8:vue and Markdown, we made a vue-markdown-loader by turning the Markdown file into a Vue component (the generated file is in the plugin's. Cache directory) and finally through the vue-loader process. can go to see this loader source code to understand.

Question 9: Since it is based on Vue, is there any further need for element? And now the framework is so much, Vue has been recognized by people. How can the element be guaranteed after the ecology? After all, there's only one team that's hungry now.
Answer 9: Not very clear "element also has the need to continue" what meaning, according to our gitter to the user's understanding, now has many users to apply element to their company's product development. In addition to our team itself, the ecological development of element relies on the power of open source to optimize and develop.

Question 10: Is there an accumulation of highly reusable business components in component development? If so, how do you maintain these business components? Is it the same as the maintenance method for logical components?
Answer 10: Component development will continue to receive a variety of functional needs of feedback, through the GitHub warehouse issue to promote the function of our components update and maintenance. It is not clear what the meaning of "logical component" means, except that a special component such as a button is logical in element.

Question 11: Is there anything that is not smooth in the process of writing a common JQ plug-in or a JQ action into a Vue component?
Answer 11: There is no reference to the dynamic effect of any JQ plug-in during component development. In fact, the development of component libraries based on the MVVM framework is much easier compared to JQ, because you do not need to handle event bindings and view updates manually.

Question 12: Is the shared document somewhat stale and not updated, Vue is no longer an RC phase?
Answer 12: The document says "development"vue is still in the RC stage, mainly referring to this year's August or September, when Vue every update of an RC version, we followed the test again, and then found a few bugs in the scene is still vivid. " Vue 2.0 was officially released last month, and we have released the official version of Element today.

Question 13: Is there a template for you to refer to?
Answer 13: Yes, look here: Https://github.com/ElementUI/element-starter. If you are familiar with cooking or laravel, we also provide the corresponding template: Https://github.com/ElementUI/element-cooking-starter, https://github.com/ Elementui/element-in-laravel-starter.

Is the developer of the problem 14:element hungry? Front-end team, how much does the developer outside the team occupy?
Answer 14: Yes. But since the Element was open source, the community has been a group of enthusiastic users, they have contributed their own code. All contributors can see from here: Https://github.com/ElemeFE/element/graphs/contributors.

Question 15: A few years ago, the jquery that did not calculate gzip 90kb was rejected by people: too big, or with the native bar. A few years later, after opening gzip still have 300KB based on react project, people think: only 300kb, calculate very small. After the concept of mega-Libraries became popular, people seemed to forget how much pain they had on their faces.
What do you think?
Answer 15: The speed of the network has improved a lot over the years, and the complexity of the front-end project has become more and more high. Compared to the volume of the library, perhaps the development efficiency is now the developer's concern.

Question 16:element This set of components and ant design feel a bit similar, have you ever borrowed their designs?
Answer 16: For reference, we have not only borrowed from Antdesign, at home and abroad, large and small Design Language have learning from reference. A lot of information has been summed up before, we hope that we can quickly get this knowledge, so that faster to go to the front to explore more cutting-edge design.

Question 17: Thanks for sharing. Are there any good application cases to share?
Answer 17: Currently we don't have the energy to collect items using Element, but the quality is still quite high, as discussed in Gitter for some time in recent years. Over time we will start to collect in the issue to share with the link of the element component library.

Question 18: How to customize CSS, overwrite or change the source code? Changed the source if the element version is updated after the style is gone?
Answer 18: You can customize the tool with the Element-theme theme, or directly download the Element-theme-default theme pack to modify the theme yourself. If it's just a simple modification, it is recommended to override the style directly.

Question 19: Hello, I am a beginner, do not understand programming, beginners to do the front-end, should start from where to learn
Answer 19: Answering 19:freecodecamp and Codecademy is a good way to get started.

Question 20: In the technology selection, based on what considerations, the choice of vue, not react
Answer 20: As compared to react, our company uses Vue more than the front end. To take care of most people, we use Vue as the framework for Element.

Question 21: I also found that the event is useful but not easy to control in the component communication of Vue, so it is generally a namespace for custom events, such as $dispatch (' acomponent::rotate ', *), does the Element team have this practice?
Answer 21: Communicating the component in the element's component does not use a global event bug, but rather communicates between interdependent components through dispatch and broadcast. Although the API for $dispatch and $broadcast was deprecated in vue2.0, we encapsulated it in the component library ourselves.

Question 22:element What are some specific scenarios when the team uses Vuex?
Answer 22:22. element does not use the Vuex scene

Question 23: Will future open some common business components, such as city selection, etc.
Answer 23: Components that are associated with a background business should not be directly open, but if this component solves a similar problem, we will pull out of the business attribute to open it as a "base component". City selection only uses a relatively basic select combination.

Question 24:element What are some of the results in the direction of animation effect?
Answer 24: Animation effect We have no manpower to explore and research, the main focus is on the business system to build

Common components for Vue2.0