当我开始设计界面时，我总是遇到这样的问题：事件处理程序直接附加到按钮上，这限制了组件交互的灵活性。问题是标准按钮无法提供任何其他行为。我需要的是逻辑隔离和动态操作管理，这在使用“开箱即用”的标准按钮时不可用。在本文中，我将提出一个关于如何使用 Web 组件和“命令”模式调整按钮的解决方案，为更灵活和可扩展的界面开辟新的可能性。
通常，当我们想到按钮时，我们将其视为一个图形控制元素，它提供了一种简单的方法来触发某些事件、操作或界面状态的变化。这是一个非常简单和方便的定义，符合我们对 Web 应用程序中用户界面元素的日常理解。
然而，当我们在网页开发中遇到按钮时，当涉及到HTML和JavaScript时，首先想到的就是标准标签，这是在网页上创建按钮最常用的工具。该标签通常如下所示：
<button onclick="myFunction()">Click me</button>
但是如果我们考虑一下，这个标签虽然充当按钮，但并没有完全反映按钮在用户与界面交互的更广泛上下文中可以执行的所有可能的方面和功能。
仔细检查按钮的定义后，人们可能会注意到它没有提供任何有关按钮的外观、行为或触发操作的信息。在这种情况下，对于触发操作的“简单方法”一词的含义，以及按钮和操作之间的连接是如何建立的，都没有清晰的理解。我们只看到按钮的基本结构，单击该按钮时会调用一些方法。但实际上，这种简单性隐藏了更广泛的可能性和方法。因此，问题出现了：也许按钮不仅仅是我们在上面的示例中看到的标签？
让我们从更哲学的角度来理解按钮的概念，深入研究它的本质和功能。按钮真正代表什么？如果我们把壶的本质看成是空的，那么按钮的本质就在于它能够启动一个动作。按钮不仅仅是一个用户界面元素；它也是一个用户界面元素。它是一种触发应用程序上下文中已存在的特定进程的机制。要执行的操作发生在应用程序内、整个系统的上下文中，但该操作的启动（即开始）是按钮的功能。因此，我们看到按钮充当一种触发器，在更广泛的外部系统上下文中启动操作。
当用户点击按钮时，他们期望这次点击会导致特定的操作。因此，按钮负责启动此操作。换句话说，按钮成为用户和应执行的操作之间的链接。然而，需要注意的是，实际执行该操作的方法或函数不应该知道该按钮是触发该操作的按钮。启动动作和执行动作之间的区别是一个至关重要的方面，它使我们能够在更复杂的系统中保持灵活性和轻松的交互。
当按钮直接执行操作或当实现操作的方法依赖于按钮本身时，我们正在处理一个相当复杂且相互依赖的系统。如果我们希望简化这样的系统，就必须将其分解为更简单、独立的部分。在这里我们得出的结论是，简化启动操作的过程主要涉及将启动过程与操作本身分开。由于在 JavaScript 上下文中，发起者通常被称为事件，因此我们专门讨论将作为发起者的事件与执行操作的逻辑分开。
为什么将事件与处理程序分开很重要？
首先，将事件与处理程序分离可以显着提高代码的可读性，并促进创建更多模块化解决方案。当按钮逻辑及其处理程序交织在一起时，或者更糟糕的是，当处理程序是匿名函数时，代码将变得极难阅读和分析。这可能会导致维护和更新项目时出现问题，因为了解按钮的实际用途以及需要进行哪些更改成为一项具有挑战性的任务。相反，当处理程序被提取到一个单独的、命名良好的函数中以清楚地反映正在执行的操作时，代码的结构变得更加透明。开发人员立即了解单击按钮时会发生什么，并且可以更轻松地修改元素的行为，而无需深入研究其余逻辑。因此，分离简化了代码的阅读和更改。
其次，分离事件逻辑和处理程序为在应用程序的不同部分重用处理程序提供了机会。当处理程序放置在其自己的函数中时，它不仅可以应用于一个按钮，还可以应用于许多具有类似行为的其他按钮。例如，执行相同操作的多个按钮可以使用相同的处理程序，从而减少代码重复并提高效率。此外，处理程序不仅可以通过按钮触发，还可以通过其他方式触发，例如编程调用或界面其他部分发起的操作。这显着扩展了应用程序的功能，提高了其灵活性和可扩展性。
第三，将事件和处理程序分开可以使按钮本身具有更大的灵活性。如果按钮的行为现在不是在按钮本身内确定，而是通过单独的处理程序确定，则可以轻松修改其操作或根据情况重新分配它们。这在具有动态界面的项目中尤其重要，其中元素的行为可以响应用户操作或应用程序状态的变化而变化。这种方法允许界面轻松适应不断变化的需求，而不会破坏整体代码结构。
第四，事件和处理程序的分离对于可测试性至关重要，特别是在大型项目中。当事件处理程序被提取到单独的函数中时，测试它们变得更加容易，因为它们可以独立于接口进行测试。您可以隔离处理程序并测试它如何使用各种参数，而无需担心与界面其他部分的交互。这使得测试变得更加容易，提高了应用程序的可靠性和稳定性，同时最大限度地减少了错误的可能性。
分离按钮事件和处理程序是迈向更干净、更灵活和可维护的代码架构的关键一步。这在复杂的项目中尤其重要，因为界面元素之间的交互变得更加复杂和相互依赖。这种方法有助于提高系统稳定性，更容易扩展和修改应用程序，并降低这些更改期间出现错误的风险。
将按钮事件与其处理程序分离的示例可以在任何初学者指南中找到。
<button onclick="myFunction()">Click me</button>
如果按钮不仅可以传达交互的上下文，还可以在事件中明确传达用户的意图，那么它将显着简化架构。处理程序可以专注于执行任务，而不是为事件分配逻辑。
这突出表明需要摆脱将按钮仅视为事件发起者的传统理解。相反，它建议采用更高级的模型，其中按钮充当用户意图和应用程序逻辑之间的桥梁。
为了创建更高级的事件处理模型，我们可以利用命令模式，它允许事件在更高的抽象级别与应用程序逻辑链接。这可以通过引入一个层来实现，该层将普通事件转换为 saveDocument 或 deleteItem 等命令。使用这种方法，事件不仅仅是发生了某事的信号，它还转变为它本来应有的样子：动作的发起者，如本文前面所讨论的。
但这提出了一个问题：为什么 JavaScript 事件的开发者不从一开始就实现命令模式？为什么活动设计成现在这样？为什么首先需要举办活动？
最初开发 HTML 以及 DOM 和 JavaScript 等相关技术时，他们的主要目标是为超文本文档创建一个简单的结构，以允许用户与网页交互。当时，用户交互受到极大限制，并且事件处理模型的设计无法适应命令模式等复杂机制。重要的是要明白，早期网络的开发是为了简化内容的创建和管理，而不是为复杂的客户端逻辑提供复杂的工具。
在 20 世纪 90 年代，当 HTML 和 Web 被创建时，他们的重点是提供一种直接的方式来以最少的用户交互来呈现超文本文档。主要目标是将数据提交到服务器，而不是在浏览器中执行复杂的逻辑。按钮和表单主要用于发送数据，而不是启动客户端进程。所有的计算和数据处理都在服务器上进行，按钮作为界面元素，触发数据提交到后端。
命令模式需要更复杂的结构，其中涉及接口和处理逻辑之间的清晰分离，以及指定要执行的确切操作的机制。随着 Web 应用程序中对动态界面和更强交互性的需求的增长，这些想法后来才变得有意义。动态且复杂的交互，例如通过事件触发客户端逻辑，需要新的方法，包括采用命令模式。
现在命令模式可以应用到按钮上吗？是的，可以。虽然标准 HTML 按钮不直接支持命令模式，但自定义事件等现代技术允许我们创建类似的机制。例如，我们已经探索了如何使用详细属性通过事件传递附加数据。
但是，这种方法仍然不理想，因为它需要为界面中的每个按钮创建单独的实现。这增加了额外的复杂性，并使扩展此类系统更具挑战性。
利用 Web 组件实现按钮现代化并使它们与命令模式保持一致是一种很有前途的方法，可以显着增强项目中交互的架构和灵活性。 Web 组件提供了强大的工具来创建可重用的界面元素，这些元素可以无缝集成到应用程序的各个部分。
您可以创建一个统一的组件来充当按钮，并具有传递命令的附加功能，而不是为每个按钮编写单独的处理程序。这种做法不仅改善了代码的结构，还增强了代码的可读性和可维护性。
这是此类组件的基本示例：
<button onclick="myFunction()">Click me</button>
当按钮组件传输命令标识符和潜在的附加参数时，它为更高级的架构奠定了基础。在此设置中，包含按钮并订阅其事件的组件本质上充当控制器，处理通过事件传递的命令。
在 MVC（模型-视图-控制器）等架构模式中，控制器充当表示数据的模型和构成用户界面的视图之间的中介。它接收用户输入，例如按钮单击，并管理由此产生的数据或状态更改，然后将其反映在界面中。
在组件中使用控制器具有几个关键优势。首先，它封装了执行命令的逻辑，使主要应用程序代码免于不必要的复杂性。实现的细节仍然隐藏在控制器本身内。其次，这种方法增强了模块化性，只需传递不同的命令和参数即可重复使用按钮。它还减少了应用程序内的耦合，因为命令处理逻辑的更改仅需要在控制器内进行修改，而不会影响系统的其他部分。最后，控制器提供了显着的灵活性。它们可以处理简单的命令（例如“保存”或“删除”）和更复杂的操作，而按钮组件保持简单并仅专注于其主要作用。
这种架构有助于清晰地分离关注点。按钮组件发出一个自定义事件，其中包括命令及其相关数据，而充当控制器的父组件则侦听此事件。控制器处理命令，必要时与数据模型交互，并相应地更新用户界面。这种方法会产生更清晰、更具可扩展性的架构，更容易扩展和维护，同时保持按钮组件的可重用性并独立于它们触发的逻辑。
总之，按钮不仅触发操作，而且通过事件传输带有必要数据的命令的方法是应用“命令”模式的一个很好的例子。该方法通过将命令执行逻辑与界面元素分离，显着改善了界面交互组织，增强了应用程序的灵活性和可扩展性。
然而，这种方法在实践中仍然相对不常见。许多开发人员继续依赖直接与事件处理程序关联的标准按钮，而不是利用 Web 组件的强大功能来创建通用且灵活的解决方案。这可能是由于习惯和缺乏对这种方法优点的认识，导致更传统地使用按钮作为操作的简单触发器。
决心改变这种情况，我开发了 KoiCom 库，其中许多组件已经被适配和增强。特别是，该库中的按钮遵循“命令”模式，通过事件传输必要的数据和命令。这种方法极大地提高了模块化性、灵活性和可维护性，消除了冗余逻辑并简化了命令的管理方式。
KoiCom 文档
KoiCom github
最终，我希望此类解决方案能够帮助开发人员采用更现代的界面设计方法，使应用程序更具可扩展性且更易于维护。
以上是下一代按钮：通过 Web 组件实现命令模式的详细内容。更多信息请关注PHP中文网其他相关文章！
