Another question:

Are you planning to switch more files (or even rc-components) from JavaScript with TypeScript definitions to native TypeScript?

Consider replacing rc-form with something more flexible, like Formik.

Question for the maintainers:

My team is interested in trying out Ant, but https://github.com/ant-design/ant-design/issues/11097 (Antd Less creates global JavaScript leaks) is blocking us. The roadmap above says that Ant will be moving to LESS version 3, and I've read that the insecure, deprecated inline JavaScript feature in question is disabled by default. Does this mean that Ant version 4 will no longer have the LESS issue?

Not only IE9/10 , but stop IE support,

Oh gosh, it would be so useful to not pollute global styles (html, body, *::before, ...)

基于react-slick的carousel用起来出现不少问题，建议新版可以换另外一个库
react-pannable用起来挺不错的

@cztflove 这个库的 commits 描述 全是no message 😃 , 而且社区关注度过低，应该不会考虑吧。

@yoyo837 主要这个组件是新出的吧，所以关注度比较低，但是它支持 virtual list 还有 仿ios边缘弹性 ，基于这个组件还能实现一些 拖拽 功能🤔 后续有比较大的扩展空间

Shouldn't we migrate to one universal language?

I completely agree & respects regional languages, even i'm not a native English speaker. There are 100s of repetitive, or better to say duplicate tasks with double language, above all most important factor is time, translating strings discussed, learning from documentation or tuts. demos etc.

I must admit, there isn't lack of contributors due to language conflicts, still hundreds of us afraid to get involved. There is already many sprints, issues ongoing for translation, but what I request is, to completely migrate to one universal language with this major release to reduce communication gap among all of us.

Shouldn't we migrate to one universal language?

I completely agree & respects regional languages, even i'm not a native English speaker. There are 100s of repetitive, or better to say duplicate tasks with double language, above all most important factor is time, translating strings discussed, learning from documentation or tuts. demos etc.

I must admit, there isn't lack of contributors due to language conflicts, still hundreds of us afraid to get involved. There is already many sprints, issues ongoing for translation, but what I request is, to completely migrate to one universal language with this major release to _reduce communication gap_ among all of us.

说得对，专心说中文吧

Question for maintainers: is there plan to use CSS vars for change color and style themes on-flight?

I learned in practice that changing component styles through variables is a very comfortable way. I tried to rewrite Less variables with var(--css-vars), but I caught a lot of errors on style compiles, cause of a lot of styles use functions and operations with vars, not just values. I suppose that it is big task and this way create breaking changes, but major versions had created for breaking changes :) And usage CSS vars can give a lot of opportunities for customization of component styles.

What you think about that? I planned develop theme with CSS vars usage as pull request anyway, cause this feature (changing theme on-flight) is needed in my project.

Sorry, if that suggestion is duplicate, but I didn't find nothing about that in other issues and PRs.

@Z3SA https://caniuse.com/#search=CSS%20Variables. This needs to stop all IE support, stop IE11 support is too radical, although I also support doing that.

@yoyo837, I agree that it's too radical cause of IE support problems. But also Ant Design has official support (as told on ant.design) of Electron (as separated platform, not web). May be for this case there could be way to create two themes: one with Less vars, other with CSS vars. But it seems like too hard to support.

So, other possible strategy that I suppose - create Less vars for all customizable attributes in Less, or remove usage of any functions and operations under Less vars that any developer can use as entry for his CSS vars. Or if say it more simple - use Less vars only as value container, not for functions and operations.

If only support major browsers, I believe that the size of the code will be smaller and and the code will be easier to maintain.

Not only IE9/10 , but stop IE support,

@wanliyunyan Too breaking. Some developer may stick on antd@3 and it is not a good thing for us.

@Z3SA That will be a huge work.

@dancerphil Fortunately, I only consider the latest version of chrome for my project. 😃 So I hope that the smaller the size, the better.

@yoyo837 I know it. And I'll do it myself if this idea could not get enough attention.

We're a company that would love to gradually migrate to antd by using individual components; However ant's use of Global styles really complicates this issue. Please stop polluting global styles.

Form is one of the most usage component. We notice that social have many comments on the API design. We wish to simplify the API in 4.0:

Fom.Item will include field bind. No need to use getFieldDecorator anymore.

Will these changes still allow us to use Form.Item as a strictly presentational component? I love antd's components, but I prefer react-final-form for state management. I want the style of Form.Item, and none of the state-management logic.

branch 4.0 is created. When can I preview

the new form component is awesome!

Please replace momentjs by dayjs as momentjs is huge and bundle size also became huge.

有考虑接手富文本编辑器的坑吗

What is the release date?

@rafaelodassi There is no confirmed date yet, but probably in Q4.

Upgrading to @babel/runtime@7 and core-js@3 would be our priority too.

Not v3 ? Is there any news for core-js@4?

Everyone talking about removing IE support altogether because the stats show it’s barely used. How about the millions of corporate users behind intranet that don’t get into the stats whatsoever? They are stuck with IE10 and IE11 because of the corporate policies.

I will stick with antd@3 if IE11 support is dropped. Drop of IE10 can be accepted by most clients since it’s not supported by MS anymore and corporate PCs get updated to IE11.

I would suggest introducing an API to allow usage of objects as <Select/> values.
for details please see https://github.com/ant-design/ant-design/issues/13485

cc @zombieJ

建议每一个组件有也有自己的更新日志，放的隐蔽一些也没关系，个人建议~

大概什么时候能Release或者RC呢？

建议每一个组件有也有自己的更新日志，放的隐蔽一些也没关系，个人建议~

同意，每个组件的文档能否顺带添加上是哪个版本加入的。不然看到文档，还能看看当前版本能不能用，是否要更新依赖。

_{Sent with GitHawk}

@fwh1990 @jas0ncn @redclown
on English pls)

Keep it as an English channel, thanks~

4.0 alpha was published. That's amazing. Come on brother.

I will refactor my project once you publish beta version

The default theme of antd is beautiful, but it also can be better.
For readability, consider enhanced contrast and use bigger text.

There are so many articles and tools.
https://www.google.com/search?q=web+readability

