Closed bestK closed 2 months ago
这个逻辑一般场景可能没问题的,不过有几个点要考虑:
这个逻辑一般场景可能没问题的,不过有几个点要考虑:
- 通过data_id取的config_type 和api明确指定的config_type如果冲突该如何处置?
- data_id创建之后是不变的,如果能过data_id后置设置类型,是不是只要在第一次时才根据data_id初始化config_type? (这样还刚好能比较好解决第1点问题)
确实是这样的,我再改改
edit:
好像不对啊, 新增跟修改的接口都是调用的 add_config
http://127.0.0.1:10848/rnacos/api/console/v2/config/add http://127.0.0.1:10848/rnacos/api/console/v2/config/update
在这个函数里面,即使使用 SetConfigReq::new(config_key, content)
设置里面的 config_type,也会被后面的 req.config_type = param.config_type;
重新赋值,
https://github.com/nacos-group/r-nacos/blob/03d84e963eab7603b3dd23b7849b86c501c22ae9/src/console/v2/config_api.rs#L98-L121
我这个 pr 初心是针对导入配置文件时根据后缀设置 config_type
的,并不影响原本的新增修改逻辑
如果只想针对导入场景,可以考虑在导入的api入口层增加类型设置。
改了 ,另外我发现前端好像有bug,在登录态失效进行上传时也会提示上传成功然后再重定向到登录页
我晚上回去验证一下,没什么问题就接受pr。
前端的问题,我后面回去抽空看看。
前端的我看了,错误是为 handlerUploadFinsh 只判断了 code 等于 200,没有像 axios 拦截器那样判断 no-login ,我在想是不是可以把
HttpResponse::Ok() // 换成 Unauthorized()
.insert_header(("No-Login", "1"))
.json(ApiResultOld::<()>::error("NO_LOGIN".to_owned(), None))
.map_into_right_body()
返回401
然后前端
截止目前发现 好像不走这个拦截器,是个 Uncaught (in promise)
后端应该有统一的拦截吧?
前端的可能要注意一下版本,目前r-nacos使用的是前端0.3.x分支,不是前端的master 分支。
前端的master分支代码结构做了较大重构,目前没有完全验证通过。
所以前端的小问题可能要先放放比较合适😂
我之前搞错了,如果 httpStatus = 401 要在 error 回调里面处理
上传组件
<n-upload
:action="apis.configImport"
:headers="uploadHeader"
:show-file-list="false"
@before-upload="doBeforeUpload"
@finish="handlerUploadFinish"
:custom-request="customRequest" // 可能需要使用 custom-request 属性才能走 axios 的统一响应拦截
v-if="webResources.canUpdateConfig"
>
那就先这样吧前端不整了
导入配置文件时,根据配置文件名(data_id)后缀调用
get_value
映射config_type
,实现初始化配置格式 https://github.com/nacos-group/r-nacos/blob/03d84e963eab7603b3dd23b7849b86c501c22ae9/src/config/config_type.rs#L55-L65