Files
superset2/docs/developer_docs/extensions/extension-points/editors.md
Claude Code 04451766e7 fix(docs): tighten onBrokenLinks to throw and fix surfaced broken links
Previously docusaurus.config.ts had `onBrokenLinks: 'warn'`, so broken
internal links produced advisory warnings during build but didn't gate
merges. Tightening to `throw` surfaces every broken internal route at
build time. Three classes of issue fell out:

1. Stale `/docs/...` and `/docs/6.0.0/...` references in the 6.0.0
   versioned snapshot. The user-facing docs section was renamed
   `docs` → `user-docs` (routeBasePath) at some point after 6.0.0 was
   cut, but the snapshot's links still pointed at the old prefix. The
   live site redirects /docs/* → /user-docs/* at runtime, but
   Docusaurus's onBrokenLinks checker doesn't honor redirects.
   Bulk-rewrote /docs/* → /user-docs/* across the snapshot (and one
   /docs/api → /developer-docs/api).

2. Bare-relative MDX links like `[Label](./mcp)` (no .md/.mdx
   extension). Docusaurus renders an absolute href in SSR HTML, so
   static crawlers see correct links — BUT React Router's `<Link>`
   component on the client side resolves the bare path relative to
   the current URL on click, so when the page URL has a trailing
   slash (e.g. /extensions/overview/), `./mcp` becomes
   /extensions/overview/mcp (404). This is exactly the broken-flow a
   user reported on /developer-docs/extensions/overview/. Added the
   `.md`/`.mdx` extension to all 44 such links across 17 files; this
   makes Docusaurus resolve them to the canonical doc URL at the
   <Link> level, so SPA navigation works regardless of trailing slash.

3. Miscellaneous content fixes:
   - 4 `/configuration/feature-flags` references in 6.0.0 snapshot
     pointed at a page that doesn't exist in that version (the
     dedicated feature-flags page was added later). Repointed to the
     `#feature-flags` anchor inside `configuring-superset.mdx`.
   - 3 references to `superset-core/src/superset_core/rest_api/decorators.py`
     in extensions docs were rendered as relative URLs, resolving to
     /developer-docs/extensions/superset-core/... (404). Converted to
     absolute GitHub URLs.
   - 1 `/storybook/?path=...` link in extensions/components/index.mdx
     pointed at a non-existent route. Repointed to the existing
     `/developer-docs/testing/storybook` page that explains how to
     run Storybook locally.
   - 4 unclosed-paren markdown links in 6.0.0 installation-methods.mdx
     (pre-existing source bugs).

Build now passes with `onBrokenLinks: 'throw'`. Note that
`onBrokenAnchors` is still `'warn'` (default); a separate effort
should tighten that and fix the surviving anchor warnings (currently
~60 instances of `/community#superset-community-calendar`).
2026-05-13 20:17:46 -07:00

6.9 KiB

title, sidebar_position
title sidebar_position
Editors 2

Editor Contributions

Extensions can replace Superset's default text editors with custom implementations. This allows you to provide enhanced editing experiences using alternative editor frameworks like Monaco, CodeMirror, or custom solutions.

Overview

Superset uses text editors in various places throughout the application:

Language Locations
sql SQL Lab, Metric/Filter Popovers
json Dashboard Properties, Annotation Modal, Theme Modal
css Dashboard Properties, CSS Template Modal
markdown Dashboard Markdown component
yaml Template Params Editor
javascript Custom JavaScript editor contexts
python Custom Python editor contexts
text Plain text editor contexts

By registering an editor for a language, your extension replaces the default Ace editor in all locations that use that language.

Implementing an Editor

Your editor component must implement the EditorProps interface and expose an EditorHandle via forwardRef. For the complete interface definitions, see @apache-superset/core/api/editors.ts.

Key EditorProps

interface EditorProps {
  /** Controlled value */
  value: string;
  /** Content change handler */
  onChange: (value: string) => void;
  /** Language mode for syntax highlighting */
  language: EditorLanguage;
  /** Keyboard shortcuts to register */
  hotkeys?: EditorHotkey[];
  /** Callback when editor is ready with imperative handle */
  onReady?: (handle: EditorHandle) => void;
  /** Host-specific context (e.g., database info from SQL Lab) */
  metadata?: Record<string, unknown>;
  // ... additional props for styling, annotations, etc.
}

