Estoy trabajando en atajos de teclado para una aplicación web y necesito verificar si presionar una tecla debe activar el atajo o si es solo el usuario que escribe y, por lo tanto, no debe activar el atajo.
Por ejemplo, un patrón común es usar las teclas / o s para abrir la barra de búsqueda global. Obviamente, esto no debería abrir la barra de búsqueda si el usuario está escribiendo en otra entrada.
La lógica ideal sería algo como esto: al presionar una tecla, verifique el elemento enfocado actualmente. Si el elemento acepta la entrada del teclado (se puede escribir), entonces no haga nada. Si el elemento no acepta la entrada de teclado, ejecute el atajo.
Tenga en cuenta que verificar la capacidad de enfoque no es suficiente porque los enlaces y los botones se pueden enfocar, pero no acepte la entrada del teclado (en la forma en que me refiero aquí).
Esto es lo que tengo hasta ahora:
function acceptsKeyboardInput(element) { return ( element.tagName === "INPUT" || element.tagName === "TEXTAREA" || element.isContentEditable ); }¿Este enfoque detecta todos los casos o hay una mejor manera de saber si un elemento HTML acepta la entrada del teclado?
¿Todos los atajos tendrán más de una tecla? Si es así, puede escuchar la input y evitar que se ejecute un acceso directo con un valor booleano.
var is_input = false window.addEventListener('keydown', function (e) { console.log(is_input) is_input = false }) window.addEventListener('input', function (e) { is_input = e.constructor.name == 'InputEvent' }) La salida esperada para /s mientras se puede escribir sería true or false (dependiendo del valor anterior de is_input ) en / keypress de tecla, luego true en s keypress de tecla y todas las teclas siguientes.
La salida esperada para /s mientras no se pueda escribir sería true or false (dependiendo del valor anterior de is_input ) en / keypress de tecla y luego false en s keypress de tecla y todas las teclas siguientes
Por lo que he visto, la sugerencia dada en la pregunta parece ser el mejor enfoque, con algunos ajustes.
La primera mejora es incluir en la lista negra un conjunto de tipos de entrada que no aceptan entrada de teclado (por ejemplo, casilla de verificación o radio). Me resulta más fácil y mejor usar una lista negra en lugar de una lista blanca por dos razones. La primera es la preparación para el futuro frente a los nuevos tipos de entrada admitidos y en caso de que se pierda uno. En segundo lugar, y lo que es más importante, un tipo de entrada no válido vuelve a escribir texto de forma predeterminada, lo que significa que hay una cantidad infinita de tipos de entrada que aceptan la entrada del teclado.
El segundo cambio es incluir también elementos <select> , ya que se pueden escribir como una especie de funcionalidad de búsqueda/selección rápida.
Aquí está la función completa:
const nonTypingInputTypes = new Set([ "checkbox", "radio", "button", "reset", "submit", "file", ]); export function acceptsKeyboardInput(element) { return ( (element.tagName === "INPUT" && !nonTypingInputTypes.has(element.type)) || element.tagName === "TEXTAREA" || element.tagName === "SELECT" || element.isContentEditable ); }Hay algunas otras entradas que no aceptan entrada de teclado pero que son menos compatibles con los navegadores (por ejemplo, color), por lo que he tratado de mantenerlo en los tipos de entrada más utilizados y ampliamente implementados.