1000 行输入框的养成:如何平衡体验与灵活性?

Posted Phodal

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了1000 行输入框的养成:如何平衡体验与灵活性?相关的知识,希望对你有一定的参考价值。

在编程的时候,我们会一直考虑所为的「灵活性」的问题。灵活性,可以降低我们变更的成本,减少部署的频率,进而提供更好的开发体验。而与此同时,追求实现的灵活性,可能会影响用户的体验。如何平衡这两种就是一个非常有意思的问题。

不过呢,我们一直在关注于所谓的用户的体验,但是有时候对于开发者的开发体验。如何开发体验更好的话,那么它就会带来更好的用户体验。

引子

在为 ArchGuard 设计「趋势与洞察」功能,它应对于「架构自治服务」一文所描述的概念,即起向用户提供一个迷你版本的数据自治服务的功能。从功能上来说,有点类似于一个自制的数据湖平台。

这个功能从一个简单的输入框,变成了一个背后有 1000 行代码的「一行代码的编辑器」。在这一个过程中,我们一直在尝试平衡灵活性与体验,也依旧在进这一方面的尝试。因为这一个过程中,非常有意思,也就想简单写个代码记录一下。

尽管,在起初,构建一个迷你的查询语言就是我们的目标。不过,我们并没有一开始就朝向这个宏大的目标,而是一步步的迈进。所以,也就产生了三个版本:

  • 第一个版本,基于下拉框与输入框的 CRUD 查询。

  • 第二个版本,通过正则匹配字段,来生成最后的 SQL。

  • 第三个版本,手写解析器替换正则表达式,构建独立于 SQL 的查询语言。

PS:感谢 @CGQAQ 重构出了第三个版本。

从一开始的 Input,到最后引入 Monaco Editor,我们逐步把一个简单的问题复杂化了。虽然如此,但是这个过程还是颇有意思的 —— 业余,我们不就应该多做一些有意思的吗?

第一个版本的设计:使用 UI 进行 CRUD

我们构建的第一个版本采用的是常见的数据查询模式:

  1. UI 交互生成数据。

  2. 后端检验数据,生成 SQL。

  3. 执行 SQL 返回数据。

在 UI 设计上,主要就是结合下拉框 + 输入框来实现:通过复杂的下拉框联动,构建出对于数据的查询;结合下拉框的值与特定的输入值,输入的值进行校验。

这一种模式的典型问题是:

  • 业务间联动过于复杂。复杂的结果,就是导致容易出现 bug。

  • 无尽的需求变更。

  • 没有挑战性。技术实现上,它就是各种 Ctrl + C / Ctrl + V。

它的优点就是胜在实用,学习成本低。

第二个版本的设计:正则匹配字段

随后,我们在表单联动上遇到了挑战:如何我们字段越来越多的时候,那么表单就会越来越复杂。随着,字段的增长,那么就会出现看上去很炫,但是很难适合人类使用。

于是呢,作为程序员的直觉,就是用编辑器解决 —— Monaco Editor。就像我们之前的架构工作台一样,如果一个编辑器不能解决,那就两个。

对应的模式

  1. 下拉框 + 查询语句生成查询条件。

  2. 将查询条件转换为 SQL。

  3. 执行 SQL 生成新的数据。

  4. 过滤数据,返回数据。

于是,在这个版本里,我们通过正则匹配出 name 和 version,以及对应的值:

field:name == /.*log4j/ field:version > 2.17.0

容易出现问题,一旦用户输错字符时。

开发者体验优化:Monaco Editor 构建搜索框

在功能实现上,我们借助于 Monaco Editor 构建了一个一行的输入框,即将一个编辑器封装成一个输入框。于是乎,这个输入框变成了一个搜索框,它具备这么一些功能:

  • 语法高亮。方便用户输入各种字段 。

  • 智能感知。在通过下拉框选择对应的类型时,选择对应的感知类型。

  • 主题。虽然,我们还没实现,但是它明显是可以的。

除了,载入比较慢之后,它似乎没有别的缺点。

不过,由于在这个版本里,它是通过正则表达式来匹配的,所以在感知上出现了一些问题。于是,后来我们在新的版本里,重写了查询语言。

第三个版本的设计:构建查询语言隔离

在构建这个工具的时候,我们也在计划在未来引入 MongoDB 替换 mysql。如此一来呢,用户也可以自定义自己的搜索类型,而不是需要编码做 CRUD 的转换。

于是呢,我们在 MySQL 和 MongoDB 中间,创建一个封层,来隔离两者之间的差异,这个就是:Insight Query Language。再论,如何将一个简单的事情往复杂的办。

这里的查询语言是一个非常迷你的 DSL,只支持非常简单的计划。所以,它的模式是:

  1. 编写查询语言解析器。

  2. 将查询语言转换为 SQL。

  3. 执行 SQL 生成新的数据。

  4. 过滤数据,返回数据。

从模式上来说,它类似于一个简化版本的 SQL。考虑到 DSL 存在一个学习成本,所以我们一直尝试将文档内建到搜索框中。

开发者体验优化:文档内建

从实现上主要由两部分技术实现:文档内建和自动建议 构建。

智能自动建议。为了实现更好的 Completion,就需要做语法分析,根据用户的输入,调整 Completion。诸如于 sca 在刚输入的时候,有 dep_name 、 dep_verion 等不同的字段;当用户输入过 dep_name 时,它就不会出现在下次的 Completion 列表中。不过,也存在一个问题,这些类型如果写在前端的时候,也会造成更新缓慢的问题。

文档内建。通过 Hover 和 Auto Suggest 来降低用户的学习成本。即当用户放在对应的 Literal 类型上,展示对应的提示文本,如支持的格式等。

其它

在这样的折腾中,你或者还观察到了另外一点,更好的用户体验,依赖于更好的技术实现。而更好的技术实现,也意味着更多的技术成本。

欢迎观摩这一部分代码:https://github.com/archguard/archguard-frontend/tree/master/archguard/src/pages/insights

以上是关于1000 行输入框的养成:如何平衡体验与灵活性?的主要内容,如果未能解决你的问题,请参考以下文章

1000 行输入框的养成:如何平衡体验与灵活性?

输入框与显示框

如何养成良好的 C++ 编程习惯—— 内存管理

平衡 balance

07平衡负载:gRPC是如何进行负载均衡的?

jsp中el表达式如何获取当前输入框的值?