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

[yacobyonas]

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]

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]

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

[tearfur]

Basically the workaround is something like this:

// Before
const comp = /* ... */;
return (
  <ScrollSyncPane>{comp}</ScrollSyncPane>
);

// After
const comp = /* ... */;
const compRef = useRef(comp);
return (
  <ScrollSyncPane attachTo={compRef}>{comp}</ScrollSyncPane>
);