Fix client state setter event var args - #6935
Conversation
Greptile SummaryThis PR updates client-state setters to derive valid wrapper argument names from event-derived expressions while preserving the complete setter value expression.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| reflex/experimental/client_state.py | Replaces expression-based wrapper parameters with leading event-identifier extraction so optional-chain setter expressions generate valid JavaScript. |
| tests/units/test_event.py | Adds focused serialization tests for optional-chain and Unicode client-state setter event expressions. |
Reviews (2): Last reviewed commit: "Handle unicode event argument names" | Re-trigger Greptile
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
Thanks, this was a valid catch. The old regex only handled ASCII identifier characters, so an event expression such as I replaced that with a small Unicode-aware JS identifier scanner and added a regression test for the non-ASCII event arg case. Verified with:
|
Fixes #5741.
ClientStateVar.set_value()was using the rendered value expression to build the wrapper function argument. That works for plain event vars, but breaks for optional-chain expressions like_event?.clientXbecause the generated handler ends up with_event?.clientXas the argument name:This patch keeps the setter call value as-is, but derives the wrapper argument from the leading event identifier instead, so the generated function is valid:
Added a regression test for the optional-chain client-state setter case.
Tested with:
Pytest warned that it could not write
.pytest_cachein my Windows workspace, but the tests passed.