-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[Portal] Prepare deprecation of onRendered #16597
[Portal] Prepare deprecation of onRendered #16597
Conversation
b6d23ae
to
5c072f1
Compare
Details of bundle changes.Comparing: b6182ce...0a78aca
|
445b94b
to
a9c5612
Compare
Updated to take the reviews into account
|
||
useEnhancedEffect(() => { | ||
if (!disablePortal) { | ||
setMountNode(getContainer(container) || document.body); | ||
} | ||
}, [container, disablePortal]); | ||
|
||
React.useImperativeHandle(ref, () => mountNode || childRef.current, [mountNode]); | ||
useEnhancedEffect(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't we use useImperativeHandle
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, probably with the new if(!node) logic. Will try +1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh no, we can't. my bad. We still need to ignore the case where disablePortal is false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you elaborate on that? Right now we handle a ref in the commit phase. If it's not possible to handle in the ref phase we need to name it differently. Otherwise it might create confusing bugs because it's expected to be updated during ref phase when it only happens during commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, with pleasure. The problem is in the case where disablePortal is true. The classic ref logic will try to set the value to the DOM node during the first ref phase. However, the useImperativeHandle logic also tries to set the value to null. It creates a conflict. I believe it can't work.
Also, I'm wondering does it care in which phase the ref value is set in our case? Previously, the ref was set to null during the ref phase (to accommodate SSR). Now, the ref isn't called. In both cases, people can't rely on the ref value to be defined, they have to handle this undefined case. They have to wait for the actual value, after the first commit, ref, layout and effect phases.
@@ -65,6 +73,8 @@ Portal.propTypes = { | |||
disablePortal: PropTypes.bool, | |||
/** | |||
* Callback fired once the children has been mounted into the `container`. | |||
* | |||
* This prop will be deprecated and removed in v5, the ref can be used instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* This prop will be deprecated and removed in v5, the ref can be used instead. | |
* You probably don't need this prop. Prefer to use callback refs on the component instead. |
We haven't deprecated it yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The motivation for the "will be deprecate" is to create a sentiment of urgency for somebody relying on the prop but has a use case (we are not aware of) that can't rely on the ref. Do you think that we should still go for the "probably not"? I'm taking the time to ask because it's a broader topic, not specific to this occurrence. I can remember that the same method is used for withWidth. We had people opening an issue "Please don't deprecate withWidth" with some details (explaining why) consequent to the initial ultimatum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could only find usage of it in Popper and that component has quite the complicated implementation for pretty simple behavior. I tried reducing the amount of logic to get a better hold of why we need onRendered instead of ref.
One part of the issue is the misnomer. Makes it hard to mentally "click" what this prop does.
I'd like to explore first why we need it in Popper and then we can go back to this one. As it looks like right now "you probably don't need it" is the better advise.
The motivation for the "will be deprecate" is to create a sentiment of urgency for somebody relying on the prop
That is not the why but the what. Why do you want to create a sense of urgency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had forgotten about the Popper. I believe that the child div ref could be used instead. Would it work?
Why do you want to create a sense of urgency?
It incentives users to give us feedback sooner than if we wait to introduce the deprecation. it optimizes for learning. The sooner we have the information:
- the less likely we will introduce a deprecation that we have to revert
- the less likely somebody will use the prop and the better migration path going from v4 to v5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what we gain by saying we will deprecate it if we're not sure about it. That can only hurt trust.
it optimizes for learning.
Could you elaborate on that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I wasn't clear.
I think that we should first agree that removing the prop is the best long-term path. Do we?
Then, it's about waiting x months (x because we don't want people to feel too much code change pressure) before introducing the deprecation warning vs saying it right away and adding a warning only later on (it creates x months of additional learning opportunity).
I don't think that saying the prop will be deprecated and not deprecating it is worse than deprecating a prop and reverting.
So, if you think that we are not ready yet to commit to a deprecation, your suggestion is better without any doubts. If you think that we are good for deprecation, we have an opportunity to collect feedback x more months ("optimize for learning").
a9c5612
to
de60732
Compare
de60732
to
5042c69
Compare
I have removed the |
5042c69
to
76c656f
Compare
Rebased. |
76c656f
to
0a78aca
Compare
Starting now, people can use the ref instead of the
onRendered
prop. I think that we should remove it in v5.Closes #16595
Related #16262 (comment).