Forward ref #1738
Forward ref #1738
Conversation
…ided, defer to its definition of a valid element type.
| return { | ||
| nodeType: 'function', | ||
| type: node.type, | ||
| props: { ...node.pendingProps }, |
There was a problem hiding this comment.
This feels fundamentally wrong, but it works? I'm not sure how React implements the fiber nodes for forward refs under the hood but it's possible memoizedProps is never equal to pendingProps...
There was a problem hiding this comment.
Please never ever create duplicate PRs; this clutters the repo forever.
This will now have to stay open until #1592 is merged, and I'll have to manually and painfully keep it in sync, otherwise I'll have to forever look at the redundant PR ref on my git log.
| @@ -133,6 +134,17 @@ function toTree(vnode) { | |||
| case ContextProviderType: // 13 | |||
| case ContextConsumerType: // 12 | |||
| return childrenToTree(node.child); | |||
| case ForwardRefType: { | |||
There was a problem hiding this comment.
I added this logic to the 16.3 adapter in addition to the 16 adapter because React.forwardRef was added in 16.3.
|
Duplicate of #1592. |
|
@ljharb should this PR be closed? Alternatively, I can force-push the branch to contain nothing? I don't understand what workflow you're optimizing around. |
|
@suchipi no worries, i know it's probably not a common one. Continue pushing to this one; I'll rebase and force push it so that both PRs match (once tests are passing here) |
Rebased version of #1592 with test added for the special proptype handling and failing tests fixed.
Fixes #1604.