周报 2021W06
写日报或周报，是职场中很常见的事情。一个有效的报告，对于自己，能够梳理思路，总结并发现问题或解决方案；对于上级，可以了解下属的状态、处境，借此判断与总体规划之间的出入，以及为可能发生的事情做预案等。
以上是一般意义上的日报、周报，我在写的这篇以及日后要写的与其有所不同。
这是我的第一篇面向公众的周报，所以先来说下这个「周报」是什么，以及为什么要写。
写作动机
在 2020 年的年终总结中提到了我所认为的「元模型」之一的「事件模型」——
事件模型，拥有时间、地点、相关人物、发生的事情这四个属性。其中，发生的事情的内容是可以不断提炼的，从一段描述中抽象出无数个模型，用来渐进式强化与完善自己的知识/能力体系。一个事件就是自己的一次经历，多个连续的事件就构成了时间线，是自己的一段人生经历。
前些日子简单说了下我关于「人生 OKR」的想法——
首先要有人生目标，将其拆成十年目标、五年目标、年目标和季度目标；每级目标分解出几个关键结果，除了季度的关键结果会成为下一级目标的参考，季度的关键结果会成为更细分的任务落实到每一天。
人生 OKR 与工作 OKR/KPI 最好是重叠的，这样可以事半功倍，更好地提高完成度和质量。
每日之事都要记录，以周或月的频次复盘。
还有关于自我督促的方式——
自我督促的方式之一就是——在公众面前或到处立 flag，然后定期复盘，给自己戴上枷锁。
我将引文中的重点语句加粗了，通过它们引申并总结出我所要写的这个「周报」是什么，以及为什么要写——
写作的意义
每天我会通过个人网站的「想法」、微信朋友圈等方式记录某个时间点所发生的让我觉得有意义的事情或想法，从而形成「事件模型」中的一个「事件」，「人生经历」这个「数据库」中的一条「数据」。这样，那时那刻的信息和感受就「持久化」了，不会随着时间的流失、脑容量的溢出和记忆力的衰退而逐渐消失。
然而，「事件」只是记录下来是没有用的，是毫无价值的「数据」，仅当从中发现了什么让自己成长的东西，才初次产生了价值，有了意义——就像第一段引文中的加粗语句所表达的——写这个「周报」就是要分析下这一周以来的「数据」，找到让自己比上一秒更好的事情。
开放的意义
我为什么要写「面向公众的周报」呢？最主要的原因是，在很多时候我自制力比较差，所以想通过这种方式为自己施加精神压力。
虽说我是不在意别人如何看我的人（不代表我听不进劝言与指谪），但我很在意在一个相对健康、合理的公众环境中自己的言行举止。因此，当我在公众空间说了我要怎样怎样之后，如果没做到，不用别人瞧不起我，我都会自我鄙视——这对我来说是比较有效的自我督促方式。
另外，我有点期待我的周报内容会帮到别人，以及在此之上的一些有效交流。
Q1 OKR
月初那几天，我公布了自己今年 Q1 的人生 OKR——
今年 Q1 的人生 OKR（从现在起到三月末）——
Objective：验证并跑通我的 UI 组件体系。
Key Results：
- 半成品 UI 组件集合 Petals 完成 90% 以上；
- 基于 Petals 写组 Vue 的结构组件；
- 两套风格配置，分别是 Ant Design 和 Element。
Q1 末或 Q2 初来个复盘总结。
当前正在做第一个 KR。
我上周五下班后就进入了春假模式，而当时老婆她们公司的安排是除夕那天开始放假，于是我计划着在她上班的那几天给 Petals 多写几个半成品 UI 组件。
然而，正所谓「计划不如变化快」，周一白天老婆告诉我她们公司的安排变了，改为周二（腊月廿八）放假……
我做事有两种截然不同的风格——要么毫无计划，随心随性，随机应变；若是有所计划，严格执行，要见成果。我向来不喜欢计划被打乱，这会使我焦躁。但这次没有，因为有个前提——
节假日，也就是有法定假期的那几天，绝大部分时间是「生活」，好好陪老婆。
正因如此，计划要做的事情也没做多少——
组件之「脑」
现在已有的 UI 组件库，普遍会把具有业务、配置语义的东西设计为 UI 组件的属性（prop），我认为这是不对的，在我的想法中，UI 组件的属性只应是表达它自然特性的——
UI 组件的属性只应与其本身的特性有关，与业务意义无关——自身特性是自然特性，业务意义是附加特性。
那如果 UI 组件需要处理具有业务、配置语义的东西，该怎么弄？先来拿人做类比，帮助理解下——
人有头、躯干、四肢、脑、五脏六腑等组成部分，经过脑活动可以进行交流、创造等——这些是人的自然特性。人的职业、角色、身份等是自然特性吗？当然不是！这些是人脑的运作机制在特定的环境、上下文中对接收到的信息处理后所形成的结果。
由此可见，人的自然特性是有限的，而由自然特性所衍生出来职业、角色、身份等则是无限的。鉴于此，倘若把 UI 组件的非自然特性设计为属性，其数量将多如牛毛。那些具有业务、配置语义的东西，理应作为环境、上下文被 UI 组件内部起到人脑作用的程序所「理解」，并做出相应的「反应」或「动作」。
在践行了「聊聊前端 UI 组件」系列文章所阐述的 UI 组件体系的 Petals 中，作为人脑存在的是 UI 组件配置的 setter 与 getter、每个 UI 组件的无头组件及结构组件的基类——设计并走通这个运作机制是我这几天所做的事情之一。
盒子组件
我给「盒子（Box）组件」的定义是：最基础的容器，仅是一个视觉透明且宽度撑满父级的方块。简单点说，就相当于是 HTML 中的 div 元素。
在我起初的设想中，这个 UI 组件有着更为复杂的结构和行为——从上到下分为 header、body 和 footer 三个部分，header 中可以放标题，footer 中能够加按钮，body 中则是主要内容；并且 footer 可以始终在整个组件区域的最下方，body 中内容过多时可出现滚动条——实际就是常见页面布局的缩小版。
但这样一来，其定位和作用就与面板（Panel）组件及卡片（Card）组件有所重叠、冲突了，キャラが被った，十分尴尬……因此先将其简化为类似于 div 的最基础的、不具备任何其他结构与行为的容器。
排版类组件
排版类 UI 组件是用来文字排版的，它们主要是在内容类页面中大显身手，对于 web 应用来说几乎无用武之地。
我暂时只弄了文本（Text）组件、标题（Heading）组件和段落（Paragraph）组件这三个使用概率相对大一些的，以及作为被它们继承的组件（基类）存在且不可单独直接使用的排版（Typography）组件。
在排版组件中定义了文本组件、标题组件和段落组件之间所共通的属性、样式和行为等，那三个组件是从排版组件派生出来的「变体」。其中，文本组件相当于 HTML 中的 span 元素，标题组件等同于 h1、h2、h3、h4、h5、h6 等元素的合体，段落组件则与 p 元素雷同。
图标组件
可以说，图标（Icon）组件是既简单又复杂的一个 UI 组件了。说它简单，是因为只有一个用来标识显示什么的必要属性；说它复杂，则由于要显示的图标的来源可能不是唯一的，如何去引用是个问题。
为了解决支持多个图标来源的问题，我引入「图标提供者（icon provider）」的概念和机制。
不像那些 UI 组件库中会内置一套图标，Petals 中没有，并且严格来说 Petals 不是「组件库」。图标组件提供了让每个项目、应用能够自定义多个图标来源的能力。
布局组件
布局（Layout）组件是几个负责页面布局的 UI 组件的集合：布局容器（LayoutContainer）组件、主要区域（LayoutMain）组件、次要区域（LayoutAside）组件、顶部区域（LayoutHeader）组件和底部区域（LayoutFooter）组件。
它们能够组合出常见的上中下、左中右页面布局——
在开发 UI 组件的同时，规范了宽松尺寸，即值可为数字或字符串的尺寸的正常化（normalization）逻辑。
社交软件
什么是「社交软件」？在本文中，它是一个相对广泛的含义——任何 to C 的，具备社交功能或性质的应用，像微信、抖音、知乎、脉脉、淘宝等，都是。
精神鸦片
本该由我们自由支配，进行娱乐、运动、学习、陪家人、见朋友等活动的日常生活，正在被各种社交软件所蚕食。
不知各位有没有意识到，就是除了上班、吃喝拉撒睡等生存或生理上所必须花费的时间之外，自己其他时间中的绝大部分都被刷各种社交软件所占用了，并且看的和参与的净是些对自己没什么帮助的！
如果你没意识到或者意识到了但靠自己难以改善，很遗憾，社交软件对你来说已经是精神鸦片了；否则，恭喜你，请继续保持与社交软件的距离。
关于我的更多看法，请看《欧雷说：「社交软件是精神鸦片？」》——
我们的隐私、生活已经被那些应用严重侵犯了，尤其是移动应用，就像刘擎教授在《奇葩说 第七季》中所说：「哈贝马斯将把这个世界分成两种，一个是系统，一个是生活世界，友谊感情爱情伦理生活，现在是系统殖民了生活世界，这个需要我们非常警惕。」
资本陷阱
之所以社交软件会变成精神鸦片，文化不高的我认为其背后原因是资本主义的底层运作机制和阶级矛盾。在 B 站看过《【硬核社会学】996、内卷、打工人：马克思为什么是对的（上）{:target=”_blank”}{:rel=”external nofollow”}》和《【硬核社会学】消费资本主义：控制世界的新宗教{:target=”_blank”}{:rel=”external nofollow”}》之后，更加确信自己的观点了。