CascadeView级联组件实现思路详解(分离思想和单链表)_javascript技巧

本文介绍自己最近做省市级联的类似的级联功能的实现思路，为了尽可能地做到职责分离跟表现与行为分离，这个功能拆分成了2个组件并用到了单链表来实现关键的级联逻辑，下一段有演示效果的gif图。虽然这是个很常见的功能，但是本文的实现逻辑清晰，代码好理解，脱离了省市级联这样的语义，考虑了表现与行为的分离，希望本文的内容能够为你的工作带来一些参考的价值，欢迎阅读和指正。

Cascade 级联操作

CascadeType. PERSIST 级联持久化 ( 保存 ) 操作

CascadeType. MERGE 级联更新 ( 合并 ) 操作

CascadeType. REFRESH 级联刷新操作，只会查询获取操作

CascadeType. REMOVE 级联删除操作

CascadeType. ALL 级联以上全部操作

Fetch 抓取是否延迟加载，默认情况一的方为立即加载，多的一方为延迟加载

mappedBy 关系维护

mappedBy= "parentid" 表示在children 类中的 parentid 属性来维护关系，这个名称必须和children 类中的 parentid属性名称完全一致才行。

另外需要注意，parent类中的集合类型必须是List或者Set，不能设置为ArrayList，否则会报错

演示效果（代码下载，注：该效果需要http才能运行，另外效果中的数据是模拟数据，并不是后台真实返回的，所以看到的省市县的下拉数据都是一样的）：

注：本文用到了前面几篇相关博客的技术实现，如果有需要的话可以点击下面的链接前去了解：

1）详解Javascript的继承实现：提供一个class.js，用来定义javascript的类和构建类的继承关系；

2）jquery技巧之让任何组件都支持类似DOM的事件管理：提供一个eventBase.js，用来给任意组件实例提供类似DOM的事件管理功能；

3）对jquery的ajax进行二次封装以及ajax缓存代理组件：AjaxCache：提供ajax.js和ajaxCache.js，简化jquery的ajax调用，以及对请求进行客户端的缓存代理。

下面先来详细了解下这个功能的要求。

1. 功能分析

以包含三个级联项的级联组件来说明这个功能：

1）每个级联项可能需要一个用作输入提示的option：

这种情况每个级联项的数据列表中都能选择一个空的option（就是输入提示的那个）：

也可能不需要用作输入提示的option：

这种情况每个级联项的数据列表中只能选数据option，选不到空的option：

2）如果当前这个页面是从数据库中查询出来跟级联组件对应的字段有值，那么就把查询出来的值回显到级联组件上：

如果查询出来的对应字段没有值，那么就按第1）点需求描述的2种情况显示。

3）各个级联项在数据结构上构成单链表的关系，后一个级联项的数据列表，跟前一个级联项所选择的数据有关联的。

4）考虑到性能方面的问题，各个级联项的数据列表都采用ajax异步加载显示。

5）在级联组件初始化完成以后，自动加载第一个级联项的列表。

6）当前一个级联项发生改变时，清空后面所有直接或间接关联的级联项的数据列表，同时如果前一个级联项改变后的值不为空则自动加载跟它直接关联的下一个级联项的数据列表。清空级联项的数据列表时要注意：如果级联项需要显示输入提示的option，在清空的时候得保留该option。

7）要充分考虑性能问题，避免重复加载。

8）考虑到表单提交的问题，当级联组件任意级联项发生改变后，得把级联组件所选的值体现到一个隐藏的文本域内，方便把级联组件的值通过该文本域提交到后台。

功能大致如上。

2. 实现思路

1）数据结构

级联组件跟别的组件不太一样的是，它跟后台的数据有一些依赖，我考虑的比较好实现的数据结构是：

{
"id": 1,
"text": "北京市",
"code": 110000,
"parentId": 0
},
{
"id": 2,
"text": "河北省",
"code": 220000,
"parentId": 0
},
{
"id": 3,
"text": "河南省",
"code": 330000,
"parentId": 0
}

登录后复制

id是数据的唯一标识，数据之间的关联关系通过parentId来构建，text,code这种都属于普通的业务字段。如果按这个数据结构，我们查询级联项数据列表的接口就会变得很简单：

//查第一个级联项的列表
/api/cascade?parentId=0
//根据第一个级联项选的值，查第二个级联项的列表
/api/cascade?parentId=1
//根据第二个级联项选的值，查第三个级联项的列表
/api/cascade?parentId=4

登录后复制

这个结构对于后台来说也很好处理，虽然在结构上它们是一种树形的表结构，但是查询都是单层的，所以很好实现。

从前面的查询演示也能够看出，这个结构能够很方便地帮我们把数据查询的接口和参数统一成一个，这对于组件开发来说是一个很方便的事情。我们从后台拿到这个数据结构之后，把每一条数据解析成一个option，如，这样既能完成数据列表的下拉显示，还能通过select这个表单元素的作用收集到当前级联项所选中的值，最后当级联项发生改变的时候，还能够获取到选中的option，把它上面存储的data-param-value的值作为parentId这个参数，去加载下一个级联项的列表。这也是级联组件数据查询和解析的思路。

但是这里面还需要考虑的是灵活性的问题，在实际的项目中，可能级联组件的数据结构是按id parentId这种类似的关联关系定义的，但是它们的字段不一定是叫id parentId text code，很有可能是别的字段。也就是说：在把数据解析成option的时候，option的text还有value到底用什么字段来解析，以及data-param-value这个属性的用什么字段的值，都是不确定的；还有查询数据时用的参数名称parentId也不能是死的，有的时候如果后台人员先写好了查询接口，用了别的名称，你不可能要求人家去改他的参数名称，因为他那边是需要编译再部署的，相比前端更麻烦一些；还有parentId=0这个0值也是不能固定，因为实际项目中第一层的数据的parentid有可能是空，也有可能是-1。这些东西都得设计成option，一方面提供默认值，同时留给外部根据实际情况来设置，比如本文最终的实现中这个option都是这样定义的：

textField: 'text', //返回的数据中要在

登录后复制