Closed Nisekoi5 closed 1 year ago
因为在尝试增加新功能的时候,发现有的东西在太前面获取的了。要传参好几下才能到 一级一级传下来非常麻烦,所以在每一次调用check_update()的时候,弄一个上下文变量。 在本次检查更新的任务中,后续无论怎么调用,都可以导入这个变量 功能已实现,核心代码在这 https://github.com/Nisekoi5/ELF_RSS/blob/test/src/plugins/ELF_RSS2/globals.py
防止某些函数逻辑太复杂。要传半天才能传到目的地。很乱。
比如某些rss需要解析标题,图片数量等,目前所有的路由handel返回的仅是需要发送的文本信息 tmp = await handler.func() 当一个数据比较特殊,有些东西不能在公共前置handler处理,只能在路由的handler中时 当一个后面的路由handler又需要这个数据
这时会出现一个参数连传四五下才能到目的地,而中间的函数完全用不着这个参数,会很复杂降低可读性
函数必须的参数不因使用该上下文变量传输,仅该作为最后的访问途径。 所有该存储的数据应该规定好,目前定义了2个全局上下文变量. current_rss 与 state
当前的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对象,如果某个路由后续需要的话。可以选择性存入。 不会影响现有代码逻辑,如果今后用得上的话在渐进式的修改
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```
之前是有想过重构这个,但是觉得头大就没动手(
为什么不提个 PR 呢?
之前是有想过重构这个,但是觉得头大就没动手( 为什么不提个 PR 呢?
改动有点大,想先问问你们的意见
功能需求
因为在尝试增加新功能的时候,发现有的东西在太前面获取的了。要传参好几下才能到 一级一级传下来非常麻烦,所以在每一次调用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对象,如果某个路由后续需要的话。可以选择性存入。 不会影响现有代码逻辑,如果今后用得上的话在渐进式的修改
会不会有安全性问题,高并发下会不会出现数据互相访问
使用标准库的上下文模块,在本地跑了四天了,目前还没出现任何异常。 https://docs.python.org/zh-cn/3/library/contextvars.html 测试脚本 https://github.com/Nisekoi5/ELF_RSS/blob/test/tests/test_globals.py