设计理念

相比传统静态设计的组件库，axue拥有黑魔法，可以在业务开发层，覆盖axue框架的底层默认配置，实现对框架的loadtime自定义。

一、全局级配置

类似的设计范式，在showTip等场景也有体现。

我们不妨一起探讨一个设计话题：

默认的tip小提示，是1.5s自动关闭，主流的组件封装思路是在showTip.send()、showTip.info()......系列方法里，提供一个duration的参数，用于自定义显示秒数。

这很不错，也很正统。但下一处你调用showTip方法，你依然需要指定，比如3s，如果你的代码里有一百处tip消息逻辑，你都需要传参，并且，一旦你感觉3s太长，希望切换到2s，也得改一百处。

于是你发出了一声哀嚎：Fuck!!

傲雪持有不同的设计理解：

偏好性的参数，其本质往往属于全局性业务需求，应该由框架级配置或者组件级配置来实现，而非组件级实例来维护。老实说，当初我看到那些大型的组件库，一个组件提供了上百个参数来支撑用户自由度，看不出层次脉络，我明显望而生畏。

二、实时生命周期

axue的组件底层的响应式能力，对配置进行了反向监听，确保能够在运行时动态响应配置更新，这种独特的特性，使得组件不仅能自定义，还拥有一个与众不同的能力，能适应一些冷门场景，比如：借助用户的实时交互，使用逻辑控制组件的形态演化。

//导入
import { showTip } from "axue";

//在调用前，进行全局配置，对后续所有类型的tip均有效
showTip.config({
    duration:5000,
    backgroundColor:"#eee"
})

//发送提示，此时将变成5s后自动关闭
showTip.warning('Hello, 特殊场景，超长显示5秒!'); 

//在调用后，第一时间重新恢复配置，对后续所有类型的tip均有效
showTip.config({
    duration:1500,
    backgroundColor:"#fffe"
})

//等待第一个tip结束再显示
setTimeout(()=>{
   showTip.info('Hello, showTip配置已恢复!');  
},1000)