Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Keep Chart interaction props in parity with interaction_config

Open
  • Is something wrong?
#435 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
data-visualization

Research direction

Start in python/xy/components.py by reading the Interaction dataclass, interaction_config(), Chart.init, Chart.figure(), and Figure.set_interaction() sections linked in the issue. Compare their interaction fields and precedence behavior, then add coverage for parity and direct-versus-child configuration; done means all listed acceptance criteria pass.

Written by the indexing model from the issue text.

Description

Summary

XY documents interaction options as usable either directly on a chart or through an interaction_config() child, but those entry points have already drifted: history exists on Interaction and interaction_config() but is missing from Chart.__init__. The direct-prop forwarding guard also omits link_axes even though the value is forwarded inside the guarded block.

Audited at 99eda6d.

Current behavior

history is part of the Interaction dataclass and the interaction_config() signature. It is applied for child components in the chart compiler.

Chart.__init__ exposes the other interaction fields but omits history in its public signature. Therefore:

xy.line_chart(xy.line([0, 1], [0, 1]), history=False)

raises an unexpected-keyword TypeError, while this works:

xy.line_chart(
    xy.line([0, 1], [0, 1]),
    xy.interaction_config(history=False),
)

The direct-prop guard checks link_group but not link_axes in Chart.figure(), so a direct link_axes value cannot by itself enter the forwarding block.

Closed issue #110 added view history; this issue is about exposing that completed feature consistently.

Proposed direction

Define one authoritative InteractionProps schema (or equivalent manifest) and derive/validate Interaction, interaction_config(), Chart.__init__, and Figure.set_interaction() against it. A parity test should make future field additions fail unless every public entry point is updated.

Acceptance criteria

  • history is accepted and documented as a direct Chart/chart-factory option.
  • Direct history= and xy.interaction_config(history=...) produce the same figure spec.
  • link_axes participates in the direct-prop forwarding guard.
  • Every interaction field has explicit precedence when both a direct prop and a child component are supplied.
  • A schema/parity test covers Interaction, interaction_config(), Chart.__init__, and Figure.set_interaction() so new fields cannot drift silently.
Dominant language
Python
Stars
1.9k
Forks
76
Avg merge
1h 25m
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from reflex-dev/xy

All issues in reflex-dev/xy

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.