When I start designing an interface, I always encounter the issue that event handlers are directly attached to buttons, which limits the flexibility of component interaction. The problem is that standard buttons cannot offer any other behavior. What I need is logic isolation and dynamic action management, which are not available when using standard buttons 'out of the box.' In this article, I will propose a solution on how to adapt buttons using Web Components and the 'Command' pattern, opening new possibilities for more flexible and scalable interfaces.
Usually, when we think about a button, we perceive it as a graphical control element that provides a simple way to trigger some event, action, or change in the interface’s state. This is a very straightforward and convenient definition, which fits our everyday understanding of user interface elements in web applications.
However, when we encounter a button in the context of web development, when HTML and JavaScript are involved, the first thing that comes to mind is the standard tag, which is the most commonly used tool for creating buttons on web pages. This tag typically looks like this:
<button onclick="myFunction()">Click me</button>
But if we think about it, this tag, while serving as a button, doesn't fully reflect all the possible aspects and functions that a button can perform in the broader context of user interaction with an interface.
Upon closer inspection of the definition of a button, one might notice that it doesn't provide any information about how the button should look, how it should behave, or how it should trigger an action. In this context, there’s no clear understanding of what is meant by the words “a simple way” to trigger an action, nor how the connection between the button and the action is established. We only see the basic structure of a button, which, when clicked, calls some method. But in reality, this simplicity hides a much broader range of possibilities and approaches. And so, the question arises: perhaps the button is more than just the tag we see in the example above?
Let’s approach the concept of a button from a more philosophical perspective, delving into its essence and function. What does a button really represent? If we consider the essence of a jug as its emptiness, the essence of a button can be found in its ability to initiate an action. A button is not just a user interface element; it’s a mechanism that triggers a specific process that already exists within the context of the application. The action to be performed happens within the application, in the context of the entire system, but the initiation of that action — its start — is the button’s function. Therefore, we see that the button serves as a kind of trigger, launching an action in a broader external system context.
When a user clicks on a button, they expect that this click will lead to a specific action. Consequently, the button is attributed with the responsibility for initiating this action. In other words, the button becomes the link between the user and the actions that should follow. However, it’s important to note that the method or function that actually carries out the action should not be aware that the button was the one that triggered it. This distinction between what initiates the action and what performs it is a crucial aspect that allows us to maintain flexibility and ease of interaction in more complex systems.
When the button directly performs the action or when the method implementing the action depends on the button itself, we are dealing with a rather complex and interdependent system. If we wish to simplify such a system, it’s necessary to break it down into simpler, independent parts. And here we conclude that simplifying the process of initiating an action primarily involves separating the initiation process from the action itself. And since in the context of JavaScript, the initiator is often referred to as an event, we are talking specifically about separating the event as the initiator from the logic that executes the action.
Why is it important to separate the event from the handler?
First of all, separating events from handlers significantly improves the readability of the code and promotes the creation of more modular solutions. When the button logic and its handler are intertwined, or, even worse, when the handler is an anonymous function, the code becomes extremely difficult to read and analyze. This can lead to problems when maintaining and updating the project, as understanding what the button actually does and what changes are required becomes a challenging task. In contrast, when the handler is extracted into a separate, well-named function that clearly reflects the action being performed, the structure of the code becomes more transparent. The developer immediately understands what happens when the button is clicked, and can more easily modify the behavior of the element without needing to delve into the rest of the logic. Thus, separation simplifies both reading and making changes to the code.
Secondly, separating the event logic and the handler opens up opportunities for reusing handlers across different parts of the application. When the handler is placed in its own function, it can be applied not just to one button, but to many others that have similar behavior. For example, multiple buttons performing the same action can use the same handler, which reduces code duplication and increases efficiency. Furthermore, the handler can be triggered not only via the button but also through other means, such as programmatic calls or actions initiated by other parts of the interface. This significantly expands the functionality of your application, increasing its flexibility and scalability.
Thirdly, separating events and handlers allows for more flexibility in the buttons themselves. If the behavior of the button is now determined not within the button itself, but via a separate handler, it becomes easy to modify its actions or reassign them depending on the situation. This is especially important in projects with dynamic interfaces, where the behavior of elements can change in response to user actions or changes in the application state. This approach allows the interface to be easily adapted to evolving requirements without disrupting the overall code structure.
Fourthly, the separation of events and handlers is crucial for testability, particularly in large projects. When event handlers are extracted into separate functions, testing them becomes much easier, as they can be tested independently of the interface. You can isolate the handler and test how it works with various parameters, without worrying about interaction with other parts of the interface. This makes testing easier, improving the reliability and stability of the application while minimizing the likelihood of errors.
Separating the button event and handler is a key step toward a cleaner, more flexible, and maintainable code architecture. This is especially important in complex projects, where the interactions between interface elements become more intricate and interdependent. This approach helps improve system stability, makes it easier to expand and modify the application, and reduces the risk of errors arising during these changes.
An example of separating a button’s event from its handler can be found in any beginner’s guide.
<button onclick="myFunction()">Click me</button>
If buttons could convey not only the context of an interaction but also the user's intent explicitly within the event, it would significantly simplify the architecture. Handlers could focus on executing tasks rather than assigning logic to events.
This highlights the need to move away from the traditional understanding of a button as a mere event initiator. Instead, it suggests adopting a more advanced model where the button acts as a bridge between user intent and application logic.
To create a more advanced model for event handling, we can leverage the Command pattern, which allows events to be linked with application logic at a higher level of abstraction. This can be achieved by introducing a layer that transforms ordinary events into commands such as saveDocument or deleteItem. Using this approach, an event becomes more than just a signal that something has occurred — it transforms into what it is meant to be: the initiator of an action, as discussed earlier in the article.
But this raises a question: why didn’t the developers of JavaScript events implement the Command pattern from the start? Why were events designed as they are now? And why were events necessary in the first place?
When HTML and related technologies like the DOM and JavaScript were initially developed, their primary goal was to create a simple structure for hypertext documents that would allow users to interact with web pages. At that time, user interaction was significantly limited, and the event-handling model was not designed to accommodate complex mechanisms such as the Command pattern. It’s essential to understand that the early web was developed to simplify the creation and management of content, not to provide sophisticated tools for complex client-side logic.
In the 1990s, when HTML and the web were being created, their focus was on providing a straightforward way to present hypertext documents with minimal user interaction. The main goal was data submission to servers rather than executing complex logic within the browser. Buttons and forms were primarily used to send data, not to initiate client-side processes. All computation and data processing were handled on the server, with buttons serving as interface elements that triggered data submission to the backend.
The Command pattern requires a more sophisticated structure that involves clear separation between the interface and processing logic, as well as a mechanism to specify the exact action to be executed. These ideas only became relevant later, as the need for dynamic interfaces and greater interactivity in web applications grew. Dynamic and complex interactions, such as triggering client-side logic through events, necessitated new approaches, including the adoption of the Command pattern.
Can the Command Pattern Be Applied to Buttons Today? Yes, it can. While standard HTML buttons don’t directly support the Command pattern, modern technologies like custom events allow us to create similar mechanisms. For example, we’ve already explored how the detail property can be used to pass additional data with events.
However, this approach is still not ideal, as it requires creating separate implementations for each button in the interface. This adds extra complexity and makes scaling such systems more challenging.
Leveraging Web Components to modernize buttons and align them with the Command pattern is a promising approach that can significantly enhance both the architecture and the flexibility of interactions in your project. Web Components provide powerful tools for creating reusable interface elements that can be seamlessly integrated into various parts of an application.
Instead of writing separate handlers for each button, you can create a unified component that acts as a button with the added ability to pass a command. This approach not only improves the structure of the code but also enhances its readability and maintainability.
Here’s a basic example of such a component:
<button onclick="myFunction()">Click me</button>
When a button component transmits a command identifier and potentially additional parameters, it establishes the foundation for a more advanced architecture. In this setup, the component containing the button and subscribing to its events essentially acts as a controller that processes the command passed through the event.
In architectural patterns such as MVC (Model-View-Controller), the controller serves as an intermediary between the model, which represents the data, and the view, which constitutes the user interface. It receives user input, such as button clicks, and manages the resulting changes to the data or state, which are then reflected in the interface.
The use of a controller within a component offers several key advantages. First, it encapsulates the logic for executing commands, keeping the main application code free from unnecessary complexity. The details of implementation remain hidden within the controller itself. Second, this approach enhances modularity, allowing buttons to be reused simply by passing different commands and parameters. It also reduces the coupling within the application, as changes to the command-handling logic require modifications only within the controller, without affecting other parts of the system. Finally, controllers provide significant flexibility. They can handle both straightforward commands, such as "save" or "delete," and more complex actions, while the button component remains simple and focused solely on its primary role.
This architecture facilitates a clean separation of concerns. The button component emits a custom event that includes the command and its relevant data, while the parent component, acting as the controller, listens for this event. The controller processes the command, interacts with the data model if necessary, and updates the user interface accordingly. This approach results in a cleaner, more scalable architecture that is easier to extend and maintain, while keeping the button components reusable and independent of the logic they trigger.
In conclusion, the approach where a button not only triggers an action but also transmits a command with the necessary data through an event is an excellent example of applying the "Command" pattern. This method significantly improves interface interaction organization by separating the logic of command execution from the interface elements, enhancing the flexibility and scalability of applications.
However, such an approach is still relatively uncommon in practice. Instead of leveraging the powerful capabilities of Web Components to create universal and flexible solutions, many developers continue to rely on standard buttons directly tied to event handlers. This is likely due to habit and a lack of awareness about the advantages of this approach, leading to the more conventional use of buttons as simple triggers for actions.
Determined to change this situation, I developed the KoiCom library, where many components have already been adapted and enhanced. In particular, buttons in this library follow the "Command" pattern, transmitting the necessary data and commands via events. This approach greatly increases modularity, flexibility, and maintainability, eliminating redundant logic and simplifying how commands are managed.
KoiCom documentation
KoiCom github
Ultimately, I hope such solutions will help developers adopt a more modern approach to interface design, making applications more scalable and easier to maintain.
The above is the detailed content of Next-Generation Buttons: Implementing the Command Pattern through Web Components. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
