自定义布局页面的思路与实现

前言

最近做了一个需求：自定义首页。

用户或运营可以自己修改首页的布局，做到千人千面。

这个需求类似于当年的自定义QQ空间，不过怕是年轻一些的没玩过这个东西。

所以你也可以简单理解为是博客园的皮肤，只是不能写样式和代码，但是可以调整各个组件的布局。

明确需求

这并不是一个低代码页面设计器，不是给程序员用的。

只是一个自定义布局的页面而已，是面向客户或者运营的。

如果遇到类似的需求，大家可以针对具体的业务需求，从而一步步明确用户到底需要改变哪些布局属性。

强调这一点的必要在于，需求每明确和精简一次，都会极大简化后面的设计和开发。

可能用户不需要细致到像素级的宽高，而仅仅就是简单的几个字——对齐和能换位置，这在后续实现上有很大差别。

技术最终还是要用来解决问题，而不是创造问题。

给用户过多的自由度，给他一大堆设置选项，除了增加开发周期，更多地只会让他茫然无措。

不懂代码的用户甚至根本不会也不愿意使用你做的这个东西。

所以这个自定义布局页面最核心的一点在于：理解简单，操作简单。

整体流程图

我们将需求简化一下，做成一个如下的流程图：

我们需要一个设计器，去设计自定义布局的页面，设计完成后会将这个数据保存在服务端。

同时首页再从服务端获取数据，用一个渲染器去渲染页面。

按照这个思路，我们可以独立开发渲染器和设计器，只要保证两者之间的数据一致即可。

后续如果有业务变更，需要替换设计器和渲染器，也可以分开替换，而不需要同时替换。

不好的案例

四五年前我其实做过一个类似的需求。

当时的做法是：设计时记录下各个组件的宽高信息和样式，然后首页渲染时，根据相应的信息直接调整各个组件的位置，宽高和样式。

这种做法无疑是可以实现的，但是业务组件和布局信息耦合在了一起，新增业务组件或者调整UI时工作量很大。

对用户而言，调整布局时，需要自行确认宽高，不断进行适配，碰到需要适配不同分辨率屏幕的情况，不懂代码的用户可能心态直接就崩了。

而且，使用这种方式，在后续的业务迭代中，改动这块代码很容易使用户出现线上样式问题，导致开发根本就不敢动这块代码。

简易渲染器结构

为了解决上述问题，关键就在于将布局组件与业务组件分离。

我将所渲染的首页区域，作为一个容器组件。

然后将里面的各个内容区域组件分为布局组件和业务组件，两者完全分离后再由用户进行绑定。

这样在渲染的时候我们只用关心渲染简单的布局组件就行了，布局组件内部各种复杂的业务组件及其逻辑与我们毫无关系。

为了简单，布局组件推荐直接采用Ant Design的24列栅格设计，使用Row和Col进行布局，并不需要设定宽高，只用设定布局组件占几列就行了。

简易设计器结构

设计器分为两个区域：预览区和属性区。

左侧为预览区域：

有且仅有一个容器组件，右侧有一个新增按钮，点击后在下方新增一个布局组件。

布局组件可通过拖拽进行排序，这里我通过react-sortable-hoc来实现，技术细节无需赘述。

右侧为属性区域：

点击容器组件后，右侧属性区域显示容器组件的属性，比如各块之间的间距和整体的背景图。

点击布局组件后，右侧属性区域显示布局组件的属性，比如在栅格系统中占多少列，绑定哪个业务组件。

想象一下我们生成的数据结构,用TypeScript可以简化为：

    // 容器组件属性
    interface IContainerInfo{
        //...各种属性
    }

    // 布局组件属性
    interface ILayoutInfo{
        //...各种属性
    }

    // 最终数据结构
    interface IData{
        container:IContainerInfo
        layouts:ILayoutInfo[]
    }

至于组件的排序，用layouts数组的索引即可。

复杂布局与树

上面的布局设定针对大多数简单布局而言，绰绰有余。

如果你的需求比较简单，比如移动端之类的首页布局，这个完全足够了。

但是对稍微复杂一点的布局而言，上面的方案是有问题的，比如下面这种布局：

使用一个Row和Col很难实现上面这个布局。

如果要实现，我们需要使用设计器生成下面的结构：

