The introduction

It’s been 16 months since Ant Design released 3.0 in December 2017. During that time, we fixed a lot of bugs and added a lot of new features (update logs). 4289 commits were submitted, 138 editions were published, 7,675 issues and PRs were closed, and 25,375 stars were added. We also released Ant Design Pro 4.0. Support for TypeScript, blocks, and layout abstraction. We would like to thank the community volunteers whose dedication makes Ant Design even better.

At the same time, we are thinking about what’s next and how we can take Ant Design further, and we expect to release Ant Design version 4.0 in Q4 this year. 🍻

Here are the detailed plans for 4.0, which are still being planned. Adjustments may be made when it is officially released.

🌓 Compatibility Adjustment

We will remove the attribute marked Deprecated in 4.0. You will no longer be able to use obsolete methods. If you upgrade your project to the latest 3.x and don’t see a warning message from ANTD in the console, your upgrade to 4.0 will be seamless. For the 3.x release, we will still do an additional six months of maintenance after the 4.0 release.

We know that the upgrade will take a lot of effort to move away from the deprecated API, and we plan to provide compatibility packages with the release of 4.0 to facilitate the project transition (the API is still being designed and may change when it is released) :

import Compatible from '@ant-design/compatible';

// It works, but will warning in console
const Demo = () => (
  <Compatible>
    <YourApp />
  </Compatible>
);
Copy the code

The compatibility package will also be updated until the 3.0 maintenance work is stopped.

Use the latest version of the React API

We’ve been supporting the React 15 version for quite some time, but based on community feedback, it doesn’t really matter (React 15 issues tend to be close to 0%). React itself has very robust compatibility. To support React 15, we used the new API very carefully during development. After version 4.0, we will use the latest React release as a baseline for development:

  • Provides Hooks versions of related components
  • Support for Concurrent mode (of course, there are a lot of things to prepare for, which will continue to be adjusted in the 4.0 release).
  • Embrace React 17 (Wow! ~)

Stop Internet Explorer 9/10 support

Ant Design 3.0 puts a lot of effort into compatibility with older versions of IE. However, according to industry statistics, BOTH the global and domestic share of IE9/10 browser is shrinking with the update of Windows system. In version 4.0, we will stop supporting IE 9/10 (IE 11 will still be supported). This also means that support for new browser features is possible.

Other Compatibility Adjustments

  • Less 2.x Is upgraded to Less 3.x
  • Icon Use change
  • Mention abandoned

📦 Reduce volume

Optimize icon size

In [email protected], we introduced SVG ICONS (why use SVG ICONS?). . Using an API for setting ICONS with string names, we couldn’t load on demand in this design, so we introduced a full SVG icon file, which greatly increased the size of the package. In 4.0, we will adjust this to optimize the volume.

The old Icon usage will be deprecated:

import { Icon, Button } from 'antd';

const Demo = () => (
  <div>
    <Icon type="smile" />
    <Button icon="smile" />
  </div>
);
Copy the code

The on-demand import approach will be adopted in 4.0:

// Directly import
import SmileOutline from 'antd/icons/SmileOutline';

// If tree-shaking supported
import { SmileOutline } from 'antd/icons';

const Demo = () => (
  <div>
    <SmileOutline />
    <Button icon={<SmileOutline />} />
  </div>
);
Copy the code

You will still be able to use the compatibility method above.

Remove the Draft. Js

We introduced draft.js in the Mention component to implement the dropdown location feature, but we only used a fraction of its functionality. Consider from cost performance, appear some waste. We plan to remove this dependency in 4.0 in favor of a more lightweight solution. Also, to distinguish the Mention component in 3.0, we will provide a new component Mentions to prevent API collisions. Also, it supports continued use of the compatible methods described above:

// Follow Code will not work
import { Mention } from 'antd';

const Demo = () => (
  <Mention />
);
Copy the code
// Added 'Mentions' in 4.0 import {Mentions} from 'antd'; const Demo = () => ( <Mentions /> );Copy the code

🚀 Performance optimization

During maintenance, we received a lot of discussion about performance under big data. To this end, we also plan to optimize performance.

Virtual rolling

Virtual scrolling is a common optimization tool, but it’s not easy to customize virtual scrolling in Ant Design due to animation effects. We now plan to support virtual scrolling natively in a component with scrolling. Of course, there is no guarantee that all components will be updated by the time 4.0 is released and will continue to be updated.

Animation to improve

In the past, we’ve used hacks to manipulate animations. For the most part, it worked pretty well. In 4.0, we plan to tweak this and move away from hack to a more React approach. This adjustment will be updated silently and you don’t need to make any changes to it.

♟ About Components

In 3.0, we have continued to add a number of components. In 4.0, we will continue. These components will be refined from our business scenarios, Ant Design Pro, and community requirements in an ongoing process. The process of adding new components is the same as Ant Design 3.0. We will show the Design drafts of related components in PR and update them with the official website. Once they are developed, they will be released in minor each month.

