Polymer 2.0中工具类Mixin与全局JS工具库的选型疑问

嘿，这个问题在Polymer项目里挺典型的，我来帮你梳理两种方案的利弊，再给你针对性的建议～

先说说继续用Mixin的情况 #

优点： #

• 贴合Polymer的组件化思路：如果你的工具函数未来有可能和组件实例产生关联（比如某个日期工具需要读取组件的时区配置），Mixin能自然地把工具能力和组件上下文绑定起来，扩展性更好。
• 依赖清晰：看元素的继承链就能直接知道它用到了哪些工具，维护的时候不用猜依赖来源。
• 无全局污染：工具函数只会混入到你指定的元素中，不会在全局作用域里乱飘，避免和其他库的命名冲突。

缺点： #

• 有点“杀鸡用牛刀”：纯工具函数（比如日期格式化、数学计算）本身不需要依赖组件实例，放在Mixin里其实是把无状态的函数和组件的状态绑定在了一起，有点冗余。
• 重复引入：如果很多元素都需要这些工具，每个元素都得声明继承对应的Mixin，虽然Polymer会处理重复混入，但代码层面还是多了一些重复的声明。

再说说封装成全局工具库的情况 #

优点： #

• 轻量化复用：只需要加载一次，所有组件都能直接调用，不用每个元素都写Mixin继承，代码更简洁。
• 通用性更强：纯工具函数本来就和Polymer无关，封装成独立的JS文件后，未来哪怕换框架，这个工具库也能直接复用。
• 调用更直接：无状态的纯函数本来就适合直接调用，比如AppUtils.formatDate(new Date())，比通过组件实例调用更符合函数的使用逻辑。

缺点： #

• 全局污染风险：如果直接把工具挂在window下，很容易和其他第三方库（比如Lodash、jQuery）的命名冲突，所以一定要做好命名空间隔离（比如包在MyApp.Utils这样的对象里）。
• 依赖不直观：看组件代码的时候，没法直接知道它用到了哪些全局工具，维护的时候得全局搜索调用位置，不如Mixin的依赖关系清晰。

我的建议 #

如果你的工具函数完全是无状态的纯函数（比如只是日期格式化、数学计算，不需要访问组件的任何属性或方法），那更推荐封装成独立的JS库，而且最好用ES模块的方式导入（如果你的项目支持的话）：

// app-utils.js
export const formatDate = (date) => {
  // 格式化逻辑
};

export const calculateSum = (nums) => {
  // 计算逻辑
};

然后在需要的组件里导入：

import { formatDate } from './app-utils.js';

class MyElement extends Polymer.Element {
  // ...
  someMethod() {
    const formatted = formatDate(new Date());
  }
}

这种方式既避免了全局污染，又能保持依赖清晰，同时兼顾了工具库的通用性。

如果这些工具函数未来大概率会和组件实例交互，或者你希望严格遵循Polymer的组件封装原则，保持每个元素的依赖都显式声明，那继续用Mixin是更稳妥的选择。

内容的提问来源于stack exchange，提问作者Junaid Akhtar