@sinux 烤箱，尤其是柜式烤箱，使用麻烦的就是要预热。不像空气炸锅，随拧随用。

空气炸锅蛮方便的，烤地瓜，烤鸡米花，烤三文鱼，烤烧饼，只要是想保持食物酥脆特性又不想开火，空气炸锅都是好的选择。微波炉不行，微波炉加热出来就塌了。

最近淘宝买了点饼胚，炖点五花肉，想吃时拿出来，空气炸锅、微波炉双开，5 分钟吃上肉夹馍，美滋滋。

微信小程序有 wx.scanCode API ，用的是微信客户端的扫码方案。
所以，搞个小程序？
https://developers.weixin.qq.com/miniprogram/dev/api/device/scan/wx.scanCode.html

如果仅仅是 css 框架，其实还是从开发实现角度来看待这个问题。

设计语言的关注的是系统或应用中视觉传达和用户认知的调和问题。

对于设计语言来说，视觉元素都是表义的，是能够通过组合和重复在用户头脑中建立统一认知的。

认知一旦建立，用户使用产品时的心智负担和学习成本就会大大降低。「绿色的通知就是代表操作成功，红色的说明报错失败了」——不用读具体的提示文案用户也能快速做出判断。

而任何对已建立认知的强行修改都会造成用户认知报错，产生负向情绪 。用户从不会认为是自己认知的问题，而是「这个产品 /功能太沙币了」。

看看 iOS 14 时间应用中 DatePicker 样式使用混乱造成的负向反馈（随便一搜的一条，https://www.reddit.com/r/iOSBeta/comments/he4xul/ios_14_changed_the_datetime_picker_in_the/，现在又回归统一了），

再看看 PS5 强行统一各区圈、叉按键功能在主机圈引发的嘲讽。

所以，当有几十个后台，大几百个页面需求要产出，而这些页面又是下游成百上千员工每天面对几个甚至十几个小时的工作环境时，统一的设计语言就太有必要了。

不光是用户侧的考量，开发、设计、需求三方能否在统一的视觉交互认知下，快速沟通、确认方案，进入实现阶段，对于能效高低至关重要。

「是不是好看」真的不是设计语言的核心，锦上添花还差不多。

@xiao109 对的。类似发送系统邮件。

@whywaoxaks 那到确实是。我自己这边通常就 chrome+几个编辑器，还没遇到那么多问题。

哈哈哈，上半年下单 M1 的 Mini ，内存加到 16GB ，Xcode 写写 Swift UI 不说，都敢开 steam 玩玩游戏了说。

@whywaoxaks 那 20%的场景大概是啥啊？

如果只是控制屏幕内元素的选中，推荐 vimac： https://vimacapp.com/
是类似 vim 的 easy-motion 的操作方式。
开了实验功能 electron 应用也可以支持。

兴趣真的是第一决定因素。「不想做这个了」真的不是理由。

本地先将 feature 上那几个修改内容的 commit stash 掉，同步完 dev 再 pop 出来？应该会有些冲突，但都是你的代码应该是比较容易解决的。

@realtozf 也可以从业务项目向公共库抽取吧。这样可能质量和使用场景更有把控一些。支持当前项目后再向其他业务项目的场景扩展。

不然，先公共后业务，除非在开发前跟各方充分讨论，不然很容易产出脱离具体使用场景的「公共组件」。

@shintendo Vue 的 props 设计就只能 anotation 吧？ https://v3.vuejs.org/guide/typescript-support.html#annotating-props

不能像 React 那样 Component<IProps, IState>。

住公司，办张公司附近健身房的健身卡……现在国内也有公用洗衣房了。

对于一个组件库，「从确定需求->开发->其他项目集成->发布版本」中间的「其他项目集成」这步是指啥？其实你是想组件库发布和业务项目发布耦合在一起？还是仅仅是有个验证项目确保组件库更新的正确性？

基本上组件库除了单测外，都会有个 portal 或者 storybook 项目用来开发验证或展示用法。

@ysoseriousC 我只是想想变量可以跟 JS 用一套还挺方便的就用了。但用完感觉还是直接删改 className 其实就够了，可能我的需求不够复杂吧。

加到收藏夹了，期望能坚持下去阿。

无聊时自己用 react 撸 blog，样式代码就挺那啥的……（好吧，我用了 styled-components ）。

虽然日常我也经常吐槽 sfc 把整个构建流弄得乱七八糟的，配个 eslint 还要装一堆 vue 的插件，但在样式上还是比 styled-components 规整一些。

@cenbiq 多谢老师傅指点

题外话，「提桶」是怎么个梗？