相比Remax，Taro使用原生组件的方法太过于复杂

[yz1311]

这个特性解决了什么问题？

目前开发Taro最难的是什么，不是taro自带的一些问题，而是UI库

如果Taro-UI不再维护了，请关闭它或者标为 停止维护，不要让无数新人踏进同一个坑

所以UI库只能寄希望于原生的库(并不是所有人都有跨多端的需求),但是Taro引入库的方式太过于复杂，还得去配置webpack，每个页面都得引入，关键是还有巨坑

以下是使用Vant-Weapp的issues，还有很多没关闭

https://github.com/NervJS/taro/search?q=vant-weapp&type=issues

远不止官方的教程几句话就解决了

https://nervjs.github.io/taro/docs/mini-third-party

这个 API 长什么样？

无意中发现了remax的用法特别简单

import React from 'react';
import { View } from 'remax/ali';
import VantIcon from '@vant/weapp/lib/icon';
export default () => {
  const handleClick = () => {};
  return (
    <View>
      <VantIcon name="close" class-prefix="custom-class-prefix" bindclick={handleClick} />
    </View>
  );
};

不知道是否有坑，但这种用法的确方便很多，至少减少很多使用成本

[cxgreat2014]

确实如此

taro(ui)整体使用体验并不算好，简单来说将文档内的代码复制粘贴到项目中都会报一堆错，五分钟的上手视频华而不实，有本事先把文档内的东西安排清楚了再做别的扩展

[Chen-jj]

利用 webpack 的模块分析，可以追踪小程序原生模块，最后再正确处理页面的 usingComponents 配置。

猜想 Webpack Dependencies 配合 resolve 应该能分析出该 import 使用的是原生自定义组件，这部分逻辑 ok 的话是可以实现的。