Cascading Configuration UI: Building Dependent Selection Chains in the Properties Panel

Part 12 of the series: "Extending bpmn-io Form-JS Beyond Its Limits"

A form designer needs to configure auto-fill for a field. They want to pull data from another ticket — a linked ticket that's part of the same process. To configure this, they need to:

Select a behavior (pull from current ticket or from another ticket)
Select the ticket type (which process definition to look at)
Select the ticket phase (which activity/step in that process)
Select the field name (which form field from that phase to pull data from)

Each selection narrows the next. Ticket phases are meaningless without knowing the ticket type. Field names are meaningless without knowing the phase. The available options at each level come from a live API — they change as the process definitions evolve.

This is a cascading configuration UI. Building it in Form-JS's properties panel — in Preact, inside getGroups, with async data fetching — requires solving several problems simultaneously. This article documents each one.

The Problem

A basic select entry in the properties panel is synchronous. You provide a getOptions function that returns an array, and the panel renders a select element with those options. This works for static choices.

Ticket types are not static. They come from Camunda's process definition API. Ticket phases depend on which type was selected — you can't know them until the user has made their type selection and you've fetched from the API. Field names depend on which phase was selected.

The naive approach — pre-load all options at panel open time — doesn't scale. Fetching all ticket types, all phases for all types, and all field names for all phases would be hundreds of API calls on every panel open. You need lazy loading: fetch each level's options only when the previous level has been selected.

The problems to solve:

Async fetching inside Preact component hooks — useEffect with the right dependency array
Reset cascade — when level N changes, clear all levels below N
Storing enriched data — you need the full details object, not just the selected ID, for downstream fetching
Atomic multi-path updates — resetting multiple schema paths in one operation
Per-level loading states — each level has its own loading indicator
Per-level error handling — a failure at level 2 shouldn't prevent level 1 from working
SearchableSelect — hundreds of options at each level make native select unusable

What I Tried First

My first attempt was to fetch all the data at the provider level — in getGroups — and pass options as props to each entry component:

// ❌ Attempt 1: Fetch in getGroups
async getGroups(element, editField) {
  // Can't do this — getGroups is synchronous
  const ticketTypes = await fetchTicketTypes();

  return (groups) => {
    // ...
  };
}

getGroups is synchronous. You cannot await inside it. The middleware function it returns is also synchronous. Async data fetching cannot happen in getGroups.

My second attempt was to fetch in the module constructor, store results in instance variables, and pass them to components:

// ❌ Attempt 2: Fetch in constructor, store on instance
export class TicketAutoFillPropertiesProvider {
  constructor(propertiesPanel, eventBus) {
    propertiesPanel.registerProvider(this, 1000);
    this._ticketTypes = [];
    this._loading = true;

    // Fetch in constructor
    fetchTicketTypes().then(types => {
      this._ticketTypes = types;
      this._loading = false;
      // But now how do you trigger a re-render? You can't.
    });
  }
}

This fetches data but has no way to trigger a panel re-render when the data arrives. The panel renders once with _loading: true and never updates when the fetch completes.

The correct approach: async data fetching belongs inside the entry components, using Preact's useState and useEffect hooks. The components are functional Preact components — they can use hooks, maintain local state, and fetch data asynchronously. When their state changes, they re-render. The panel re-renders the affected entry.

The Solution: Async Fetching in Entry Components

Each level of the cascade is a separate entry component. Each component manages its own loading state, options list, and error state using Preact hooks.

The Full Four-Level Cascade

Here is the complete implementation of all four levels, showing how they connect:

Level 1: Behavior Selection

The first level is synchronous — static options, no async fetching:

function TicketAutoFillBehaviorEntry(props) {
  const { field, getValue, setValue, id } = props;

  // ✅ Static options — no async needed
  const getOptions = () => [
    { value: '', label: '-- None --' },
    { value: 'current_ticket', label: 'Current Ticket' },
    { value: 'another_ticket', label: 'Another Ticket' }
  ];

  return SelectEntry({
    element: field,
    getValue,
    id,
    label: 'Ticket Auto Fill',
    description: 'Auto-fill from ticket data',
    getOptions,
    setValue,
    tooltip: 'Select how to auto-fill this field from ticket data'
  });
}

When this selection changes, the setValue function (from the entry definition) is called. The onChange factory in createTicketAutoFillEntries handles the reset cascade:

