Use case
Downstream consumers (Louie/graphistrygpt LLM tool surface, JS dashboards) regularly receive encoding payloads in the React-side declarative shape:
{
"encodePointColor": ["type", "categorical", {"primary": "#1f77b4"}],
"encodePointIcons": ["type", {"primary": "server"}],
"encodePointSize": ["degree_bucket", {"small": 5, "large": 30}],
"encodeAxis": [{"r": 200, "label": "outer", "external": true}]
}
Today they have to hand-translate this into kwargs:
g.encode_point_color(column="type", as_categorical=True, categorical_mapping={"primary": "#1f77b4"})
This translation lives in graphistrygpt's _extract_*_from_react_settings cluster (5 helpers, ~80 LOC) and is duplicated in any other consumer that bridges JS and Python.
Ask
A declarative constructor on the Plottable that takes the React shape directly:
g.apply_encodings({
"encodePointColor": ["type", "categorical", {...}],
"encodePointIcons": ["type", {...}],
"encodeAxis": [...],
})
# returns a new Plottable with all encodings applied
Equivalent to calling each encode_* method individually but with the JS-shaped payload as input. The same shape that client-api-react's <Graphistry encodePointColor=... encodePointIcons=... /> props accept.
Why this lives upstream
JS+Python contract drift is a recurring source of bugs. If pygraphistry owns the canonical translation, every downstream consumer (Louie, JS bridges, dashboard tools) imports it and benchmarks/tests against the same source.
Effort estimate
Low. Each encode_* method already exists; the new constructor is a thin dispatcher. Reuses existing per-method signatures.
Filed via Louie graphistrygpt PR #2791 audit (findings.md upstream issue #1). Tracked in graphistrygpt as a TODO(upstream-deletion): reference at graphistrygpt/plugins/graphistry/tool.py:_extract_point_color_from_react_settings.
Use case
Downstream consumers (Louie/graphistrygpt LLM tool surface, JS dashboards) regularly receive encoding payloads in the React-side declarative shape:
{ "encodePointColor": ["type", "categorical", {"primary": "#1f77b4"}], "encodePointIcons": ["type", {"primary": "server"}], "encodePointSize": ["degree_bucket", {"small": 5, "large": 30}], "encodeAxis": [{"r": 200, "label": "outer", "external": true}] }Today they have to hand-translate this into kwargs:
This translation lives in graphistrygpt's
_extract_*_from_react_settingscluster (5 helpers, ~80 LOC) and is duplicated in any other consumer that bridges JS and Python.Ask
A declarative constructor on the Plottable that takes the React shape directly:
Equivalent to calling each
encode_*method individually but with the JS-shaped payload as input. The same shape thatclient-api-react's<Graphistry encodePointColor=... encodePointIcons=... />props accept.Why this lives upstream
JS+Python contract drift is a recurring source of bugs. If pygraphistry owns the canonical translation, every downstream consumer (Louie, JS bridges, dashboard tools) imports it and benchmarks/tests against the same source.
Effort estimate
Low. Each
encode_*method already exists; the new constructor is a thin dispatcher. Reuses existing per-method signatures.Filed via Louie graphistrygpt PR #2791 audit (findings.md upstream issue #1). Tracked in graphistrygpt as a
TODO(upstream-deletion):reference atgraphistrygpt/plugins/graphistry/tool.py:_extract_point_color_from_react_settings.