在 Chart.js 的线图里增加竖线

我经常使用 Chart.js 生成图表,无它,名字好记+免费+持续更新。现在主要基于 Vue 开发项目,所以经常使用 vue-chart.js。前阵子遇到一个需求:

  1. 把一组数据画成线图
  2. 用户可以任意点击时间
  3. 用数据生成饼图

那么就需要在线图中画一条竖线,标识出当前时间点。本以为这个需求不复杂,没想到不仅 Chart.js 不支持,包含这个功能的插件因为 Chart.js 升级的关系,暂时没法用。所以只好自己实现。

继续阅读“在 Chart.js 的线图里增加竖线”

Chat idea:记一次 Firefox 下 Vue 带来的性能危机的解决

前两天遇到一个问题:我厂的一个产品在 Firefox 下,可能发生因为 CPU 占用过高而卡死的情况。这个问题在测试环境不复现,在 Chrome下基本上也不会复现。

因为我厂老板是这个产品的主要用户,这个 bug 让我倍感压力,但一直没有解决它的好办法。终于有一天,在某台生产机上调试另外一个 bug 的时候,我终于发现了稳定复现这个 bug 的方式。

接下来就是几个小时的 debug,然后发现问题所在,然后解决问题,然后发现解决方案不理想,于是寻求新的解决方案,然后找到新的 API,最终彻底的解决这个问题。

接下来我就分享这个过程,读完整篇文章当中你将学会:

  1. 使用开发者工具查找性能问题
  2. 不断切分,缩小问题范围
  3. 理解 Vue 响应式原理分析问题根源
  4. 修复问题并验证
  5. 新的解决方案 Intersection Observer
  6. 解决问题并上线

目标读者:

  1. 中级开发者
  2. 熟悉原生 JS

大家觉得这个 idea 如何?请留言告诉我。不出意外的话这将是我下个月的 gitchat 内容。

Chat Idea:扫雷网页版实战

最近最常玩的游戏是扫雷。年纪大了,干什么时候都先考虑成本,游戏也是如此。扫雷的成本最低,倒不是说购买成本,而是启动、游戏、退出之类的成本。

可惜的是,经典版扫雷已经从 Windows 10 里移除了,现在只能通过 Windows 应用商店装一个很复杂的扫雷游戏,花样多了很多,却并不好玩。所以我现在多半玩网页版。

玩着玩着,出于程序员的本能,我就开始考虑如何写这个游戏,逻辑不算复杂,功能点也不多,好像蛮适合做成“实战派”教程的,比如用 Grid 写界面,项目结构就用 Vue CLI 3 吧,然后部署的话前端纯静态就够了。

那么就愉快的决定了吧,把这个项目做出来,把中间需要的知识,用到的技能、工具,可能会遭遇的问题记下来分享出来,写成一篇文章,分享出去。读完整篇文章,你将学会:

  1. 使用 Vue CLI 3 搭建项目
  2. 使用 CSS Flex + Grid 完成页面布局
  3. 扫雷游戏的逻辑
  4. 使用 Vue 完成游戏逻辑
  5. 记录成绩
  6. 部署和分享

目标读者:

  1. 初级开发者,能看到一个项目的成型
  2. 希望了解现代化前端框架、工具链

Chat:Vue 进阶必经之路

Vue 进阶必经之路

Vue 的学习曲线平缓,入门很简单,所以后发夺人,争取到一大批支持者,我也是其中之一。但是因为隐蔽了很多细节,所以我也没少踩坑,挠头拍桌,不厌其烦。如今,我终于突破屏障,遇到大部分问题,都能举一反三,快速定位、快速解决。这段过程,难免追本溯源,穷究细节。我希望通过这次分享,把我的经验和收获传达给大家。

面向听众:

1. 有一定 Vue 开发经验,希望进一步提升;
2. 平时业务代码写得多,想学习技术细节。

写完了,不得不说,没有预先想象中写得好。原因嘛,当然是工作太忙,能够写文的时间不太够。以后还是平时多写,Chat 当汇总比较好。

不过还是希望大家都来看,毕竟我这两年踩坑得到的 Vue 经验都在里面了。

继续阅读“Chat:Vue 进阶必经之路”

Vue 小贴士

1. 使用 Vue + Webpack 开发
2. 使用 CDN 加载依赖
3. 在开发阶段尽量不要使用压缩的文件,一边取得尽量全面的错误信息

书说简短:

  1. 使用 Vue + Webpack 开发
  2. 使用 CDN 加载依赖
  3. 在开发阶段尽量不要使用压缩的文件,一边取得尽量全面的错误信息

继续阅读“Vue 小贴士”

《Electron + Vue 实战建站工具开发》读者圈开启

今年计划出一本书:《Electron + Vue 实战建站工具开发》。在 SF 开了读者圈,欢迎大家入圈,提前看全书,实时解答勘误,还有机会拿到实体书。

今年很努力的做视频培训,收效一般。不过在社区收获了一些声望,还得到一个写书的机会,跟编辑讨论再三,确定下内容:Electron + Vue 实战开发。

然后呢,也不是我有意拖延,因为很快就入职贵司,一直都很忙,将近两个月,渐渐熟悉了框架,也适应了节奏(希望如此),现在得抓紧时间补书稿了。

最开始想在知加边写边发,结果知加没挺到现在,所以只好退而求其次,在 SF 开了读者圈——倒不是说 SF 不好,而是他们家的“技术圈”从产品形态上来看,不是非常合适。

Anyway,欢迎大家加入圈子,您会得到:

  1. 读到这本书全文,并且更早读到
  2. 获得实时问题解答
  3. 得到实时勘误
  4. 得到实体书(具体看出版社给多少了……)

入圈链接

组件化的度

最近快被贵司的后台架构搞崩溃了,吐槽吐槽发泄一下。

加入贵司后,接手前端开发,主做后台产品。按理说,我在前司做了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次就一定要做成组件)。做出来的组件,只包含这个表单;抽象的目的:统一管理这个表单,方便别人复用。

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

晚期

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

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


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