增加上下文管理流程

Nisekoi5 commented 1 year ago

功能需求

因为在尝试增加新功能的时候，发现有的东西在太前面获取的了。要传参好几下才能到一级一级传下来非常麻烦，所以在每一次调用check_update()的时候,弄一个上下文变量。在本次检查更新的任务中，后续无论怎么调用，都可以导入这个变量功能已实现，核心代码在这 https://github.com/Nisekoi5/ELF_RSS/blob/test/src/plugins/ELF_RSS2/globals.py

理由

防止某些函数逻辑太复杂。要传半天才能传到目的地。很乱。

当一个路由handle，需要另一个路由handle的数据的时候

比如某些rss需要解析标题,图片数量等，目前所有的路由handel返回的仅是需要发送的文本信息 tmp = await handler.func() 当一个数据比较特殊,有些东西不能在公共前置handler处理,只能在路由的handler中时当一个后面的路由handler又需要这个数据

函数太深需要非常前面的一个参数的时候

这时会出现一个参数连传四五下才能到目的地,而中间的函数完全用不着这个参数,会很复杂降低可读性

滥用导致函数的参数及作用不明确

函数必须的参数不因使用该上下文变量传输，仅该作为最后的访问途径。所有该存储的数据应该规定好,目前定义了2个全局上下文变量. current_rss 与 state

current_rss

当前的rss对象,在执行最初开始的时候存入上下文 https://github.com/Nisekoi5/ELF_RSS/blob/8faa44c3cd0b13a6c7e23899529108624098d395/src/plugins/ELF_RSS2/my_trigger.py#L21 后续任何地方如需使用直接引入globals current_rss即可 https://github.com/Nisekoi5/ELF_RSS/commit/9101f81d7d614fe4d7b982d22c8578747cb735b7

state

state对象,如果某个路由后续需要的话。可以选择性存入。不会影响现有代码逻辑，如果今后用得上的话在渐进式的修改

    new_rss: # fetch_rss()获取的数据 在获取最新rss时存入
    sn： # 图片序列号,在保存文件时需要用到 在route的picture handel中每处理一张图片后将该值+1
    img_num:# 单次更新包含的图片数量  应在route的picture handel内后存入
    item: # change_data里的一个更新, 应在循环change_data的时候存入其中的子项
    id: # 每次更新的唯一ID 应在route的before handel内处理后存入

会不会有安全性问题,高并发下会不会出现数据互相访问

使用标准库的上下文模块,在本地跑了四天了，目前还没出现任何异常。 https://docs.python.org/zh-cn/3/library/contextvars.html 测试脚本 https://github.com/Nisekoi5/ELF_RSS/blob/test/tests/test_globals.py


测试开始
开始处理任务:10
任务10初始state:0
开始处理任务:11
任务11初始state:0
开始处理任务:12
任务12初始state:0
开始处理任务:13
任务13初始state:0
开始处理任务:14
任务14初始state:0
开始处理任务:15
任务15初始state:0
开始处理任务:16
任务16初始state:0
开始处理任务:17
任务17初始state:0
开始处理任务:18
任务18初始state:0
开始处理任务:19
任务19初始state:0
任务11 inner修改后, state值:0-11 inner修改-11
任务11 inner修改后, state值:0-11 inner修改-11
任务14 inner修改后, state值:0-14 inner修改-14
任务14 inner修改后, state值:0-14 inner修改-14
任务12 inner修改后, state值:0-12 inner修改-12
任务12 inner修改后, state值:0-12 inner修改-12
任务18 inner修改后, state值:0-18 inner修改-18
任务18 inner修改后, state值:0-18 inner修改-18
任务19 inner修改后, state值:0-19 inner修改-19
任务19 inner修改后, state值:0-19 inner修改-19
任务17 inner修改后, state值:0-17 inner修改-17
任务17 inner修改后, state值:0-17 inner修改-17
任务16 inner修改后, state值:0-16 inner修改-16
任务16 inner修改后, state值:0-16 inner修改-16
任务15 inner修改后, state值:0-15 inner修改-15
任务15 inner修改后, state值:0-15 inner修改-15
任务10 inner修改后, state值:0-10 inner修改-10
任务10 inner修改后, state值:0-10 inner修改-10
任务13 inner修改后, state值:0-13 inner修改-13
任务13 inner修改后, state值:0-13 inner修改-13
==================================================
协程返回值: [('0-10 inner修改-10', '0-10'), ('0-11 inner修改-11', '0-11'), ('0-12 inner修改-12', '0-12'), ('0-13 inner修改-13', '0-13'), ('0-14 inner修 
改-14', '0-14'), ('0-15 inner修改-15', '0-15'), ('0-16 inner修改-16', '0-16'), ('0-17 inner修改-17', '0-17'), ('0-18 inner修改-18', '0-18'), ('0-19 inner修改-19', '0-19')]
.
----------------------------------------------------------------------
Ran 1 test in 9.010s

OK```

NekoAria commented 1 year ago

之前是有想过重构这个，但是觉得头大就没动手（

为什么不提个 PR 呢？

Nisekoi5 commented 1 year ago

之前是有想过重构这个，但是觉得头大就没动手（

为什么不提个 PR 呢？

改动有点大，想先问问你们的意见

Quan666 / ELF_RSS