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

Lock on the cleanNode function #2062

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

arvid220u
Copy link

Summary

It is possible for cleanNode to be called recursively. This PR adds a simple isCleaning lock to ensure that cleanNode isn't called on the same node twice.

Minimal example: https://playground.solidjs.com/anonymous/9f860e26-d0a3-476d-8b20-82ebff4763d7 (when you click "hide", you get a Cannot read properties of null error which comes from cleanNode being called twice on the same node).

I believe this error is most likely to happen when your entire app isn't in Solid, but you're instead mounting several Solid roots inside an existing application. We have global state controlling which Solid roots and components to show, and a syncState function that reads from the global state and disposes/creates Solid roots based on that. If component A has a Show that causes component B to be disposed, and component B has an onCleanup that calls the global syncState which disposes the entire Solid root that A is rendered in, then A will error in the cleanNode function.

I believe that this change should solve this problem, but I would love input on whether this change is reasonable at all, or whether it may have side effects that I haven't considered.

Thank you!

How did you test this change?

Would love advice on where you think it'd be best to add a test for this — didn't do it yet, because would first love input on whether this change makes sense.

Copy link

changeset-bot bot commented Feb 7, 2024

⚠️ No Changeset found

Latest commit: 4cff3e4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

@ryansolid
Copy link
Member

I think it does. The only challenge is concurrency. That being said I don't think it changes the desire for this. Just it complicates things a bit.

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