全局加载状态管理方法、装置、设备及介质与流程
本技术涉及前端开发,可应用于金融及医疗领域,具体涉及一种全局加载状态管理方法、装置、设备及介质。
背景技术:
1、在现代web前端应用开发领域,特别是在租赁、金融客户关系管理(crm)、后台管理系统等复杂业务场景下,页面初始化或交互操作往往需要依赖大量的后端数据接口。为了缓解用户在等待过程中的焦虑感、提升用户体验,业内通常采用在数据请求期间显示全局加载提示(如全屏遮罩层、旋转图标或加载动画等)的技术手段,以告知用户系统正在处理中。当前,行业内针对上述需求的主流加载状态管理方案主要分为以下三类:
2、第一类,在页面初始化或操作触发时并发发起多个http请求,请求前统一显示全局加载提示(loading),并维护一个请求计数器,每次请求发出时计数器加一,请求完成后减一,当计数器归零时关闭全局加载提示(loading)。
3、第二类,由开发者在具体的业务逻辑中,通过手动调用showloading()和hideloading()函数,并在每个请求的回调函数(如then/catch)中硬编码控制加载提示的显示与隐藏。
4、第三类,通过对axios或fetch等网络请求库进行二次封装,提供统一的请求入口,在封装层统一拦截并处理全局加载提示(loading)的显示与隐藏,通常基于请求配置参数来控制全局加载提示(loading)的行为。
5、尽管上述方案在一定程度上解决了加载状态的提示问题,但在实际应用中仍存在诸多技术缺陷与痛点,在现有方案中,所有请求默认均参与全局loading状态管理。然而在实际业务中,异步上报、缓存更新、埋点统计、数据预加载等属于非关键请求,若其强制参与loading计算,将导致低优先级请求阻塞主流程,使用户感知的“加载完成”时间被无故拖慢,在网络环境较差时用户体验显著下降。
6、其次,在嵌套请求场景下(例如请求a成功后触发请求b),由于计数逻辑或回调执行顺序问题,极易出现“加载提示无法关闭”的问题。同时,在并发请求中若某个请求异常或超时,loading状态往往无法正确恢复;且在多个组件同时独立发起请求时,loading状态容易被错误地重复触发或提前关闭。
技术实现思路
1、有鉴于此,本技术提供了一种全局加载状态管理方法、装置、设备及介质,主要目的在于解决在实际业务中,若非关键请求强制参与loading计算,将导致低优先级请求阻塞主流程,使用户感知加载完成时间被无故拖慢,在网络环境较差时用户体验显著下降,以及由于计数逻辑或回调执行顺序问题,极易出现加载提示无法关闭的问题。同时,在并发请求中若某个请求异常或超时,loading状态往往无法正确恢复;且在多个组件同时独立发起请求时,loading状态容易被错误地重复触发或提前关闭的技术问题。
2、第一方面,本技术提供了一种全局加载状态管理方法,包括:
3、获取前端发起的http请求,读取所述http请求的请求配置参数,所述请求配置参数中携带有请求级加载标志位;
4、根据所述请求级加载标志位,确定所述http请求是否参与全局加载状态管理;
5、若确定所述http请求参与全局加载状态管理,则对全局计数器执行递增操作,若递增后所述全局计数器的当前计数值满足预设显示触发条件,则将全局加载状态变更为显示状态;
6、将所述http请求发送至服务端,并拦截所述服务端返回的针对所述http请求的响应结果,所述响应结果包括请求成功响应或请求失败响应;
7、当拦截到所述响应结果时,从所述响应结果中获取所述http请求的请求配置参数,读取所述请求配置参数中的请求级加载标志位,根据所述请求级加载标志位,确定所述http请求是否参与全局加载状态管理,若确定所述http请求参与全局加载状态管理,则对所述全局计数器执行递减操作,若递减后的所述全局计数器的当前计数值满足预设关闭触发条件,则将所述全局加载状态变更为关闭状态,以完成对单个http请求的独立加载控制。
8、第二方面,本技术提供了一种全局加载状态管理装置,包括:
9、获取模块,用于获取前端发起的http请求,读取所述http请求的请求配置参数,所述请求配置参数中携带有请求级加载标志位;
10、确定模块,用于根据所述请求级加载标志位,确定所述http请求是否参与全局加载状态管理;
11、第一触发模块,用于若确定所述http请求参与全局加载状态管理,则对全局计数器执行递增操作,若递增后所述全局计数器的当前计数值满足预设显示触发条件,则将全局加载状态变更为显示状态;
12、拦截模块,用于将所述http请求发送至服务端,并拦截所述服务端返回的针对所述http请求的响应结果,所述响应结果包括请求成功响应或请求失败响应;
13、第二触发模块,用于当拦截到所述响应结果时,从所述响应结果中获取所述http请求的请求配置参数,读取所述请求配置参数中的请求级加载标志位,根据所述请求级加载标志位,确定所述http请求是否参与全局加载状态管理,若确定所述http请求参与全局加载状态管理,则对所述全局计数器执行递减操作,若递减后的所述全局计数器的当前计数值满足预设关闭触发条件,则将所述全局加载状态变更为关闭状态,以完成对单个http请求的独立加载控制。
14、第三方面,本技术提供了一种电子设备,包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现第一方面所述的全局加载状态管理方法。
15、第四方面,本技术提供了一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现第一方面所述的全局加载状态管理方法。
16、借由上述技术方案,本技术提供的一种全局加载状态管理方法、装置、设备及介质,与目前现有技术相比,本技术可通过获取前端发起的http请求,读取http请求的请求配置参数,请求配置参数中携带有请求级加载标志位;根据请求级加载标志位,确定http请求是否参与全局加载状态管理;若确定http请求参与全局加载状态管理,则对全局计数器执行递增操作,若递增后全局计数器的当前计数值满足预设显示触发条件,则将全局加载状态变更为显示状态;将http请求发送至服务端,并拦截服务端返回的针对http请求的响应结果,响应结果包括请求成功响应或请求失败响应;当拦截到响应结果时,从响应结果中获取http请求的请求配置参数,读取请求配置参数中的请求级加载标志位,根据请求级加载标志位,确定http请求是否参与全局加载状态管理,若确定http请求参与全局加载状态管理,则对全局计数器执行递减操作,若递减后的全局计数器的当前计数值满足预设关闭触发条件,则将全局加载状态变更为关闭状态,以完成对单个http请求的独立加载控制。
17、采用上述技术方案,本技术通过在请求配置参数中引入请求级加载标志位,在请求发起的源头构建了准入判断机制。对于异步上报、缓存更新、埋点统计等非关键请求,系统在首次读取配置时即判定其不参与全局管理,直接旁路绕过后续的计数与显示逻辑。这种机制彻底解耦了非关键请求与全局加载生命周期的强绑定,使得用户感知的“加载完成”时间仅由核心主流程请求决定,显著缩短了页面可交互时间,在网络较差的环境下大幅提升了用户体验。
18、针对多个组件同时独立发起请求时loading被错误重复触发的问题,本技术摒弃了传统的简单状态标记,引入了全局计数器与预设显示触发条件相配合的边缘检测逻辑(即“递增后满足预设显示触发条件才触发”)。当多个并发请求同时到达时,只有第一个使计数器发生状态跃迁(例如从0变为1)的请求能够满足该触发条件从而显示加载状态,后续并发的请求仅执行计数递增而无法再次触发显示。该机制在底层逻辑上实现了绝对的并发去重,避免了加载弹窗的抖动与叠加。
19、针对嵌套请求(如请求a成功后触发请求b)因回调顺序混乱导致加载无法关闭的问题,本技术通过“递增操作”与“递减操作”的强制配对机制予以克服。无论嵌套层级多深、回调顺序如何错乱(例如b先于a返回),只要请求参与了管理,其发起必然导致计数递增,其响应必然导致计数递减。这种基于数学累加与抵消原则的模型,屏蔽了业务代码中复杂的异步时序问题,确保只要参与计数的请求全部收尾,计数器必然回归初始基态,从而绝对保证加载提示被正确关闭。
20、针对请求异常或超时时loading状态无法恢复的问题,本技术将状态回收逻辑从业务层的成功回调中剥离,统一下沉至网络请求拦截器中,且明确限定了拦截对象“包括请求成功响应或请求失败响应”。这意味着无论请求是正常返回还是发生网络异常、超时报错,只要请求生命周期终结,拦截器便会无差别地执行“递减操作”及后续的关闭判断。该强制的兜底通道彻底切断了异常分支对全局状态的污染,确保了即使在极端网络条件下,用户界面也能从加载状态中自动恢复至可操作状态,极大地提升了系统的健壮性与稳定性。
21、上述说明仅是本技术技术方案的概述,为了能够更清楚了解本技术的技术手段,而可依照说明书的内容予以实施,并且为了让本技术的上述和其它目的、特征和优点能够更明显易懂,以下特举本技术的具体实施方式。
版权声明:本站专利文献数据主要来源于国家知识产权局等公开渠道,由 技术新讯 进行整理汇编。页面设计及数据汇编的著作权归本站所有。全部内容仅供个人学习、科研评估与技术交流参考,严禁用于任何商业用途(包括但不限于直接生产制造、技术转让、倒卖数据等)。
免责条款:专利技术具有时效性,本站不对资料的绝对准确性、完整性和可实施性提供任何明示或暗示的担保。因参考本站内容造成的直接或间接损失,本站不承担相关法律责任。若您认为本站内容有侵权问题,请及时提供权属证明与我们联系,本站将在核实后依法处理。反馈意见:yyfuon@163.com