# 视图名称
## 概述
视图名称的作用，是为了辅助开发者实现 “使用抽象名称，而非确切的视图ID完成视图跳转” 的效果。
通常情况下，开发者并不需要声明视图名称。但当开发者实现了视图的动态集成，并且相同作用的视图可能存在多个的时候，通过使用视图名称，基本就可以不用修改代码，便能保证视图之间动态集成的有效性了。
> 如果使用确切的视图ID，开发者会面临 “如何得知跳转的目标视图ID是否已集成到页面中” 这一问题。为此不得不借助视图配置，或分别撰写跳转代码，这样就无形之中提高了视图之间的耦合度，降低了代码的有效复用度。
## 声明视图名称
开发者可以通过在视图的 DOM 骨架上声明 `data-view-name` 属性来声明视图名称。例如：
{% tabs %}
{% tab title="main.html" %}
```markup
```
{% endtab %}
{% endtabs %}
> 视图名称当前不支持通过API动态设定。
## 使用视图名称
只有在进行视图跳转时，开发者才需要使用视图名称。此时，视图名称将作为导航目标而存在，例如：
{% tabs %}
{% tab title="main.html" %}
```markup
```
{% endtab %}
{% tab title="action.js" %}
```javascript
/* 导航至 商品详情 */
View.navTo("~goods-detail");
```
{% endtab %}
{% endtabs %}
当使用视图名称执行视图跳转时，View\.js 将自动检索所有声明为给定名称的视图，并将检索到的第一个作为目标视图跳转过去。
对于上述代码，当用户点击 “商品详情” 链接时，View\.js 将自动跳转至 `goods-detial_01` 视图。
## 延申
为了最大限度的节约研发成本，提升软件利润，软件公司会将一套程序销售给多家需求相近的客户。
这些客户大多对软件的整体UI和功能基本满意，但细微之处又各有各的诉求。可能是界面布局，也可能是业务逻辑，抑或是功能的丰富完善或调整。
相比整个软件功能，这些差异化的诉求所占据的工作量，可能不足10%，也可能高达40%，甚至于70%。
软件公司不可能因为这些客户不是“没有一点意见的完美客户”就放弃订单，但把代码在工程中分别硬拷贝生成多份的操作，又会把摊子铺的太大，担心维护成本会一下子放大很多。
软件公司的担心不无道理。没有人会乐意将同一个故障的修复过程一遍遍的向多个工程中同步。
针对这个问题，View\.js 建议软件公司将实现的视图功能放到一个巨大的视图仓库中，借助构建脚本将视图动态集成到客户的页面上去。对于客户提出的个性化诉求，软件公司可以将其以视图为单位进行实现。
借助这种方式，差异化诉求的实现成本，就降低到了可量化计算的多个视图的功能开发上，而对于没有个性化诉求的共用视图，则始终只有一份副本。如此一来，可以“头疼医头，脚疼医脚”，能够极大地节约软件公司的开发资源。与此同时，开发团队也能够持续不断地积累仓库，使得复用能力越来越强。
虽然 View\.js 当前只是一个运行在浏览器中的单页框架，但不远的未来某天，我们会给开发者提供给模板化的开发工程，使得开发者轻松实现视图的动态集成。