最近搞一个 chrome 插件，涉及到网站 favicon 图标替换，于是乎看了解下.ico格式的图片文件。

阅读更多

前端页面凡是涉及到用户输入，一般都会都数据校验。广义的说，涉及用户输入部分都可以统称之为表单。之所以需要对用户输入的数据进行校验，个人觉得有以下两个原因：

1. 系统的稳定性，我们不能保证用户输入是符合我们预期的，通过对输入的数据进行格式、内容校验，避免系统出现问题。例如需要输入年龄只能是正整数。
2. 用户体验，一般输入时就会给出提示，然后方便用户修正。例如输入的内容过长或者格式不对。
3. 数据安全或合规，避免用户输入一些不合规数据，例如游戏中各种激情互喷词语。

为了保证数据的一致性，前、后端都会对数据进行校验，一般而言后端的校验会更加全面。前端更偏向于一些数据通用性质的校验，例如数据格式、是否为空、长度等。这里主要介绍如何实现一个前端的表单校验器，当然思路都是通用的。

阅读更多

听公司内部大佬的产品思维分析，以自我的视角的整理一下, 本文分为三个部分：

1. 什么是产品思维；
2. 为什么需要产品思维；
3. 如何培养产品思维；

阅读更多

随着业务的迭代，不经意间写下的那几行代码，在后续的修修补补中，已经堆积成为屎山了。如果是自己一手造成了，还能游刃有余，修个 Bug 不至于引起雪崩。凡事都怕有个万一，是的，万一你接手了这么一个项目，而且这个万一的概率特别大，在换工作时，换业务方向时，业务有调整接手别人代码时，基本上能中奖。每一次改代码，都是嘴里念念有词，手上停滞不前。每一次上线都是胆战心惊，打开回滚页面，准备随时回滚以减少影响。一次又一次想推翻重来，然而没有人给予你勇气，直到有一天你能面对现实。。

阅读更多

之前一直有记账的习惯，最早是随便下载了一个记账的 App。用了快 3 年了，然而不幸的事情终究还是发生了，大概今年 5 月份，这个 App 的作者不再维护了。唯一的安慰是可以将数据导出到另外一个记账 App 中，顺便了送了一个月的 Vip。 Vip 的好处不多，但可以导出数据，还好及时导出到了邮箱中。用了一小段时间，发现还是很不习惯，原因主要有三个：

1. App 的交互和之前的较大的差异，总是不习惯，可能和预期的交互差异较大，我只需要记录一下消费情况，除了吃喝，就是买些日用品啥的，根本不需要那么复杂的功能；
2. 免费版功能不受限制，但数据不能导出，这点让我总感觉不安全，万一又不继续运维就凉凉；
3. 记账的成本较高，流程比较繁琐，打开 APP 得看广告，记账还得点击一个添加按钮，然后才开始输入；

阅读更多

最近遇到一个很无趣的问题，发现问题到解决问题耗费了不少精力。问题是这个样子的，在一个SPA的项目中，有两个页面复用了同一个下拉选择组件，传递给组件的属性是不一样的，期望获取的数据字段字段不一样：

阅读更多

如今的前端开发可真是越来越难了，不仅前端技术变化快，能访问页面的终端也越来越多了。以前大部分是通过PC访问，后面是出现智能手机后，平板，甚至手表，各个终端的屏幕尺寸千差万别。以iPhone为例，最早都是3.5英寸的，后面4.7英寸，现如今都有8种不同尺寸，具体可以看设备屏幕尺寸大全，开发一个页面就不得不考虑各种屏幕的展示效果，那我们又如何来适配不同屏幕的展示效果呢，总不可能不通尺寸开发一套样式吧。

阅读更多

因为新换了一个部门，这周需要接手了一个已有项目，后面开发维护都由我来负责。一个已经上线有半年多时间的B端项目，整体复杂度还是很高的.

可以看到纯代码量4w+，其中包含的外部依赖也非常多，React全家桶，redux， rxjs等，还有富文本编辑逻辑，动态表单渲染和国际化方案，随便一个都是一个挑战，一个项目包含这么多其复杂性不言而喻。给我的时间并不多，如何能快速熟悉项目并正常开发需求呢？

阅读更多

探索问题：

1. 为什么ES6中数组，字符串等是可迭代的，而对象却是不可迭代？直观感受就是数组和字符串都可以用for...of，而对象却不可以。
2. 实现一个最小化的迭代器。

阅读更多

在开发代码时，通常需要配置一些额外的代码质量校验工具来保证代码质量，像我们这边使用的就是fecs。因为平常都是用Webstorm来开发，正好fecs有提供这样的插件，用起来却也很方便。

阅读更多