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

v0.11.0 changes behavior in a breaking way for our app with no attachTo prop is provided #78

Open
yacobyonas opened this issue Jul 2, 2022 · 2 comments

Comments

@yacobyonas
Copy link

yacobyonas commented Jul 2, 2022

When we upgraded to version 0.11.0 we (h/t @andyyu, the eng on our team who found the issue) noticed that some core app behavior changed and upon digging in, we discovered that it was related to changes in behavior around the attachTo prop. If no attachTo prop is provided, it will clone the children passed in and swap in a new ref (code).

We had code that relied on the fact that the refs would not be swapped out. The culprit PR is #76. Can you advise on how we should be using the API after this change to the behavior? If we want to avoid having children be cloned, how should we be utilizing the attachTo prop? From reading the code, it wasn't clear how to get the behavior we'd like.

Thanks in advance for the assistance!

@okonet
Copy link
Owner

okonet commented Jul 2, 2022

Yeah unfortunately I realized later after building this library that using cloneElement is very dangerous for exact that reason.

In your case I would suggest to start using attachTo so you can pass the ref you need somewhere else to this lib. That's the only way to work around this issue.

Hope it makes sense.

@dimitrisnl
Copy link

@yacobyonas I'm on the same boat- would you mind sharing how you overcame this?

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

No branches or pull requests

3 participants