本文共 6735 字，大约阅读时间需要 22 分钟。
这里记录的都是和处理边界情况有关的功能，即一些需要对 Vue 的规则做一些小调整的特殊情况。不过注意这些功能都是有劣势或危险的场景的。我们会在每个案例中注明，所以当你使用每个功能的时候请稍加留意。
在绝大多数情况下，我们最好不要触达另一个组件实例内部或手动操作 DOM 元素。不过也确实在一些情况下做这些事情是合适的。
在每个 new Vue 实例的子组件中，其根实例可以通过 $root 属性进行访问。例如，在这个根实例中：
// Vue 根实例new Vue({ data: { foo: 1 }, computed: { bar: function () { /* ... */ } }, methods: { baz: function () { /* ... */ } }}) |
所有的子组件都可以将这个实例作为一个全局 store 来访问或使用。
// 获取根组件的数据this.$root.foo// 写入根组件的数据this.$root.foo = 2// 访问根组件的计算属性this.$root.bar// 调用根组件的方法this.$root.baz() |
对于 demo 或非常小型的有少量组件的应用来说这是很方便的。不过这个模式扩展到中大型应用来说就不然了。因此在绝大多数情况下，我们强烈推荐使用 来管理应用的状态。
和 $root 类似，$parent 属性可以用来从一个子组件访问父组件的实例。它提供了一种机会，可以在后期随时触达父级组件，以替代将数据以 prop 的方式传入子组件的方式。
在绝大多数情况下，触达父级组件会使得你的应用更难调试和理解，尤其是当你变更了父级组件的数据的时候。当我们稍后回看那个组件的时候，很难找出那个变更是从哪里发起的。
另外在一些可能适当的时候，你需要特别地共享一些组件库。举个例子，在和 JavaScript API 进行交互而不渲染 HTML 的抽象组件内，诸如这些假设性的 Google 地图组件一样：
| |
这个 <google-map> 组件可以定义一个 map 属性，所有的子组件都需要访问它。在这种情况下 <google-map-markers> 可能想要通过类似 this.$parent.getMap 的方式访问那个地图，以便为其添加一组标记。你可以在查阅这种模式。
请留意，尽管如此，通过这种模式构建出来的那个组件的内部仍然是容易出现问题的。比如，设想一下我们添加一个新的 <google-map-region> 组件，当 <google-map-markers> 在其内部出现的时候，只会渲染那个区域内的标记：
| |
那么在 <google-map-markers> 内部你可能发现自己需要一些类似这样的 hack：
var map = this.$parent.map || this.$parent.$parent.map |
很快它就会失控。这也是我们针对需要向任意更深层级的组件提供上下文信息时推荐的原因。
尽管存在 prop 和事件，有的时候你仍可能需要在 JavaScript 里直接访问一个子组件。为了达到这个目的，你可以通过 ref 特性为这个子组件赋予一个 ID 引用。例如：
| |
现在在你已经定义了这个 ref 的组件里，你可以使用：
this.$refs.usernameInput |
来访问这个 <base-input> 实例，以便不时之需。比如程序化地从一个父级组件聚焦这个输入框。在刚才那个例子中，该 <base-input> 组件也可以使用一个类似的 ref 提供对内部这个指定元素的访问，例如：
甚至可以通过其父级组件定义方法：
methods: { // 用来从父级组件聚焦输入框 focus: function () { this.$refs.input.focus() }} |
这样就允许父级组件通过下面的代码聚焦 <base-input> 里的输入框：
this.$refs.usernameInput.focus() |
当 ref 和 v-for 一起使用的时候，你得到的引用将会是一个包含了对应数据源的这些子组件的数组。
$refs 只会在组件渲染完成之后生效，并且它们不是响应式的。这只意味着一个直接的子组件封装的“逃生舱”——你应该避免在模板或计算属性中访问 $refs。
在此之前，在我们描述的时候，展示过一个类似这样的例子：
| |
在这个组件里，所有 <google-map> 的后代都需要访问一个 getMap 方法，以便知道要跟那个地图进行交互。不幸的是，使用 $parent 属性无法很好的扩展到更深层级的嵌套组件上。这也是依赖注入的用武之地，它用到了两个新的实例选项：provide和 inject。
provide 选项允许我们指定我们想要提供给后代组件的数据/方法。在这个例子中，就是 <google-map> 内部的 getMap 方法：
provide: function () { return { getMap: this.getMap }} |
然后在任何后代组件里，我们都可以使用 inject 选项来接收指定的我们想要添加在这个实例上的属性：
inject: ['getMap'] |
你可以在看到完整的示例。相比 $parent 来说，这个用法可以让我们在任意后代组件中访问 getMap，而不需要暴露整个 <google-map> 实例。这允许我们更好的持续研发该组件，而不需要担心我们可能会改变/移除一些子组件依赖的东西。同时这些组件之间的接口是始终明确定义的，就和 props 一样。
实际上，你可以把依赖注入看作一部分“大范围有效的 prop”，除了：
然而，依赖注入还是有负面影响的。它将你的应用以目前的组件组织方式耦合了起来，使重构变得更加困难。同时所提供的属性是非响应式的。这是出于设计的考虑，因为使用它们来创建一个中心化规模化的数据跟做这件事都是不够好的。如果你想要共享的这个属性是你的应用特有的，而不是通用化的，或者如果你想在祖先组件中更新所提供的数据，那么这意味着你可能需要换用一个像 这样真正的状态管理方案了。
你可以在 学习更多关于依赖注入的知识。
现在，你已经知道了 $emit 的用法，它可以被 v-on 侦听，但是 Vue 实例同时在其事件接口中提供了其它的方法。我们可以：
$on(eventName, eventHandler) 侦听一个事件$once(eventName, eventHandler) 一次性侦听一个事件$off(eventName, eventHandler) 停止侦听一个事件你通常不会用到这些，但是当你需要在一个组件实例上手动侦听事件时，它们是派得上用场的。它们也可以用于代码组织工具。例如，你可能经常看到这种集成一个第三方库的模式：
// 一次性将这个日期选择器附加到一个输入框上// 它会被挂载到 DOM 上。mounted: function () { // Pikaday 是一个第三方日期选择器的库 this.picker = new Pikaday({ field: this.$refs.input, format: 'YYYY-MM-DD' })},// 在组件被销毁之前，// 也销毁这个日期选择器。beforeDestroy: function () { this.picker.destroy()} |
这里有两个潜在的问题：
picker，如果可以的话最好只有生命周期钩子可以访问到它。这并不算严重的问题，但是它可以被视为杂物。你应该通过一个程序化的侦听器解决这两个问题：
mounted: function () { var picker = new Pikaday({ field: this.$refs.input, format: 'YYYY-MM-DD' }) this.$once('hook:beforeDestroy', function () { picker.destroy() })} |
使用了这个策略，我甚至可以让多个输入框元素同时使用不同的 Pikaday，每个新的实例都程序化地在后期清理它自己：
mounted: function () { this.attachDatepicker('startDateInput') this.attachDatepicker('endDateInput')},methods: { attachDatepicker: function (refName) { var picker = new Pikaday({ field: this.$refs[refName], format: 'YYYY-MM-DD' }) this.$once('hook:beforeDestroy', function () { picker.destroy() }) }} |
查阅 可以了解到完整的代码。注意，即便如此，如果你发现自己不得不在单个组件里做很多建立和清理的工作，最好的方式通常还是创建更多的模块化组件。在这个例子中，我们推荐创建一个可复用的 <input-datepicker> 组件。
想了解更多程序化侦听器的内容，请查阅相关的 API。
注意 Vue 的事件系统不同于浏览器的 。尽管它们工作起来是相似的，但是 $emit、$on, 和 $off 并不是 dispatchEvent、addEventListener 和 removeEventListener 的别名。
组件是可以在它们自己的模板中调用自身的。不过它们只能通过 name 选项来做这件事：
name: 'unique-name-of-my-component' |
当你使用 Vue.component 全局注册一个组件时，这个全局的 ID 会自动设置为该组件的 name 选项。
Vue.component('unique-name-of-my-component', { // ...}) |
稍有不慎，递归组件就可能导致无限循环：
name: 'stack-overflow',template: ' |
类似上述的组件将会导致“max stack size exceeded”错误，所以请确保递归调用是条件性的 (例如使用一个最终会得到 false 的 v-if)。
假设你需要构建一个文件目录树，像访达或资源管理器那样的。你可能有一个 <tree-folder> 组件，模板是这样的：
|
还有一个 <tree-folder-contents> 组件，模板是这样的：
|
当你仔细观察的时候，你会发现这些组件在渲染树中互为对方的后代和祖先——一个悖论！当通过 Vue.component 全局注册组件的时候，这个悖论会被自动解开。如果你是这样做的，那么你可以跳过这里。
然而，如果你使用一个模块系统依赖/导入组件，例如通过 webpack 或 Browserify，你会遇到一个错误：
Failed to mount component: template or render function not defined. |
为了解释这里发生了什么，我们先把两个组件称为 A 和 B。模块系统发现它需要 A，但是首先 A 依赖 B，但是 B 又依赖 A，但是 A 又依赖 B，如此往复。这变成了一个循环，不知道如何不经过其中一个组件而完全解析出另一个组件。为了解决这个问题，我们需要给模块系统一个点，在那里“A 反正是需要 B 的，但是我们不需要先解析 B。”
在我们的例子中，把 <tree-folder> 组件设为了那个点。我们知道那个产生悖论的子组件是 <tree-folder-contents> 组件，所以我们会等到生命周期钩子 beforeCreate 时去注册它：
beforeCreate: function () { this.$options.components.TreeFolderContents = require('./tree-folder-contents.vue').default} |
或者，在本地注册组件的时候，你可以使用 webpack 的异步 import：
components: { TreeFolderContents: () => import('./tree-folder-contents.vue')} |
这样问题就解决了！
当 inline-template 这个特殊的特性出现在一个子组件上时，这个组件将会使用其里面的内容作为模板，而不是将其作为被分发的内容。这使得模板的撰写工作更加灵活。
|
不过，inline-template 会让你模板的作用域变得更加难以理解。所以作为最佳实践，请在组件内优先选择 template 选项或 .vue 文件里的一个 <template> 元素来定义模板。
另一个定义模板的方式是在一个 <script> 元素中，并为其带上 text/x-template的类型，然后通过一个 id 将模板引用过去。例如：
Vue.component('hello-world', { template: '#hello-world-template'}) |
这些可以用于模板特别大的 demo 或极小型的应用，但是其它情况下请避免使用，因为这会将模板和该组件的其它定义分离开。
感谢 Vue 的响应式系统，它始终知道何时进行更新 (如果你用对了的话)。不过还是有一些边界情况，你想要强制更新，尽管表面上看响应式的数据没有发生改变。也有一些情况是你想阻止不必要的更新。
如果你发现你自己需要在 Vue 中做一次强制更新，99.9% 的情况，是你在某个地方做错了事。
你可能还没有留意到或的变更检测注意事项，或者你可能依赖了一个未被 Vue 的响应式系统追踪的状态。
然而，如果你已经做到了上述的事项仍然发现在极少数的情况下需要手动强制更新，那么你可以通过 来做这件事。
渲染普通的 HTML 元素在 Vue 中是非常快速的，但有的时候你可能有一个组件，这个组件包含了大量静态内容。在这种情况下，你可以在根元素上添加 v-once 特性以确保这些内容只计算一次然后缓存起来，就像这样：
Vue.component('terms-of-service', { template: ` |
再说一次，试着不要过度使用这个模式。当你需要渲染大量静态内容时，极少数的情况下它会给你带来便利，除非你非常留意渲染变慢了，不然它完全是没有必要的——再加上它在后期会带来很多困惑。例如，设想另一个开发者并不熟悉 v-once 或漏看了它在模板中，他们可能会花很多个小时去找出模板为什么无法正确更新。
from：
转载地址：http://lzwrf.baihongyu.com/