面向中后台复杂场景的低代码实践思路

一 中后台前端研发复杂度背景

做中后台前端开发,会经常碰到复杂交互和复杂逻辑问题:

你负责的业务中,规则是不是很多?是不是会不自觉的试图用if...else解决一切问题,逻辑是不是在迭代过程中变得越来越乱?最后彻底变成一个看不懂改不动的黑盒子,没有人能搞清楚黑盒子里面到底发生了什么。

现实中,业务场景多,迭代频繁,变化快到跟不上,规则可能由多人掌握,无法通过一个人了解全貌;

还有业务所在行业固有的复杂度和历史包袱,这些问题都会让我们感到痛苦。

除了逻辑问题,我们还关注易用性交互开发的问题。

试想,在中后台系统中,没有说明、没有指引,那该有多难用?所以通过内容运营,增加指引提升易用性是十分必要的,但对于前端开发来说,又像是下了一道魔咒。为什么这么说呢?

易用性交互的形式很多,不但会放大整体功能开发难度,而且很容易干扰到业务功能,让本来已经很复杂的开发工作更加复杂,加速了整体腐化。

本身排期就已经低于功能需求了,再加上这些问题,导致大家都不爱去做,长此下去,平台越来越难用。

那么问题逐渐显现,如何面对中后台复杂场景中最深刻的两个问题:即复杂交互、复杂逻辑。

二 复杂交互解法

1 思路

首先是使用动态标注生成交互界面,来解决复杂交互问题:

这是一个典型的后台功能配置页:这里面有列表有详情,加入了很多指引。这里相当一部分交互的繁琐编码工作,其实是以一种简洁高效的低代码方式去解决的。

首先我们需要把

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值