Skip to content

fix: react to ConfettiWidget colors updates - #105

Open
erperejildo wants to merge 1 commit into
funwithflutter:masterfrom
erperejildo:fix/colors-update-on-widget-rebuild
Open

fix: react to ConfettiWidget colors updates#105
erperejildo wants to merge 1 commit into
funwithflutter:masterfrom
erperejildo:fix/colors-update-on-widget-rebuild

Conversation

@erperejildo

Copy link
Copy Markdown

Why

Fixes flutter_confetti #102 — updating the colors parameter of a ConfettiWidget has no effect.

When the widget is rebuilt with a different colors list (e.g. via setState in the parent), the emitted confetti keeps using the original colors. Two root causes:

  1. _ConfettiWidgetState never implemented didUpdateWidget, so the new color list was simply ignored.
  2. ParticleSystem stored the colors in a final field read once at construction, so there was no way to update it even if the state noticed the change.

The only workaround available to users was forcing a full widget recreation via a Key derived from the color value (as noted in the issue).

What changed

  • lib/src/confetti.dart_ConfettiWidgetState now implements didUpdateWidget: when widget.colors differs from oldWidget.colors, the new list is forwarded to the ParticleSystem.
  • lib/src/particle.dart_colors is no longer final; added a colors setter so the emission colors can be updated at runtime.
  • test/confetti_test.dart — added 3 tests:
    • ParticleSystem emits particles with the color set through the setter.
    • Newly generated particles pick up updated colors after emission already started.
    • ConfettiWidget rebuilds with a different colors list without errors.

Behavior notes

  • Newly emitted particles use the updated colors; particles already in flight keep the color they were created with. This is consistent with how the widget already behaves for other per-particle parameters (size, shape, etc.).
  • Only the colors parameter is handled for now — it's the only one whose change the issue reports, and the only one that can be updated safely without affecting in-flight particle physics.

How I tested

  • flutter test — all tests pass (existing + 3 new).

  • Built a local test app with the exact reproduction sample from the issue (blue square, "Toggle Color" / "Play" / "Pause" buttons, colors: [_particleColor]) wired to this branch via a path dependency, and ran it on Chrome:

    1. Initial state: blue square, no confetti.
    2. Click Toggle Color → square turns red (triggers the ConfettiWidget rebuild).
    3. Click Play → confetti is now emitted in red (verified by pixel analysis of screenshots: ~2000 red confetti pixels, zero blue).

    On the released 0.8.0 code the same steps emit blue confetti, matching the issue's video.

Handle didUpdateWidget in _ConfettiWidgetState so changes to the
`colors` parameter propagate to the ParticleSystem. Previously the
color list was only read at initState, so rebuilt widgets kept emitting
particles with the original colors (fixes funwithflutter#102).
@netlify

netlify Bot commented Aug 5, 2026

Copy link
Copy Markdown

Deploy Preview for dazzling-euclid-7da31e failed.

Name Link
🔨 Latest commit 3240dab
🔍 Latest deploy log https://app.netlify.com/projects/dazzling-euclid-7da31e/deploys/6a73c0a61e8050000848b1eb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ConfettiWidget.colors change have no effect when updating widget

1 participant