hallo
Was Du mit ev.target==ta prüfst, ist mir nicht klar.
ta ist ein Textarea-Element. Das ist etwas Testcode, die realen Namen sind Expliziter.
Dann musst Du nach Identifikation einer relevanten Taste nicht mehr in ein zweites Dictionary einsteigen, sondern hast die passende Function direkt am Wickel. Du könntest damit auch mehrere KeyHandler-Container unterstützen.
Ich dachte dass ein Gewinn noch möglich ist vor der Abfrage des ersten Binding-Schlüssels.
Die meisten Events haben ja keinen zugeordnete Schlüssel Beispiel ev.key == Shift | Controll | Alt oder Events ohne Zusatztaste.
Deshalb interessirt mich die Optimierung, falls ein Binding-Schlüssel vorliegt, nicht so sehr.
Das setzt natürlich voraus, dass alle Key-Funktionen vor Aufbau der Bindings bereit stehen und dass Du nicht dynamisch einem KeyFunction-Namen eine andere Function zuweisen willst (was aber Spagetti-Deluxe wäre).
Gewiss, vor allem da Anwender die Bindings selber konfigurieren.
Die Frage ist auch, ob Dir dieses Konstrukt hinreicht. Wie legst Du fest, dass das Handling einer Tastenkombination nur an die Handlerfunktion Xyz gehen soll, wenn sich das Event-Target innerhalb eines bestimmten Containers befindet?
Nun ja, derzeit berücksichtige ich nur die Editor Textarea als ein Modifikator. Später könnte ein anderer Modifikator hinzukommen Dann wirds halt 1,2,4,8,16
Möglicherweise hat Ctrl+Q ja im Container A eine andere Semantik als im Container B. Oder möchtest Du das im Einzelfall behandeln und eine Verteilerfunktion im Binding eintragen? Wäre vermutlich die performanteste Lösung...
Je mehr Abweichende Funtionalität ich per Kontxt biete um so schwerer wird der Lernprozess. Das möchte ich eigentlich vermiden.
Es gibt aber Funktionen, die wirklich nur in der Textarea Sinn machen. Da möchte ich nicht das Defaultverhalten entziehen, wenn der Kontext ausserhalb der Textarea liegt.
Es könnte noch eine Überlegung sein, zweistufig zu agieren, d.h. zunächst mit ev.key einzusteigen und die Prüfung auf Modifier nur zu machen, wenn für die Taste etwas hinterlegt ist.
Du bekommst immer einen ev.code! Manchmal heisst er halt shift oder controll.
Aber ich glaube nicht, dass das lohnt. Du wirst nicht schnell genug Tasten drücken können, um einen Computer mit dem von Dir angedachten Code ins Schwitzen zu bringen. Selbst ein kleines Atom-Öfchen oder Brombeerchen nicht.
Eine andere Frage, die mir gerade einfällt, ist Modularisierung. Angenommen, du hast mehrere sauber gekapselte JS-Module, die auf der Seite laufen.
Dann darf der Listener eben nicht auf der Obermenge der Teil-Doms agieren.
Da schau ich schon, dass der Listener nur auf dem Container-Element des Editors registriert wird.