vue 是不是在理论上，任何情况下都不需要操作 dom？

[mostkia]

请教一下，vue 是不是在理论上，任何情况下都不需要操作 dom ？看到 vue 的官方说明里提到，尽量不要操作 dom ，应该交给 vue 来处理。

但某些情况下似乎的确得操作 dom ，比如点击时一个 dom 时需要操作另外一个 dom 时（后来发现可以在 data 里面写个对象，然后让另外一个 dom 监视它做出反应，而 on 方法里直接改这个对象就行），但我很清楚，因为我比较熟悉传统写法，而新学 vue ，总会有 vue 写法暂时无法解决但直接操作 dom 能解决的事情，一方面想引经据典，尽量不操作 dom ，一方面一个现成方案摆在眼前不用真的有些眼馋。

有时候总在想，是不是 vue 有更好的方法解决，我这样写是不是成了异端，vue 真的是能不用就不用 dom 吗？那些情况下大家都是会选择操作 dom 的？

[GeruzoniAnsasu]

@mostkia 我后端写得多一些，半吊子前端。反正我的感觉是，vue 的设计目标就是数据-视图的自动渲染器，因为我的思维都是从后端出发的，所以好像没感觉到什么 需要 获得 dom 来取得里面数据的场景。

比方说你想拿到「某个标签的内容」，按我的自然思路是，这个内容应该也是某组数据渲染出来的，那我直接用数据不就好了，如果不存在，那是这个组件有问题，我得改这个组件让它能提供一个暴露数据的接口

如果是想「修改另一个节点的状态」，那也应该是节点 /组件各司其职，提供一个 emit 来让别人通知节点自己变更状态。这个思路跟桌面 GUI 是一样的，qt 那的 signal/slots 跟 vue 的 emits 基本上是同一种东西

-------

可能也是写过桌面 GUI 的原因，我是很忌惮直接去改变非自控 dom 的状态的，因为在桌面 GUI 程序里这样写是大忌——很容易搞不清自己当前在哪个线程里。跨线程去操作 ui 组件容易引发访问违例、死锁、竞争等各种各样奇怪的问题，所以传统桌面 GUI 的程序一律在使用各种事件去通知组件重绘自己的内容。这跟传统 js 出来的「宏状态」一把梭，一个位置掌控全页面 dom 的思路就很不一样。我倒是「天生更适应现代的前端框架」

[nomagick]

既然你已经会操作 Dom 并且知道有些事 Vue 做不了，那么你已经超过 99.9%的 Vue 用户并且不是 Vue 的目标用户群。
这个时候你就果断根据自己的判断行动就可以了。

当它能够帮你的时候就酌情用用，帮不了你也别把它奉若圭臬。

[doommm]

我感觉这不是哪一个框架的问题，而是一个编程思维（或者说编程模型？）的问题。
直接操作 dom 当然是被允许的，某些情况下是必须这么做的，但前提是遵守 vue 的一些规定，否则就会出问题。建议去看看 vue 的文档的相关部分

[mostkia]

好的，感谢，人总是得从群体中汲取智慧，车辙印虽然可能不好走，但肯定也不会把自己带进坑里，问一下大家的看法还是很有必要的 @nomagick @doommm

[mostkia]

其实前端 js 从底层设计就是基于 dom 操作视图的，所有 api 都是围绕这个目标设计的，并没有一个统一的 dom 状态管理器，没人干的活，原生 js 挑大梁自己干自然不存在你说的这种冲突。vue 这类库算是走出了第一步吧，但的确还不够健壮，还不能覆盖开发的方方面面，手动操作 dom 可以作为点缀，不能喧宾夺主，并行和 vue 两套逻辑各自争夺 dom 的控制权，我想这就是 vue 文档里说的意思吧。这里还是提出一个问题，不是抬杠啊，是实在我也不知道在 vue 里面该用什么方案解决比较好，比如要完整移动一个 dom （包括它绑定的事件，所以不能以拷贝节点方式实现，vue 中没提供相关方法，应该只能直接操作其 dom ）这在拖拽功能中是很常见的一类需求。

[mostkia]

@GeruzoniAnsasu

[mostkia]

忽然发现自己开发的一套轻量化的 MVC 组件非常适合和 vue 互补，哪天有空开源算了

[Biwood]

@mostkia 你说的拖拽和拷贝这类操作其实不适合用 vue 来写，vue 适合做那种丰富的数据展示和数据流动的系统。拖拽这类虽然 vue 也能写，也有已经封装好的插件，但是总归是不够灵活，会有很多必须按照 vue 的方式来写的约束。这种情况一般直接用一些第三方的轻量级的纯 JS 插件也是可以的。