Skip to content

Singular/plural normalization: encodePointIcons (plural) vs encodePointColor (singular) trips downstream tooling #196

Description

@lmeyerov

Inconsistency

Today the React-side encoding prop names are:

  • `encodePointColor` (singular)
  • `encodeEdgeColor` (singular)
  • `encodePointIcons` (PLURAL)
  • `encodeEdgeIcons` (PLURAL)
  • `encodePointSize` (singular)
  • `encodeAxis` (singular, no graph-type prefix)

Downstream tooling (Louie graphistrygpt) regularly receives `encodePointIcon` (singular) from LLM tool callers because it pattern-matches the color/size shape. The wrong key gets silently dropped (key not in allowlist → never reaches the renderer). This was a real bug we hit twice during graphistrygpt PR #2791.

Ask

Either:

  1. Accept BOTH `encodePointIcon` and `encodePointIcons` as the same prop (with a deprecation warning on the singular for the next major); OR
  2. Rename to consistent `encodePointIcon` (singular) — pygraphistry uses `encode_point_icon` (singular) for the same concept; OR
  3. Document the inconsistency loudly in the README so downstream tooling knows to translate.

Why

Pygraphistry (`encode_point_icon`) and graphistry-js (`encodePointIcons`) drift on this single-vs-plural axis. Every JS↔Python bridge has to know the convention.

Filed via Louie graphistrygpt PR #2791 audit (findings.md upstream issue #9). Tracked in graphistrygpt's `_extract_point_icon_from_react_settings` and `_extract_edge_icon_from_react_settings` which use the JS-canonical plural form on the wire.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions