Before, keyboard input used key codes to map events to Apple II keys.
This worked reasonably well, but `event.keyCode` was deprecated and
slated to be removed.
The refactored code now uses `event.key` which returns the localized,
keyboard-mapped key that the user pressed, which may be a letter or a
"symbolic" key. This is then transformed into an Apple II key.
One side effect of the refactoring is that the keys now light up as
you type and that combinations of mouse clicks on modifiers and plain
keys will take the modifiers into account.
Before, if the browser window wasn't tall enough to show the whole
keyboard, using the arrow keys in the window would cause the page
to move as well. Now all key events that are sent to the keyboard
have `preventDefault()` called on them.
* Add `spawn` as a way of calling promise-returning blocks
This change adds `spawn` which takes a no-argument, promise-returning
function, calls it, and returns `void`. This makes it easy to call
async blocks from `useEffect` and other places that don't take async
functions, but also makes such calls explicit.
* Adds interruptability to `spawn`
Now, the task function passed to `spawn` can take an `Interrupted`
argument, which is merely a method that returns `true` if the task
should stop doing work. Likewise, `spawn` returns an `Interrupt`
function that causes the `Interrupted` function to return `true`.
* Change to using `AbortController` and `AbortSignal`
Before, `spawn` used functions to interrupt and determine interruption
state. Now, based on feedback from @whscullin, it uses
`AbortController` and `AbortSignal`.
Tests now show how the controller can be used to abort long-running
tasks and API calls in the `spawn`. The also show how signals can be
chained using `addEventListener`.
* Fix `Apple2.tsx`
Forgot to change it to use `AbortController` and `AbortSignal`.
Co-authored-by: Will Scullin <scullin@scullin.com>
This change adds `spawn` which takes a no-argument, promise-returning
function, calls it, and returns `void`. This makes it easy to call
async blocks from `useEffect` and other places that don't take async
functions, but also makes such calls explicit.
This removes the `FileSystemFileHandleLike` interface in preference to
just implementing the correct interface. The advantage of the
`FileSystemFileHandle` interface is that it can be passed to the
worker directly to load the file.
This adds both the recommended TypeScript checks, plus the recommended
TypeScript checks that require type checking. This latter addition
means that eslint essentially has to compile all of the TypeScript in
the project, causing it to be slower. This isn't much of a problem in
VS Code because there's a lot of caching being done, but it's clearly
slower when run on the commandline.
All of the errors are either fixed or suppressed. Some errors are
suppressed because fixing them would be too laborious for the little
value gained.
The eslint config is also slightly refactored to separate the strictly
TypeScript checks from the JavaScript checks.
* Create a FileChooser component using showOpenFilePicker
Before, `FileModal` always used a file input control for selecting
local files. This allowed the emulator to read from the file, but
precluded writing back to the file.
With this change, the `FileModal` delegates to the new `FileChooser`
component. The `FileChooser` will use `showOpenFilePicker` if it is
available and a regular file input if it's not.
Using `showOpenFilePicker` has the advantage of allowing the emulator
to write back to the file (if the user grants permission). While the
emulator does not yet take advantage of this write capability, that
will come.
* Addressed comments
* useState() instead of direct DOM manipulation
* backed out eslint changes in favor of suppressing the warning