It is better to provide a script to migrate antd v3 to v4.

In biz project, it exist too many form component. Migrate antd v3 to v4 will cost too many times.

The react-relay team have done something similar.
If you want to migrate react-relay v3 to react-relay v4 Realease, you need to modify many files.
Therefor, they use jscodeshift to write a migrating script, so that the user of react-relay can easy to Migrate react-relay v3 to v4.

I feel it's difficult to overwirte some of the styles. So if there is a plan of improving that?

I personally prefer using CSS-in-JS, it's very flexible and incredibly fit well with React.

4.0 alpha下在使用class component时，无法获取form实体，https://5d403395cd145c0008eea971--ant-design.netlify.com/components/form/v3-cn 这个链接下的示例代码无法实现，formRef中不存在实体方法

解决了，在

@Kwei9 , 能开个 issue 附上重现不？我看一下哈

@Kwei9 , 能开个 issue 附上重现不？我看一下哈

ref写法换成这样解决了

I think now would be the time to address the global style pollution! This makes it very had to use antd along side other applications!

Moment is too big to front-end project, there are many alternatives, but TimePicker and DatePicker's props relay on Moment. It leads us cannot replace moment ...

@jas0ncn Hi, please consider replace momentjs by dayjs (a 2kb alternative). These is already a tested issue of Replace Moment.js in Ant Design (Antd) with Day.js https://github.com/iamkun/dayjs/issues/529 and it works really well.

As a core maintainer of dayjs, we are willing to offer any help with this replacement.

Thanks.

请考虑使用轻量的 Dayjs 来替换 moment.js ， 在这里已经充分测试过替换的可行性 https://github.com/iamkun/dayjs/issues/529 。

Old Icon usage way will be* deprecated*:

import { Icon, Button } from 'antd';

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

Will use import single Icon instead 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>
);

关于新的图标引用我有一个想法，因为上面的新写法，每个图标相当于一个单独的组件， 比如引入 loading 图标，可能像这样：

import Loading from 'antd/icons/Loading';

<Loading />

但是平常可能自己会封装一个 真的的loading 组件，而且以前 <Icon /> 一眼就知道这是个图标，现在占用名字太多了而且想知道是图标还得往上找到 import 的地方。
比如：

<Title />
<Loading />
<Sun />  

一眼看上去下面两个看不出来是 icon（当然对代码运行没有任何影响~）
如果改成下面这种写法：

 import {Icon} from 'antd';
 import {Loading, Sun} from '@antd/icons';  

<Icon spec={Loading}  {...otherProps}/>
<Icon spec={Sun} />

通过外面包一层的样式，跟以前看起来很相似，而且同样可以按需使用，无非多引入一个 Icon 组件。
而且如果满足一定的约定的话，用户自定义 Icon 可以通过 spec 属性传进去？就相当于 antd 预先帮忙定义了许多图标，但是用户自定义是一模一样的~~~(随便说说~)

ps: 还是说这种写法其实早就想到了或者根本没想因为这种写法有某方面的问题？。。😂
我只是想到了说一下。。。

@ppbl 按照你的想法写法类似如下：

import Icon from '@antd/icons'; 
imoort { LoadingOutline } from '@antd/icons-svg';

<Icon component={LoadingOutline}  {...otherProps}/>

新的 Icon 也是类似生成的，可见 https://github.com/ant-design/ant-design-icons/blob/master/packages/icons-react/src/icons/AccountBook.tsx

是否我们可以通过在 Icon 的名字增加 Icon 前缀/后缀的方式来避免这种情况呢？

imoort { LoadingOutlineIcon } from '@antd/icons';

<LoadingOutlineIcon  {...otherProps}/>

Please work on reducing bundle size
https://github.com/ant-design/ant-design/issues/9419
When importing Button adds 95kb to the project - that is simply unacceptable in 2019. 👎

@vagusX 可能我只是觉得名字有点长了？ 我总觉得名字简洁一点看起来就是小组件或者比较单一的组件，名字太长了应该是个很大的组件（当然这是错误的感觉~ 我知道）。。~

当然这个我如果仅仅是为了想看见<Icon /> 就知道是 icon 的话，完全也可以自己搞一个 <Icon />组件 ,然后用的时候 把 antd 的 icon 包裹一下，是差不多的效果~ 我只是感觉全都是 icon, 确是一堆散落的名字感觉有点奇怪~ 差别就是原来先知道是 icon, 后知道是什么类型的， 现在是先知道类型，后知道， 哦， 是个icon~

@avalanche1 you can have a look at the bundle analysis result from this pr https://github.com/ant-design/ant-design/pull/18217#issuecomment-520683838, and the size of component Button declines clearly

Good to know. But on your screenshots there there is no indication of actual size, so I can neither confirm nor disprove.

I'm going to migrate Form to new APIs, but I found that the version of field-form is unstable, so I want to know whether it would get breaking changes with these interfaces now in the future.

@orzyyyy ,
antd release the 4.0-alpha.x version for social & internal volunteer to test it. If no negative feedback from alpha version, this api will be the final one on release.

@avalanche1 @ant-design/icons v4-alpha version supports tree-shaking, so the bundle size dependents on how much icons you used in your own project, whether you use antd component which import icons internally or you use @ant-design/icons directly, so maybe I couldn't understand your concern about this point.

Why are we talking about icons when my initial post was about Button, Calendar and other components? https://github.com/ant-design/ant-design/issues/9419

DatePicker value must be moment, can be remove moment? If i update the from, I must convert to moment

For the moment, here is my consideration. DatePicker still use moment by default since compatibility requirement, but it provides the factory function to create with other date lib:

import DatePicker, { createPicker } from 'antd/lib/date-picker';

import dayjs from 'dayjs';

const basicDemo = <DatePicker />

const MyDatePicker = createPicker(dayjs, {
  // Some proxy function, maybe can provided by default...
  format(dayObj, formatStr) {
    return ...;
  },
  parse(str, formatStr) {
    return ...;
  },
});

const dayDemo = <MyDatePicker />;

Just thought, welcome discussion.

Now is the time to get rid of moment.js !

