分类
教程

给 Bootstrap Modal 增加缩放功能

需求

Bootstrap 应该还是目前最流行的前端基础框架之一。因为架构方面的优势,它的侵入性很低,可以以各种方式集成到其它项目当中。在我厂的各种产品里,都有它的用武之地。

前两天,老板抱怨,说 Modal(弹窗)在他的屏幕上太小,浪费他的 5K 显示器。

我看了一下,按照 Bootstrap 的设计,超过 1200px 就算是 XL,此时 .modal-lg 的宽度固定在 1140px。其实 Bootstrap 这么设计也有它的道理,因为人眼聚焦后宽度有限,如果弹窗太宽的话,内容一眼看不全,也不好。不过在我厂的产品里,弹窗要呈现火焰图,所以宽一些也有好处。

技术方案

那么,综合来看,最合适的做法,就给 Modal 添加一个拖拽的功能:用户觉得够大了,就这么着;用户想看大一点,就自己拉大一些,然后我记录用户的选择,以便复用。

看过我《用 `resize` 和 MutationObserver 实现缩放 DOM 并记录尺寸》的同学,应该知道 resize 这个 CSS 属性,使用它可以很方便的给元素添加缩放功能。参考 caniuse 上面的普及度,大部分新版本的浏览器都已经支持,可以放心使用。

使用它的时候要注意两点:

首先,我们在缩放元素的同时,也会对它的子元素、父元素同时造成影响。因为在静态文档流当中,块级元素的宽度默认是父元素 content-box 的 100%,而高度由子元素决定。所以,对一个块级元素的缩放,不可能宽过它的父元素(如果限制了宽度的话),也不可能矮于它的子元素。

其次,拖拽手柄的显示优先级很低,会被子元素盖住,哪怕子元素没有填充任何内容。换言之,一定要有 padding 的元素才适合添加 resize 缩放。

实施方案

总而言之,把这个属性加在哪个元素上面,很有讲究。具体到本次需求,Bootstrap Modal,最合适添加 resize 属性的的是 modal-content,因为它有 1rem 的内边距。

但是限制宽度的是父元素,也就是 modal-dialog,它是响应式的,会根据显示器的宽度设置一个最大宽度。如果不修改它的 max-widthmodal-content 的最大宽度就无法超过它,达不到预期效果。但是也不能改成 width,这样的话,弹窗会失去弹性,分辨率低的时候表现不好。

所以还是要在 max-width 上做文章。如果直接去掉它,modal-dialog 的宽度就会是 100%,失去弹窗效果,所以也不能这样做。最终,我的方案是:

  1. 窗口完全展开后,获取宽高,赋给 modal-content
  2. 去掉 modal-dialogmax-width
  3. 用 MutationObserver 监测 modal-content 的宽高,保存 localStorage,以便接下来使用

完整代码展示

我厂的产品基于 Vue 开发,所以部分逻辑用 Vue 组件实现。

效果演示

为方便在 Codepen 里呈现,有部分修改。

代码及解释

<template lang="pug">
.modal.simple-modal(
  :style="{display: visibility ? 'block' : 'none'}",
  @click="doCloseFromBackdrop",
)
  .modal-dialog.modal-dialog-scrollable(
    ref="dialog",
    :class="dialogClass",
  )
    .modal-content(ref="content", :style="contentStyle")
      .modal-header.p-2
        slot(name="header")
          h4 {{title}}
        span.close(v-if="canClose", @click="doClose") ×
      .modal-body
        slot(name="body")
</template>

<script>
import debounce from 'lodash/debounce';

const RESIZED_SIZE = 'resized_width_key';
let sharedSize = null;

