Alex/use avatar

[WHChen-Alex]

依赖检查

组件之间的依赖声明，是微服务组件架构下的重要信息，请确保其正确性。

请勾选以下两组选项其中之一：

• 本次 MR 没有使用上游组件（例如框架、后台组件等）的较新版本提供的特性。

或者：

• 本次 MR 使用了上游组件（例如框架、后台组件等）的较新版本提供的特性。
• 在对应的文件中更新了该上游组件的依赖版本（或确认了当前声明的依赖版本已包含本次 MR 使用的新特性）。

提交信息检查

Git 提交信息将决定包的版本发布及自动生成的 CHANGELOG，请检查工作内容与提交信息是否相符，并在以下每组选项中都依次确认。

破坏性变更是针对于下游使用者而言，可以通过本次改动对下游使用者的影响来识别变更类型：

• 下游使用者不做任何改动，仍可以正常工作时，那么它属于普通变更。
• 反之，下游使用者不做改动就无法正常工作时，那么它属于破坏性变更。

例如，构件修改了一个属性名，小产品 Storyboard 中需要使用新属性名才能工作，那么它就是破坏性变更。
又例如，构件还没有任何下游使用者，那么它的任何变更都是普通变更。

破坏性变更：

• ⚠️ 本次 MR 包含破坏性变更的提交，请继续确认以下所有选项：
• 没有更好的兼容方案，必须做破坏性变更。
• 使用了 feat 作为提交类型。
• 标注了 BREAKING CHANGE: 你的变更说明。
• 同时更新了本仓库中所有下游使用者的调用。
• 同时更新了本仓库中所有下游使用者对该子包的依赖为即将发布的 major 版本。
• 同时为其它仓库的 Migrating 做好了准备，例如文档或批量改动的方法。
• 手动验证过破坏性变更在 Migrate 后可以正常工作。
• 破坏性变更所在的提交没有意外携带其它子包的改动。

新特性：

• 本次 MR 包含新特性的提交，且该提交不带有破坏性变更，并使用了 feat 作为提交类型。
• 给新特性添加了单元测试。
• 手动验证过新特性可以正常工作。

问题修复：

• 本次 MR 包含问题修复的提交，且该提交不带有新特性或破坏性变更，并使用了 fix 作为提交类型。
• 给问题修复添加了单元测试。
• 手动验证过问题修复得到解决。

杂项工作：

即所有对下游使用者无任何影响、且没有必要显示在 CHANGELOG 中的改动，例如修改注释、测试用例、开发文档等：

• 本次 MR 包含杂项工作的提交，且该提交不带有问题修复、新特性或破坏性变更，并使用了 chore, docs, test 等作为提交类型。

[coveralls]

Coverage decreased (-0.02%) to 86.989% when pulling ed7e52e on alex/useAvatar into d9fa7b3 on master.

[weareoutman]

我感觉这个更适合做成一个组件，而不是钩子

[WHChen-Alex]

我觉得做成钩子灵活点，有更多组合，可以不使用内置的Mention组件，只借助其搜索users的能力也可以自己拼出来类似Mention组件。

[weareoutman]

但你这个钩子已经集成了 Mention 组件，用户如果要自定义它，那么这里实际会额外渲染一个用不上的内置 Mention 组件，这是完全不需要的开销。要么你的钩子就不要自带 Mention 组件，另外封装一个组件来调用你的这个钩子，由这个组件去带上 Mention，而不是这个钩子。

[weareoutman]

我感觉有点过度设计了，如果现阶段没有明确需要复用它的地方，不用着急把它抽出来并把它做成一个非常抽象的接口，可以先在构件那边实现，需要复用的时候再拎出来。

[WHChen-Alex]

那打算放在哪个仓库？

不只是agile的comment构件，业务构件也有用到Mention，都是自己实现的，设计也许前后也不一样，我这样改也是有一个统一的标准，同时也不失灵活性。

[weareoutman]

那可以加一个 libs/user-components 吧，记得在实现上区分组件与钩子，不要把组件混到钩子里了。