Lion项目中的Listbox组件验证焦点问题解析

问题背景

在Lion项目中使用Listbox组件时，当组件被标记为必填项(Required)但用户未进行选择时，系统会触发验证流程。虽然验证错误信息能够正确显示，但在控制台会出现"Uncaught TypeError: Cannot read properties of undefined (reading 'focus')"的错误。

技术原理分析

这个问题源于Lion表单系统的焦点管理机制与Listbox组件实现方式的冲突。Lion表单系统在验证失败时会自动尝试将焦点设置到第一个出现错误的表单元素上，以便提升用户体验。

Listbox组件内部包含多个LionOption子组件，这些子组件实际上并不具备接收焦点的能力。在Web无障碍标准中，Listbox通常通过aria-activedescendant属性来实现焦点管理，而不是让每个选项都成为可聚焦元素。

问题根源

当前实现中存在两个关键判断逻辑：

1. 首先检查表单元素是否有子表单元素(formElements)
2. 然后在这些子元素中查找第一个有错误的元素，如果没有则选择第一个子元素

对于Listbox组件，虽然其子选项(LionOption)不是设计为可聚焦元素，但由于它们被识别为表单元素，系统错误地尝试在这些选项上设置焦点，导致undefined错误。

解决方案

正确的处理方式应该是判断子元素是否真正具备可聚焦能力，而不仅仅是判断是否存在子表单元素。可以通过检查子元素是否具有_focusableNode属性来实现这一判断。

改进后的逻辑应该类似于：

function hasFocusableChildren(formEl) {
  return formEl.formElements?.some(child => child._focusableNode);
}

这样修改后，系统将能够正确识别Listbox组件作为整体才是可聚焦元素，而不是尝试在其不可聚焦的子选项上设置焦点。

影响范围

这个问题不仅影响Listbox组件，还会影响所有使用Listbox作为基础的组件，如select-rich和combobox组件。因为这些组件都共享相同的焦点管理机制。

最佳实践建议

在开发自定义表单组件时，特别是包含子表单元素的复合组件，开发者应当：

1. 明确标识组件是否可聚焦
2. 正确实现_focusableNode属性
3. 考虑组件的无障碍访问特性
4. 确保验证流程与焦点管理协调工作

通过遵循这些原则，可以避免类似的焦点管理问题，同时提供更好的用户体验和无障碍支持。