我以为 “写给前端” 会从 “你怎么让元素 B 的颜色随着按钮 A 的位置移动而改变” 这种角度入门

之前有一个帖子问 怎么实现对象值之间的相互约束，比如定义 C=A+B，改变 AB 的值能直接导致 C 结果改变。这种具体场景才好解释函数式的特点和必要性


写给前端为啥不直接讲讲怎样 “make something reactive” ?

阻止处理照片的意义是什么？

游戏中这么多外星人和超级英……







我是有多无聊才忍不住回这个帖子

@mayx
@ruixue

google 定这个名字的时候是 06 年，我这句话跟 “什么大清亡了？” 是一个意思：2021 年了才知道百度浪费时间吗

“google 中文名居然定成了谷歌？”

因为 md 语法里没有 style

markdown 就是为了分离格式语法和渲染效果而发明的

有些 md 编辑器支持自定义 css 可以实现自定义样式

能有啥问题？？ 光 static 咋看得出来

static 又不可能是接口方法

你又不描述这些 static 是干啥的
static plus 1+1 这种方法能有啥问题嘛

直接大群里发

“谁老趁我不在偷吃我东西！这个月已经吃了我 2 罐八宝粥、3 瓶纯牛奶、2 个面包、1 瓶营养快线啦！！”

这个时候就会有行政出来强调纪律然后有其他人帮你哈哈哈打圆场




*仅适用于他不知道你知道是他的情况

@imdong 我的说法只是写单元测试的思路 hint 而已，并不是单元测试的方法论……

当你不知道你写的这坨代码从什么角度写测试时，用我提到的方法来构造一些可递归拆解的 “单元”，拆到你自我感觉足够独立足够单元后，就好对它们进行测试了

实际上在写的时候，肯定要根据实际情况考虑正负分支、边界异常条件什么的。我是觉得到写 assert 的时候自然会多想到一些条件来 assert 的，不用说太细

想象一下 UI 编程。
把 click 看成一个 signal，http 模块把现在文本框的内容 post 出去作为 slot

显然在 button 的 onclick handler 里完全没必要实例化一个 http requester，从某个全局区获取一个 requester 再进行请求则更显怪异。优雅的做法当然是让 click 只作为一个信号灯，我们找一个第三者视角，看到灯亮的时候指使 http 模块发出请求。在第三者的上帝视角里能看到 button 的实例与 http 模块的实例，而 button 和 http 相互并不需要知道对方的实例存在。

这是 qt 框架最基本的事件响应机制。基本上有 signal 这个概念的框架设计理念都是类似的。

@www5070504 对于 #6 提到的场景，如果要做单元测试，那么思路是

1. 前提：确定 receiver 的正确性
2. 把 foo 产生的 value 喂给 receiver，在 receiver 上断言行为符合预期
3. 如果 1 不能确定，递归拆解问题