Closed calebfoss closed 1 year ago
Thank you! Also I'm sorry to hear that. I'm going to try to not make more breaking changes after v3.5, just add new features.
That's strange, the library is still hosted at https://p5play.org/v3/p5.play.js Can you access it? I only switched the links on the website to the CDN because I got reports from other teachers that p5play.org was blocked by their school's firewall.
You're absolutely right, I shouldn't have just marked that function as deprecated. I honestly forgot it was a p5.js function originally that only used key codes and key name support was added on in p5.play v1.
Now I'm going to have p5.play override that function and throw an error with this message since I don't want people to use it in their p5.play projects:
The p5.js keyIsDown function is outdated and can't be used in p5.play. Trust me, you'll see that the p5.play function kb.pressing(keyName) is much better. Key name strings are easier to write and make your code easier to read! https://p5play.org/learn/input_devices.html The p5.js keyIsDown function relies on key codes and custom constants for key codes, which are not only hard to remember but were also deprecated in the JavaScript language standards over six years ago and shouldn't be used in new projects. More info: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
The problem with changing the CDN links to be more version specific is that I don't want people to use previous versions of the library. I am more concerned with people not being able to use new features if the version in their link is too old. If people need to use a more specific version of p5.play they can specify it in their project.
I would really appreciate some help making Jest tests! I already have some tests for the Sprite class you can look at for examples. Lmk if you'd be interested! 😄
Sure, I'd be interested in writing tests! Any particular features that are a priority?
I hear you on wanting people to have access to the latest features, but keep in mind, beginners are likely to copy that CDN link, not knowing that the library could change, altering the result of their code, even when they haven't changed anything. In the p5 web editor, p5.js is loaded with a specific version number, so if someone writes a sketch and then later wants to use newer features, they simply update the script tag.
Sweet! Feel free to prioritize the features you'd to make tests for first.
Let me know what you think of this idea. I think it'd be good to have a guide on "finishing your p5.play project" that could tell users how to limit the cdn link to only get the version of the library that the user made the game with, that way it won't break if future versions do have breaking changes. This way, while users are still working on a p5.play project they can always use the most recent version of the library to access new features and update their code if breaking changes to p5.play are added. Though as I said before hopefully this won't be a big source of problems going forward as the foundational features of p5.play will be finalized soon.
I'm so excited to see the new generation of this project! I teach in a Game Design college program, and one of my students used p5.play this past term.
I wanted to mention 2 issues that came up. In both cases, the student's project stopped working, despite the code remaining the same due to the src attribute on the script tag loading the library:
If in the future you need to change where the library file is hosted, I think it would be helpful to continue hosting the file in the original location for a period and to console.log a warning message that the src attribute needs to be updated.
One simple thing that could prevent issues like the second one would be including the full version number in the CDN link on the home page. So when folks copy paste that block of script tags (which is super convenient!), they're only loading the current version of the library and won't risk loading breaking changes.
I also think changing the behavior of existing p5 functions is not ideal, though I understand there are complications with harmonizing the base p5 library with the complexities of this project. My expectation would be that a lot of p5.play users would already have experience with p5, and so if there are inconsistent behaviors, that could cause a lot of confusion.
Anyway, this is an awesome project, I'm grateful for all the work you've put into this, and I'm interested in helping with contributing.