Add compatibility for keyboard events (keyCode constants) to data.js

[ksen0]

Based on this issue: processing/p5.js#7876 looks like the data.js add-on is not allowing the 1.x use: https://editor.p5js.org/ksen0/sketches/cvGEDgY_0 - looks like it provides compatibility for touch/mouse but not keyboard.

We've in the past combined data with events; it may also be useful to relabel the add-on in the editor from "Data Structures" to "Data & Events." I think this combination still makes sense because it contains various usages where the 2.0 breaking changes have the goal of more consistency - but if others think it would be better to split them into data and events, for example, I am also happy to support (with the attendant editor updates)

This issue includes reinstating 1.x constants (LEFT_ARROW) and keyboard events that have been changed (reviewing hem first; keyIsPressed, keyTyped, keyReleased, keyPressed, keyIsDown).

[ksen0]

@davepagurek does the above sound reasonable / anything I'm missing? I'm happy to take this on.

I was also thinking that longer-term, it could be really helpful for the CI on this repository to run 1.x tests on the bundle of p5.js 2.x + compatibility add-ons, but that seems potentially quite challenging, or is there a way to do this (even manually, if not in a workflow)?

[davepagurek]

I think that makes sense keeping it as one. We'll probably also have to override the internal key event handlers to use the old event.keyCode instead of the new .key and .code properties.

I was also thinking that longer-term, it could be really helpful for the CI on this repository to run 1.x tests on the bundle of p5.js 2.x + compatibility add-ons, but that seems potentially quite challenging, or is there a way to do this (even manually, if not in a workflow)?

We could maybe do a CI action where we clone the main p5 repository (similar to what the website repo does), and then patches the code before running tests. It's definitely more complicated than running normal tests, but seems possible if anyone's interested in taking that work on.

[perminder-17]

We've in the past combined data with events; it may also be useful to relabel the add-on in the editor from "Data Structures" to "Data & Events." I think this combination still makes sense because it contains various usages where the 2.0 breaking changes have the goal of more consistency - but if others think it would be better to split them into data and events, for example, I am also happy to support (with the attendant editor updates)

Yes, I believe it would be a good idea to relabel the add-on in the editor from "Data Structures" to "Data & Events." It makes sense and would help reduce confusion for users. If you’d like, I’d be happy to open a PR to implement this change relabeling stuff and it could be merged once the work on the current PR is complete.