Skip to content

Feature/re render on cancel#477

Draft
jtanya17 wants to merge 2 commits intomainfrom
feature/re-render-on-cancel
Draft

Feature/re render on cancel#477
jtanya17 wants to merge 2 commits intomainfrom
feature/re-render-on-cancel

Conversation

@jtanya17
Copy link

@jtanya17 jtanya17 commented Mar 2, 2026

No description provided.

Tanya Jain and others added 2 commits February 24, 2026 10:31
When a zoid component is rendered, the rerender callback is stored in
currentRerender. However, if the component is destroyed or re-initialized
after rendering, currentRerender may become unavailable while the component
is still functional.

This change implements a fallback mechanism:
- Store the last successful rerender callback in lastRerender
- Track if the component has ever been rendered with hasBeenRendered
- In rerender(), first try currentRerender, fall back to lastRerender
- Provide more specific error messages to distinguish between "never
  rendered" and "callback lost after render"

This fixes the issue where rerender() throws "Rerender not available"
even though render() was successfully called. This commonly occurs in
app switch resume flows where the component may be temporarily destroyed.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
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.

1 participant