export default {
  props: {
    canClose: {
      type: Boolean,
      default: true,
    },
    size: {
      type: String,
      default: null,
      validator: function(value) {
        return ['sm', 'lg', 'xl'].indexOf(value) !== -1;
      },
    },
    resizable: {
      type: Boolean,
      default: false,
    },
    backdrop: {
      type: Boolean,
      default: true,
    },
    title: {
      type: String,
      default: 'Modal title',
    },
  },

  computed: {
    dialogClass() {
      const classes = [];
      if (this.size) {
        classes.push(`modal-${this.size}`);
      }
      if (this.resizable) {
        classes.push('modal-dialog-resizable');
      }
      if (this.resizedSize) {
        classes.push('ready');
      }
      return classes.join(' ');
    },
    contentStyle() {
      if (!this.resizable || !this.resizedSize) {
        return null;
      }
      const {width, height} = this.resizedSize;
      return {
        width: `${width}px`,
        height: `${height}px`,
      };
    },
  },

  data() {
    return {
      visibility: false,
      resizedSize: null,
    };
  },

  methods: {
    async doOpen() {
      this.visibility = true;
      this.$emit('open');
      if (this.resizable) {
        // 通过 debounce 节流可以降低函数运行次数
        const onResize = debounce(this.onEditorResize, 100);
        // 这里用 MutationObserver 监测元素尺寸
        const observer = this.observer = new MutationObserver(onResize);
        observer.observe(this.$refs.content, {
          attributes: true,
        });

        if (sharedSize) {
          this.resizedSize = sharedSize;
        } 
        // 第一次运行的时候,记录 Modal 尺寸,避免太大
        if (!this.resizedSize) {
          await this.$nextTick();
          // 按照张鑫旭的说法,这里用 `clientWidth` 有性能问题,不过暂时还没有更好的解决方案
          // https://weibo.com/1263362863/ImwIOmamC
          const width = this.$refs.dialog.clientWidth;
          this.resizedSize = {width};
          // 这里产生纪录之后,上面的 computed 属性就会把 `max-width` 去掉了
        }
      }
    },
    doClose() {
      this.visibility = false;
      this.$emit('close');
    },
    doCloseFromBackdrop({target}) {
      if (!this.backdrop || target !== this.$el) {
        return;
      }
      this.doClose();
    },

    onEditorResize([{target}]) {
      const width = target.clientWidth;
      const height = target.clientHeight;
      if (width < 320 || height < 160) {
        return;
      }
      sharedSize = {width, height};
      localStorage.setItem(RESIZED_SIZE, JSON.stringify(sharedSize));
    },
  },

  beforeMount() {
    const size = localStorage.getItem(RESIZED_SIZE);
    if (size) {
      this.resizedSize = JSON.parse(size);
    }
  },

  beforeDestroy() {
    if (this.observer) {
      this.observer.disconnect();
      this.observer = null;
    }
  },
};
</script>

<style lang="stylus">
.simple-modal
  background-color: rgba(0, 0, 0, 0.5)
  .modal-content
    padding 1em

    .close
      cursor pointer

.modal-dialog-resizable
  &.ready
    max-width unset !important

  .modal-content
    resize both
    margin 0 auto
</style>

注意

因为浏览器的异步加载机制,有可能在 modal 打开并完成布局后,高度和宽度被内容撑开导致记录不准,或者内容被异常遮盖。请读者自己想办法处理,就当练习题吧。

总结

本次组件开发非常符合我理想的组件模式:

  1. 充分利用浏览器原生机制
  2. 配合尽量少的 JS
  3. 需要什么功能就加什么功能,不需要大而全

在 MVVM 框架的配合下,这样的方案很容易实现。另一方面,每个项目都有独特的使用场景,通过长期在特定场景下工作,我们可以逐步整理出适用于这个场景的组件库,不断改进该项目的开发效率。我认为这才是组件化的正道。

分类
技术

组件化的度

加入贵司后,接手前端开发,主做后台产品。按理说,我在前司做了5年后台产品,轻车熟路,熟的不能再熟,这项工作对我来说应该再合适不过。结果进展非常不顺,甚至老板来敲打我,说工作效率太低,需求做的太慢。

