react-tyshemo-form 发布
昨晚想到了很晚，睡不着，然后就实现了它，今天就把它发布了。react-tyshemo-form基于tyshemo的model实现响应式，基于react-tyshemo实现react和model的绑定，最终体现为一个Field组件。
<Field model={model} name="field" component={FieldComponent} />
整个包的核心就在这个Field组件上面，它基于我早前在robust中提出的表单范式理论，对于表单视图而言，实际上只需要 value, required, disabled, readonly, hidden, errors 这几个信息，以及一个 onChange 回调函数。所以，这这个 Field 组件的实现上，完全遵照这个理论去做，对于用于展示字段 UI 的组件，只需要接收这些 prop 就够了。当然，为了必要的扩展，Field 也支持一个 extend 属性，用来确保可以传入其他 prop。
以上面这段示例代码为例，<Field /> 只是一个驱动器，主要作用是确保 model 上的 field 字段值发生变化时，可以重新渲染该字段。仅此而言，所以使用也超级简单。
领域模型 Domain Model
今天学到的新知识点，领域模型 Domain Model。简单总结一下，什么是领域模型？领域模型有哪些好处？如何在开发中运用领域模型？
什么是领域模型？
有两个领域对领域模型做出解释。
- 管理领域：领域模型是对整个行业的工作模式的抽象总结。
- 软件领域：领域模型是对对象普遍性的最高抽象。
虽然出发点不同，但是实际上表达意思的核心思想是一致的。要理解领域模型，首先看下“领域”的概念。横向比较，domain对应的是range，domain是定义域，range是值域。纵向对比，领域是比专业/职业/业务更高水平的概念，例如我们经常说“机器人领域”“水产品领域”“航空航天领域”。“领域模型”概念的核心思想，就是寻找某一宽泛范围内的行为模式的共性，抽象为可适用于这一范围内所有行为的普遍性原则、规律或方法。
在编程领域怎么去理解？从大的层面讲，电商类应用与OA办公应用是两个领域的应用，它们适用不同的业务领域模型。从小的角度讲，用户鉴权和订单跟踪这两个业务完全不同，适用不同的编程领域模型。这里你可以发现两个点：1）虽然鉴权和订单领域模型不同，但是这两个业务之间可能存在联系，比如是否得到订单信息基于鉴权的结果；2）虽然电商应用和OA应用业务场景不同，但是它们可能都需要鉴权。
所以，从编程角度看，领域模型实际上既要解决对象抽象的问题，也要解决对象间的关系问题，还要解决在什么事件下触发对象关系的转变问题。
领域模型有哪些好处？
这里的好处是指相对于业务模型来说。我们开发过程中，经常基于业务场景去进行设计。而一个应用系统的开发，必须应对业务需求的变化。特别是办公软件这种系统，一个企业使用办公软件，必然遵循企业管理的流程，而流程变更是常有的事，基于业务场景去设计和架构软件，并持续迭代，最终带来的后果就是在多次迭代之后，不得不进行重构。而如果该次重构仍然基于业务模型去重构的话，必然还会经历再一次的重构。因为一个业务模型是无法适应所有业务场景的。所以，一旦现实中的业务需求迭代了，给原有的技术架构造成必须重构的影响时，开发者没有任何回旋余地。
而如果基于领域模型设计软件，那么可能接受的代价更小。在分析业务本身时，不只为了实现业务去设计架构，而是从行业的普遍性出发去设计架构，同时结合自己的业务特征，再在设计好的架构上包上一层。哪一天自身的业务发生变化，往往只需要在上面包的那一层上做调整。在软件整体上，分不同的层“视图层-业务层-数据层”，在每一层中又具体的去划分，比如业务层“领域模型-业务模型-流转模型”。而且在设计之初，每一个领域（鉴权、订单等）都采用行业标准，再在行业标准基础上包一层实现定制。那么这一就可以以最小的成本，把知识沉淀在自己的真实业务代码中。
如何运用领域模型？
以下是我在这篇文章中看到的建议。
- 理解后端领域模型
- 建立前端领域模型
- 分离领域层
- 主导接口约定
- 开发中注意业务含义
- 实时同步
简单讲，就是要建立抽象类，这些类去定义领域对象的属性、方法，而且这些类要有一定的内在联系，可扩展。在视图层可以被很好的使用，并不需要在视图层去撰写业务逻辑。
一些相关话题的文章：
- https://juejin.im/post/5d3926176fb9a07ef161c719
- https://zhuanlan.zhihu.com/p/37904835
- https://juejin.im/post/5b1c71ad6fb9a01e5918398d
- https://zhuanlan.zhihu.com/p/109114670
- https://www.jianshu.com/p/fe45506ea358
- https://zhuanlan.zhihu.com/p/59886663
- https://www.cnblogs.com/luminji/p/3703082.html
另外，刚才在阅读的时候，发现“视图模型”“业务模型”“领域模型”这些概念。现在前端编程实际上大部分是杂糅“视图模型”和“业务模型”，也就是MVVM中的VM那一套东西，真正的MVC还非常少见。
var === undefined vs. typeof var === 'undefined'
全等号 === 已经在我日常开发中占据绝对位置，在我开发中所有判断里面，== 已经被当作奇淫巧技了，不在万不得已的情况下，不会使用，其地位和分号; 等同。所以，现在讨论如何判断一个值是否为 undefined 的时候，我只会用 ===。
现在的问题是，在 var === undefined vs. typeof var === 'undefined' 这两种判断中，谁更好？先说结论，使用 typeof 的方法更好。最主要的原因有两点：
- var === undefined 的形式，你不能确保 var 被声明过，当 var 没声明过时，程序直接报错，而使用 typeof 可以用来判定一个变量是否声明过，这也是我们常用的 typeof window ... typeof global ... typeof self ... this 这个办法来搞定不同运行时环境下的处理。
- undefined 竟然是 window 的属性，按理来说作为 js 语言的基础类型，提供和 null 一样的关键字应该由语言解释器来做吧，但是在运行时中（浏览器），undefined 和 null 完全是两个层面的东西，null 是内置于解析器的空指针符号，而 undefined 是挂在 window 上的全局变量，竟然是挂在 window 上的变量，那么每次使用 var === undefined 时，实际上会去 window 上读取变量，读取的多了，也就让我们开始遐想有没有办法通过不断调用 undefined 变量使系统崩溃。不过值得庆幸的是，undefined 是不能重新赋值的，undefined = 1 虽然不会报错，但是没效果。而执行 null = 1 则会直接报错。就是这么奇妙。
虽然使用 typeof 要多写好多个字母，但是，抛开其他各种个人偏好问题，上面这两个理由足以让人选择 typeof 的形式来判断 undefined 了。
刚开始注册了codepen，用了一会儿就开始不舒服，咋只能用cdn连入包呢？然后转战codesandbox，这才是我要的呀。直接在线写项目，毫无压力，包管理，在线编译查看效果，一切都非常符合我的口味。顺带，看了 codesandbox 的实现原理，浏览器端实现编译，也是牛皮哄哄的。当然，说了这么多，我主要还是用它来实现 demo 效果，感觉也是嘴上说的好，实际上也是牛刀杀鸡用。
