In modern enterprise digital transformation, low‑code rapid development platforms greatly reduce the cycle for building internal management systems. Most developers focus on tables and forms, yet overlook the importance of button components. Buttons act as the trigger entry for almost all business behaviors: querying data, creating records, editing forms, deleting entries, exporting files and popping dialog windows. Many strange bugs in low‑code projects are not caused by back‑end interface errors, but by improperly configured button events, missing pre‑check logic, or unreasonable state control.
Unlike many conventional low‑code products that provide hard‑coded buttons with fixed built‑in actions, Geejing WebBuilder provides a fully programmable enterprise‑grade Wb.Button component. It separates visual appearance, runtime state and click events. Developers can freely assemble business flows without being limited by preset templates. Even complex composite business logic can be completed inside button click handlers. This article systematically introduces button attributes, event mechanism, typical business implementations, advanced features and common troubleshooting for real‑world enterprise projects.
Basic attributes of the button component
The button component consists of visual configuration and dynamic state configuration. Visual attributes define how the component renders on the page, while state attributes control interactivity at runtime.
text: The display label of the button, such as Query, Reset, New, Edit, Delete, Save, Export. Business‑oriented text helps end‑users understand operations without extra documentation.
type: Style type, including primary, default, danger, text. Use primary for core positive operations; danger for high‑risk actions like deletion; text‑style buttons for auxiliary lightweight operations. Clear visual distinction lowers mis‑operation risks.
icon: Built‑in system icon name. Matching icons improve page readability and consistency across the whole system.
size: Controls button dimension, keep unified size within one page for better UI experience.
disabled: Static or dynamic expression. When true, the button becomes non‑clickable. It is widely used for scenario locking: disable Edit and Delete when no table row is selected, or disable modification after business documents are audited.
hidden: Supports dynamic binding. Buttons can be hidden according to user roles, data status or process phases to implement fine‑grained front‑end permission control.
loading: Loading status. After user clicks, enable loading status during asynchronous requests to prevent duplicate clicks caused by network latency.
A common mistake for beginners is only setting text and style, ignoring state‑related configurations. In enterprise‑level development, dynamic state control is equally important as business event logic.
Core event mechanism: onClick click event
The onClick event is the core of the button component. All business logic is triggered here. WebBuilder follows a separation‑of‑concerns principle: button front‑end scripts are responsible for obtaining component values, pre‑verification, popup control, parameter assembly, page refresh and user prompts. Real database write operations must be completed in server‑side scripts, never directly in front‑end event code.
Standard execution sequence for a complete button click:
Pre‑condition check: verify whether the table has selected rows, whether form mandatory fields are filled. If conditions are not met, pop‑up warning message and terminate subsequent logic.
Assemble request parameters: collect values from input boxes, drop‑down dictionaries or selected table row data.
Trigger asynchronous ajax request to invoke server‑side action script.
Process callback results according to success or failure status.
Update page status: close dialog, reload grid table data, clear form fields.
Give user feedback through alert or toast prompt.
This standardized execution chain avoids most logical defects. Many developers write business code skipping pre‑check or page‑refresh steps, which leads to phenomena such as “data saved in database but page remains unchanged”.
Implementation of typical business scenarios
In enterprise management systems, button‑driven operations converge into several classic scenarios. These code patterns can be reused in most data‑list pages.
Query Button
Read values from query area components, assemble filter parameters, reset grid pagination to page one, and reload table data. If some query inputs are empty, skip empty parameters to avoid invalid filter conditions. Without resetting pagination, filtered results may show blank content when matched data count is less than previous page offset.
Reset Button
Clear all query components, restore them to initial values, reset grid pagination, and reload original full dataset. It prevents residual filter conditions from interfering with subsequent operations.
New Button
Clear all form fields inside the dialog, exit edit mode, and open the popup window. A frequent bug is that old form data remains when creating another new entry, because developers forget to clear form values before opening dialog.
Edit Button
First check whether one table row is selected. If no row is selected, pop‑up reminder and return. Obtain primary key ID from selected row, call server‑side script to get detail data, assign values to form fields, then open edit dialog. Missing row‑selection check will cause blank dialog or runtime script error.
Delete Button
Row selection check is required. Then trigger confirmation popup to avoid accidental deletion. After user confirms, call server‑side delete script. On success, refresh grid and show success prompt. Confirmation prompt is mandatory for production systems.
Save Button inside dialog
Trigger front‑end form validation first. After validation passes, package all form field data and submit to server‑side script. Server‑side performs secondary data validation and database CRUD. When callback returns success, close dialog window and refresh main grid table.
Export Button
Reuse current query filter conditions, pass parameters to back‑end script, generate excel file stream and trigger browser download. It supports both full‑data export and conditional filtered export for business report requirements.
Advanced enterprise‑level capabilities
Beyond basic CRUD operations, buttons support advanced interactive capabilities for complex business requirements.
Dynamic state linkage is a powerful feature. Buttons’ disabled and hidden attributes support data‑driven expressions. For example, after a business order status changes to “completed”, edit and delete buttons are automatically disabled; only view and export remain available. When no grid row is selected, edit and delete buttons turn disabled automatically. This kind of intelligent interaction reduces manual mis‑operations and enhances business constraint without writing complex judgment code inside click events.
Role‑based button visibility control can be implemented via hidden property. Different roles see different operation sets on the same page. Front‑end hiding is only for UI experience; real permission interception still needs to be guaranteed in server‑side scripts.
Loading status prevents duplicate submission. During ajax request, set button loading to true. After request completes (whether success or fail), release loading status. It solves duplicate record creation caused by slow network response.
Composite multi‑step operations can be realized in one onClick event. One button click can trigger a whole workflow: data validation → update business status → generate log records → export attachment → refresh table. This simplifies user operation steps for complicated enterprise workflows.
Common pitfalls and troubleshooting
Many button‑related problems appear in real‑world projects. Summarized typical issues are as follows:
Button clicks produce no response: Usually onClick event is empty, or script runtime error interrupts execution. Check browser console for script exceptions.
Edit dialog shows blank: Missing row‑selection pre‑check, or primary key ID not correctly passed to detail interface.
Data saved to database but page display unchanged: Forget to call grid reload method after successful callback.
Old form data remains when creating new records: Missing form‑clear logic in new‑button event.
Duplicate data submitted: Lack of loading anti‑repetition mechanism.
Accidental data deletion: No confirmation popup before delete action.
Developers can establish a fixed inspection checklist when debugging button logic: pre‑check logic exists? parameters are correctly assembled? server‑side script is invoked? page state is refreshed after callback? user prompt is provided?
Conclusion
In Geejing WebBuilder low‑code development, button components are far more than simple UI click controls. They are the scheduling hub connecting UI components, front‑end scripts and server‑side business logic. Excellent button implementation requires reasonable visual configuration, complete pre‑condition check, standardized asynchronous callback processing, proper runtime state management, and strict separation of front‑end and back‑end responsibilities.
Many developers only drag‑and‑drop components visually without standardizing event logic, resulting in demo‑style pages that cannot go online for production. By mastering button‑component development specifications summarized in this article, developers can build stable, secure, user‑friendly enterprise management systems, and improve overall project quality in low‑code rapid‑development platforms.
Top comments (0)