(this page was created automatically. In case of formatting issues, please visit the official Wiki Page)

Code Editor

Overview

• The Code Editor Component is a specialized form control for code editing.
• It provides syntax highlighting, language detection, and a modern editor interface.
• It supports code formats like JSON, YAML, plain text, and Nginx configuration.
• It helps users input structured text or code snippets inside forms.

Specs

Tokens

Structure

• The Code Editor is a form control embedded within forms.
• It displays a text editing area with syntax highlighting and language detection.

(Configured in Non-Visual Properties)

• dataField – Defines the field name that will be used when submitting form data. For example, setting to "configurationJson" ensures the code content is submitted with this field name in the data object.
• controlsRequestType – Specifies how the field data is sent in HTTP requests: 'BODY', 'HEADER', or 'PATH'. For example, setting to "BODY" includes the code content in the request body, which is standard for most form submissions involving complex data.

(Configured in Visual Properties)

• saveInLocalStorage – Determines whether the editor's content is preserved in local storage between sessions. When enabled, input persists between page reloads.

Styling

(Configured in Visual Properties)

• height – Sets the height of the code editor in pixels or percentage. For example, setting to "400px" creates a fixed-height editor, while "100%" makes it fill its container.
• theme – Determines the visual appearance of the code editor with options for "Dark" or "Light" themes. For example, "upw-theme-dark" provides a dark background with light text, while "upw-theme-light" offers better visibility in well-lit environments.
• defaultLanguage – Sets the default syntax highlighting language when automatic detection fails. Options include plain text, JSON, YAML, and Nginx configuration formats. For example, setting to "json" applies JSON syntax highlighting.
• defaultValue – Sets the initial code content used when the form is reset or first displayed. For example, { "example": "value" } pre-populates the editor.

Actions & Variants

(Configured in Visual Properties)

• hidden – Controls whether the component is visible in the form. When set to true, the component remains in the form structure but is not displayed, which is useful for conditional rendering.
• readonly – Controls whether the code can be edited by users. When set to true, the editor displays the code but prohibits modifications, which is useful for code display or review scenarios where changes should not be permitted.

(Configured in Events)

• events – Configures the events that the component can trigger and respond to:
• ON_VALUE_CHANGE – Triggered when the content of the code editor is modified. Can be used for immediate actions like validation or preview updates.
• ON_INIT – Triggered when the code editor is initialized. Can be used for setup operations or initial state calculations.
• ON_DESTROY – Triggered when the component is removed from the DOM. Useful for cleanup operations and releasing resources.

Validation

(Configured in Validation)

• validation – Configures validation rules for the code editor, including:
• required – When set to true, code content must be provided before the form can be submitted.
• email – Validates content as an email address (rarely used for code editors).
• maxLength – Limits the maximum number of characters allowed in the editor.
• minLength – Requires a minimum number of characters in the editor.
• pattern – Allows validation of the content against a regular expression pattern, which can be useful for enforcing specific syntax rules or formatting.

Authorization

(Configured in Authorization)

• authorizationDisable – Specifies a policy set that determines when the component should be disabled based on user permissions. For example, setting to "readOnlyPolicy" will disable the code editor for users who don’t have edit permissions according to the specified policy.

Links

Figma: tba Live style guide: tba

Guidelines

Usage

• Set defaultLanguage to the expected syntax so highlighting is predictable when automatic detection fails (e.g., json, yaml, nginx, plaintext).
• Seed helpful starter content with defaultValue (e.g., a minimal valid JSON object) to reduce user errors.
• Enforce input rules with validation (use required, minLength, maxLength, and pattern for syntax/shape checks).

Sizing & Layout

• Set height to a fixed px value for consistent editing space (e.g., 400px) or a percentage for flexible layouts (e.g., 100% within its container).
• Choose theme (Dark or Light) to maintain comfortable contrast in the expected environment; prefer the option that meets contrast needs of surrounding UI.

States & Feedback

• Use readonly to present code without allowing edits.
• Use authorizationDisable to disable editing based on policy while keeping the control present.
• Toggle hidden to remove the control from view when not applicable.

Data-Driven / Conditional Behavior

• Constrain content shape with validation.pattern (regex) and size with minLength/maxLength; require presence with required.
• Preserve draft stability across sessions with saveInLocalStorage.

Content & Localization

• Provide clear starter content with defaultValue that matches defaultLanguage.
• Prefer language-neutral examples in defaultValue, since the component exposes no text translation settings.

Dos & Don’ts

Accessibility

• Ensure readable presentation by selecting an appropriate theme and sufficient edit area with height.
• Prevent non-functional interaction by using readonly for view-only scenarios and authorizationDisable when policy blocks editing.
• Reduce error burden with built-in validation so incorrect content is caught by the control before submission.
• Use defaultValue that demonstrates valid structure matching defaultLanguage to assist comprehension for screen-reader and keyboard users.