1. Moment.js will never be tree-shakable due to it's complex OOP API. (They'd need to re-write it from scratch). It's a huge overhead for antd and users.

2. Ant Design v4 is a major release with breaking changes already. Now is the time!

3. I suggest not to replace it with another library. Antd might use something small like dayjs or date-fns internally but it should accept native Date objects or strings for its components.

Every time you call moment(), a puppy dies..

:dog:

@zombieJ 想了解Table组件的进展如何了，有没有像Form一样的预览版可以使用？快被合计搞到吐血了😂

Does the alpha version include the new Table already? If so, the preview website should contain an example of it?

Table is in the queue, currently I'm working on the virtual list.

What about the styled-components support?

Form initialValues don't set moment. https://github.com/react-component/field-form/blob/master/src/interface.ts#L7

希望 Form 可以提供非受控版本，以解决那种类似 Excel 的大表单性能问题

Any chance the alpha documentation could be moved to the regular Ant documentation site?

My employer blocks Netlify domains and I assume others might as well.

Any concrete plan to support keyboard operation over Menu and Dropdown?

Any chance the alpha documentation could be moved to the regular Ant documentation site?

My employer blocks Netlify domains and I assume others might as well.

why? lol

It is hoped that the Table component will resemble Element's Table component. Each column will automatically set a width first. It is suggested that the header character of the table be changed to min-width instead of line-changing. It is hoped that the folding and scrolling functions can be used simultaneously. It is hoped that the tree-shaped table will resemble TreeSelect when multiple choices are made.

希望Table组件能像Element的Table组件，每列自动先设置一个宽度，表格头部字符不换行建议改成min-width,希望折叠功能和滚动功能能同时使用，希望树形表格在多选的时候，能像TreeSelect类似

Any chance that with v4 or maybe v5 you will do something about customization? MaterialUI is much easier to customize which keeps making it a choice for the project which I am working on, even if I would really like to use AntD as it is much more complete etc.
Please, please drop less for something better for customization.

After letting an agency test our antd web app, they identified serious accessibility flaws and we got the worst grade possible. When investigating the main reasons, it boils down to the following rc-components:

• rc-select (we had to replace with Downshift and apply antd styles on top)
• rc-tabs (see #18798)
• and maybe others we do not use so far

How big of a governance does antd have over rc-components and would the team be able to fix this in a timely manner for the 4.0 release? Accessibility will always be relatively deprioritized, but the truth is, it is increasingly harder to ignore it as enterprises become legally bound to provide accessible apps to the employees/customers.

You can count me in on some heavy testing with screen readers and benchmarking against best practices.

MaterialUI is much easier to customize

@murbanowicz could you elaborate ? I'm curious why you think that.

@abenhamdine No problem!
In MUI there is a ThemeProvider which you wrap your app in and you configure whole theme just by the JS object which is typed in TypeScript so it's so nice to work with.

In AntD to customize you have to mess with LESS or SASS (with some plugins) so you have to maintain other deps etc, you have to go through the components source to find variable which you want to change for specific component etc.
Also, there is no good way of changing the theme in runtime which is so easy with MUI, just by switching JS object which can be easily sourced from the server etc.

Basically when you look for customization of AntD and MUI, you find easy examples on MUI because there is nothing to talk about as it is straight forward, but when you google for AntD cusotmization, you find a lot of hacky solutions etc.

I love AntD for completnes and so many great components, but customization is really bad and based on my experience and talking to other developers it should be one of the key points on the roadmap

@abenhamdine No problem!
In MUI there is a ThemeProvider which you wrap your app in and you configure whole theme just by the JS object which is typed in TypeScript so it's so nice to work with.

In AntD to customize you have to mess with LESS or SASS (with some plugins) so you have to maintain other deps etc, you have to go through the components source to find variable which you want to change for specific component etc.
Also, there is no good way of changing the theme in runtime which is so easy with MUI, just by switching JS object which can be easily sourced from the server etc.

Basically when you look for customization of AntD and MUI, you find easy examples on MUI because there is nothing to talk about as it is straight forward, but when you google for AntD cusotmization, you find a lot of hacky solutions etc.

I love AntD for completnes and so many great components, but customization is really bad and based on my experience and talking to other developers it should be one of the key points on the roadmap

clear and precise explanation, thx !

@abenhamdine No problem!
In MUI there is a ThemeProvider which you wrap your app in and you configure whole theme just by the JS object which is typed in TypeScript so it's so nice to work with.

In AntD to customize you have to mess with LESS or SASS (with some plugins) so you have to maintain other deps etc, you have to go through the components source to find variable which you want to change for specific component etc.
Also, there is no good way of changing the theme in runtime which is so easy with MUI, just by switching JS object which can be easily sourced from the server etc.

Basically when you look for customization of AntD and MUI, you find easy examples on MUI because there is nothing to talk about as it is straight forward, but when you google for AntD cusotmization, you find a lot of hacky solutions etc.

I love AntD for completnes and so many great components, but customization is really bad and based on my experience and talking to other developers it should be one of the key points on the roadmap

I agree with @murbanowicz that customization with Antd can get a bit messy (global style leaking, hacky way of using Sass, priority conflicts between style overrides, quite a lot of external dependencies such as moment leading to huge bundle size), but having used MUI for a long time, I find Antd a lot more customizable.

I am not up to date to MUI's new releases, but last time I checked, there were part of components that you were unable to customize, since MUI uses styled-components, if the developpers did not add classNames everywhere, you couldn't just select the component's exact className and override it with your own style.
Theming is cool for direct usage of a library, but if you want to adapt styling to your design system, it's very messy with MUI, sometimes even impossible ;)

But still, antd indeed needs some work to make the customization experience easier ;)

@filipjnc,
rc-select released alpha version which enhance the accessibility. You can help to test on that. And v4 prepare branch has used it you can see preview on the top.
For rc-tabs, since it's not on the top priority, I will enhance it also but later.

@zombieJ alright, I will take a look at rc-select alpha.

Even though rc-tabs is not a priority, can you please have a look at my pull request, where I fix the most critical points from our accessibility test results?