<Row>
    <Col span={12}>
        <Row>
            <Col span={24}>组件A</Col>
            <Col span={24}>组件B</Col>
        </Row>
    </Col>
    <Col span={12}>
        组件C
    </Col>
</Row>

实际上这就是一个树形结构：

容器组件作为唯一根节点，无需改动。

之前绑定业务组件的布局组件，都可以理解为叶子节点，也无需改动。

唯一需要引入的是树枝节点。

为了渲染器能够渲染出目标结果，我们可以修改一下原先的数据结构为：

    // 容器组件属性
    interface IContainerInfo{
        //...各种属性
    }

    // 布局组件属性
    interface ILayoutInfo{
        //...各种属性
        isLeaf:boolean
        children:ILayoutInfo[]
    }

    // 最终数据结构
    interface IData{
        container:IContainerInfo
        layouts:ILayoutInfo[]
    }

可以看到我们给布局组件引入了两个属性

• isLeaf 是否为叶子节点
• children 如果是树枝节点，那么children下面为一个布局组件属性数组

既然数据结构确定，反推到我们的设计器，那么就是加一个是否为叶子节点的复选框属性。

勾选该属性，为叶子节点，那么展示绑定业务组件的属性。

不勾选该属性，为树枝节点，展示子组件数量这个属性。

各位可能很疑惑为什么是子组件数量这个数字类型，而不是children之类的数据格式。

实际上，用户可以简单设定子组件数量，来设定树枝节点下子组件的个数，然后再点击左侧的子组件来进行进一步的设置。

这样在操作上来讲，会简单很多。

当然，实际开发中考虑的也需要更多，比如子组件数字增大，需要插入新的子组件，数字变小，需要删除子组件，设计器保存和加载时子组件数量这个属性与children这个属性的互相转换。

细节实现

上面的方案应该是可以满足绝大多数情况了，但是您可能在实际开发过程中遇到以下细节问题：

设计器中节点定位

在设计器中，点击左侧布局组件，在右侧展示属性这一功能，有些朋友可能会存在一点困惑：如何获取当前组件在树形结构中的位置？

我这里实现时，是给每一个节点给了一个code，这个code是从根节点到当前节点的index数组，用字符分隔后得到的字符串。

在点击布局组件时，可以在当前节点上拿到这个字符串，然后快速还原成index数组，从而在树形结构中存取数据。

设计器中业务组件的预览

组件预览的这块，在绑定业务组件后，不必直接加载业务组件来展示。

因为这里只调整布局，不需要业务组件内部的逻辑。

所以我推荐这里用一张图片，或者一些简化后的组件代替即可。

如非必要，设计器这里的预览业务组件和业务组件应该完全分离，用code关联即可，否则代码的可读性和可维护性都会受到挑战。

渲染器中业务组件隐藏的情况

通常我们可能会遇到一些隐藏业务组件的需求，比如如果是管理员，那么就在首页展示这个组件，否则隐藏。

我们通过上述手段实现的布局中，如果业务组件隐藏，包裹它的布局组件是不会隐藏的。

所呈现的效果就是，这个隐藏的业务组件附近，块之间的间隔会比正常间隔大。

解决这个问题，可以使用下面三种方法：

• 方法一（不推荐）：取消块间隔这一属性，组件的间隔由业务组件实现。这样最简单，但是业务组件承担了过多的布局任务。
• 方法二（不推荐）：在业务组件中判定需要隐藏后，触发布局组件传递进来的回调函数，从而隐藏布局组件。但是这种子组件控制父组件的方式并不好，可读性差。而且业务组件应该与布局组件解耦，不能直接控制布局组件。另外这种控制方法，对于隐藏操作而言只能生效一次。
• 方法三（推荐）：在根节点组件中，设置控制逻辑。传递一个操作信息数组到每个子节点，如果布局组件的业务组件Code在这个操作信息数组中存在，并且操作为隐藏，那么就隐藏该布局组件。

推荐使用上述方法三，可以在渲染器上保持业务逻辑和布局逻辑始终分离开来，并且不仅仅能用于隐藏信息，还能用于其它的组件联动操作。

总结

以上便是我自己对这样一个自定义布局页面的思考和实现。

因为是公司的项目，所以无法开源。

但是如果参照上面的思路，实现起来应该也只是填充一些技术细节就可以了，希望对您起到帮助作用。

如果您有更好的方案，也希望不吝赐教。