小程序跨框架组件调用实践：高效实现时间区间选择功能

文
章
目
录

• 一、业务难题
• 二、技术方案
• （一）插件层：用Taro框架打造优质插件
• （二）业务层：将插件集成到Wepy框架小程序中
• 三、技术关键
• 四、方案优势：对比原生开发的显著成效
• 开发周期大幅缩短
• 维护成本降低
• 体验一致性更好
• 扩展性更强
• 五、未来规划

小程序开发过程经常会遇到各种各样的技术难题，尤其是当现有框架与新需求之间产生矛盾时，如何找到一个平衡的解决方案就显得尤为重要。今天，就来给大家分享一个在小程序场景下跨框架组件调用的实际案例，看看我们是如何巧妙解决业务问题的。

一、业务难题

当前有个小程序是基于Wepy框架开发的，为了满足业务需求，需要接入NutUI日历组件来实现时间区间选择的功能。但这一过程中，遇到了不少麻烦：

1. 框架代际差异明显：Wepy框架和现在主流的一些框架相比，存在一定的技术代差。这种代差使得在引入新组件时，可能会出现兼容性等一系列问题。
2. 开发成本超出预期：如果选择原生开发日历组件，预计需要耗费2周/人天的时间。这对于项目的迭代周期来说，时间成本实在是太高了，根本无法满足快速迭代的需求。
3. 用户体验要求苛刻：产品对用户体验的要求非常高，期望接入的NutUI日历组件能完美复现其原有的交互体验，让用户在使用过程中感觉流畅、自然。

面对这些问题，经过多方评估和研究，最终确定通过小程序插件体系实现跨框架组件调用，这样既能保证开发效率，又能兼顾用户体验。

二、技术方案

（一）插件层：用Taro框架打造优质插件

在插件层，我们选用Taro框架来开发。Taro框架的优势在于能够让我们更方便地开发出高质量的组件。具体代码如下：

// plugins/calendar/index.tsx
// 引入样式文件，用于设置日历组件的样式
import \"./calendar.less\";
// 从NutUI的React-Taro组件库中引入日历组件
import { Calendar } from \'@nascent/nutui-react-taro\'
// 引入NutUI图标库的样式文件
import \"@nascent/nutui-icons-react/libstyle.css\";

// 定义一个名为CalendarPlugin的函数组件，接收日历组件的属性props
const CalendarPlugin = (props: CalendarProps) => {
  // 将接收到的属性props传递给NutUI的日历组件，并返回该组件
  return <Calendar {...props} />;
}

// 将CalendarPlugin组件导出，以便在其他地方使用
export default CalendarPlugin;

这里有几个关键的配置要点：

• 采用独立的插件项目管理方式，这样可以让插件的开发、维护更加清晰、高效。
• 使用Taro框架进行开发，能有效保证组件的质量，同时利用Taro的跨端能力，为后续拓展打下基础。
• 完整继承NutUI的样式体系，确保日历组件的外观和交互与NutUI官方保持一致，满足用户体验要求。

（二）业务层：将插件集成到Wepy框架小程序中

1. 插件声明配置
   在Wepy框架的项目中，需要先对插件进行声明配置，具体代码如下：

// wepy.config.js
// 导出配置对象，用于配置Wepy项目的相关参数
module.exports = {
  // 配置插件相关信息
  plugins: {
    // 定义名为scrmMiniPlugin的插件
    scrmMiniPlugin: {
      // 插件版本号为0.0.6
      version: \'0.0.6\',
      // 插件提供者的标识，用于唯一确定插件来源
      provider: \'xxxxxxxxxxxxxxx\'
    }
  }
}

这个配置文件告诉Wepy框架，项目中要使用一个名为scrmMiniPlugin的插件，并且指定了插件的版本和提供者。

2. 页面组件接入
   完成插件声明后，接下来要在页面组件中接入插件，代码如下：

<template >
  <!-- 页面容器组件，同步导航配置，添加页面背景类名 -->
  <PageContainer :navConf.sync=\"navConf\" class=\"pageback\" >
    <!-- 引入日历组件，并将calendarprops属性传递给它 -->
    <calendar props=\"{{ calendarprops }}\"></calendar>
  </PageContainer>
