Simplifying Component Interaction in Low-Code Frontend Development

Background : The map data operation platform is transitioning from a large WebGIS “comprehensive operation” to a human‑machine combined, WYSIWYG “simple operation” workflow. The simple workflow consists of many customized workshop logics that are hard to configure, making low‑code approaches necessary.

Problem analysis: A basic component linkage example is shown (Figure 2‑1). The current low‑code engine requires writing event‑callback code, which is easy for front‑end engineers but difficult for non‑technical users (product, process engineers) because they must understand event‑driven programming, immutability, two‑way binding, etc.

Goal: Provide a code‑free or expression‑only solution for such linkage.

Code analysis (pseudo‑code) :

class Main extends PurComponents {
  constructor() {
    this.state = {
      A: '',
      B: '',
      C: '',
    }
  }
  // response logic
  handleAChange = (e) => {
    // 1. data source filtering
    const { target: { value } } = e;
    // 2. two‑way binding, organize data structure
    let stateOptions = { A: value };
    // 3. data linkage
    if (value === '1') {
      stateOptions = {
        ...stateOptions,
        B: '',
        C: '',
      }
    }
    // 4. update data
    this.setState(stateOptions);
  };
  render() {
标牌是否是施工场景
this.handleAChange(e)} />
      ...
...
... bla bla bla
  }
}

The implementation can be divided into UI and logic. In visual building, UI and simple interactions are handled by the component itself, while cross‑component logic is expressed as event callbacks. These callbacks can be broken down into four functional parts:

Data filtering – extracting needed data from function parameters (event‑driven).

Two‑way binding – controlled components driven by external data, updating dependent sources (immutability).

Data linkage – business logic that updates other components.

Data update – using the front‑end framework API.

To hide these concepts from non‑technical users, the platform introduces a saveEffect object that describes a side‑effect with three fields: fromPath (source), toPath (target), and formatFunc (transformation). Example:

{
  // source data
  fromPath: 'e.target.value',
  // target data
  toPath: 'state.B',
  // conversion logic
  formatFunc: 'function switchStoreValue(value, state) { return A == 1 ? "" : state.B };'
}

The saveEffect setter lets users select source and target paths and optionally write a conversion function. The plugin parses the object, generates the necessary state references, and automatically calls setState to update the UI.

Usage effect: In a real workshop, the saveEffect setter reduces the amount of code needed. Instead of writing a full event handler (see original JS example), the user only needs to assign the target value:

state.arrowList[state.currentIndex].type = value

The corresponding setter UI is shown in Figure 3‑1.

Integration with pro‑code components: After understanding the saveEffect mechanism, ordinary UI components can be adapted by injecting the saveEffect via the low‑code setter layer, without changing the component’s internal logic.

Summary and outlook : By providing custom plugins, setters, and standardized components, the platform lowers the difficulty of component linkage and data handling for non‑developers, enabling them to build fine‑grained workshops independently. Future work includes adding visual logic orchestration to achieve graphical representation of complex logic.