我这边有个问题，按照目前icon的改法，如果存在antd的组件form和icon的
form同时引入的情况是不是只能给其中一个别名

@zkwolf 对的，我们正在给 icon 做重命名：https://github.com/ant-design/ant-design-icons/pull/118

cc @vagusX

I would very much want that the issue with constant Form re-rendering is addressed

Pleae note that on https://next.ant.design Components are not sorted alphabetically in component sidebar

As you might know, ant-design is not doing really well in terms of accessibility. This is not too visible on the surface for the majority of people, but is a big issue when you dive deeper. See how ant-design is scoring pretty badly here: https://darekkay.com/blog/accessible-ui-frameworks/

The good news is, since I love ant-design a lot and I indend to use it further for enterprise projects, my goal is to bring it to the top of the list.

I let an agency test one of my enterprise apps for a client in Germany (where accessibility is a huge topic in big firms). The most critical things were:

1. Screen reader accessibility for basic but crucial components like Select, Autocomplete and Tabs
2. Color contrasts in many places
3. Keyboard navigation in some places

I picked rc-tabs first as a quick-win to fix all of its accessibility issues -- it should be out soon (https://github.com/react-component/tabs/pull/218). But what worries me most is rc-select, especially the combobox (autocomplete) part of it. Comboboxes are one of the most tricky aspects of screen reader accessibility and it's easy to get it wrong. To fix all of the issues it requires not only some tweaks to aria properties but rather a big overhaul.

To fix it quickly in my application before go-live, I've replaced ant-design's Select and AutoComplete (rc-select) with my own components based on https://github.com/downshift-js/downshift. I just replicated the ARIA best practices and applied antd styles on top -- looks almost exactly the same and it's perfectly accessible.

So the provocative question is: would you consider not doing the double-work and deprecate rc-select in favour of the more popular and complete downshiftlibrary? You could save some time in the team and focus on perfecting the other core components, which do not have good alternatives on the open-source market.

This idea looks fantastic to me @filipjnc . Also, downshift it's 1/4 of the size of rc-select. I hope the antd team can do this.

I would love to see more colors improvements in the 4.0 release. Specifically, the docs mention a “Data Visualization Color Palette (Coming soon)” that would be very helpful in dashboards and other data heavy applications. Warm and cool greys would help build more cohesive color palettes as well. Plus, it's a good opportunity to fix color contrast for accessibility (as mentioned by @filipjnc). Keep up the good work 👍

As you might know, ant-design is not doing really well in terms of accessibility. This is not too visible on the surface for the majority of people, but is a big issue when you dive deeper. See how ant-design is scoring pretty badly here: https://darekkay.com/blog/accessible-ui-frameworks/

The good news is, since I love ant-design a lot and I indend to use it further for enterprise projects, my goal is to bring it to the top of the list.

I let an agency test one of my enterprise apps for a client in Germany (where accessibility is a huge topic in big firms). The most critical things were:

1. Screen reader accessibility for basic but crucial components like Select, Autocomplete and Tabs

2. Color contrasts in many places

3. Keyboard navigation in some places

I picked rc-tabs first as a quick-win to fix all of its accessibility issues -- it should be out soon (react-component/tabs#218). But what worries me most is rc-select, especially the combobox (autocomplete) part of it. Comboboxes are one of the most tricky aspects of screen reader accessibility and it's easy to get it wrong. To fix all of the issues it requires not only some tweaks to aria properties but rather a big overhaul.

To fix it quickly in my application before go-live, I've replaced ant-design's Select and AutoComplete (rc-select) with my own components based on https://github.com/downshift-js/downshift. I just replicated the ARIA best practices and applied antd styles on top -- looks almost exactly the same and it's perfectly accessible.

So the provocative question is: would you consider not doing the double-work and deprecate rc-select in favour of the more popular and complete downshiftlibrary? You could save some time in the team and focus on perfecting the other core components, which do not have good alternatives on the open-source market.

I wouldn't be so enthusiastic about downshift, see https://github.com/downshift-js/downshift/issues/730
Accessibility is important for some users, but performance is important for even more users.

Table is in the queue, currently I'm working on the virtual list.

hi, @zombieJ
Is there any progress in Summary Footer?

@alexchen1875,
Pending on new lifecycle code update. Table is the next after done : )

4.0 能把一些 props 参数改成驼峰式吗？比如 Input.TextArea 里面的 autosize 改成 autoSize？
原生 HTML 的标签在 React 里的 props 都是驼峰式的，比如 <input autoComplete />，这个 autosize 看着总是不和谐。。。

3.x 里就能改，兼容并废弃原来的用法即可。@jinliming2 有没有兴趣来个 PR？

• 4.0 为啥把Tree的 props.children 标记为过时的api, 转而推荐treeData这种纯数据的方式了， 感觉 props.children 这个很好用，可玩性很高
• react 最新的 api 中已经将 componentWillReceiveProps 标记为过时， 目前试用时发现 table 组件和Animate组件还存在

+1 for accessibility. Please!

说起来，关于clear图标大小的问题，好像其他组件的图标是12px,datepicker是14px，这里是有其他组件clear和后缀图标大小区别的考量还是因为datepicker是图标切换就14px了？有没有统一一下大小的打算

@zombieJ 计划添加Table 多列排序的功能吗

pls write on English

moment size 太大的问题会被修复吗？

moment size 太大的问题会被修复吗？

试试先用 dayjs 吧

可不可以 in English ，考虑考虑老外的感受，我都是 google translate，语法标不标准不重要，单词对他们就看的懂

@afc163
Have you considered that foreigners people are following this repo? Unfortunately, Google Translate is not a good tool to understand what you are saying. I realize that most of the developers and users of Ant-Design are Chinese, but do you consider non-Chinese as well?
Therefore, I urge you to use the international language to respect all of us.

Hi,
I wanted to try Ant Design 4.0 with create-react-app and Typescript.
I followed the instruction on https://next.ant.design/docs/react/introduce but can't get a working app.
Followed basic instruction (import Button from 'antd/es/button';) for create-react-app causes error:

cannot find module antd/es/button

After add react-app-rewired, customize-cra, babel-plugin-import and changing import to import {Button} from 'antd' I get error message:

Could not find a declaration file for module 'antd'

Can you give me advice on how to make antd4 work with crea-react-app and typescript, please?

@gynekolog,
Please check if node_modules installed correctly.

ref https://codesandbox.io/s/cool-paper-4y1u7

@lvlohammadi Unfortunately, some Chinese people like me are not good enough in English, but I will try my best to use the international language to participate in community communication.

@gynekolog,
Please check if node_modules installed correctly.

ref https://codesandbox.io/s/cool-paper-4y1u7

You're right. I run

yarn add "https://github.com/ant-design/ant-design.git#4.0-prepare"

instead

yarn add "[email protected]"

Shame...
Thank you.

dropdownMatchSelectWidth on Select component break on alpha version, 在之前的版本是生效的

If I'm to start a new project using antd, would you choose version 3 or 4 alpha? How "production ready" is the version 4? Do you still aim for a q4 release?

If I'm to start a new project using antd, would you choose version 3 or 4 alpha? How "production ready" is the version 4? Do you still aim for a q4 release?

Antd 4 is not production ready yet. You should start with antd 3, transition should be easy (notably if codemods are provided as expected).

I hope to see a complete separation between logic and display, that is, other than manipulating class names, js does nothing else to the view. Visual appearance should all be handled by CSS (LESS). Also, instead of React Components, maybe use Web Components so non-React developers could use it more easily.

I hope to see a complete separation between logic and display, that is, other than manipulating class names, js does nothing else to the view. Visual appearance should all be handled by CSS (LESS). Also, instead of React Components, maybe use Web Components so non-React developers could use it more easily.

I think this idea to purify everything is pointless. It's better to focus on something more important.

Any plans for multi-select in AutoComplete, like https://react-select.com?

I hope to see a complete separation between logic and display, that is, other than manipulating class names, js does nothing else to the view. Visual appearance should all be handled by CSS (LESS). Also, instead of React Components, maybe use Web Components so non-React developers could use it more easily.

I think this idea to purify everything is pointless. It's better to focus on something more important.

I don't think there's more pressing matter than the separation. In a team, CSS is generally handled by designers, whereas JS is usually by coders. Allowing both to manipulate the style will lead to chaos and unnecessarily lost development time.

Take Menu for example, default width and height are set by JS, problem is, when someone wants to change outter wrapper's width or height, the menu would either stick out or having gaps around. This would require both the designer and the coder to fix, which means downtime.

Also, as components, the code is not overly complex, separation should not take too much an effort, but the result would make life much easier for users, and the ant.design team itself.

Another small issue, Icon needs to default to 16px, not 14px, which is the global default font size. This means Icon should use variables like @default-icon-size, @icon-size-lg, etc., separate from text. This is not really a bug, but a feature lost.

@afc163
Have you considered that foreigners people are following this repo? Unfortunately, Google Translate is not a good tool to understand what you are saying. I realize that most of the developers and users of Ant-Design are Chinese, but do you consider non-Chinese as well?
Therefore, I urge you to use the international language to respect all of us.

People are entitled to use their own language and should feel comfortable doing so, and as much as I respect the effort to involve the largest audience possible by provide translations, no one should be given a lecture just for using the language he's most comfortable with and that the maintainer understands to communicate. The idea that major contributors on this project should not use their native language to communicate for that some other language is superior is beyond absurd. It's ok to ask for translations, but with respect. To downvote responses because they are in Chinese is both counter-productive and childish.

Dudes, Does And Design version 4.0 have JSS instead of _Less_ for generating CSS?

Dudes, Does And Design version 4.0 have JSS instead of _Less_ for generating CSS?

AFAIK, no. But you can try to use styled-components (for instance) in addition to less.

Thanks, dear @tomgao365, I create the issue that you referenced it. I wanna make a great PR for removing Less completely and use JSS instead in. working on version 3 is not a Good Idea, because many projects were made by using version 3, so I decided to work on implementing JSS on version 4.

Also, I have a little question, dear @abenhamdine, what's your idea about using JSS instead of using Less?

Also, I have a little question, dear @abenhamdine, what's your idea about using JSS instead of using Less?

Main benefits according to me :

• dynamic styling (pain with less)
• autocompletion (not sure for that one, depend on which tooling/JSS library you use)
• inheritance of styles

worth to try.
But it' not a silver bullet.

Dear @abenhamdine, I leave an issue that got Discussion badge. It's #19181.

And I want to start to implement JSS and omit Less but a new version is coming and I afraid all of my efforts will be wasted.

Glad to see a discussion about replacing moment.js to some alternative like Day.js or native Date Object here https://github.com/ant-design/ant-design/issues/19738

Will there be an easier way to change the color themes using create-react-app in version 4?

I agree with @flashtheman that overriding the theme without requirement of working with less variables would be nice - i.e. something like ThemeProvider from emotion: https://emotion.sh/docs/theming

In the jQuery era, theme settings are very popular and users like to use it.
I have waited for an easy way to modify the theme in the production environment for more than 2 years.

在新版的icon组件中，如果icon是动态确定的，那在新版中应该如何处理，暂时只能想到用require+变量字符串，原来只需要用变量填充type属性即可，有什么其他处理方法吗？
google translate：In the new version of the icon component, if the icon is dynamically determined, then how to deal with it in the new version, for the time being can only think of the require + variable string, the original only need to fill the type attribute with variables, what other processing methods?

在新版的icon组件中，如果icon是动态确定的，那在新版中应该如何处理，暂时只能想到用require+变量字符串，原来只需要用变量填充type属性即可，有什么其他处理方法吗？
google translate：In the new version of the icon component, if the icon is dynamically determined, then how to deal with it in the new version, for the time being can only think of the require + variable string, the original only need to fill the type attribute with variables, what other processing methods?

试试用 React 文档里推荐的 https://github.com/smooth-code/loadable-components

什么时候发布正式版呀

4.0 Table有支持Pivot功能吗？

@afc163 - Seems like the global style pollution is the number 1 issue folks want with a new release. Do you have someone to work on this? I would be happy to do this work and help. It should not be hard, just will take some effort. I also suffer from this problem with Ant Design. I'd like to resolve it.

Is there any work being done on reducing component size?
For once: why if I want a simple Button- I have to import the whole of antd.css file??

Is there any work being done on reducing component size?
For once: why if I want a simple Button- I have to import the whole of antd.css file??

@avalanche1 Refer to https://ant.design/docs/react/introduce#Usage

Use modularized antd

我来说一个上传组件对于目前对于支持自定义列表渲染支持不够.
另外上传进度只有百分比,而且也不方便扩展以支持实时速度的显示.

@banxi1988

https://github.com/ant-design/ant-design/blob/c824569ea0810e2cf11bc2953b333eb0e404fd1c/components/upload/interface.tsx#L47-L52

If want a speed display, onChange has returned the percentage of the file that has been uploaded. You can calculate the upload speed.

@Z3SA https://caniuse.com/#search=CSS%20Variables. This needs to stop all IE support, stop IE11 support is too radical, although I also support doing that.

You could still do this with fallback support. Ex: color: var(--red, @red); A simple global find/replace for all current variables would solve for this.

Is dropping LESS in favor of SASS or other better styling solution being considered for v4 or not?

@murbanowicz , Hi, thanks for your comment, I leave an issue about using JSS instead of Less and here, I show my readiness about this migration but no one shows any actions.

Hi @zombieJ, thank you for your great work on Ant Design? Is there any plans to provide an out of the box way to toggle dark theme in the application?

关于 form 组件的一个建议：
非常高兴看到在新的4.0版本中，form 组件将会对开发人员更友好。我看到新的示例，Form 组件下面的Form.Item 组件将不再需要使用getFieldDecorator 。这是一个非常好的改进，但是我有一个一个更激进的建议：移除 Form.Item 组件，进一步优化代码的编写体验，让编码更清爽。而 Form.Item 组件的原有功能直接下放到具体的输入组件（如：Input、DataPick等）中。
这样做是考虑到大部分情况下开发的表单，使用的都是 antd 内置的输入组件，具备条件通过增强输入组件的能力来实现 Form.Item 组件的功能；而对于少部分特殊情况（如用户自定义组件、某个输入组件不希望通过 Form 进行绑定），可以专门提供特殊的包装组件来进行指示。
对 antd 的研究不深，仅从普通的使用者角度提出上诉建议，如有不妥，请海涵。

关于 form 组件的一个建议：
非常高兴看到在新的4.0版本中，form 组件将会对开发人员更友好。我看到新的示例，Form 组件下面的Form.Item 组件将不再需要使用getFieldDecorator 。这是一个非常好的改进，但是我有一个一个更激进的建议：移除 Form.Item 组件，进一步优化代码的编写体验，让编码更清爽。而 Form.Item 组件的原有功能直接下放到具体的输入组件（如：Input、DataPick等）中。
这样做是考虑到大部分情况下开发的表单，使用的都是 antd 内置的输入组件，具备条件通过增强输入组件的能力来实现 Form.Item 组件的功能；而对于少部分特殊情况（如用户自定义组件、某个输入组件不希望通过 Form 进行绑定），可以专门提供特殊的包装组件来进行指示。
对 antd 的研究不深，仅从普通的使用者角度提出上诉建议，如有不妥，请海涵。

@shengliangli 感觉耦合性太强了吧。。。

关于 form 组件的一个建议：
非常高兴看到在新的4.0版本中，form 组件将会对开发人员更友好。我看到新的示例，Form 组件下面的Form.Item 组件将不再需要使用getFieldDecorator 。这是一个非常好的改进，但是我有一个一个更激进的建议：移除 Form.Item 组件，进一步优化代码的编写体验，让编码更清爽。而 Form.Item 组件的原有功能直接下放到具体的输入组件（如：Input、DataPick等）中。
这样做是考虑到大部分情况下开发的表单，使用的都是 antd 内置的输入组件，具备条件通过增强输入组件的能力来实现 Form.Item 组件的功能；而对于少部分特殊情况（如用户自定义组件、某个输入组件不希望通过 Form 进行绑定），可以专门提供特殊的包装组件来进行指示。
对 antd 的研究不深，仅从普通的使用者角度提出上诉建议，如有不妥，请海涵。

@shengliangli 感觉耦合性太强了吧。。。

我认为 Form.Item 是 antd 为了实现 Form 组件数据绑定功能而“额外” 增加的一个组件，本身这样实现固然有原因，但是终归是增加了一个额外的东西。就像大家诟病 redux 的模式化代码太多的问题一样，开发人员可能也并不喜欢这样的写法。如果能够把 form.item 实现的数据绑定的功能理解为 Input 这样的输入组件应该具有的特质，从而增强 输入组件的能力，是不是感觉更自然一些。

耦合性的问题我也想了一下，问题的根源可能还在于我们如何定义输入组件的能力和行为特征。

关于 form 组件的一个建议：
非常高兴看到在新的4.0版本中，form 组件将会对开发人员更友好。我看到新的示例，Form 组件下面的Form.Item 组件将不再需要使用getFieldDecorator 。这是一个非常好的改进，但是我有一个一个更激进的建议：移除 Form.Item 组件，进一步优化代码的编写体验，让编码更清爽。而 Form.Item 组件的原有功能直接下放到具体的输入组件（如：Input、DataPick等）中。
这样做是考虑到大部分情况下开发的表单，使用的都是 antd 内置的输入组件，具备条件通过增强输入组件的能力来实现 Form.Item 组件的功能；而对于少部分特殊情况（如用户自定义组件、某个输入组件不希望通过 Form 进行绑定），可以专门提供特殊的包装组件来进行指示。
对 antd 的研究不深，仅从普通的使用者角度提出上诉建议，如有不妥，请海涵。

@shengliangli 感觉耦合性太强了吧。。。

我认为 Form.Item 是 antd 为了实现 Form 组件数据绑定功能而“额外” 增加的一个组件，本身这样实现固然有原因，但是终归是增加了一个额外的东西。就像大家诟病 redux 的模式化代码太多的问题一样，开发人员可能也并不喜欢这样的写法。如果能够把 form.item 实现的数据绑定的功能理解为 Input 这样的输入组件应该具有的特质，从而增强 输入组件的能力，是不是感觉更自然一些。

耦合性的问题我也想了一下，问题的根源可能还在于我们如何定义输入组件的能力和行为特征。

不是特别同意，我认为 Form.Item 主要还是一个组件的外部包装，比如 label 和 column 之类的属性，确实不适合 inline 到组件里。

Hi @zombieJ
Interested to know when version 4 will be out?
Looking forward to hearing back

How do I contribute to the design too.
Looking to hear from someone

beta.0版本了，意味着可以开始用了吗？

关于 form 组件的一个建议：
非常高兴看到在新的4.0版本中，form 组件将会对开发人员更友好。我看到新的示例，Form 组件下面的Form.Item 组件将不再需要使用getFieldDecorator 。这是一个非常好的改进，但是我有一个一个更激进的建议：移除 Form.Item 组件，进一步优化代码的编写体验，让编码更清爽。而 Form.Item 组件的原有功能直接下放到具体的输入组件（如：Input、DataPick等）中。
这样做是考虑到大部分情况下开发的表单，使用的都是 antd 内置的输入组件，具备条件通过增强输入组件的能力来实现 Form.Item 组件的功能；而对于少部分特殊情况（如用户自定义组件、某个输入组件不希望通过 Form 进行绑定），可以专门提供特殊的包装组件来进行指示。
对 antd 的研究不深，仅从普通的使用者角度提出上诉建议，如有不妥，请海涵。

首先你要知道这和内不内置没有关系，用所谓的内置组件可以说是一种偶然
getFieldDecorator是连接form组件和input组件的桥梁 form.item传入value和onChange两个属性，然后被wrap的组件通过value和onChange这两个接口方法和外部交互。换句话说，任何组件只要implement了value和onChange就都可以成为getFieldDecorator的参数。这是典型的program to interface的思想

PS：我没有看过源码，以上全部是我看完文档猜的

The reason why Form.Item can interact with the underlying Component has nothing to do with some 'build-in' mechanism as someone expects. It just a common trick in the programming world called program to interface

Basically, the Form Component and the underlying Component agree on something like value and onChange. They serve as the interface between the two worlds in order to communicate. It is a good design for the purpose of decoupling

@dancerphil Maybe you can clarify the idea more explicitly on the official documentation

Hi all, v4 beta is released. API is stable now which means no breaking change on API unless critical issue happened. During beta version, designers will help on continue UI visual design adjustment and we will focus on bug fix. Please feel free to try on and help us for fire bug or feed back.

Thanks for everyone participate in coding & trying. Your help means a lot : )

