Configuration-based UI (Element Logic)

Context

At Element Logic, every customer has distinct requirements — structurally similar to others, but not enough to put in the standard product. Customization touches many places in the backend and the UI, and traditionally that meant code changes scattered across the codebase.

We're also rebuilding the entire software from scratch. Without this approach, we'd have to implement every table, every admin page, every CRUD view by hand. With proper state management and our test-driven approach, a single table could take a week and a half of engineering time.

What I built

A configuration-driven system for generating UI components. Tables are the most prominent use case, but the approach is more general:

• Declare resources and components: Define data schemas, available operations, required inputs, optional live streaming channels, and presentation rules — similar to how Terraform defines infrastructure.
• Generate and register: Configurations are stored centrally, read in, and used to generate React components. Since we use a micro front-end framework, these can be registered as full pages or plugged into existing pages written in Angular, Vue, or Blazor.
• Flexible interactions: An "interaction" can mean user input, a REST call, a GraphQL query — or in theory, anything else. The config declares what; the system handles how.

The result: a declarative, capability-driven framework that scales without additional UI development effort.

Sanitized config example

Backend behaviour is defined as operations (queries and mutations). The table binds to a query for paginated data; actions bind to mutations.

resource: orders

# Backend: what the UI can call
operations:
  - id: listOrders
    type: query
    # endpoint, params, pagination shape live here
  - id: updateOrderStatus
    type: mutation
    # endpoint, input schema live here

table:
  # Table loads data from the query operation (paginated)
  query: listOrders
  columns:
    - key: orderId
      label: Order ID
    - key: status
      label: Status
  actions:
    - type: openDialog
      label: Update Status
      operation: updateOrderStatus # runs the mutation

Result: the system generates a usable table view, wires the query for data and the mutation for the action, and registers the page without hand-coding a custom table component.

Outcome

Still in active development — not deployed to customers yet. But internally, implementing a full table dropped from ~1.5 weeks to under an hour after the first couple.

More importantly, this widens who can make changes. Without it, even a simple customization — a new column, a formatting tweak — requires a developer. With config-driven UI, we can eventually get to self-service: customers make their own updates, they get features faster, and we focus on product instead of maintenance.

If this works out as expected and the initial positive feedback continues, we're considering open-sourcing the approach. Most config-driven UI solutions focus on representation only — ours includes the full stack: what the component looks like, how interactions are defined, how they execute, and how event streams drive live updates.

Key Insights

• If you're building the same type of page repeatedly, stop and abstract. The upfront investment pays off fast.
• Configuration should follow known patterns. Borrowing from Terraform's resource model made the system immediately understandable to anyone who'd seen infrastructure-as-code.
• The real unlock isn't developer productivity — it's changing who can make changes at all.

Proof: Internal demos and architecture walkthroughs are available through Element Logic channels on request.

This is my day job. I can share high-level ideas here, but specifics remain confidential until officially published or open-sourced. Detailed discussions are available to prospective Element Logic customers through standard channels.