const onChange = (key) => (value) => {
  const currentConfig = get(field, ['ticketAutoFillLogic']) || {};
  const newConfig = { ...currentConfig, [key]: value };

  // ✅ Reset cascade when behavior changes
  if (key === 'behavior') {
    if (value === 'current_ticket') {
      // Clear all 'another_ticket' fields
      delete newConfig.ticketFieldKey;
      delete newConfig.ticketType;
      delete newConfig.ticketTypeDetails;
      delete newConfig.ticketPhase;
      delete newConfig.ticketPhaseDetails;
      delete newConfig.fieldName;
      delete newConfig.populateOptions;
      delete newConfig.condition;
    } else if (value === 'another_ticket') {
      // Clear all 'current_ticket' fields
      delete newConfig.currentTicketFieldName;
    } else {
      // None selected — clear everything
      delete newConfig.currentTicketFieldName;
      delete newConfig.ticketFieldKey;
      delete newConfig.ticketType;
      delete newConfig.ticketTypeDetails;
      delete newConfig.ticketPhase;
      delete newConfig.ticketPhaseDetails;
      delete newConfig.fieldName;
      delete newConfig.populateOptions;
      delete newConfig.condition;
    }
  }

  // ✅ Reset downstream when ticket type changes
  if (key === 'ticketType') {
    newConfig.ticketPhase = '';
    newConfig.ticketPhaseDetails = null;
    newConfig.fieldName = '';
  }

  // ✅ Reset field name when phase changes
  if (key === 'ticketPhase') {
    newConfig.fieldName = '';
  }

  return editField(field, 'ticketAutoFillLogic', newConfig);
};

The reset cascade happens in onChange — the function that setValue calls. Every time a selection changes, all downstream selections are cleared. This ensures the panel never shows a stale downstream selection after an upstream change.

Level 2: Ticket Type Selection

function TicketAutoFillTicketTypeEntry(props) {
  const { field, getValue, setValue, id, editField } = props;

  const config = get(field, ['ticketAutoFillLogic']) || {};
  const behavior = config.behavior;

  // ✅ Pattern 3 from Article 11: return null when condition not met
  if (behavior !== 'another_ticket') {
    return null;
  }

  // ✅ Per-level state: loading, options, error
  const [ticketTypes, setTicketTypes] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  // ✅ Fetch on mount — behavior is already 'another_ticket' at this point
  useEffect(() => {
    const fetchTicketTypes = async () => {
      setLoading(true);
      setError(null);

      try {
        const response = await deploymentClient.get('/workflow-engine/process-definitions/', {
          params: {
            limit: 100,
            offset: 0,
            sort_by: 'version',
            sort_order: 'desc',
            latest_version_only: true,
            latest_active_startable_only: true
          }
        });

        const definitions = response.data?.process_definitions || [];

        const options = definitions.map(def => ({
          value: def.id,
          label: def.name || def.key,
          // ✅ Store full object alongside ID
          processData: def
        }));

        setTicketTypes(options);
      } catch (err) {
        setError(err.message);
        notify.error(`Failed to load ticket types: ${err.message}`, 5000);
        setTicketTypes([]);
      } finally {
        setLoading(false);
      }
    };

    fetchTicketTypes();
  }, []); // ✅ Empty deps — fetch once when component mounts

  // ✅ Custom setValue that stores full details, not just the ID
  const handleSetValue = (selectedId) => {
    const selectedOption = ticketTypes.find(opt => opt.value === selectedId);

    if (selectedOption && selectedOption.processData) {
      const currentConfig = get(field, ['ticketAutoFillLogic']) || {};

      // ✅ Use editField directly — updating multiple paths atomically
      // We can't use setValue (which only updates ticketType)
      // because we also need to store ticketTypeDetails
      // and reset downstream selections
      const newConfig = {
        ...currentConfig,
        ticketType: selectedId,
        ticketTypeDetails: selectedOption.processData, // ✅ Full object stored
        // ✅ Reset downstream
        ticketPhase: '',
        ticketPhaseDetails: null,
        fieldName: ''
      };

      editField(field, 'ticketAutoFillLogic', newConfig);
      notify.success(`Selected: ${selectedOption.label}`, 2000);
    } else {
      // Fallback: just update the ID if no processData
      setValue(selectedId);
    }
  };

  const getOptions = () => {
    if (loading) return [];
    if (error) return [{ value: '', label: 'Error loading ticket types' }];
    return [
      { value: '', label: '-- Select Ticket Type --' },
      ...ticketTypes
    ];
  };

  return SearchableSelect({
    element: field,
    getValue,
    id,
    label: 'Ticket Type',
    description: 'Process definition to use',
    getOptions,
    setValue: handleSetValue, // ✅ Custom handler, not raw setValue
    loading,
    placeholder: 'Search ticket types...',
    tooltip: 'Select the ticket type/process definition'
  });
}

