网站内容管理系统后台 设计( 如何面对中后台复杂场景中最深刻的两个问题？)

　　网站内容管理系统后台 设计(

如何面对中后台复杂场景中最深刻的两个问题？)

　　作者 | 剩下

　　来源 | 阿里巴巴科技公众号

　　中后台前端研发的复杂背景

　　在做中后台前端开发的时候，经常会遇到复杂的交互和复杂的逻辑问题：

　　您负责的业务中有很多规则吗？你是不是下意识地尝试用if...else解决所有问题，在迭代过程中逻辑是不是越来越乱？最后彻底变成了一个无法改变的黑匣子。没有人能弄清楚黑匣子里发生了什么。

　　现实中业务场景多，迭代频繁，变化太快，跟不上。规则可能多人掌握，不可能通过一个人了解全貌；

　　我们经营的行业也存在固有的复杂性和历史包袱，这对我们来说可能是痛苦的。

　　除了逻辑问题，我们还关注易用*敏*感*词*互开发问题。

　　试想在没有说明或指导的情况下在中后端系统中使用是多么困难？因此，通过内容运营来提高可用性是非常有必要的，但是对于前端开发来说，它就像是一个咒语。你为什么这么说？

　　易用交互的形式很多，不仅会增加整体功能开发的难度，而且容易干扰业务功能，使本已复杂的开发工作更加复杂，加速整体腐败。

　　调度本身已经低于功能要求。再加上这些问题，大家都不喜欢做。如果这种情况持续下去，该平台将变得越来越难以使用。

　　然后问题逐渐浮出水面，如何面对中后台复杂场景中最深刻的两个问题：复*敏*感*词*互和复杂逻辑。

　　两个复杂的交互解决方案 1 个想法

　　首先是使用动态注解生成交互界面，解决复杂的交互问题：

　　这是一个典型的后台功能配置页面：有列表和详细信息，并添加了许多指南。这里相当一部分繁琐的交互编码工作，其实是用简洁高效的低码方式解决的。

　　首先，我们需要将页面分为业务功能交互和辅助内容交互。所谓业务功能交互，即没有这部分交互业务就不再完整，辅助的内容交互没有这部分交互系统可以使用，但可能会很难用。

　　那么我们解决方案的核心目标是：业务功能的交互应该由前端开发通过procode来完成，而这些辅助内容的交互可以通过低代码配置来完成。

　　思路比较直接，那么实际效果如何呢？

　　这是一个比较复杂的配置页面，使用了很多引导交互，比如点击时弹出窗口、文档查看、各种带下划线的气泡、分步引导，甚至还有更复杂的流程图。这是 SVG 系统中有近 400 个这样的交互。如果把这些写在代码里，会是一个非常大的负担，而这些，我们都是通过低代码配置来解决的。

　　2 练习

　　接下来是实战部分：

　　第一步是找到辅助类的交互，这些是必须编码的关键业务能力，而哪些是非必要的。根据我们的实践经验，可以将这些辅助类之类的交互抽象为组件以供重用。

　　第二步，我们通过动态注解将这些组件渲染到界面上。

　　关键过程可以描述为，首先捕获用户的行为，比如元素的点击、移入移出，或者节点的生成、销毁，或者URL的改变等等。

　　当这些行为匹配时，找到组件插入或更新的位置，然后进行渲染。此时，组件会根据预设的规则动态标记到页面上的指定位置。

　　例如，当用户进入某个页面时（行为是 URL 改变），我们为指定区域（可能由选择器指定）插入流程图。

　　在第三步中，这些组件可以相互交互。例如，点击问号按钮时会弹出一个窗口，点击按钮时会出现感谢反馈，感谢反馈。我们为此使用自定义协议 url。为了完成，这里有一些示例来展示我们正在使用的操作，例如：

　　向机器人提问、提交工单、显示消息、打开弹出窗口、复制内容等

　　通过配置组件的url来完成不同的动作

　　这样就完成了整个可用*敏*感*词*互的注解和动作过程。

　　3个相关问题

　　所以问题来了。现在有一些动态渲染技术。如果状态发生变化，页面结构也可能发生变化，组件也会丢失。没关系，当 DOM 发生变化时，我们还在*敏*感*词*。只要检测到 DOM 树的变化或者关键属性的变化，我们就会重新渲染。

　　第二个问题是这些规则过于专业，比如 CSS 选择器和 XPath，对于非技术的学生来说使用起来非常昂贵，并且可能因为页面变化很小而导致配置失败。

　　我们对这类问题的实际解决方案是通过视觉特征的相似性来进行模糊匹配。用户只要选择相应的特征和偏差范围，就可以自动生成脚本进行匹配。这里我们扩展了 XQuery 形式自己的模糊查询方式。

　　4 复杂的交互

　　标签的问题解决了，但是复杂的交互呢？下面是一个例子来说明：

　　想象一个场景，一个系统，对于新用户和老用户，需要不同的引导方式

　　新用户场景下，首先提示用户使用新手指南，2秒后显示新手指南弹窗；

　　老用户场景下，只提示用户查看FAQ，点击FAQ时，要求机器人获取知识；

　　在每个链接中，我们通过 url 生成动作，但是如何将它们串在一起呢？

　　在我们的定义中，url可以串联执行，也可以加上@if、条件执行、@delay延迟执行，这样就可以将所有一系列url组织成一个url，在两种不同的场景下分别触发。

　　三种复杂的逻辑解决方案

　　接下来，我们要面对一个更难的问题，复杂的逻辑，通过策略编排生成逻辑代码。

　　该方案的核心目标是将所有的交互逻辑从ProCode开发转换为低码/*敏*感*词*配置，但这个核心目标的前提不是用低码代替procode，而是因为procode很难写出复杂的逻辑，所以要使用简单的低代码实现。