Key EditorHandle Methods

interface EditorHandle {
  /** Focus the editor */
  focus(): void;
  /** Get the current editor content */
  getValue(): string;
  /** Get the current cursor position */
  getCursorPosition(): Position;
  /** Move the cursor to a specific position */
  moveCursorToPosition(position: Position): void;
  /** Set the selection range */
  setSelection(selection: Range): void;
  /** Scroll to a specific line */
  scrollToLine(line: number): void;
  // ... additional methods for text manipulation, annotations, etc.
}

Example Implementation

Here's an example of a Monaco-based SQL editor implementing the key interfaces shown above:

MonacoSQLEditor.tsx

import { forwardRef, useRef, useImperativeHandle, useEffect } from 'react';
import * as monaco from 'monaco-editor';
import type { editors } from '@apache-superset/core';

const MonacoSQLEditor = forwardRef<editors.EditorHandle, editors.EditorProps>(
  (props, ref) => {
    const { value, onChange, hotkeys, onReady } = props;
    const containerRef = useRef<HTMLDivElement>(null);
    const editorRef = useRef<monaco.editor.IStandaloneCodeEditor | null>(null);

    // Implement EditorHandle interface
    const handle: editors.EditorHandle = {
      focus: () => editorRef.current?.focus(),
      getValue: () => editorRef.current?.getValue() ?? '',
      getCursorPosition: () => {
        const pos = editorRef.current?.getPosition();
        return { line: (pos?.lineNumber ?? 1) - 1, column: (pos?.column ?? 1) - 1 };
      },
      // ... implement remaining methods
    };

    useImperativeHandle(ref, () => handle, []);

    useEffect(() => {
      if (!containerRef.current) return;

      const editor = monaco.editor.create(containerRef.current, { value, language: 'sql' });
      editorRef.current = editor;

      editor.onDidChangeModelContent(() => onChange(editor.getValue()));

      // Register hotkeys
      hotkeys?.forEach(hotkey => {
        editor.addAction({
          id: hotkey.name,
          label: hotkey.name,
          run: () => hotkey.exec(handle),
        });
      });

      onReady?.(handle);
      return () => editor.dispose();
    }, []);

    return <div ref={containerRef} style={{ height: '100%', width: '100%' }} />;
  },
);

export default MonacoSQLEditor;

index.tsx

Register the editor at module load time from your extension's entry point:

import { editors } from '@apache-superset/core';
import MonacoSQLEditor from './MonacoSQLEditor';

editors.registerEditor(
  {
    id: 'my-extension.monaco-sql',
    name: 'Monaco SQL Editor',
    languages: ['sql'],
  },
  MonacoSQLEditor,
);

Handling Hotkeys

Superset passes keyboard shortcuts via the hotkeys prop. Each hotkey includes an exec function that receives the EditorHandle:

interface EditorHotkey {
  name: string;
  key: string;  // e.g., "Ctrl-Enter", "Alt-Shift-F"
  description?: string;
  exec: (handle: EditorHandle) => void;
}

Your editor must register these hotkeys with your editor framework and call exec(handle) when triggered.

Keywords

Superset passes static autocomplete suggestions via the keywords prop. These include table names, column names, and SQL functions based on the current database context:

interface EditorKeyword {
  name: string;
  value?: string;  // Text to insert (defaults to name)
  meta?: string;   // Category like "table", "column", "function"
  score?: number;  // Sorting priority
}

Your editor should convert these to your framework's completion format and register them for autocomplete.

Completion Providers

For dynamic autocomplete (e.g., fetching suggestions as the user types), implement and register a CompletionProvider via the EditorHandle:

const provider: CompletionProvider = {
  id: 'my-sql-completions',
  triggerCharacters: ['.', ' '],
  provideCompletions: async (content, position, context) => {
    // Use context.metadata for database info
    // Return array of CompletionItem
    return [
      { label: 'SELECT', insertText: 'SELECT', kind: 'keyword' },
      // ...
    ];
  },
};

// Register during editor initialization
const disposable = handle.registerCompletionProvider(provider);

Next Steps