大家好，beta 版本已经发布。API 如果没有重大设计问题，不会再进行变动。在 beta 版本中，设计师会协助对 v4 的 UI 样式进行调整，而我们会聚焦在 bug 修复。欢迎使用来帮助我们找 bug 或者有任何其他反馈。

感谢大家参与开发和试用工作。你们的帮助意义非凡 : )

ref: http://new-issue.ant.design/

How do I contribute to the design too.
Looking to hear from someone

@ekeminimarkk001 maybe refer: https://ant.design/docs/react/contributing

@zombieJ Have all changes listed in the issue been implemented in the beta version?

关于 form 组件的一个建议：
非常高兴看到在新的4.0版本中，form 组件将会对开发人员更友好。我看到新的示例，Form 组件下面的Form.Item 组件将不再需要使用getFieldDecorator 。这是一个非常好的改进，但是我有一个一个更激进的建议：移除 Form.Item 组件，进一步优化代码的编写体验，让编码更清爽。而 Form.Item 组件的原有功能直接下放到具体的输入组件（如：Input、DataPick等）中。
这样做是考虑到大部分情况下开发的表单，使用的都是 antd 内置的输入组件，具备条件通过增强输入组件的能力来实现 Form.Item 组件的功能；而对于少部分特殊情况（如用户自定义组件、某个输入组件不希望通过 Form 进行绑定），可以专门提供特殊的包装组件来进行指示。
对 antd 的研究不深，仅从普通的使用者角度提出上诉建议，如有不妥，请海涵。

