[comp: badge]: feature badge component

[KnorienChang]

• I have searched the issues of this repository and believe that this is not a duplicate.

徽标组件

• 支持圆点徽标
• 支持数字徽标和自定义最大数字徽标
• 支持自定义徽标(组件徽标)

What problem does this feature solve?

徽标组件

What does the proposed API look like?

API

参数	说明	类型	全局配置
dot	圆点徽标	boolean	false
count	数值徽标的值	number|string	-
overflowCount	最大数值徽标的值，超出以${overflowCount}+显示	number|string	99
showZero	数值为0时是否显示	boolean	false
color	徽标的颜色，数值徽标和圆点徽标为设置背景色，组件徽标为字体颜色	hex|rgb?a	-

SLOTS

方法	说明
defalut	需要添加徽标的内容
count	自定义徽标

[danranVm]

@clfeng @danranVm 负责 review

[clfeng]

count的类型我们定义的是number和string；因此默认值给个特殊含义的number或者string会更为合理一些（而不是undefined），建议的话默认值给0；同时配合实现showZero的配置项体现其特殊含义；然后跟antd保持一致，如果是0默认不展示；类似的overflowCount可以给个默认值99，这个比较常见；

slot的话；我不是很理解为什么要有custom项；内容一般是用户自己去插入的；如果整个badge都自定义了，那么为什么还要用我们的这个Bage呢；业务里直接自己封装一个简单的就是了；所以建议给个默认插槽就好了；custome暂时不做考虑

[KnorienChang]

count的类型我们定义的是number和string；因此默认值给个特殊含义的number或者string会更为合理一些（而不是undefined），建议的话默认值给0；同时配合实现showZero的配置项体现其特殊含义；然后跟antd保持一致，如果是0默认不展示；类似的overflowCount可以给个默认值99，这个比较常见；

slot的话；我不是很理解为什么要有custom项；内容一般是用户自己去插入的；如果整个badge都自定义了，那么为什么还要用我们的这个Bage呢；业务里直接自己封装一个简单的就是了；所以建议给个默认插槽就好了；custome暂时不做考虑

1. 确实新增属性showZero，同时count默认值为有效值更合理
2. 具名slot的考虑主要是为了用户能够自定义badge内容，比如用户使用icon组件作为badge

[clfeng]

count的类型我们定义的是number和string；因此默认值给个特殊含义的number或者string会更为合理一些（而不是undefined），建议的话默认值给0；同时配合实现showZero的配置项体现其特殊含义；然后跟antd保持一致，如果是0默认不展示；类似的overflowCount可以给个默认值99，这个比较常见；
slot的话；我不是很理解为什么要有custom项；内容一般是用户自己去插入的；如果整个badge都自定义了，那么为什么还要用我们的这个Bage呢；业务里直接自己封装一个简单的就是了；所以建议给个默认插槽就好了；custome暂时不做考虑

1. 确实新增属性showZero，同时count默认值为有效值更合理
2. 具名slot的考虑主要是为了用户能够自定义badge内容，比如用户使用icon组件作为badge

用户自定义内容的话，使用默认插槽就已经能实现了；例如：
<bage><icon />chen</bage>
然后单纯数字
<bage>10</bage>
也可以通过配置实现：
<bage count="10" />;

我想你需要的也就是上面这三种使用方式；这个一个默认插槽处理就够了

[KnorienChang]

count的类型我们定义的是number和string；因此默认值给个特殊含义的number或者string会更为合理一些（而不是undefined），建议的话默认值给0；同时配合实现showZero的配置项体现其特殊含义；然后跟antd保持一致，如果是0默认不展示；类似的overflowCount可以给个默认值99，这个比较常见；
slot的话；我不是很理解为什么要有custom项；内容一般是用户自己去插入的；如果整个badge都自定义了，那么为什么还要用我们的这个Bage呢；业务里直接自己封装一个简单的就是了；所以建议给个默认插槽就好了；custome暂时不做考虑

1. 确实新增属性showZero，同时count默认值为有效值更合理
2. 具名slot的考虑主要是为了用户能够自定义badge内容，比如用户使用icon组件作为badge

用户自定义内容的话，使用默认插槽就已经能实现了；例如：
<bage><icon />chen</bage>
然后单纯数字
<bage>10</bage>
也可以通过配置实现：
<bage count="10" />;

我想你需要的也就是上面这三种使用方式；这个一个默认插槽处理就够了

badge的设计是一个wrapper包裹住需要添加badge内容的实现，解析出的DOM结构为

<span> // badge wrapper
  content
  <sup></sup> // 此处才为badge内容
</span>

所以，自定义badge内容需要具名实现

或者说有什么更好的实现建议呢，欢迎提出

[clfeng]

count的类型我们定义的是number和string；因此默认值给个特殊含义的number或者string会更为合理一些（而不是undefined），建议的话默认值给0；同时配合实现showZero的配置项体现其特殊含义；然后跟antd保持一致，如果是0默认不展示；类似的overflowCount可以给个默认值99，这个比较常见；
slot的话；我不是很理解为什么要有custom项；内容一般是用户自己去插入的；如果整个badge都自定义了，那么为什么还要用我们的这个Bage呢；业务里直接自己封装一个简单的就是了；所以建议给个默认插槽就好了；custome暂时不做考虑

1. 确实新增属性showZero，同时count默认值为有效值更合理
2. 具名slot的考虑主要是为了用户能够自定义badge内容，比如用户使用icon组件作为badge

用户自定义内容的话，使用默认插槽就已经能实现了；例如：
<bage><icon />chen</bage>
然后单纯数字
<bage>10</bage>
也可以通过配置实现：
<bage count="10" />;
我想你需要的也就是上面这三种使用方式；这个一个默认插槽处理就够了

badge的设计是一个wrapper包裹住需要添加badge内容的实现，解析出的DOM结构为

<span> // badge wrapper
  content
  <sup></sup> // 此处才为badge内容
</span>

所以，自定义badge内容需要具名实现

或者说有什么更好的实现建议呢，欢迎提出

了解，这样的话确实是应该有两个插槽，区分开来