Why store ticketTypeDetails? Level 3 — the ticket phase selector — needs to know the ticket type's ID to fetch phases. It already has config.ticketType. But the phase fetch URL requires the ticket type ID, and different API endpoints may use different ID formats. Storing the full processData object means level 3 can extract whatever it needs without making another API call to re-fetch the ticket type.

Why use editField instead of setValue? setValue (from the entry definition) updates only the specific path it was created for — in this case, ['ticketAutoFillLogic', 'ticketType']. But when the ticket type changes, you also need to update ticketTypeDetails, clear ticketPhase, clear ticketPhaseDetails, and clear fieldName. These are five separate schema paths. Calling setValue five times would result in five separate schema updates and five panel re-renders. Using editField directly lets you build the complete new config object and write it in one operation — one schema update, one re-render.

Level 3: Ticket Phase Selection

function TicketAutoFillTicketPhaseEntry(props) {
  const { field, getValue, setValue, id, editField } = props;

  const config = get(field, ['ticketAutoFillLogic']) || {};
  const behavior = config.behavior;
  const ticketType = config.ticketType; // ✅ Depends on level 2's selection

  // ✅ Only show when behavior AND ticketType are set
  if (behavior !== 'another_ticket' || !ticketType) {
    return null;
  }

  // ✅ Per-level state — independent from level 2's loading state
  const [phases, setPhases] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  // ✅ Fetch when ticketType changes
  // ticketType is in the dependency array — re-fetch if it changes
  useEffect(() => {
    if (!ticketType) {
      setPhases([]);
      return;
    }

    const fetchPhases = async () => {
      setLoading(true);
      setError(null);

      try {
        const response = await deploymentClient.get(
          `/camunda/tickets/types/${encodeURIComponent(ticketType)}/phases/`,
          { params: { exclude_form_content: true } }
        );

        const phasesData = response.data?.phases || [];

        const options = phasesData.map(phase => ({
          value: phase.activity_id,
          label: phase.activity_name || phase.activity_id,
          // ✅ Store full activity data for downstream use
          activityData: {
            id: phase.activity_id,
            name: phase.activity_name,
            type: phase.activity_type,
            form_key: phase.form_key
          }
        }));

        setPhases(options);
      } catch (err) {
        setError(err.message);
        notify.error(`Failed to load ticket phases: ${err.message}`, 5000);
        setPhases([]);
      } finally {
        setLoading(false);
      }
    };

    fetchPhases();
  }, [ticketType]); // ✅ ticketType in deps — re-fetch when it changes

  const handleSetValue = (selectedId) => {
    const selectedOption = phases.find(opt => opt.value === selectedId);

    if (selectedOption && selectedOption.activityData) {
      const currentConfig = get(field, ['ticketAutoFillLogic']) || {};

      // ✅ Atomic update: phase + phaseDetails + reset downstream
      const newConfig = {
        ...currentConfig,
        ticketPhase: selectedId,
        ticketPhaseDetails: selectedOption.activityData, // ✅ Store full details
        fieldName: '' // ✅ Reset downstream
      };

      editField(field, 'ticketAutoFillLogic', newConfig);
      notify.success(`Selected: ${selectedOption.label}`, 2000);
    } else {
      setValue(selectedId);
    }
  };

  const getOptions = () => {
    if (loading) return [];
    if (error) return [{ value: '', label: 'Error loading phases' }];
    if (phases.length === 0) return [{ value: '', label: 'No phases available' }];
    return [
      { value: '', label: '-- Select Phase --' },
      ...phases
    ];
  };

  return SearchableSelect({
    element: field,
    getValue,
    id,
    label: 'Ticket Phase',
    description: 'Activity to pull data from',
    getOptions,
    setValue: handleSetValue,
    loading,
    placeholder: 'Search phases...',
    tooltip: 'Select the phase/activity'
  });
}

