Add support for custom scatter markers

[mattpap]

This PR allows to define custom scatter markers using Scatter(defs={"@new_name": CustomJS(...)}). Custom marker names are prefixed with @, so that they can be differentiated easily (and on the type level) from built-in markers.

From examples/basic/scatters/custom_markers.py:

[bryevdv]

Just noting this exact ask came up on the Discourse recently: https://discourse.bokeh.org/t/custom-markers-extensions-and-registering-new-marker-types/12089/2

[bryevdv]

I had imagined this with a dedicated CustomJSMarker but it we can get by with existing CustomJS maybe that's fine with enough documentation support.

I do think passing the defs to individual scatter calls is a little awkward. At least personally, I'd rather register them explicitly up front to use later.

custom_markers = {"@foo": ..., "@bar": ...}

Scatter.register(custom_markers)

plot.scatter(x, y, marker="@foo")
plot.scatter(x, y, marker="@bar")

I'm sure there are other possibilities, e.g. decorator or something.

[mattpap]

I had imagined this with a dedicated CustomJSMarker but it we can get by with existing CustomJS maybe that's fine with enough documentation support.

I'm considering adding CustomJSMarker for the sake of documentation, though it would still inherit from CustomJS. For that, however, I need override support implemented in PR #13344.

I do think passing the defs to individual scatter calls is a little awkward. At least personally, I'd rather register them explicitly up front to use later.

If there's only one .scatter() call then the implemented API should be sufficient. When multiple glyphs are involved, then having preregistered markers would be beneficial. I need to think where those definitions would live, because currently we don't have a mechanism for storing "static" data and models.

[bryevdv]

because currently we don't have a mechanism for storing "static" data and models.

Yup I expected that to be the main little roadblock. It's something that could have been useful in other contexts though so using this as a motivating use-case might be worthwhile.

[mattpap]

Yup I expected that to be the main little roadblock. It's something that could have been useful in other contexts though so using this as a motivating use-case might be worthwhile.

Technically we already have something quite similar to this for Document and custom model definitions, but that would have to be expanded in scope and adapted. I will start a new feature issue for this.

[bryevdv]

Simulating positional args seems a bit unconventional in TypeScript. FWIW I think splitting into apply and apply_for_path or something similar would also be reasonable.

[mattpap]

Simulating positional args seems a bit unconventional in TypeScript. FWIW I think splitting into apply and apply_for_path or something similar would also be reasonable.

This is standard practice in JavaScript, thus it's standard practice TypeScript. TypeScript covers existing patterns in JavaScript and it isn't (as much as possible) opinionated about chosen patterns. This also follows the canvas API. I would typically split such API into multiple methods if signatures were too complex and/or there were run-time performance implications of a unified API.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.