Skip to content

Conversation

@johannes-lindgren
Copy link
Collaborator

@johannes-lindgren johannes-lindgren commented Sep 9, 2025

What?

useFieldPlugin calls createFieldPlugin, which disabled the global styles as a side effect. It also attempts to clean up the side effect by enabling the style sheet again. This means that when a component that calls useFieldPlugin unmounts, the cleanup function enables the style sheet again. But this causes an issue if there is still another component that was using this side effect:

  1. Component A is rendered, and calls useFieldPlugin. The style sheet gets disabled.
  2. Component B is rendered, and calls useFieldPlugin. The style sheet remains disabled.
  3. Component B unmounts, so the cleanup function runs. The style sheet is re-enabled.
  4. Component A is still mounted, but the style sheet is now enabled.

Originally, createFieldPlugin was not meant to be called more than once: you were supposed to pass the state and methods via context or props.

As a solution, I think we can simply skip removing the disabled attribute from the style element,

How to test? (optional)

@vercel
Copy link

vercel bot commented Sep 9, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
plugin-sandbox Ready Ready Preview Comment Sep 9, 2025 3:16pm

@johannes-lindgren johannes-lindgren changed the title fix: global styles get re-enabled when useFieldPlugin is called multiple times fix(lib): global styles get re-enabled when useFieldPlugin is called multiple times Sep 9, 2025
Copy link
Contributor

@demetriusfeijoo demetriusfeijoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @Dawntraoz 🙌

Q: Syncing this change with the field-plugin moved to the monorepo is something feasible, or should the changes that happen here be manually replicated there? 🤔

Probably yes, but as I haven't done it before, I'm curious about it.

@Dawntraoz
Copy link
Contributor

Hey @Dawntraoz 🙌

Q: Syncing this change with the field-plugin moved to the monorepo is something feasible, or should the changes that happen here be manually replicated there? 🤔

Probably yes, but as I haven't done it before, I'm curious about it.

It is feasible, indeed, no need for manual changes, these changes will be rebased on the monorepo for now, using a CLI tool I created to handle git subtree folders 🙏 Once I do it, I can show you the process (that will not be needed once we have everything migrated there)

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.

4 participants