Breaking the CRUD Sisyphus Loop: Low‑Code, DSL, and Atomic Components for Frontend Development

Low‑Code

Low‑code platforms that emerged a few years ago usually let developers model data and generate CRUD pages with a single click, but they often fail to solve complex problems and become a marketing hype without solid engineering foundations.

💡 The "low‑code" discussed here refers to a narrow, visual‑builder style platform.

While low‑code is easy to start with, the core software engineering effort still accounts for only 20‑30% of the total development time, and continuous business changes require ongoing code refactoring that visual tools struggle to support.

Complex business logic becomes even more complex when forced into low‑code GUIs.

Software engineering is an evolving process; current low‑code tools provide little assistance for maintainability or verification.

Other issues include vendor lock‑in, lack of standards, performance, reusability, extensibility, security, and high operational cost.

Low‑code is suitable for specific, non‑core scenarios such as marketing pages, dashboards, form engines, or quick POCs.

Intermediate Form – DSL

Between visual low‑code platforms and hand‑written code lies a domain‑specific language (DSL). A DSL abstracts the problem domain, making the concrete syntax less important than the abstraction itself.

💡 DSLs can be built as new micro‑languages, JSON/YAML specifications, or extensions of existing meta‑languages like Ruby, Groovy, or Rust.

Visually‑driven low‑code platforms are essentially visual DSLs; their limitations stem from the visual representation rather than the abstraction.

Abstraction Process

Typical CRUD pages consist of forms and tables, which are built from atomic "fields". These fields have two states: edit and preview. By extracting fields as reusable "atoms" (called 原件 or Atomic ), we can treat them as the smallest building blocks of CRUD interfaces.

The atomic component encapsulates data type, validation, preview, and value handling (value/onChange), enabling a declarative definition of tables and forms.

Declarative Table Example

import { defineFatTable } from '@wakeadmin/components'

/**
 * Table item type
 */
export interface Item {
  id: number
  name: string
  createDate: number
}

export const MyTable = defineFatTable<Item>(({ column }) => {
  // Vue hooks can be placed here
  return () => ({
    async request(params) { /* fetch data */ },
    async remove(list, ids) { /* delete rows */ },
    columns: [
      column({ prop: 'name', label: '名称', queryable: true }),
      column({ prop: 'createDate', valueType: 'date-range', label: '创建时间', queryable: true }),
      column({
        type: 'actions',
        label: '操作',
        actions: [{ name: '编辑' }, { name: '删除', onClick: (table, row) => table.remove(row) }],
      }),
    ],
  })
})

Declarative Form Example

import { defineFatForm } from '@wakeadmin/components'
import { ElMessageBox } from 'element-plus'

export default defineFatForm<{ name: string; nickName: string }>(({ item, form, consumer, group }) => {
  // Vue hooks can be placed here
  return () => ({
    initialValue: { name: 'ivan', nickName: '狗蛋' },
    submit: async (values) => {
      await ElMessageBox.confirm('确认保存')
      console.log('保存成功', values)
    },
    children: [
      item({ prop: 'name', label: '账号名' }),
      item({ prop: 'nickName', label: '昵称' }),
    ],
  })
})

Global configuration can be injected to standardize component behavior, such as image upload endpoints or date‑range picker defaults.

Conventions Over Configuration

To reduce boilerplate and communication overhead, front‑end teams should align on layout, UI style, validation rules, data formats, and common APIs (e.g., file upload, import/export). Embedding these conventions into the component library enables an "out‑of‑the‑box" experience.

Summary

By moving from a "bare‑bones" to a "fully‑fitted" approach—using visual abstraction, atomic components, and a declarative DSL—developers can focus on business logic rather than repetitive technical details, achieving a high‑level of productivity for the majority of CRUD scenarios while still allowing custom extensions for the remaining edge cases.