我也不得不承认,就目前来看,自己确实没有达到很高的效率。不过我也得吐槽一下,这是有原因的!不是我不努力,而是现在的架构实在太太太……(我得选个好词,以免伤害到球哥的感情),太僵硬吧。

(目前的后台架构是球哥基于 Vue 设计开发的组件化框架。球哥是个码力十足,有追求有实力的人,我非常欣赏他,然则这套框架我实在不敢苟同。)

Vue 最大的优势,就在于它用很低的成本赋予了 Web MVVM 的能力。于是我们这些前端开发者可以用很低的软件复杂度,完成非常优秀的产品。而且,其作者还尽可能的把 Vue 解耦,降低入门门槛和使用门槛,我们不需要上来就面对一大批陌生的名词和概念,几乎可以直接上手实操。

可惜,与之同期到来的,还有“组件化”这把双刃剑。组件化当然有好处,它方便我们复用代码,提升效率。但也有很多开发者走上歪路——写组件库,用组件库。写组件库当然有好处,比如,是个扬名立万的好机会。用组件库也有好处,可以提升效率,省去很多开发量。

但是,所有组件库都有一个避不开的槛——颗粒度。颗粒度太细,用起来跟原生 HTML 差不多,意义不大;颗粒度太粗,一旦不合业务逻辑,就会很蛋疼(对,我就很蛋疼,简直每隔几天蛋就要碎一次……)。怎么样来确定颗粒度的粗细呢?只能看业务了。

2B 开发的特点

回到2B业务上。2B开发有几个明显不同于2C开发的地方:

  1. 业务流程又长又复杂
    • 2C 业务,比如微博、微信,用户操作简单直接,效果反馈很快
    • 2B 业务,如果某个操作要填10个表单,经过5个环节审批,那就一个都少不了
  2. 客户多付费,必须尊重他们的需求

这两点之下,会产生一些要求:

  1. 表单复杂,校验项多,灵活性要求高。此时,表单生成器就不再适用;只要,要把可以生成的简化版,和需要人工的复杂版分开。
  2. 表格多,列多,单元格多变。此时,表格组件也不宜复杂,处理好简单的分页筛选即可,剩下的还是交给业务相关的组件。
  3. 表格表单复用性差,很多表格表单都只出现一次,或者有自己独特的需求。此时,组件的优势不复存在,工作量怎么做都是接近的,反倒是原始的做法更清晰直接。

2B 开发的组件化

所以,我认为,2B 的产品,不适宜上来就用组件库搭建复杂的框架。相反,用最简单直接的 HTML、JS 元素,加上 MVVM 特性,效果会更好。

初期

最合适的组件化方案就是“不要过早组件化”。组件化的颗粒度以增强原始 HTML 元素为主,比如 Typeahead(输入搜索下拉选择)、给 Input 增加通用的校验工具,等等。用几乎最原始的方式开发,完成需求。这样看起来土,但带来的两个非常重要的好处:

  1. 思路直接,符合直觉,开发者不用投入大量精力学习新框架可以凭直觉完成
  2. 颗粒细,方便实现各种业务逻辑。比如表单想哪几个字段一起校验就一起校验,想怎么显示数据就怎么显示数据。

中期

这个时候我们应该完成很多需求了,哪些组件使用频繁值得抽象,哪些组件很复杂但是只用一次,大家心理都有数了,就可以开始着手进行组件化的工作。

不过,这个时候,仍然不需要做什么表单生成器、表格生成器之类的东西。我们要做的,是强业务相关组件。比如,某个表单在多处被重复使用,我们就要想办法把它抽象成组件(一般用到第3次,就要考虑做组件,用到第4次就一定要做成组件)。做出来的组件,只包含这个表单;抽象的目的:统一管理这个表单,方便别人复用。