The useEffect dependency array is critical here. When the designer selects a different ticket type, level 2's handleSetValue calls editField which updates config.ticketType. Level 3's component re-renders because field changed. The useEffect runs again because ticketType in the dependency array is now different. Level 3 fetches phases for the new ticket type. Level 3's options update automatically.

Without ticketType in the dependency array, the effect only runs on mount. If the designer changes the ticket type, level 3 would show stale phases from the previous type.

Level 4: Field Name Selection

function TicketAutoFillFieldNameEntry(props) {
  const { field, getValue, setValue, id } = props;

  const config = get(field, ['ticketAutoFillLogic']) || {};
  const behavior = config.behavior;
  const ticketType = config.ticketType;
  const ticketPhase = config.ticketPhase; // ✅ Depends on level 3's selection

  // ✅ Three conditions — all three upstream levels must be set
  if (behavior !== 'another_ticket' || !ticketType || !ticketPhase) {
    return null;
  }

  const [fieldOptions, setFieldOptions] = useState([]);
  const [loading, setLoading] = useState(false);

  // ✅ Fetch when EITHER ticketType OR ticketPhase changes
  useEffect(() => {
    if (!ticketType || !ticketPhase) {
      setFieldOptions([]);
      return;
    }

    const fetchFormFields = async () => {
      setLoading(true);

      try {
        // ✅ Uses ticketType to identify the process
        const response = await deploymentClient.get(
          `/camunda/tickets/types/${encodeURIComponent(ticketType)}/search-options`
        );

        // ✅ Uses ticketPhase to find the specific activity
        const activities = response.data?.activities || [];
        const selectedActivity = activities.find(act => act.id === ticketPhase);

        if (!selectedActivity) {
          notify.warning(`Activity "${ticketPhase}" not found`, 3000);
          setFieldOptions([]);
          return;
        }

        const formFields = selectedActivity.form_fields || [];
        const options = formFields.map(field => ({
          value: field.key,
          label: field.label || field.key
        }));

        setFieldOptions(options);
      } catch (err) {
        console.error('Failed to fetch form fields:', err);
        notify.error(`Failed to load form fields: ${err.message}`, 5000);
        setFieldOptions([]);
      } finally {
        setLoading(false);
      }
    };

    fetchFormFields();
  }, [ticketType, ticketPhase]); // ✅ Both deps — re-fetch when either changes

  const getOptions = () => {
    if (loading) return [{ value: '', label: 'Loading fields...' }];
    if (fieldOptions.length === 0) return [{ value: '', label: 'No fields available' }];
    return [
      { value: '', label: '-- Select Field --' },
      ...fieldOptions
    ];
  };

  return SearchableSelect({
    element: field,
    getValue,
    id,
    label: 'Field Name',
    description: 'Variable to use for auto-fill',
    getOptions,
    setValue,
    loading,
    placeholder: 'Search fields...',
    tooltip: 'The field variable to populate this field with'
  });
}

Level 4 depends on both ticketType and ticketPhase. When either changes, the fetch re-runs. This means if the designer changes the ticket type, level 3's handleSetValue clears ticketPhase — which causes level 4 to return null immediately (condition: !ticketPhase) and unmount. When the designer selects a new phase in level 3, level 4 mounts again and fetches for the new combination of type and phase.

Why `SearchableSelect` Is Necessary at Every Level

Ticket types can number in the hundreds across a mature Camunda deployment. A native HTML <select> element with 200 options is unusable — the designer has to scroll through a long list to find what they want.

SearchableSelect (covered in detail in Article 14) provides:

A text input to filter options as you type
Keyboard navigation (ArrowUp, ArrowDown, Enter, Escape)
A loading state that shows "Loading..." while fetching
Accessible label association
Consistent styling with the rest of the properties panel

For cascading configuration specifically, the loading state is essential. Between the moment a designer selects a ticket type and the moment the phases finish loading, the level 3 component shows its select button with "Loading..." text. Without this, the designer might think the panel is frozen and click again.

The Full Picture: What Happens on Each Selection

Here is the sequence for a complete configuration:

Designer selects behavior: "another_ticket"
  → onChange('behavior')('another_ticket') called
  → ticketType, ticketPhase, fieldName all cleared
  → field schema updated via editField
  → Panel re-renders
  → TicketAutoFillTicketTypeEntry mounts (behavior === 'another_ticket')
  → useEffect fires, API called
  → Ticket types loaded into local state
  → SearchableSelect renders with type options

