黄子毅
周刊参考池
列举长期更新的周刊源，每周精选的主要来源。 活跃中： - [奇舞周刊](https://www.zhihu.com/column/75weekly) - [InfoQ 前端专栏](https://www.infoq.cn/topic/33) - [javascript weekly](http://javascriptweekly.com/latest) - [nodejs weekly](https://nodeweekly.com/latest) - [frontend focus](https://frontendfoc.us/latest) - [indepth](https://indepth.dev/) [indepth-react](https://indepth.dev/search/?query=react&tags=react) - [smashing magazine](https://www.smashingmagazine.com/) - [每日时报](https://wubaiqing.github.io/zaobao/) 已停更： - [FEX 周刊](https://fex.baidu.com/) - [zaobao](https://github.com/sorrycc/zaobao/issues?page=1&q=is%3Aissue+is%3Aopen)
使用指南
使用 redux 时，很多时候是傻傻分不清要不要将结构化数据拍平，再分别订阅，或者分不清订阅后数据处理应该放在组件上还是全局。这是因为 redux 破坏了 react 分形设计，在 [最近的一次讨论记录](https://zhuanlan.zhihu.com/p/32273365) 有说到。而许多基于 redux 的分形方案都是 “伪” 分形的，偷偷利用 `replaceReducer` 做一些动态 reducer 注册，再绑定到全局。 讨论理想数据流方案比较痛苦，而且引言里说到，很多业务场景下收益也不大，所以可以考虑结合工程化思维解决，将组件类型区分开，分为普通组件与业务组件，普通组件不使用数据流，业务组件绑定全局数据流，可以避免纠结。 ### Store 如何管理 > 使用 Mobx 时，文档告诉我们它具有依赖追踪、监听等许多能力，但没有好的实践例子做指导，看完了 todoMvc 觉得学完了 90%，在项目中实践后发现无从下手。 所谓最佳实践，是基于某种约定或约束，让代码可读性、可维护性更好的方案。约定是活的，不遵守也没事，约束是死的，不遵守就无法运行。约束大部分由框架提供，比如开启严格模式后，禁止在 Action...
根据笔者的项目经验，本文讲解了从函数回调，到 `es7` 规范的异常处理方式。异常处理的优雅性随着规范的进步越来越高，不要害怕使用 `try catch`，不能回避异常处理。 我们需要一个健全的架构捕获所有同步、异步的异常。业务方不处理异常时，中断函数执行并启用默认处理，业务方也可以随时捕获异常自己处理。 优雅的异常处理方式就像冒泡事件，任何元素可以自由拦截，也可以放任不管交给顶层处理。 > 文字讲解仅是背景知识介绍，不包含对代码块的完整解读，不要忽略代码块的阅读。 ### 1. 回调 如果在回调函数中直接处理了异常，是最不明智的选择，因为业务方完全失去了对异常的控制能力。 下方的函数 `请求处理` 不但永远不会执行，还无法在异常时做额外的处理，也无法阻止异常产生时笨拙的 `console.log('请求失败')` 行为。 ```javascript function fetch(callback) { setTimeout(() => { console.log('请求失败') }) } fetch(() =>...
将之前对 React Hooks 的总结整理在一篇文章，带你从认识到使用 React Hooks。 # 什么是 React Hooks React Hooks 是 React `16.7.0-alpha` 版本推出的新特性，想尝试的同学安装此版本即可。 **React Hooks 要解决的问题是状态共享**，是继 [render-props](https://reactjs.org/docs/render-props.html) 和 [higher-order components](https://reactjs.org/docs/higher-order-components.html) 之后的第三种状态共享方案，不会产生 JSX 嵌套地狱问题。 这个状态指的是状态逻辑，所以称为**状态逻辑复用**会更恰当，因为只共享数据处理逻辑，不会共享数据本身。 > 不久前精读分享过的一篇 [Epitath...
支持通用的手势缩放，手势跟随，多图翻页 ## 手势系统  通过 `PanResponder.create` 创建手势响应者，分别在 `onPanResponderMove` 与 `onPanResponderRelease` 阶段进行处理实现上述功能。 ## 手势阶段 大体介绍整体设计，在每个手势阶段需要做哪些事。 ### 开始 `onPanResponderGrant` ``` typescript // 开始手势操作 this.lastPositionX = null this.lastPositionY = null this.zoomLastDistance = null...
# React Editor 应用编辑器(2) - 编辑区基本设计 上一篇说了**如何实现灵活的拖拽**，那么加上**编辑功能**，拖拽编辑器的两大核心功能就集齐了，剩下就是**组件树、版本管理、模板、预览、快捷键、事件、动画、在线编辑代码**以及**部署方式**这些边角功能，当然这些边角功能都不影响大局，这次我们来谈谈如何设计编辑区，类似下图的结构：  1. 从图中可以看出，编辑区涉及很多数据同步操作，我们使用了 `mobx` 很好的解决了这个问题，本篇文章因为重点描述编辑器设计，因此数据设计部分不会过多涉及。 2. 除了基本属性设置，还应该有脚本设置、事件设置、动画设置，这些后续文章再讨论。 ## 通用属性编辑 我们发现，样式才是最通用的属性，无论何种组件都逃离不了样式的设置，除此以外的属性都是自定义的，我们无法抽象出共性加以定制，但是样式是固定的，所以编辑区先要支持通用样式的编辑。 通用样式：`背景` `边框` `字体` `边距` `布局` `溢出处理` `宽高` `透明度` 我们提供了对应的 13 余中定制编辑类型，比如像上图的边距调节器，专门针对边距进行修改，只要将编辑类型设置为 `marginPadding` ，编辑框中就会出现非常方便的边距调节器。...
[syntax-parser](https://github.com/syntax-parser/syntax-parser) 是完全利用 JS 编写的词法解析+语法解析引擎，所以完全支持在浏览器、NodeJS 环境执行。 它可以帮助你快速生成 **词法解析器**，亦或进一步生成 **语法解析器**，将字符串解析成语法树，语法解析器还支持下一步智能提示功能，输入光标位置，给出输入推荐。 目前 [syntax-parser](https://github.com/syntax-parser/syntax-parser) 功能逐渐稳定，内核性能还在逐步优化中，我们会利用 [syntax-parser](https://github.com/syntax-parser/syntax-parser) 引擎的能力，完成一些令人惊喜的小 DEMO，如果与你的业务场景恰好契合，欢迎使用！ 这次的 DEMO 是：利用 [syntax-parser](https://github.com/syntax-parser/syntax-parser) 快速完成四则运算语法解析器！ ## 1. 生成词法解析器 通过下面 20 行配置，生成一个能解析英文、数字、加减乘除、左右括号的词法解析器，so easy！ ```typescript import { createLexer...
本次分享是带大家了解什么是 mvvm，mvvm 的原理，以及近几年产生了哪些演变。 同时借 mvvm 这个话题拓展到对各类前端数据流方案的思考，形成对前端数据流整体认知，帮助大家在团队中更好的做技术选型。 ## Mvvm 的概念与发展 ### Mvvm & 单向数据流 Mvvm 是指双向数据流，即 View-Model 之间的双向通信，由 ViewModel 作桥接。如下图所示：  而单向数据流则去除了 View -> Model 这一步，需要由用户手动绑定。 ### 生态 - 内置 &...
前端数据流哲学
本系列分三部曲：《框架实现》 《框架使用》 与 《数据流哲学》，这三篇是我对数据流阶段性的总结，正好补充之前过时的文章。 本篇是收官之作 《前端数据流哲学》。 ## 1 引言 写这篇文章时，很有压力，如有不妥之处，欢迎指正。 同时，由于这是一篇**佛系文章**，所以不会得出你应该用 某某 框架的结论，你应该当作消遣来阅读。 ## 2 精读 首先数据流管理模式，比较热门的分为三种。 - 函数式、不可变、模式化。典型实现：Redux - 简直是正义的化身。 - 响应式、依赖追踪。典型实现：Mobx。 - 响应式，和楼上区别是以流的形式实现。典型实现：Rxjs、xstream。 当然还有第四种模式，裸奔，其实有时候也挺健康的。 数据流使用通用的准则是：副作用隔离、全局与局部状态的合理划分，以上三种数据流管理模式都可以实现，唯有是否强制的区别。 ### 2.1 从时间顺序说起...
我们先来回顾一下 React ，Facebook 是这么描述的： > A JavaScript library for building user interfaces 官方定义其为 UI 库，这名字似乎太低调了些。从 React-Native 的发展就能看出来其野心勃勃，但官方的定义反而使其成为了开发者的宠儿 —— "为什么要用React?" "它只是个UI库"。 从 jQuery 开始，前端组件遍地花开，有jQuery官方提供的成套组件，也有活跃社区提供的第三方组件，从最简单的文本截断功能，到复杂的拖拽排序都应有尽有。业务使用的时候，经常会给 window 挂上 $，代码中组织也非常灵活，在需要复杂 dom 操作时，jQuery 总能帮忙轻松完成。 React...