你可以涨价，也可以说明清楚仅当前版本买断，否则你搞二次收费在消费者的角度看就是欺诈，评价吃相难看并不过分。

@EvansUtopia 哈哈哈啊哈哈

@2i2Re2PLMaDnghL 说的好，你指出了两个看上去可行的替代方案。
现在我顺着之前的例子继续延伸，在全局 request 方法中通常需要添加一个异常拦截器，我希望在状态码异常时调用 notification 弹出错误消息（包涵额外组件）并返回 Promise.reject 。
按照你 notifiable 组件的逻辑，我是不是要将这个全局处理定义为.vue 文件？
并且我在什么地方调用 request 方法，就要在什么地方导入并初始化这个组件。
如果没有发生请求异常，那么在运行时的 notifiable 组件初始化产生的算力开销是无意义的。
这合理吗？这不合理。

所以在这种场景下，良好的解决方案应该使用你说的 sexpr ，也就是半结构化表达式来创建 VNode ，并手动将 VNode 挂载到真实 DOM 上（这里手动挂载的操作在 react 中也是一样的）。
能做到，但是很麻烦且难以阅读。

我写过两年以上的 vue ，一直在尝试解决这个问题，但是没有成功，只能通过手动创建 VNode 来妥协。
这是一种回归本源的操作，就好像某一个高级语言你写着写着，忽然发现某一个功能无法实现，你只能通过手敲二进制码来曲线救国，这样的缺陷要是放在一个语言中，我完全可以将其定义为图灵不完备。

这是在 template 方案设计之初就注定无法弥补的缺陷。
缺陷就是缺陷，大可不必那么倔。

@gadfly3173 你这一条把我逗乐了，你好好阅读一下 antd 的文档，notification 的 api 中 message 和 description 字段接收的类型到底是啥，看清楚了再发表想法。如果你不知道 ReactNode 类型意味这什么，去查阅 react 文档，希望你有所收获。

@2i2Re2PLMaDnghL 任何人在 vue 中使用任何方案我都没有意见，你甚至可以使用 jq ，这与我们讨论的议题有关联吗？我要捍卫的，是 template 相对于 jsx 具有致命缺陷这一真理。

楼上有个老哥称述了 react 使用优雅这一事实，并没有提到 vue 怎么怎么样，迅速引来一群人围攻，并且这些人的论据是可笑的 template 优于 jsx 这一观点。

拿着牙签拼刺刀。

大多数人都是谦逊的，不屑于争论，这让一些人产生了“我很能打”的错觉。

@Alander @gadfly3173 不管是 notification 还是 dialog ，还原的都是在 render 函数之外插入 React.Node 的场景，notification 中添加操作按钮简直不要太常见，加个 icon ，加个链接，导一个组件，等等。。怼都怼不到点上，只会暴露出自己代码写得少。

此特性属于基础特性、基础功能，它没有得到支持，这就是客观事实。

@Alander 自始至终我都是基于 “template 方案优于 jsx 方案” 这个观点提出异议，根本没有反对在 vue 中使用 jsx ，你这种篡改发言的行为有点莫名其妙。

@murmur

试想想一个场景，你需要弹出 10 个 notification ，每一个的 content 都不相同，它不是简单的 string ，里面有 input ，有 button ，有其他组件，量不大。按你说的封装策略，是不是需要封装 10 个组件？这些代码分散后，阅读者无法一目了然的掌握所有逻辑，还得一个个找，可读性是不是就差了？

@Alander

你最好查看并尝试理解一下 15 楼老哥到底说了啥。

你也提到了用 jsx 写 vue ，你看，你这不是能理解吗？
遗憾的是，vue 的 jsx 与 ts 的契合度非常差。

这是一个简单的例子， `notification.error` 方法会在执行后弹出一条消息。注意此方法可以在任意区域执行。
```tsx
notification.error({
content: (
<div>Any React.ReactNode</div>
)
})
```

@Alander

“只有新手才会在 jsx 中添加大量业务代码。” 是反驳 @murmur 在 15 楼的观点。

依赖库中存在大篇幅代码和业务代码中的上千行是两码事，你在日常开发中根本不需要阅读和维护库中的代码，而业务代码不同，篇幅越大越难以理解。

react 的优雅是在于程序设计，而不是代码范式。

你似乎不太理解插入元素的含义，插入的不是原生 dom ，而是 jsx 虚拟 dom ，我真的不太明白你是怎么理解到那上面的，这让我感觉你似乎不是很懂。

逐句对线你似乎怒气很大，就像炸了毛的刺猬，有点好笑。

@gamexg
#19

哈哈哈，这就就要说到大名鼎鼎的 node_modules 了
npm 默认会自动安装依赖的最新小版本，即使强行锁版本，但依然无法锁住依赖的依赖的版本（也就是二级依赖），所以当过了一段时间后，这些依赖还是会在 npm install 时被更新，由于这时间，整体的依赖库已经发生变化，这些被更新的依赖只要存在 api 变更或兼容性问题，就有可能发生 node 运行事故。

@murmur

只有新手才会在 jsx 中添加大量业务代码。

vue 的 template 类 UI 描述方案饱受诟病的核心原因是在 js 代码中无法插入元素，只能手动创建 VNode ，以及没有 TS 类型提示，这将导致功能性、灵活性丢失。

@66beta


所谓单文件就是 css 与 js 放在一起，小组件无所畏惧，大型业务组件呢？上千行的代码难道不是糟糕的代码吗？

@Robertwhite 考虑一下把高阶组件换成修饰器，需要复用的东西采用抽象派生，那才叫优雅

@ReferenceE 只有用 function 关键字才会提升吧？在用 TS 的情况下，似乎只能用箭头函数的方式赋予 React.FC 泛型，还有 React.memo，也不能用 function 关键字声明。

函数式组件每一次 rerender 都会执行函数体内的所有代码，需要通过 useEffect 和 useCallback 优化，增加了开发者的心智负担，尤其对于新手而言更容易写出低性能代码。

函数式组件还不能被继承，我认为函数式组件除了 hooks 复用一无是处

坦率一点不好吗? 筛选一下身边的朋友，离那些口是心非的垃圾玩意儿远一点。还有这根程序员有什么关系？

你们那么多用 GraphQL 的大佬，我想问一句，字符串模板里面怎么整合 TS 类型？

理性的争论是好事，帖子本身是有价值的。
看了各位的观点收货颇丰，我总结一下我所认同的观点：

## 优点
- 类型推导, 一切可溯源
- ide 代码补全增强, 降低心智负担
- 第三方库不看文档直接打点就用
- 映射后端接口, 确保字段的准确性
- 依然可以保持 JS 动态类型特性, 可以通过 as, any 逃课。
- 类型即文档 (且与代码深度集成)，大家都不喜欢写文档。类型定义了，文档就有了
- 易于维护, 随便翻一个函数，不用看上下文，就知道参数类型，返回值类型
- 规范化约束整个团队
- 易于修改 (变量使用 F2 重命名)

## 缺点
- 开发成本 +
- 学习成本 ++
- 用人成本 +++

编译后的 React 代码，这根本不是源码。