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

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions