Skip to content

WIP: suport colorscale, custom labels and scattergl#1

Draft
adrien-n wants to merge 2 commits intocamlspotter:masterfrom
adrien-n:master
Draft

WIP: suport colorscale, custom labels and scattergl#1
adrien-n wants to merge 2 commits intocamlspotter:masterfrom
adrien-n:master

Conversation

@adrien-n
Copy link

Hey, I've started using plotly and I'm very happy to have bindings for it!

I wanted to add a Viridis colorscale and label all my markers. Unfortunately this doesn't really fit in well with the current API (and Plotly's API does not always make things easy) and I wanted to start a discussion on how to integrate these two things.

First, "colorscale" is an attribute in the "marker" attribute and there are several ways to use it, including passing all the colors to use one-by-one but the most common case is probably to pass all your data and habe plotly create the colormap.

Second, "text" is a direct attribute and it's simply the strings in the same order as the points to label.

I think it's possible to add a ?text argument as I've done here. I don't think the current code for marker and color scale is fine however and I'd like your input.

It's possible to extend the Base.Type.t and convert using it but that's quite a bit of work and there are probably more cases (here, I already needed an array of elements that are either a string, an integer or a float array). What do you think about allowing the user to directly pass custom attributes directly as lists of python values? In the linked code, marker_attributes would be a parameter instead of being defined in plotly-ocaml.

PS: I think the string "marker" shouldn't be constant but that doesn't change the crux of the topic.

@adrien-n
Copy link
Author

Two other possible approaches:

1- expose more of python.ml (make t not private and expose go, of_attributes and of_layout functions)
2- add an ?extra_attributes : Pytypes.pyobject argument to both of_figure and of_graph, and concat it with the other attributes (the pyobject type has to appear in the API, there's no easy way around it)

My preference is 2- as it's very simple and effective. On the other hand, it requires using pyml (which I had already used) but it's not horribly complicated and a few lines of documentation would probably enough for > 90% of the extra cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant