Skip to content
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

[TASK] Instance Custom Parameters Inputs #2552

Open
Tracked by #2546
monaiuu opened this issue Sep 23, 2024 · 0 comments
Open
Tracked by #2546

[TASK] Instance Custom Parameters Inputs #2552

monaiuu opened this issue Sep 23, 2024 · 0 comments

Comments

@monaiuu
Copy link
Contributor

monaiuu commented Sep 23, 2024

Description

For each instance deployment, depending on the selected Blueprint, additional custom parameters may be required. To ensure that the interface can properly handle and render these configurations dynamically, implement a system to render custom input fields based on a JSON schema provided by each Blueprint. The schema defines how parameters will be displayed in the UI.

Parameter Structure (attributes):

  • name: The name of the parameter, which will be displayed as the label or key in the UI.
  • type: The data type of the parameter, which determines what kind of input component (e.g., text, number, boolean) should be rendered.
  • description (optional): A brief description of the parameter to be displayed as tooltip or help text in the UI.
  • default (optional): A pre-filled default value or placeholder that provides initial input guidance for the user.
  • required (optional): A boolean indicating whether the input is mandatory.

Prop-Based Configuration:

  • Utilize components to accept various props that control their behavior and appearance. These props should enable the components to dynamically adjust based on the incoming configuration from the Blueprint schema.
  • Dynamic Rendering: Use conditional rendering based on the JSON schema to dynamically display the appropriate input fields for each parameter type.

Common parameter types and corresponding components to be rendered:

  • String:

    • Component: text input
    • Use Case: Wallet addresses, user names, transaction IDs.
    • Example: {"name": "param1", "type": "string"}
  • Number:

    • Component: number input or range slider
    • Use Case: Token amounts, thresholds, block numbers, or gas fees.
    • Example: {"name": "param2", "type": "number"}
  • Boolean:

    • Component: checkbox or switch
    • Use Case: True/false states such as feature toggles, transaction confirmations.
    • Example: {"name": "param3", "type": "boolean"}
  • Array:

    • Component: Input fields with add/remove buttons to handle multiple values.
    • Use Case: Lists of wallet addresses, permissions, or hashes.
    • Example: {"name": "param4", "type": "array", "items": {"type": "string"}}
  • Object:

    • Component: A collection of inputs (e.g., text, number) for each property in the object.
    • Use Case: Complex configurations like user profiles, smart contract details, or multi-property data structures.
    • Example: {"name": "param5", "type": "object", "properties": {"subParam1": {"type": "string"}}}
  • Enum:

  • Component: select dropdown or checkboxes

    • Use Case: Selectable options like transaction types, user roles, or predefined environments.
    • Example: {"name": "param6", "type": "string", "enum": ["value1", "value2", "value3"]}

Validation and Error Handling:

  • Ensure proper validation for each input type based on the schema requirements (e.g., required fields, valid input formats).
  • Implement error messages and user feedback for invalid inputs, missing required fields, or incorrect data types.

Screenshot

Screenshot 2024-09-23 at 4 06 29 PM
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Not Started 🕧
Development

No branches or pull requests

1 participant