-
Notifications
You must be signed in to change notification settings - Fork 972
Conversation
The anywidget refactors in #8156, #8159, and #8163 separated model lifecycle from widget binding and moved to a dedicated ModelCommand for frontend-to-backend communication.
However, unlike UpdateUIElementCommand which goes through SetUIElementRequestManager's drain-and-merge path, the new ModelCommand is processed immediately. Each rapid model update (e.g. dragging a map widget) triggered an individual cell re-execution.
These changes puts ModelCommand on the same shared queue as UpdateUIElementCommand so both go through the same batching pipeline. When multiple model updates arrive in quick succession, they are now drained and merged (last-write-wins per model ID on state keys), matching the existing UI element behavior.
The handler for model messages also now enqueues the resulting UpdateUIElementCommand back through the control queue instead of calling set_ui_element_value directly, so the downstream cell re-execution also benefits from batching.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
a5229b7 to
d97731a
Compare
fc72c3f to
9f962c8
Compare
f1f2972 to
ed502bd
Compare
ed502bd to
1dbb193
Compare
1dbb193 to
65995d4
Compare
65995d4 to
5176b22
Compare
lifecycle from widget binding and moved to a dedicated ModelCommand for
frontend-to-backend communication.
However, unlike UpdateUIElementCommand which goes through
SetUIElementRequestManager's drain-and-merge path, ModelCommand was
processed immediately -- each rapid model update (e.g. dragging a map
widget) triggered an individual cell re-execution.
These changes puts `ModelCommand` on the same shared queue as
`UpdateUIElementCommand` so both go through the same batching pipeline.
When multiple model updates arrive in quick succession, they are now
drained and merged (last-write-wins per model ID on state keys),
matching the existing UI element behavior.
The handler for model messages also now enqueues the resulting
`UpdateUIElementCommand` back through the control queue instead of
calling `set_ui_element_value` directly, so the downstream cell
re-execution also benefits from batching.
ModelCommand was re-enqueuing a separate UpdateUIElementCommand back
onto the control queue. Because the batch merger only collapses
contiguous runs of the same type, these interleaved Model+UI pairs could
never be merged, so every single drag tick triggered its own full cell
re-execution.
Two changes fix this. First, handle_receive_model_message now calls
set_ui_element_value directly instead of re-enqueuing, eliminating the
interleaving entirely. Second, ModelCommand gets a token field (matching
UpdateUIElementCommand) so the dual-queue dedup works for both command
types. Previously only UI commands had tokens, so model commands left on
the control_queue after a set_ui_element_queue drain were each processed
individually rather than skipped. The dedup logic is unified into a
single _dedup method that handles both types.
1c52a67 to
a620401
Compare
|
Development release published. You may be able to view the changes at https://marimo.app?v=0.19.10-dev45 |