We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在需要输入一个platform / sid / permission / user ... 或任何由插件描述的概念时, 提供一个运行时的建议列表
常见的场景如以上列出的,在添加platform/sid filter(或者由插件支持的类似配置项)时,提供当前运行中bots的属性作为suggestions;在设置一个权限继承关系时,从全局的权限空间中获得补全等
直接实现 或似乎可以实现前端部分,然后借助Schema.reactive(callback) + Schema.dynamic()来响应式地进行更新?
No response
The text was updated successfully, but these errors were encountered:
dynamic 我一直不知道是不是要保留。目前的主要问题就是一方提供 + 一方使用的设计限制过于严重了。考虑到 dynamic 主要的使用场景其实就是用做 select,直接用 autocomplete 替换 dynamic 就成了一种选择。
Sorry, something went wrong.
dynamic的限制确实太强了。 实际问题应该是现在的设计并不能允许运行时config和schema在前后端间自由传递(我认为后端向前端更新config是可以考虑的)。否则的话,完全可以自己给自己提供dynamic schema。 因此本issue选择一种绕开config/schema的方案,来保证尽可能不破坏原本的设计,同时在autocomplete不可用时不影响原本的行为。
我认为后端向前端更新 config 是可以考虑的
dynamic 就是这种设计的自然结果。它的主要问题在于配置是显示在插件加载前的,而后端逻辑必须在插件加载后才会有。你用任何方案都会遇到这个问题。
在废弃掉 dynamic 后我们会引入两套 API 满足不同层次的需求:
No branches or pull requests
Describe the problem related to the feature request
在需要输入一个platform / sid / permission / user ... 或任何由插件描述的概念时,
提供一个运行时的建议列表
常见的场景如以上列出的,在添加platform/sid filter(或者由插件支持的类似配置项)时,提供当前运行中bots的属性作为suggestions;在设置一个权限继承关系时,从全局的权限空间中获得补全等
Describe the solution you'd like
直接实现
或似乎可以实现前端部分,然后借助Schema.reactive(callback) + Schema.dynamic()来响应式地进行更新?
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: