API alterations to allow injection of hotkey parsing and event processing about hotkey

[theinterned]

I think this is a great plan going forward and I've added it to the v2 tracking issue #65!

One quibble I'd make with this API though is around the naming of processHotkey vs processExpansion. There are indeed these two serializers, however I would change the names:

1. During installation we read the data-hotkey value and store that internally (in a trie). I would call this function processHotkey.
2. When handling events, we need to serialize the event into a string to compare to the hotkey trie node: I would call this processEvent

Notice that these names align with the function argument names you have already proposed.

I also wonder if we want to use a class approach: One concern I have with the class approach is that I would expect that state would be managed in the class instance, but we currently manage state in module-scoped private variables.

I think we could continue with a functional approach, but pass a config object to the install command. I don't think the uninstall command depends on processHotkey or processEvent.

The API, then could be

export type ProcessHotkey = (hotkey: string): string[][]
export type ProcessEvent = (event: KeyboardEvent): string

export interface HotkeyOptions {
  hotkey?: string;
  processHotkey: ProcessHotkey;
  processEvent: ProcessEvent;
}

export function install(
  element: HTMLelement, 
  options = {
    hotkey,
    processHotkey: expandHotkeyToEdges,
    processEvent: eventToHotkeyString;
  }: HotkeyOptions
): void {}

export function uninstall(element: HTMLElement): void {}

This would almost not even be a breaking change — except I had to move the optional hotkey argument to install into the HotkeyOptions.

Anyways, I am okay with either approach in the end: just thought I would throw this option out there.

[keithamus]

One quibble I'd make with this API though is around the naming of processHotkey vs processExpansion

Your suggestion here LGTM 👍

I think we could continue with a functional approach, but pass a config object to the install command

The problem with that proposal is less to do with uninstall and more to do with the internalizing of the processors in respect to stored state. Having a functional approach where users can change what processHotkey and processExpansion across multiple install calls leaves issues with how Leafs are processed in the radix trie, and how event delegation would work. Another way to say this is that each combination of processHotkey+processExpansion needs its own event manager/radix trie.

[theinterned]

Having a functional approach where users can change what processHotkey and processExpansion across multiple install calls leaves issues with how Leafs are processed in the radix trie, and how event delegation would work.

Yeah! I totally agree with this. I am onboard with the class.

[theinterned]

(I updated the code in your description with the changed processor names)