意识上传，数字飞升。风口，绝对的风口

吐槽 promise 那一段相当诡异，还 monkeypatch 你还真是着了道了，程序设计成一坨屎应该怪语言吗？

看了下大家的评论，除了那个说 html 是世界上最好的语言的故意引战言论，其他说的都挺认真的没啥问题，从描述很明显能看出楼主对于前端了解的不多，"没有参数的函数不加括号也可以" 把我逗乐了，不过也怪不得一个新手，很明显这是 vue 的锅，template 中的传入的事件函数是框架做了处理而不是语言设计问题。typescript ，typescript ，前面的同学说了多少次了，去了解下吧。

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

@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 复用一无是处

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