1.x Compatibility Addon

[davepagurek]

Increasing access

When we release p5 2.0, there will be some API changes. For ease of switching and for preservation purposes, we'd like to make an addon that re-introduces the old APIs so old sketches can continue to run.

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

Feature request details

Here's a running list of things we'll need to include:

• Handle preload and make it run before setup
  • Make load* methods like loadImage immediately return an object instead of a promise
• Add back 1.x shape drawing API
• Add some color internals that are semi-commonly relied upon
  • color.levels: an array of RGB values in [0, 255]
  • color._array: an array of RGB values in [0, 1]
• Make cameras auto-set themselves as the default camera on creation
• Attach p5 constants to p5.Graphics

[diyaayay]

I would like to work on this issue.

[limzykenneth]

Just to note that this is something we'd like to have for at least the first few releases of 2.0 while the transition to 2.0 happens and is not planned to be maintained long term. We don't know the full set of things that need to be implemented yet so likely won't start implementing this immediately.

[GregStanton]

A few thoughts about add-on support for the 1.x shape drawing API:

Right now, we have support for some of the 1.x API directly inside 2.0, in #7373. My initial thinking is that the 1.x support should be moved to the compatibility add-on, for a couple reasons:

• Reduce user confusion. Instead of documenting a deprecated feature, a link could be provided to the 1.x compatibility add-on from the affected features' reference pages, like this: "Looking for the old way of doing things? Check out the 1.x compatibility add-on."
• Reduce code size and complexity in 2.0.

Downsides:

• Users need to learn how to use an add-on. I think this can probably be mitigated with user-friendly instructions, and maybe even a short video showing how to do it.
• Maintaining a separate add-on might increase maintenance requirements, but maybe that's not clear? If most contributors are working directly on 2.x code, then reduced complexity there might outweigh the extra maintenance requirements of an add-on. Maybe that's wishful thinking, though.

[ksen0]

Closing as compatibility add-on libraries and transition resources are now available here: https://github.com/processing/p5.js-compatibility