抽象成组件的目的,是让今后的开发更成熟快捷,不是为了提炼出一套通用工具集,放到市场上扬名立万。

晚期

这个时候我们应该积累了不少组件,足以应付日常需求,可以快速响应快速开发。此时,组件化以重构为主。

最终,很遗憾,我们并未收获一套普适的通用组。但是,我们得到一套和业务深度绑定的组件库,和建筑于底层,弹性好鲁棒佳的架构。


这才是我眼中的组件化之道。

分类
vue 技术

小试 Element UI

不确定写多长,写先结论吧:暂时不推荐使用。原因如下:

  1. 影响使用的小 Bug 有点多
  2. 需要重新学习一门语言


接下来详述。

从前司离职之后,我开始更新技术栈。离开惯用的 Backbone,考虑再三,投入 Vue 怀抱。选择 Vue,而不是竞品 Angular、React 有三个理由:

  1. 文档友好,社区活跃。
  2. 模块拆分的很好,学习曲线平缓。
  3. 基于标准化技术,可以最大限度的避免浪费。

不过实操之后发现,Vue 与我惯用的 Bootstrap 有些冲突,主要在于:

  1. Bootstrap 对过渡效果和切换的操作依赖于样式,比如 .active.in。Vue 在处理模板时会把当前样式先缓存起来,然后根据数据增删绑定的样式。此时就可能出问题,tab 页切不动或者动画突然打断之类的。
  2. Bootstrap 会广播特定的事件,这些事件无法被 Vue 捕获,只能在 mounted() 的钩子里手工绑定。

于是我觉得,既然根基(jQuery)变了,最好把整条线都更新了吧。左右看了看,准备先试下 Element UI。这是饿了么推出的基于 Vue2.0 的组件库,目测组件齐全,文档详细,而且直接以 2.0 为基础,符合我追新的想法。

实际用了之后……唉……有点……遗憾。项目地址

首先,Element UI 把所有组件都封装了,包括布局,比如 <el-row><el-col>,我觉得这样太过了。从现实经验来看,布局元素几乎不可能够用,别人总要补充一些。封装的元素我不太知道最终生成的代码是什么样的,也就不好操作,总不能审查元素一个一个看吧?——对了,Element 的文档里缺少样式列表,也是个问题。

封装的另一个问题,所有元素都要通过后期渲染,总让我感觉不舒服。以及,我几乎无论干什么都要查文档,几乎没法直接动手,这和我选择 Vue 的初衷是相违背的。

接下来,小 Bug,有点多。除去布局和提示之类,我只用到3个组件:<el-button><el-table><el-pagination>,结果就遇到4个 bug,浪费很多时间去调试,有两个我给他们开了 issue,还有两个懒得弄了。这里列一下吧:

  1. <el-button :loading="scope.row.fetching"> 无法把 loading 绑定到数据的 .fetching 属性上
  2. <el-pagination> 设置 total 不更新视图
  3. <el-pagination> 更新 total 之后再次广播 current-change 事件,导致重复刷新
  4. <el-table> 里每行的 ref 属性没法正确生成数组

2017-04-04 更新:

经过 issue 沟通,我的理解的确有些问题,

  1. Vue 绑定属性的时候,如果该属性层次较深,比如 a.b.c,就不会修改它的 getter/setter,于是会失去响应式更新的特性;同时也不会报错。
  2. <el-table> 不是通过 v-for 渲染的,自然 ref 的表现也就正常了。

可能别的组件很健壮吧,我运气不好。

总之,我觉得就目前这个版本,1.2.5,来看,Element UI 还没到让人放心用并且用得好的程度。

下一次我可能会选别家的再试下,或者继续用 Bootstrap 然后自己拼些小组件出来——我这次就是想找个有 loading 的 button 才找 UI 库的。


啊,最后,还是感谢 Element UI 团队,感谢饿了么。希望你们再接再厉,相信将来这套库会更好。