Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent Reaction From Keeping a Reference to The OldValue #3812

Merged
merged 2 commits into from
Jan 10, 2024

Conversation

barroij
Copy link
Contributor

@barroij barroij commented Jan 4, 2024

HI Folks

This PR is about reaction and memory retainment preventing object beeing garbage collected

For some reason, the reactionRunner of a reaction creates a closure around an oldValue and so the reference to the oldValue is kept untill a newValue is computed.

I can see no reason for keeping such a reference "alive", oldValue could just be declared in the scope of the reactionRunner as it is the only place where it is used. Doing so, the oldValue can be garbage collected if needed.

No additional Unit test is needed for such a change, and there is no backward compatibility issue as it only touches internal/private stuff within a reaction.

Copy link

changeset-bot bot commented Jan 4, 2024

🦋 Changeset detected

Latest commit: a3d5692

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
mobx Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@urugator
Copy link
Collaborator

urugator commented Jan 8, 2024

Did you investigate the behavior when expression throws?

@barroij
Copy link
Contributor Author

barroij commented Jan 9, 2024

@urugator
Assuming that disableErrorBoundaries is false or that an onError errorHandler is provided, if expression thows an exception it would be caught within track, but changed remains unchanged anyway, its value is false. So the effectAction is not called.
Except if (firstTime && opts.fireImmediately!) is true but in this case oldValue is undefined as it used to be, so the behavior remains the same.

@urugator
Copy link
Collaborator

urugator commented Jan 9, 2024

Ok, thank you. Could you please provide changeset (yarn changeset)? Otherwise LGTM.

@barroij
Copy link
Contributor Author

barroij commented Jan 9, 2024

I never made a changeset before. I ran yarn changeset and commited the generated .md file, is that all ?

@urugator
Copy link
Collaborator

urugator commented Jan 9, 2024

Yep. Github just seems to be sluggish atm, at least on mind end.

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.

2 participants