Designer selects ticket type: "process-123"
  → handleSetValue('process-123') called
  → ticketType = 'process-123', ticketTypeDetails = {full object}
  → ticketPhase = '', ticketPhaseDetails = null, fieldName = ''
  → editField updates schema atomically
  → Panel re-renders
  → TicketAutoFillTicketPhaseEntry mounts (behavior + ticketType set)
  → useEffect fires with ticketType = 'process-123'
  → Phases loaded for process-123
  → TicketAutoFillFieldNameEntry stays null (ticketPhase not set)

Designer selects ticket phase: "activity-456"
  → handleSetValue('activity-456') called
  → ticketPhase = 'activity-456', ticketPhaseDetails = {full object}
  → fieldName = ''
  → editField updates schema atomically
  → Panel re-renders
  → TicketAutoFillFieldNameEntry mounts (all three conditions met)
  → useEffect fires with ticketType + ticketPhase
  → Form fields loaded for process-123, activity-456

Designer selects field name: "assignee"
  → setValue('assignee') called
  → fieldName = 'assignee'
  → schema updated
  → Configuration complete

Designer changes ticket type to "process-789"
  → handleSetValue('process-789') called
  → ticketType = 'process-789'
  → ticketPhase cleared, fieldName cleared  ← Reset cascade
  → editField updates schema atomically
  → Panel re-renders
  → TicketAutoFillTicketPhaseEntry useEffect fires with new ticketType
  → New phases fetched for process-789
  → TicketAutoFillFieldNameEntry returns null (ticketPhase cleared)

The reset cascade and the component-level null checks work together to keep the UI consistent. You can never have a phase selected that belongs to a different ticket type than the one currently selected.

The Minimal Two-Level Cascade Template

If you have a simpler cascading select — for example, a region selector followed by a city selector — here is the minimal template:

// Entry factory — creates both levels
function createRegionCityEntries(field, editField, eventBus) {
  const fieldId = field.id;

  // Helper: update config path
  const onConfigChange = (key) => (value) => {
    const current = get(field, ['my_config'], {});
    const newConfig = { ...current, [key]: value };

    // ✅ Reset city when region changes
    if (key === 'region') {
      newConfig.city = '';
    }

    editField(field, 'my_config', newConfig);
  };

  const getConfigValue = (key) => () => {
    return get(field, ['my_config', key], '');
  };

  return [
    // ✅ Level 1: Region — static options
    {
      id: `region-select-${fieldId}`,
      component: RegionEntry,
      getValue: getConfigValue('region'),
      setValue: onConfigChange('region'),
      field,
      isEdited: () => !!get(field, ['my_config', 'region'])
    },
    // ✅ Level 2: City — dynamic, depends on region
    {
      id: `city-select-${fieldId}`,
      component: CityEntry,
      getValue: getConfigValue('city'),
      setValue: onConfigChange('city'),
      field,
      isEdited: () => !!get(field, ['my_config', 'city'])
    }
  ];
}

// Level 1: Static options — no async needed
function RegionEntry(props) {
  const { field, id, getValue, setValue } = props;

  return SelectEntry({
    element: field,
    getValue,
    id,
    label: 'Region',
    getOptions: () => [
      { value: '', label: '-- Select Region --' },
      { value: 'north', label: 'North' },
      { value: 'south', label: 'South' },
      { value: 'east', label: 'East' },
      { value: 'west', label: 'West' }
    ],
    setValue
  });
}

// Level 2: Dynamic options — async, depends on level 1
function CityEntry(props) {
  const { field, id, getValue, setValue } = props;

  const config = get(field, ['my_config']) || {};
  const region = config.region;

  // ✅ Return null when upstream not set
  if (!region) return null;

  // ✅ Per-level state
  const [cities, setCities] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  // ✅ Fetch when region changes
  useEffect(() => {
    if (!region) {
      setCities([]);
      return;
    }

    const fetchCities = async () => {
      setLoading(true);
      setError(null);
      try {
        const response = await myApiClient.get(`/cities?region=${region}`);
        const data = response.data || [];
        setCities(data.map(city => ({
          value: city.id,
          label: city.name
        })));
      } catch (err) {
        setError(err.message);
        setCities([]);
      } finally {
        setLoading(false);
      }
    };

    fetchCities();
  }, [region]); // ✅ region in deps — re-fetch when it changes

  const getOptions = () => {
    if (loading) return [];
    if (error) return [{ value: '', label: 'Error loading cities' }];
    return [
      { value: '', label: '-- Select City --' },
      ...cities
    ];
  };

  // ✅ SearchableSelect for large option lists
  return SearchableSelect({
    element: field,
    getValue,
    id,
    label: 'City',
    getOptions,
    setValue,
    loading,
    placeholder: 'Search cities...'
  });
}