首先你要知道这和内不内置没有关系，用所谓的内置组件可以说是一种偶然
getFieldDecorator是连接form组件和input组件的桥梁 form.item传入value和onChange两个属性，然后被wrap的组件通过value和onChange这两个接口方法和外部交互。换句话说，任何组件只要implement了value和onChange就都可以成为getFieldDecorator的参数。这是典型的program to interface的思想

PS：我没有看过源码，以上全部是我看完文档猜的

看了各位的回复，不得不说我对 antd 的 form 组件的建议不是太成熟，但是另一方面，提出这个建议也完全是从一个普通用户的角度出发在思考问题。对于一个使用强度如此之高的组件来说，如何能够更便利开发使用，写更少的代码，使用更清晰和自然的表达方式，是我对 antd 的殷切期望。

从使用者的角度，antd 已经非常优秀了，绝大部分的组件都能够做到拿来就用，用完就忘，下次想用，还能拿来就用。之所以能够达到这种效果，是同组件良好的 api 设计和封装分不开的，但是还有部分组件（比如 from、table）的使用场景，还有更好的提升的空间。

antd 只是工程中的一个工具组件，最好是不暴露自己的实现机制，或者说把实现机制巧妙地隐藏和同化在对外的 api 中。用户只是想用这个组件，想用最方便的形式，最自然的形式去使用，而不想成为某个工具组件的专家。

