销售合同移动化

这是一篇关于销售合同移动化的思维导图。从看wikl，看原型，看ui；劳作阶段等方面进行了概述和分析，需要可收藏。

销售合同移动化

• 看wiki，看原型，看ui
  • 事实证明ui和原型不一定相同，但是Wiki一定是正确的
• 劳作阶段
  • 一年多不写小程序，边看边写
  • ui上有蛮多用到表单的地方，思考了一分钟59.99999999秒后决定写一个组件
    • 写组件的路上起起落落落落落落落落落落落落落落落落落落......
    • 这个组件要满足平常使用的一些表单，比如input，弹窗选择，一些时间选择，地址选择，也有可能出现联动选择，还有下拉选择，以及校验规则不符合或者必填没有输入需要，定位在它下方爆红，我当然是不可能全部功能都给他满足，所以就舍弃了一些，校验规则是在点击确定的时候校验，我们采用比较人性化的提示，当你不输入哪个，我们就提示哪个没有输入🐕，联动这么麻烦的东西肯定暂时不做，
    • 在做数字输入的时候，要满足除了数字不能输入，小数的时候只能输入小数点后几位，input自身的数字键盘digit，但是限制大小和限制位数的时候没有找到原生属性，就用普通的input写了一个用正则替换的规则，能满足大部分数值场景，感觉还可以优化一下，等有时间写一个更简洁的
    • 在使用popup的时候出现了position: fixed;效果成了absolute，在position为right会出现这种情况，出现的原因是transform改变了fixed的行为，变成了absolute的行为，transform的影响还不止如此，transform和overflow以及absolute结合使用还会产生不同的效果，第一个改变fixed行为对chrome和firefox有影响，对ie等其他暂时没发现，后面的对overflow结合使用基本所有浏览器都变得行为一致了，可以避免使用，也可以使用上中下固定布局，中间可以滚动，实现底部固定，头部固定
  • 组件传值的时候碰到爷孙传值，跨两个以上页面传值的时候总会有点问题，思考🤔：能不能在当前页面订阅一个事件订阅一个事件，在某个需要传值过来的页面或者组件，发布一样的事件把值给传过来，订阅的事件接收到这个值，然后在回调事件中进行处理，发布者和订阅者之间订阅/发布同一个事物,解决跨页面，跨n组件传值。这种实现方案不就是订阅/发布者模式么，说了那么多怎么还不上代码，这就来。