This two-level template is the foundation. Add more levels by following the same pattern: check upstream conditions at the top (return null if not met), put the dependency in the useEffect array, reset downstream selections in onChange.

The Tradeoffs

Every API call happens in a component, not a service. Ideally, data fetching would happen in a dedicated service class that caches results and manages loading states centrally. In the properties panel context, there's no convenient service layer — you're inside functional Preact components. Moving fetching to the provider class (as a service method) would work but requires passing references through the entire component tree.

No shared cache between component instances. If the designer opens the properties panel for two different fields that both use ticket auto-fill, each renders its own component instances with separate useState for ticket types. Both fetch the ticket types list independently. The simplest fix is a module-level cache:

// Module-level cache — shared across all component instances
let cachedTicketTypes = null;
let cachedTicketTypesPromise = null;

async function getTicketTypes() {
  if (cachedTicketTypes) return cachedTicketTypes;
  if (!cachedTicketTypesPromise) {
    cachedTicketTypesPromise = deploymentClient.get('/workflow-engine/process-definitions/', {
      params: { ... }
    }).then(response => {
      cachedTicketTypes = response.data?.process_definitions || [];
      return cachedTicketTypes;
    });
  }
  return cachedTicketTypesPromise;
}

// In the component:
useEffect(() => {
  setLoading(true);
  getTicketTypes()
    .then(types => setTicketTypes(types.map(...)))
    .catch(err => setError(err.message))
    .finally(() => setLoading(false));
}, []);

I didn't implement this cache in the initial version. It's a straightforward improvement that reduces API calls at the cost of stale data if process definitions change while the panel is open.

The reset cascade is in onChange, not in the component. This means the cascade only runs when the designer changes a value through the properties panel. If the field's schema is modified programmatically (e.g., by a form import or schema migration), the cascade doesn't run and the schema may have inconsistent state — a phase ID that belongs to a different ticket type than the stored type ID. Adding schema validation to the panel open event would catch this.

Loading states per level don't communicate to each other. If level 2 is loading and level 3 tries to render (which shouldn't happen because level 3's null check requires ticketType to be set, and it isn't set until level 2 completes), there's no synchronization mechanism. In practice, level 3 can't render while level 2 is loading because level 2 hasn't called editField yet — ticketType is still empty. The null checks provide the synchronization naturally.

What Comes Next

The cascading configuration UI works because of SearchableSelect — a component that makes hundreds of options navigable. Building SearchableSelect for the properties panel (in Preact, not React) involves specific challenges that don't apply to building it for form renderers.

Article 13 covers SearchableSelect in the Preact properties panel context — keyboard navigation with Preact hooks, the onInput vs onChange difference in Preact, click-outside detection, and why you can't use a React library here even if you've already built one for your form renderers.

This is Part 12 of "Extending bpmn-io Form-JS Beyond Its Limits." The series covers the complete architecture for production-grade Form-JS extensions — the documentation that doesn't exist yet.

Tags: camunda bpmn formjs properties-panel async cascading-select form-editor javascript devex

推荐订阅源

DEV Community

The Problem

What I Tried First

The Solution: Async Fetching in Entry Components

The Full Four-Level Cascade

Level 1: Behavior Selection

Level 2: Ticket Type Selection

Level 3: Ticket Phase Selection

Level 4: Field Name Selection

Why `SearchableSelect` Is Necessary at Every Level

The Full Picture: What Happens on Each Selection

The Minimal Two-Level Cascade Template

The Tradeoffs

What Comes Next

推荐订阅源

DEV Community

The Problem

What I Tried First

The Solution: Async Fetching in Entry Components

The Full Four-Level Cascade

Level 1: Behavior Selection

Level 2: Ticket Type Selection

Level 3: Ticket Phase Selection

Level 4: Field Name Selection

Why SearchableSelect Is Necessary at Every Level

The Full Picture: What Happens on Each Selection

The Minimal Two-Level Cascade Template

The Tradeoffs

What Comes Next

Why `SearchableSelect` Is Necessary at Every Level