In addition, we are refactoring some key components to improve ease of development and interaction. Which includes but is not limited to:

The Form component

Forms components have a large audience, and we’ve noticed complaints from the community about cumbersome forms apis, and in 4.0 we wanted to explore better forms of API to simplify development costs:

  • Form will aggregate Form data fields by default, so you no longer need to passForm.create()Create the context.
  • Fom.item will default to aggregate form fields that you don’t need to passgetFieldDecoratorBinding Field.
  • The value of form.item will always remain, but its validation will only take effect if the Form Item is visible.
const Demo = () => { const [form] = Form.useForm(); const onFinish = () => { // Do something... }; useEffect(() => { // Something like ajax call form.setFieldsValue({ username: 'light', }); } []); return ( <Form form={form} onFinish={onFinish}> <Form.Item name="username" rules={[{ required: true }]}> <Input /> </Form.Item> </Form> ); }Copy the code

In a real world scenario, we encounter multiple form linkage scenarios (common in verbose configuration). We know this is not easy to use, so we will also provide linkage between forms:

const { useForm, createContext } = Form;
const FormContext = createContext();

const Demo = () => {
  return (
    <FormContext>
      <YourForm1 />
      <YourForm2 />
    </FormContext>
  );
};
Copy the code

The Table component

In past releases, we’ve received a lot of feedback on the Table component. We know that the expand and Scroll properties of Table have not worked well in the past. This time, we will focus on resolving conflicts in this area. In addition, we will further tune the Table component for performance. And explore some easier table layouts:

const Demo = () => {
  return (
    <Table
      header={{
        templateAreas: `
          name    address     address
          name    building    no
        `,
        cells: [
          { key: 'name', title: 'Name' },
          { key: 'address', title: 'Address' },
          { key: 'building', title: 'Building' },
          { key: 'no', title: 'No' },
        ],
      }}
    />
  );
};
Copy the code

In addition, we plan to add Summary footers to support Summary requirements.

DatePicker redo

The existing DatePicker already meets most of the requirements, but judging from the community discussion. We have the opportunity to dig deeper, and we will complete the remaining year selectors and corresponding range selectors (discussed). In addition, we will adjust the relevant date and time picker styles to further reduce the cognitive cost of users.

🚀 Continuously updated

In addition to the above content, we also plan some continuous updates. This will be followed up in 4.0 to better improve user development and user experience.

🥁 Improve accessibility

Ant Design 3.0 is a little less accessible, so we plan to tweak the component structure and add more ARIA tags to improve the screen reading experience. In addition, we are going to optimize the existing component keyboard interaction to ensure a better full keyboard interaction experience.

🎯 developer API specification

Over the course of evolution, we found that a few API styles were incompatible with other components. This isn’t a problem for TypeScript users, but for others it can cause memory problems.

So we put together a standard named document. This document contains a list of existing apis and appropriate naming conventions. When new features are added, they are named according to the specification. To avoid possible API disagreements in the future. Of course, we also welcome community students to give feedback in PR.

💼 React Strict mode

If you try to wrap

around antD, you’ll get a lot of warnings from antD. We have updated the lifecycle methods for some components in 3.0. In 4.0, we will continue.

💡 Improve the developer experience

In the past maintenance process, we found that certain issues would appear repeatedly. These issues are often used for use specifications or application scenarios. For this reason, we decided to make improvements here (which we’ve been making since 3.0). In a development environment, we would alert the console for unexpected situations such as invalid Moment objects, Dom structure changes due to Input preffix/affix dynamic adjustments, and so on. We are sure that the console is the first place developers look when they encounter a problem, and providing appropriate hints here can help quickly locate the problem. At the same time, for some special use methods or scenarios. We will provide the FAQ in the corresponding component documentation. From the perspective of project maintenance, we are unable to give detailed answers to the issue of usage mode. But these questions are real, and especially for new developers, an FAQ can save a lot of searching time. If you are interested, community volunteers are also welcome to help improve the developer experience.

🐱 Design asset management

Ant Design is more than just a library of components. It has a strong Design architecture behind it. In 4.0, we will update the latest design-related assets (Sketch kit, Kitchen toolset, Design Token, etc.) for the convenience of designers and students interested in Design. Existing component design styles will also be tweaked to improve the visual and user experience.

Time to plan

Here is our timeline, some of which is ongoing. We will establish relevant issues on Github, and community volunteers are also welcome to participate:

Q2

  • Mark the Deprecated API as Deprecated and clear it in the document.
  • The underlying components are warmed up.

Q3

  • Branch antD 4.0 and update the documentation.
  • Underlying component development.

Q4

  • Release 4.0.

Welcome to participate

This may change during the 4.0 development process. Community students are welcome to provide valuable ideas and suggestions, let us make Ant Design 4.0 together more convenient and easy to use! Click here for github Issue.