[p5.js 2.0+ Bug Report]: strands breaking on arrow functions with parameters

[davepagurek]

Most appropriate sub-area of p5.js?

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

p5.js version

2.3.2

Web browser and version

All

Operating system

All

Steps to reproduce this

If you are using instance mode, you have to pass in a second parameter to p5.strands containing whatever outside context you need in the shader. This gets passed back into the function you pass in, so you add an argument to your function to collect the data from the outside world. However, this currently throws an error, I assume because a regex doesn't handle param => { ... } correctly.

new p5(p => {
  let gradientShader

  p.setup = function() {
    p.createCanvas(400, 400, p.WEBGL)
    gradientShader = p.buildMaterialShader((param) => {
      let { p } = param
      let pos = p.sharedVec4()
  
      p.worldInputs.begin();
      pos = [p.worldInputs.position/200, 1];
      p.worldInputs.end();
      
      p.pixelInputs.begin();
      p.pixelInputs.color = pos;
      p.pixelInputs.end();
    }, { p })
  }
  
  p.draw = function() {
    p.clear()
    p.shader(gradientShader)
    p.noStroke()
    p.plane(p.width, p.height)
  }
})

Live: https://editor.p5js.org/davepagurek/sketches/k64e4h1LA

Notably, this works if you:

• Use function(param) { ... }
• Use an arrow function with no args (e.g. in global mode)
• Destructure parameters directly in the parentheses instead of in the function body, e.g. ({ p }) => { ... } in the example above.

I believe we have tests that do some of the above, but I guess not this particular case.

[tsumon]

Hi maintainers, I would like to work on this issue if a contributor PR would be welcome.

My current understanding is that the strands callback handling assumes a parenthesized parameter list. JavaScript permits a single arrow-function parameter without parentheses (param => { ... }), and the transpiled form can therefore bypass the current parameter/body extraction, while destructuring (({ p }) => { ... }) retains parentheses and still works.

I would first add regression coverage for the failing single-parameter arrow form and the working destructuring form, then make the smallest parser/transpiler change that handles both forms without changing existing callback behavior. I am using AI assistance for repository exploration; I will review and understand every line and disclose that assistance in any PR.

Could you confirm the preferred implementation direction and whether you would welcome a PR for this issue?

[davepagurek]

Hi @tsumon, the approach of first adding a test to verify it fails and then adding a fix makes sense to me. Feel free to go ahead with a PR and to ask any questions you have along the way here to build up your understanding.

As far as changes go, that regex has been pretty brittle, possibly we can replace it with something that uses the AST.