回到 form 组件，在现今 3.x 的 api 下，我其实更多地愿意使用阿里系的 uform，相比于 antd 的 form， uform 需要写的代码更少，生产效率更高。当然，uform 感觉更像是一个声明式的写法， 这点和 antd 的 form 差别很大，可能没有太多借鉴的价值。

作为 antd 的伸手党来说，提这么多要求确实有点不好意思，但是正因为热爱，所以才希望它更好，希望项目组理解，也希望能够在合适的版本下，进一步优化组件的开发使用体验。

很奇怪。我完全没有使用Icon，但是打包时却将icons-svg全部打包进来了。

版本号：4.0.0-beta.0。使用了babel-plugin-import和tree-shaking，但是也没有什么用。

很奇怪。我完全没有使用Icon，但是打包时却将icons-svg全部打包进来了。

版本号：4.0.0-beta.0。使用了babel-plugin-import和tree-shaking，但是也没有什么用。

Use this config

{
                    test: /\.js?$/,
                    include: [/node_modules[\\\\/]antd/],
                    use: [
                        {
                            loader: 'babel-loader',
                            options: {
                                plugins: [
                                    '@babel/plugin-syntax-dynamic-import',
                                    [
                                        'import',
                                        {
                                            libraryName: 'antd',
                                            style: true,
                                            libraryDirectory: 'es',
                                        },
                                        'ant',
                                    ],
                                    [
                                        'import',
                                        {
                                            libraryName: '@ant-design/icons',
                                            customName: name => {
    const formatName = name.split('-').reduce((acum, value) => acum + value[0].toUpperCase() + value.slice(1), '');

    return `@ant-design/icons/lib/icons/${formatName}`;
};
                                        },
                                        '@ant-design/icons',
                                    ],
                                ],
                            },
                        },
                    ],
                },

