You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use the rerender method to tigger a new rendering of a component and then later call unmount when we're done with it. This has worked well for our use case but after upgrading to 5.1.0, we're seeing a race condition that's causing the component to render after the component has been unmounted.
git clone https://github.com/mdonnalley/ink-bug.git
cd ink-bug
npm install
node --loader=import-jsx index.js
With 5.1.0
--- Time to render the component ---
Hello Foo!
--- Done! ---
Hello Baz!
With 5.0.1
--- Time to render the component ---
Hello Baz!
--- Done! ---
Best I can tell the regression is caused by this PR, which swapped lodash's throttle for es-toolkit's.
Our best workaround at the moment is to pin ink to 5.0.1 but it's not a great long term solution since we'd like to stay up to date with latest.
We also considered adding a 10ms sleep before unmounting the component. This seems to work but it would require some painful refactoring on our end to make the entire call stack async.
The text was updated successfully, but these errors were encountered:
We use the
rerender
method to tigger a new rendering of a component and then later callunmount
when we're done with it. This has worked well for our use case but after upgrading to 5.1.0, we're seeing a race condition that's causing the component to render after the component has been unmounted.I created a repo that replicates the issue
With 5.1.0
With 5.0.1
Best I can tell the regression is caused by this PR, which swapped lodash's
throttle
for es-toolkit's.Our best workaround at the moment is to pin ink to 5.0.1 but it's not a great long term solution since we'd like to stay up to date with latest.
We also considered adding a 10ms sleep before unmounting the component. This seems to work but it would require some painful refactoring on our end to make the entire call stack async.
The text was updated successfully, but these errors were encountered: