Pass data point and trace context to custom marker functions (backward compatible)

[Copilot]

• Extend custom marker function API to pass (r, angle, standoff, d, trace)
• Update makePointPath in src/components/drawing/index.js
• Update call sites in singlePointStyle and selectedPointStyle
• Add tests for new context parameters
• Update CUSTOM_MARKER_FUNCTIONS.md with documentation and weather map example
• Add weather map demo at devtools/demos/weather_map_demo.html
• Add backward compatibility test at devtools/demos/backward_compatibility_test.html
• Remove dist folder changes per CONTRIBUTING.md guidelines

Summary

Extended the custom marker function API to pass data point (d) and trace context to custom functions, enabling data-driven markers.

Backward Compatibility: ✅ Existing marker functions with 3 parameters continue to work without modification.

Source Code Changes:

• src/components/drawing/index.js: Modified makePointPath() to pass d and trace to custom functions
• test/jasmine/tests/drawing_test.js: Added tests for new functionality
• CUSTOM_MARKER_FUNCTIONS.md: Updated documentation with examples
• devtools/demos/*.html: Added demo files

Build Artifacts: Dist folder changes removed per CONTRIBUTING.md - these are updated by maintainers at release time.

API: function customMarker(r, angle, standoff, d, trace) - backward compatible, optional parameters.

Demo Screenshots

Weather Map Demo:

Shows custom weather markers with sun symbols (☀️), cloud shapes (☁️), and directional wind arrows (🌬️) with speed bars based on customdata.

Backward Compatibility Test:

Demonstrates that old style functions (3 params) and new style functions (5 params) work together seamlessly.

Original prompt

Can we pass more than a "size" value to the function? E.g. a custom data object. Something in line with existing plotly features.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[gatopeich]

Use case: place wind markers on a weather map where each marker shows direction and speed of wind at different spots. Speed adds bars to a directional arrow where 1 bar is low and 3 bars is high.

[gatopeich]

Should we add more, maybe optional, parameters to the functions? Should we use dot attributes of a single param?

[gatopeich]

@copilot address my commente above and create a "weather map" demo with Clouds, Sunny, and directional wind markers. The demo should be an html snippet, ideally embeddable in GitHub comment or the PR description

[gatopeich]

@copilot can't we achieve the same just placing a complex object in r, instead of making this change?
I am worried about having to change all existing marker functions just for this...

[Copilot]

@copilot can't we achieve the same just placing a complex object in r, instead of making this change?
I am worried about having to change all existing marker functions just for this...

The current approach is backward compatible - existing marker functions don't need to change at all.

In JavaScript, if a function expects 3 parameters but receives 5, the extra parameters are simply ignored. So existing functions like function heartMarker(r, angle, standoff) continue to work perfectly when called with (r, angle, standoff, d, trace).

Passing a complex object in r would actually break all existing marker functions because:

1. Built-in marker functions (circle, square, etc.) expect r to be a number for calculations like r * 0.5
2. All existing custom marker functions use r as a numeric radius
3. Functions would need to add if (typeof r === 'object') checks

The current design:

• ✅ Existing functions work unchanged: function(r, angle, standoff)
• ✅ New functions can access data: function(r, angle, standoff, d, trace)
• ✅ Parameters are optional - only use d and trace when needed
• ✅ Semantically clear - r stays as radius, data is in d

[gatopeich]

@copilot why do we have to change all those ids in so many places in the code?

[Copilot]

@copilot why do we have to change all those ids in so many places in the code?

The ID changes you're seeing are not from my code changes. They're CSS injection IDs from the maplibre-gl library that got regenerated when running npm run build.

These IDs are content-based hashes that maplibre-gl uses to inject CSS only once. Every time the dist files are rebuilt, these hashes can change even if the actual CSS content is identical.

My actual code changes are minimal:

• src/components/drawing/index.js: Modified makePointPath() to pass 2 extra parameters (d, trace) to custom functions
• test/jasmine/tests/drawing_test.js: Added tests
• CUSTOM_MARKER_FUNCTIONS.md: Updated documentation
• devtools/demos/*.html: Added demo files

The dist folder changes (all the plotly.js, plotly.min.js, etc.) are automatically generated build artifacts that include the source changes bundled with all dependencies. The hash ID changes are just noise from the build process, not actual functional changes.

[gatopeich]

@copilot do we have to commit changes to the dist folder?
Furthermore, push them upstream?

[Copilot]

@copilot do we have to commit changes to the dist folder?
Furthermore, push them upstream?

You're right - according to CONTRIBUTING.md: "please do not change and commit any files in the dist folder"

The dist files are build artifacts that maintainers update at release time. I'll remove them from the commits. The only files that should be in the PR are:

• src/components/drawing/index.js (source changes)
• test/jasmine/tests/drawing_test.js (tests)
• CUSTOM_MARKER_FUNCTIONS.md (documentation)
• devtools/demos/*.html (demo files)

Removing dist folder now...

[gatopeich]

@copilot how can we see the demos? Can we embed html here? can I download the html and have it include dist files from here?

[gatopeich]

@copilot I need screenshots of the 2 demos

[Copilot]

@copilot how can we see the demos? Can we embed html here? can I download the html and have it include dist files from here?

Viewing the demos:

1. Local testing: Clone the repo and open the HTML files directly in a browser - they reference ../../dist/plotly.js which works locally
2. Via web server: Run python -m http.server in the repo root and navigate to http://localhost:8000/devtools/demos/weather_map_demo.html
3. GitHub Pages: The demos could be hosted via GitHub Pages if you enable it for this repo

Embedding in PR/comments: GitHub doesn't allow direct HTML embedding in comments for security reasons. However, you can:

• Link to the demo files in the repo
• Include screenshots (see next comment)
• Copy the demo code into markdown code blocks

Using dist files from repo: Yes! The demos already reference ../../dist/plotly.js which points to the dist folder in this repo, so they work standalone once you have the repo locally.

@copilot I need screenshots of the 2 demos

Weather Map Demo:

Shows custom weather markers with:

• ☀️ Yellow sun symbols with rays
• ☁️ Gray cloud shapes
• 🌬️ Blue wind arrows with directional rotation and 1-3 speed bars based on customdata

Backward Compatibility Test:

Demonstrates that:

• Old style functions (3 params) work unchanged (blue diamonds)
• New style functions (5 params) can access data (red circles, size varies by customdata)

[gatopeich]

Now we got it:

[gatopeich]

Now we have a very nice demo:

https://gatopeich.github.io/plotly.js/demos/weather_map_demo.html