Allow hovertemplate to accept a closure

[facetious]

Using a format string (which isn't particularly well documented) is cumbersome and restrictive. This would be a better interface if the signature for hovertemplate were string | (x, y) => string.

The code is rather disorganized in this repo, or else I would have attached a PR myself to do this relatively straightforward process. Simply put, whenever a closure is provided instead of a format string, the coercer should simply use the closure and skip all of its regular format string processing. I'm open to producing a PR, so long as someone can point me to the places (either via a series of links or even just general guidance) that would need to be updated to make this happen.

As it stands right now, we are processing all of our data points on the way in as the provided data set which, as you can imagine, is not particularly performant on large data sets. Having it just execute the hover display on-demand would be much better. While we're talking about it, a similar functionality for the tick marks would also be desirable.

Thanks.

[alexcjohnson]

This has been discussed many times over the years (see eg #1464), but in light of changes in the ecosystem perhaps it's worth revisiting. Three commitments we've made for plotly.js make functions like this this difficult. The decreasing importance of Chart Studio has shifted things a bit but these are still firm requirements:

• The figure spec for plotly.js must be JSON-serializable, so that the full functionality is available from all back-end languages, no functionality is JavaScript-only.
• The figure must be portable - ie no information is lost and no visual changes if the figure is saved and reconstituted in another environment.
• For security purposes we do not execute arbitrary code from strings in the figure spec. Many applications allow part or all of the figure to be provided by one user, stored, and reloaded by another user, and we do not want authors of such applications to have to think about XSS via plotly.js.

There is a workaround we could imagine adding here, which already exists in Dash AG Grid - bundle in a JS parser that can execute a restricted set of functionality from a string. This is an awfully heavy solution, and would be even more limited here because the portability requirements for plotly.js are stronger than in Dash AG Grid so the code here would need to be fully self-contained, ie no reaching out to functions somewhere in the global namespace. So it's not clear to me that adding a parser would be better than continuing to enhance the declarative spec.

I'm sorry you find the code disorganized, feel free to submit a PR to help us improve the organization.

[gvwilson]

Hi - we are tidying up stale issues and PRs in Plotly's public repositories so that we can focus on things that are still important to our community. Since this one has been sitting for a while, I'm going to close it; if it is still a concern, please add a comment letting us know what recent version of our software you've checked it with so that I can reopen it and add it to our backlog. If you'd like to submit a PR, we'd be happy to prioritize a review, and if it's a request for tech support, please post in our community forum. Thank you - @gvwilson