-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
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
Config Input design #14
Comments
How is this config displayed in #13? I haven't yet managed to run that PR successfully. |
It looks like this right now because The default HTML tags are not exhaustive but Imo we need a method for creating an individual |
The I suppose in the end we should:
|
This is the current state of affairs with that plugin in particular - notice the size of the scrollbar. #28 Should read from something like |
There's this npm package (demo) which allows editing yaml files with meaningful hints when editing parameters. This is not as user friendly as html forms but (keeping in mind we'll have predefined configs) perhaps it makes sense to:
|
Right now we only have Otherwise we'd need to create a template for each plugin. I've built the UI to be generic but would it be completely out of the question to have a dedicated view for particularly complex plugins? Once a new plugin is shipped to |
That's a proposition, but the answer is "yes"
Default plugin template can be derived from plugin-input.ts so introducing a new abstraction for the template is kind of redundant.
That's not scalable. We won't build individual UIs for 1000 3rd party plugins. |
Yeah I guessed that ty, I'm sure we'll find an optimal solution. |
Look at this config, it's huge. How is a config like this expected to be displayed?
Are we going to have to build custom setups for some plugins or is it expected to just fill the editor and scroll?
Seeing all of this without explicit info about what it is (within the UI) might be a lot to take in.
The text was updated successfully, but these errors were encountered: