This is not only an introduction to the features of 3.0, but also explains the reasons behind the changes and the logic behind the design. If you are developing your own component library, I hope it will help you.
3.0 is a lucky number. She’s one more than two, but one less than four. It’s just magical, isn’t it? (it’s even…
The main reasons for the switch to V3 are as follows:
- It has more updates and some are not backward compatible, for example, replacing Momentjs with dayJS
- The V2 version is mainly a Vue 3 compatible release, it does not have many new features, a few disruptive updates are for better Vue 3 compatibility, and some new features and interactions will have to be deferred to V3.
- 3 is really a lucky number, it just happens to be the same as Vue 3, will not let some people misunderstand the future of 4, 5, 6…… “And” I’m using a 4 and you’re still using a 3, “which, I have to say, does reduce the cost of answering questions (brilliant).
- The team starts to maintain the component library full time, the pace will be much faster than before, speed up ahead, please fasten your seat belt (update fast, you say I am unstable, update slow, you say I do not maintain, too damn hard)
Let’s get back to business
What has been updated in 3.0? I want to explain the source level, the functional level, the ease of use level, and the performance level respectively.
The source code level
Use the TS + Composition Api for refactoring. Currently, only a few components are still using the Option Api. We will gradually refactor, but these components will not break the update, so don’t worry about future upgrade costs. Pair with Volar for a better type cue. It has to be said that Vue 3 in TS has a great improvement, but there are still some shortcomings, for component library body sense is strong Vue 3 source type complexity is high, generic component is not friendly, component attribute type reuse is not friendly, these three problems separately have some solutions to solve, but the three combined, We still haven’t found a good balance to regulate it, of course, we are not deep in TS, if you are good at it, you are welcome to join us and contribute to the Vue 3 ecosystem and open source.
Our current approach to defining component properties is to separate props as a function, for example:
import type { ExtractPropTypes, PropType } from 'vue';
export type ButtonTypes = 'primary' | 'ghost' | 'dashed' | 'link' | 'text';
export const buttonProps = () = > ({
type: { type: String as PropType<ButtonTypes> }
})
export type ButtonProps = Partial<ExtractPropTypes<ReturnType<typeof buttonProps>>>;
export default defineComponent({
name: 'AButton'.props: buttonProps(),
})
Copy the codeIn this way, we also export buttonProps, buttonProps, buttonProps, buttonProps, buttonProps, buttonProps, buttonProps, buttonProps, buttonProps It’s a classic interview question from the Vue 2 era, why data should be defined as a function return is the same reason. In this way, the purpose of type reuse is achieved. If you have a better suggestion, feel free to discuss it via PR, and you can start with a simple component.
Functional level
The antD 4.x function is synchronized with antD 4.x:
1. Custom time library, using DayJS as the default time library, providing momentjs and Date-FNS fast switching function
2, Tree, TreeSelect support virtual scrolling, Table support Table totals
Better dark themes
4. Better accessibility
5. RTL is supported, except for a small number of unrefactored components, which are not supported, and will be added before the official release
6. CSS Variables will be added before the official release
More detailed features are no longer described.
Usability level
Antd has experienced good default, and now it has been pursuing good default, but good default includes powerful functions and simple API, which are in contradiction. It should be said that what we have been exploring is the balance between them, how to maintain simple and easy to use API while expanding more functions.
This time, we changed the API of Tree, TreeSelect, Table and Card for custom rendering. We used Table as an example.
<template>
<a-table :dataSource="dataSource" :columns="columns" />
</template>
<script>
export default {
setup() {
return {
dataSource: [{key: '1'.name: 'King two Eggs'],},columns: [{title: 'name'.dataIndex: 'name',}]}; }};</script>
Copy the codeRender the result as follows:
It’s very simple, isn’t it? But Wang Erdian is a rich second generation with hundreds of millions of assets and is also our VIP customer. The boss expects to mark this kind of customer with special name, bold plus red plus V plus… In React, we can just:
name: <div class="jia_cu jia_hong jia_v">Two eggs</div>
Copy the codeOf course, in Vue, you can still configure in the same way if you use the Vue -jsx syntax or the render function by hand, but the Template syntax gives us better performance than React. X and 2.x we agreed on a rule to specify an “arbitrary” name for columns via slots:
<template>
<a-table :dataSource="dataSource" :columns="columns">
<template v-slot:customName="{record, text}">
<template v-if="Record. name === 'Wang2 egg '">
<div class="jia_cu jia_hong jia_v">Two eggs</div>
</template>
<template v-else>{{text}}</template>
</template>
</a-table>
</template>
<script>
export default {
setup() {
return {
dataSource: [{key: '1'.name: 'King two Eggs'],},columns: [{title: 'name'.dataIndex: 'name'.slots: { customRender: 'customName' }}},]}; }};</script>
Copy the codeIt seems that there is nothing wrong with this method. Indeed, this method has been with us for many years, and it seems that everyone has been used to this configuration method. However, after weighing it for a long time, we still decided to break the comfort zone.
1. Configure bloat. If you need custom render for each column, you need to configure slots for columns and provide a corresponding slot for template.
2, is the main problem, it has a big risk is that we can not limit the user defined slot name, so if the component needs to expand the slot in the future, there will be a risk of conflict, which is an uncontrollable risk.
In fact, we provide the a-table-column mode to build the configuration, which does not need to configure slots, but we have not promoted this mode:
First, I feel that columns are much less than a-table-column and more intuitive.
The second reason is the form of columns. Compared with a-table-column, the performance of A-table-column is slightly higher. In fact, a-table-column will still be converted into columns internally. Traverses the sub-component A-table-column to generate columns. Vue does not promise to render “process order”, but only “result order”. This index will not be expanded. Vue does not promise to render “result order”. In addition, both methods use non-VUE document apis, which are risky. In short, since most users choose columns, we expect to make columns easier to use and tables easier to use.
So for 3.0, we scrapped the column.slots configuration and instead provided a unified custom exit v-slot:bodyCell. Using the new API, the optimized code is as follows:
<template>
<a-table :dataSource="dataSource" :columns="columns">
<template v-slot:bodyCell="{record}">
<template v-if="Record. name === 'Wang2 egg '">
<div class="jia_cu jia_hong jia_v">Two eggs</div>
</template>
</template>
</a-table>
</template>
<script>
export default {
setup() {
return {
dataSource: [{key: '1'.name: 'King two Eggs'],},columns: [{title: 'name'.dataIndex: 'name',}]}; }};</script>
Copy the codeThere is no need for V-else in the slot, the internal component will automatically fallback to the default value. As I said before, when we add a new slot, there will be a risk of conflict with your custom slot. I hope you don’t have a slot named bodyCell. HeaderCell customFilterDropdown customFilterIcon are all new slots, I think it should probably not happen to meet it.
For the same logic, we optimized the Tree/TreeSelect custom title logic. Instead of configuring custom slots in the treeData data source, v-slot:title takes over. Card customTab. Instead of configuring custom slots in the tabList data source through slots, v-slot:customTab takes over.
The performance level
FormItem uses provide/ Inject instead of cloneElement to reduce render times and improve form performance
2. Discard TreeNode and replace TreeSelectNode with treeData attribute
In 2.x, Select and AutoComplete support virtual scrolling. In 3.0, we added Tree and TreeSelect to support virtual scrolling. Can easily deal with big data rendering.
4. Internal performance optimization of many other components that users do not perceive
Why does Table still not support virtual scrolling?
Two reasons: disruptive updates and cost
If you want to support full virtual scrolling, there is a lot of cost. Note that we are talking about full virtual scrolling, not just a list. We need to support fixed columns, column merging, expansion, subtables, etc., and the development cost is no less than a set of component libraries. That’s why MUI(formerly material UI 70,000 + STAR, an open source project) hires full-time staff to maintain the virtual forms component.
Although you have an example of virtual scrolling in the ANTD React version documentation, it is a simple virtual scroll example that is completely customized with third-party components. It is very expensive to add fixed columns, select, drag, expand, and so on. You can try searching for table virtual keywords under issue in antD React version to see related issues.
For Table, we will also launch an independent product to solve the problem of big data display. The first version should not make you wait too long. If everything goes well, we will meet you in the next couple of months, please look forward to it! You can follow the official account, we will issue a notice through the official account in time.
