为什么数据结构与算法，对前端开发很重要？

作者｜ LeuisKen

原文链接：

https://github.com/LeuisKen/leuisken.github.io/issues/2

在我之前的项目中，曾经遇到过这样一个需求，编写一个级联选择器，大概是这样：

图中的示例使用的是Ant-Design的Cascader组件。

要实现这一功能，我需要类似这样的数据结构：

一个具有层级结构的数据，实现这个功能非常容易，因为这个结构和组件的结构是一致的，递归遍历就可以了。

但是，由于后端通常采用的是关系型数据库，所以返回的数据通常会是这个样子：

前端这边想要将数据转换一下其实也不难，因为要合并重复项，可以参考数据去重的方法来做，于是我写了这样一个版本。

还好keys的长度只有3，这种东西长了根本没办法写，很明显可以看出来这里面有重复的部分，可以通过循环搞定，但是想了很久都没有思路，就搁置了。

后来，有一天晚饭后不是很忙，就跟旁边做数据的同事聊了一下这个需求，请教一下该怎么用循环来处理。他看了一下，就问我：“你知道trie树吗？”。我头一次听到这个概念，他简单的给我讲了一下，然后说感觉处理的问题有些类似，让我可以研究一下trie树的原理并试着优化一下。

讲道理，trie树这个数据结构网上确实有很多资料，但很少有使用JavaScript实现的，不过原理倒是不难。尝试之后，我就将transObject的代码优化成了这样。（关于trie树，还请读者自己阅读相关材料）

这样，解决方案就和keys的长短无关了。

这大概是我第一次，真正将数据结构的知识和前端项目需求结合在一起。

目前为止我参加过几次前端开发方面的面试，确实有不少面试官会问道一些算法。通常会涉及的，是链表、树、字符串、数组相关的知识。前端面试对算法要求不高，似乎已经是业内的一种共识了。虽说算法好的前端面试肯定会加分，但是仅凭常见的面试题，而不去联系需求，很难让人觉得，算法对于前端真的很重要。

直到有一天，有一位面试官问我这样一个问题，下面我按照自己的回忆把对话模拟出来，A指面试官，B指我：

A：你有写过瀑布流吗？

B：我写过等宽瀑布流。实现是当用户拉到底部的一定高度的时候，向后端请求一定数量的图片，然后再插入到页面中。

A：那我问一下，如何让几列图片之间的高度差最小？

B：这个需要后端发来的数据里面有图片的高度，然后我就可以看当前高度最小的是哪里列，将新图片插入那一列，然后再看看新的高度最小的是哪一列。