很奇怪。我完全没有使用Icon，但是打包时却将icons-svg全部打包进来了。

版本号：4.0.0-beta.0。使用了babel-plugin-import和tree-shaking，但是也没有什么用。

Use this config

{
                    test: /\.js?$/,
                    include: [/node_modules[\\\\/]antd/],
                    use: [
                        {
                            loader: 'babel-loader',
                            options: {
                                plugins: [
                                    '@babel/plugin-syntax-dynamic-import',
                                    [
                                        'import',
                                        {
                                            libraryName: 'antd',
                                            style: true,
                                            libraryDirectory: 'es',
                                        },
                                        'ant',
                                    ],
                                    [
                                        'import',
                                        {
                                            libraryName: '@ant-design/icons',
                                            customName: name => {
    const formatName = name.split('-').reduce((acum, value) => acum + value[0].toUpperCase() + value.slice(1), '');

    return `@ant-design/icons/lib/icons/${formatName}`;
};
                                        },
                                        '@ant-design/icons',
                                    ],
                                ],
                            },
                        },
                    ],
                },

感谢您的回复，可是我按照您的配置并没有起作用。

版本： 4.0.0-beta.0
问题：Modal组件visible切换的时候页面会滚
复现地址：

• https://next.ant.design/components/form-cn/#components-form-demo-form-in-modal
  
  
  
  • https://next.ant.design/components/modal-cn/
  
  

@xiaoxintang It's fixed in the master branch, waiting for merge.

@afc163 我要怎么安装 antd4.0 beta

https://next.ant.design/ 挂了

@afc163 我要怎么安装 antd4.0 beta

npm install antd@next
OR
yarn add antd@next

It seems that the preview site is broken. I get only a Page Not Found error.

关于 form 组件的一个建议：
非常高兴看到在新的4.0版本中，form 组件将会对开发人员更友好。我看到新的示例，Form 组件下面的Form.Item 组件将不再需要使用getFieldDecorator 。这是一个非常好的改进，但是我有一个一个更激进的建议：移除 Form.Item 组件，进一步优化代码的编写体验，让编码更清爽。而 Form.Item 组件的原有功能直接下放到具体的输入组件（如：Input、DataPick等）中。
这样做是考虑到大部分情况下开发的表单，使用的都是 antd 内置的输入组件，具备条件通过增强输入组件的能力来实现 Form.Item 组件的功能；而对于少部分特殊情况（如用户自定义组件、某个输入组件不希望通过 Form 进行绑定），可以专门提供特殊的包装组件来进行指示。
对 antd 的研究不深，仅从普通的使用者角度提出上诉建议，如有不妥，请海涵。

可以试试这个：https://github.com/aweiu/ant-modifier

对于全局样式污染，有什么优化吗？

对于全局样式污染，有什么优化吗？

antd似乎都有前缀吧，算不上污染。自己的项目css代码可以尝试使用css-modules解决全局污染的问题

对于全局样式污染，有什么优化吗？

antd似乎都有前缀吧，算不上污染。自己的项目css代码可以尝试使用css-modules解决全局污染的问题

嗯这个前缀我知道，我是指全局css reset的那部分的污染，对在遗留项目中引入antd，css reset造成的污染问题

对于全局样式污染，有什么优化吗？

antd似乎都有前缀吧，算不上污染。自己的项目css代码可以尝试使用css-modules解决全局污染的问题

具体可以参看官网链接中issue的讨论：https://ant.design/docs/react/faq-cn#antd-%E8%A6%86%E7%9B%96%E4%BA%86%E6%88%91%E7%9A%84%E5%85%A8%E5%B1%80%E6%A0%B7%E5%BC%8F%EF%BC%81

求问 有Antd Pro 4.0 layout迁移Antd4.0的计划吗？
自己迁移项目的时候遇到 pro-layout 中 SiderMenu.js Icon.createFromIconfontCN错误
由于pro-layout里面依赖还是v3版本，本人小白不知道怎么改依赖，有懂的大神教一下

求问 有Antd Pro 4.0 layout迁移Antd4.0的计划吗？
自己迁移项目的时候遇到 pro-layout 中 SiderMenu.js Icon.createFromIconfontCN错误
由于pro-layout里面依赖还是v3版本，本人小白不知道怎么改依赖，有懂的大神教一下

由于icon在4.0里被分离出来了，需要修改import，你可以取next.ant.design看一下现在icon的api文档

Thanks all your contribution on v4 version. Close since 4.0.0-rc.0 version released: ref #20661

Is StrictMode a goal? Legacy context needs to be migrated https://github.com/ant-design/ant-design/issues/9870

https://github.com/ant-design/ant-motion/issues/272

Can we keep both antd3 and antd4 in the repo? Can't change everywhere as the repo is too big and it will be almost rewriting of complete codebase.
Also if yes, can we keep antd3 CSS in global and antd4 CSS for just some folder and it's children