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

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 754819) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Sam Abaasi Posted on Apr 28 Cascading Configuration UI: Building Dependent Selection Chains in the Properties Panel #camunda #formio #bpmnio #javascript Extending bpmn-io Form-JS Beyond Its Limits (12 Part Series) 1 The bpmn-io Form-JS Module System: Dependency Injection Nobody Explains 2 Building Your First Custom Field in Form-JS: The Complete Four-Layer Architecture ... 8 more parts... 3 FEEL at Runtime in Form-JS: Building an Expression Evaluation Pipeline from Scratch 4 Preparing a FEEL Context: The Type Coercion Problem Nobody Warns You About 5 The Properties Panel Provider Contract: What the Official Docs Leave Out 6 Overriding Default Properties Panel Entries: How to Replace What Form-JS Ships With 7 The Toggle-or-FEEL Pattern: Properties That Can Be Static or Dynamic 8 Five Evaluators, One Pattern: Scaling Conditional Logic Across a Form 9 React Inside Preact: Mounting React Components in a Form-JS Renderer 10 Hooking Into Form Validation Without Breaking It: The Merge-Errors Pattern 11 Dynamic Properties Panels: Three Patterns for Conditional Entry Display 12 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…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.