</template>

<script>
// 引入Wepy框架核心模块
import wepy from \'wepy\';
// 引入自定义的页面容器组件
import PageContainer from \'@/components/PageContainer\';
// 定义名为TasksPage的页面组件类，继承自wepy.page
export default class TasksPage extends wepy.page {
  // 配置页面的导航栏标题、是否开启下拉刷新以及使用的组件
  config = {
    navigationBarTitleText: \'工作任务\',
    enablePullDownRefresh: false,
    usingComponents: {
      // 声明使用的日历组件来自名为scrmMiniPlugin的插件中的calendar组件
      calendar: \'plugin://scrmMiniPlugin/calendar\'
    }
  };
  // 定义页面组件的数据对象，初始化日历组件的属性
  data = {
    calendarprops: {},
  };
  // 页面加载时执行的函数，设置日历组件的初始属性
  onLoad(options) {
    this.calendarprops = {
      visible: false,
      defaultValue: [\'\', \'\'],
      startDate: \'1997-01-11\',
      endDate: endDate,
      type: \'range\',
      title: \'任务时间\',
      // 关闭日历组件时执行的回调函数，绑定当前页面实例的this指针
      onClose: this.onClose.bind(this),
      // 确认选择日期时执行的回调函数，绑定当前页面实例的this指针
      onConfirm: this.onConfirm.bind(this)
    };
  }
}
</script>

在这段代码中，通过usingComponents配置引入插件中的日历组件，并在onLoad函数中设置了日历组件的初始属性，包括是否可见、默认选中日期、日期选择范围等。

三、技术关键

实现跨框架组件调用，关键在于跨框架通信机制。在这个方案中，我们采用了以下方法：

• props传递：利用小程序原生的插件通道来传递组件的属性（props）。这样，业务层可以方便地将需要的参数传递给插件层的组件，实现对组件的个性化配置。
• 事件回调透传：对于组件的事件回调，比如用户点击确认日期的操作，通过函数引用的方式进行透传。这样，业务层可以在用户操作插件组件时，及时执行相应的业务逻辑。
• 数据格式统一：为了避免数据格式不一致带来的问题，建议统一使用YYYY-MM-DD这种日期格式。这样在数据传递和处理过程中，能减少很多不必要的麻烦。

四、方案优势：对比原生开发的显著成效

通过采用插件方案实现跨框架组件调用，和原生开发日历组件相比，优势非常明显，具体如下：

开发周期大幅缩短

插件方案主要的耗时集中在联调阶段，大概3天就能完成。而原生开发则需要10 – 14天，插件方案在开发效率上有了质的飞跃。

维护成本降低

插件是独立更新的，不会影响到业务代码。而原生开发时，如果组件有更新需求，就需要同步维护业务代码，增加了维护的复杂性和成本。

体验一致性更好

插件方案能够和NutUI官方的交互体验完全一致，最大程度满足了用户对体验的高要求。原生开发则存在还原差异的风险，可能无法完美呈现原组件的交互效果。

扩展性更强

插件可以复用至其他小程序项目，提高了代码的利用率。而原生开发的组件往往是单项目专用，无法在其他项目中直接使用。

五、未来规划

虽然目前的插件已经满足了时间区间选择的功能需求，但我们还有更长远的规划：

• 插件功能扩展：计划增加日期组件、地址组件等更多实用的组件，进一步丰富插件的功能，满足更多业务场景的需求。
• 插件页面新增：使用Taro框架开发更多的页面，提升插件的整体能力和可扩展性。

另外，有个特别提示需要大家注意：在微信开放平台审核时，要提前把插件添加到白名单，否则可能会导致审核受阻。建议预留3个工作日用于插件审核流程，避免影响项目进度。

通过这次在小程序场景下跨框架组件调用的实践，我们成功解决了业务中的难题，也为后续的小程序开发积累了宝贵的经验。希望这篇文章能对大家有所帮助，如果在实际开发中遇到类似问题，不妨参考一下这个方案。