Skip to content

Declarative encode_*_from_dict constructor parity with React-side ['col','categorical', mapping] shape #1250

@lmeyerov

Description

@lmeyerov

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions