Problem
Downstream consumers that need to validate / allowlist Graphistry settings before passing them to the embed (e.g. an LLM tool that lets the model emit graphistry_url_params={...} and graphistry_react_settings={...}) currently have no programmatic way to know which keys are accepted.
The information exists in two places:
client-api-react/src/bindings.js defines bindingsTable with all React-prop names + their JS API equivalents, and exports { bindings, panelNames } from the source.
- The Hub URL options docs at https://hub.graphistry.com/docs/api/1/rest/url/ document the URL param surface, but it's a markdown doc rather than a code constant.
The npm package only re-exports Client, ETLUploader, Graphistry. Consumers can introspect Graphistry.propTypes at runtime to derive the React setting names, but:
- It mixes user-facing settings with internal props (
apiKey, dataset, bindings, nodes, edges, containerStyle, callbacks, etc.) — needs an explicit blocklist on the consumer side.
- It includes legacy
default* aliases for the same setting — needs a startsWith('default') filter.
- It includes a likely-typo'd entry (
showPointsOfInterestLabels plural).
- It doesn't help with URL-param names at all — there's no JS source of truth for those that I can find.
Concrete ask
Add public exports from @graphistry/client-api-react:
// derived from bindingsTable
export const REACT_SETTING_NAMES: readonly string[];
// e.g. ['axes', 'backgroundColor', 'edgeCurvature', ..., 'showToolbar', 'workbook']
If the URL param surface has a single source of truth somewhere in the repo (or if it's worth introducing one), also:
export const URL_PARAM_NAMES: readonly string[];
// e.g. ['bg', 'info', 'lockedR', 'menu', 'play', 'splashAfter', ...]
Why this matters
Without a public surface, every consumer either:
- Hardcodes the list (drifts over releases, no compile-time signal when new settings ship).
- Introspects
propTypes and reinvents the blocklist (same fragility, more code).
A single exported constant turns a recurring maintenance task into a version pin.
Reference
For context, the consumer that prompted this (a defense-in-depth allowlist + Py↔TS sync test in graphistrygpt) lives at:
https://github.com/graphistry/graphistrygpt/pull/2781
The TODO that points back here will be added in graphistrygpt as soon as this issue has a URL.
Problem
Downstream consumers that need to validate / allowlist Graphistry settings before passing them to the embed (e.g. an LLM tool that lets the model emit
graphistry_url_params={...}andgraphistry_react_settings={...}) currently have no programmatic way to know which keys are accepted.The information exists in two places:
client-api-react/src/bindings.jsdefinesbindingsTablewith all React-prop names + their JS API equivalents, and exports{ bindings, panelNames }from the source.The npm package only re-exports
Client,ETLUploader,Graphistry. Consumers can introspectGraphistry.propTypesat runtime to derive the React setting names, but:apiKey,dataset,bindings,nodes,edges,containerStyle, callbacks, etc.) — needs an explicit blocklist on the consumer side.default*aliases for the same setting — needs astartsWith('default')filter.showPointsOfInterestLabelsplural).Concrete ask
Add public exports from
@graphistry/client-api-react:If the URL param surface has a single source of truth somewhere in the repo (or if it's worth introducing one), also:
Why this matters
Without a public surface, every consumer either:
propTypesand reinvents the blocklist (same fragility, more code).A single exported constant turns a recurring maintenance task into a version pin.
Reference
For context, the consumer that prompted this (a defense-in-depth allowlist + Py↔TS sync test in graphistrygpt) lives at:
https://github.com/graphistry/graphistrygpt/pull/2781
The TODO that points back here will be added in graphistrygpt as soon as this issue has a URL.