共计 3771 个字符，预计需要花费 10 分钟才能阅读完成。
作者：Michael Thiessen
译者：前端小智
起源：medium
点赞再看，微信搜寻 【大迁世界】 关注这个没有大厂背景，但有着一股向上踊跃心态人。本文
GitHubhttps://github.com/qq44924588… 上曾经收录，文章的已分类，也整顿了很多我的文档，和教程材料。
控制流指令，如 v-if 和v-for，如果在较大我的项目中，就很有可能会创立一些难以浏览的嵌套代码。如果在 v-if 内嵌套了v-for，刚这个特色就更显著了。
为了程序员的头发着想，我心愿大家不要编写具备多级嵌套代码。
然而，如果你偏要这么干，那么送你一个技巧，能够以轻松地将这些噩梦转变成童话故事。
一个孤单的子组件
当嵌套开始变多时，如果我还想要放弃整洁，我的默认做法是将代码提取到一个新组件中。
应用 v-for 和v-if，咱们把指令中的所有货色都转换成它本人的组件。
举个例子来看看，咱们从这个有嵌套的模板开始
<template>
<div>
<h1>{{title}}</h2>
<div class="navigation">
<!-- ... -->
</div>
<div v-for="item in list">
<h2 class="item-title">
{{item.title}}
</h2>
<p class="item-description">
{{item.description}}
</p>
</div>
<footer>
<!-- ... -->
</footer>
</div>
</template>
接着，咱们把 v-for 外面的内容提取到一个新的组件中：
<template>
<div>
<h2 class="item-title">
{{item.title}}
</h2>
<p class="item-description">
{{item.description}}
</p>
</div>
</template>如果咱们导入这个新组件，咱们会看到它很好地解脱了所有嵌套:
<template>
<div>
<h1>{{title}}</h2>
<div class="navigation">
<!-- ... -->
</div>
<ListItem
v-for="item in list"
:item="item"
/>
<footer>
<!-- ... -->
</footer>
</div>
</template>此示例中没有太多的嵌套，所以独自为一小部分内容做一个组件，有点繁琐。然而，如果咱们有两个，三个或更多的嵌套级别，则此技巧能够打消嵌套构造并让代码更易于了解。
但这里有一个问题: 为什么咱们不把 v-for 指令也写入新的组件中？
咱们应该把控制流指令放入新的组件中吗？
假如，咱们下面的 v-for 放到新的组件内，则咱们会失去上面的构造：
<template>
<div>
<h1>{{title}}</h2>
<div class="navigation">
<!-- ... -->
</div>
<List :list="list" />
<footer>
<!-- ... -->
</footer>
</div>
</template>这样看上去，父组件的确清晰很多。但可怜的是，这种变向的把复杂度放到了子组件中：
<template>
<div>
<div v-for="item in list">
<h2 class="item-title">
{{item.title}}
</h2>
<p class="item-description">
{{item.description}}
</p>
</div>
</div>
</template>哪种形式更好？
如果你最终的目标就是想缩小嵌套数量，那么这个抉择必定更蹩脚。咱们在子组件中增加了额定的嵌套级别，而没有缩小父组件中的嵌套级别。
通常，我会防止将诸如 v-if 和v-for之类的控制流指令放在这样的组件的根部，因为它会影响可重用性。
如果只须要一个简略ListItem 该怎么办？
假如应用v-if，如果要应用不同的逻辑在组件之间进行切换，或者要应用齐全不同的组件怎么办？
将控制流指令写小最小通用构造的组件中会限度咱们的灵活性，而不会给咱们带来更多的便利性。因而，我偏向于将控制流指令留在这样的小组件之外。我还尝试防止将它们放在组件的根部。
一旦你深刻理解“底层”的状况，此问题及其解决方案就会显得更加有劣势。
https://www.digitalocean.com/…
作者：Michael Thiessen
译者：前端小智
起源：medium
点赞再看，微信搜寻 【大迁世界】 关注这个没有大厂背景，但有着一股向上踊跃心态人。本文
GitHubhttps://github.com/qq44924588… 上曾经收录，文章的已分类，也整顿了很多我的文档，和教程材料。
控制流指令，如 v-if 和v-for，如果在较大我的项目中，就很有可能会创立一些难以浏览的嵌套代码。如果在 v-if 内嵌套了v-for，刚这个特色就更显著了。
为了程序员的头发着想，我心愿大家不要编写具备多级嵌套代码。
然而，如果你偏要这么干，那么送你一个技巧，能够以轻松地将这些噩梦转变成童话故事。
一个孤单的子组件
当嵌套开始变多时，如果我还想要放弃整洁，我的默认做法是将代码提取到一个新组件中。
应用 v-for 和v-if，咱们把指令中的所有货色都转换成它本人的组件。
举个例子来看看，咱们从这个有嵌套的模板开始
<template>
<div>
<h1>{{title}}</h2>
<div class="navigation">
<!-- ... -->
</div>
<div v-for="item in list">
<h2 class="item-title">
{{item.title}}
</h2>
<p class="item-description">
{{item.description}}
</p>
</div>
<footer>
<!-- ... -->
</footer>
</div>
</template>
接着，咱们把 v-for 外面的内容提取到一个新的组件中：
<template>
<div>
<h2 class="item-title">
{{item.title}}
</h2>
<p class="item-description">
{{item.description}}
</p>
</div>
</template>如果咱们导入这个新组件，咱们会看到它很好地解脱了所有嵌套:
<template>
<div>
<h1>{{title}}</h2>
<div class="navigation">
<!-- ... -->
</div>
<ListItem
v-for="item in list"
:item="item"
/>
<footer>
<!-- ... -->
</footer>
</div>
</template>此示例中没有太多的嵌套，所以独自为一小部分内容做一个组件，有点繁琐。然而，如果咱们有两个，三个或更多的嵌套级别，则此技巧能够打消嵌套构造并让代码更易于了解。
但这里有一个问题: 为什么咱们不把 v-for 指令也写入新的组件中？
咱们应该把控制流指令放入新的组件中吗？
假如，咱们下面的 v-for 放到新的组件内，则咱们会失去上面的构造：
<template>
<div>
<h1>{{title}}</h2>
<div class="navigation">
<!-- ... -->
</div>
<List :list="list" />
<footer>
<!-- ... -->
</footer>
</div>
</template>这样看上去，父组件的确清晰很多。但可怜的是，这种变向的把复杂度放到了子组件中：
<template>
<div>
<div v-for="item in list">
<h2 class="item-title">
{{item.title}}
</h2>
<p class="item-description">
{{item.description}}
</p>
</div>
</div>
</template>哪种形式更好？
如果你最终的目标就是想缩小嵌套数量，那么这个抉择必定更蹩脚。咱们在子组件中增加了额定的嵌套级别，而没有缩小父组件中的嵌套级别。
通常，我会防止将诸如 v-if 和v-for之类的控制流指令放在这样的组件的根部，因为它会影响可重用性。
如果只须要一个简略ListItem 该怎么办？
假如应用v-if，如果要应用不同的逻辑在组件之间进行切换，或者要应用齐全不同的组件怎么办？
将控制流指令写小最小通用构造的组件中会限度咱们的灵活性，而不会给咱们带来更多的便利性。因而，我偏向于将控制流指令留在这样的小组件之外。我还尝试防止将它们放在组件的根部。
一旦你深刻理解“底层”的状况，此问题及其解决方案就会显得更加有劣势。
代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
原文：https://www.digitalocean.com/…
交换
文章每周继续更新，能够微信搜寻 【大迁世界】 第一工夫浏览，回复 【福利】 有多份前端视频等着你，本文 GitHub https://github.com/qq449245884/xiaozhi 曾经收录，欢送 Star。
