-
Notifications
You must be signed in to change notification settings - Fork 47.5k
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
[Fiber] Child Reconciler + New Coroutines Primitive #6859
Conversation
var element = getElement(unitOfWork); | ||
var fn = element.type; | ||
var props = element.props; | ||
var value = fn(props); |
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.
Should this check shouldConstruct?
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, I see. value
is an object only if fn
is module-pattern-y (like Relay containers currently are).
I think this makes sense overall. My two main points of confusion (already noted inline):
|
// If there is more work to do in this parent, do that next. | ||
return unitOfWork.sibling; | ||
} else if (unitOfWork.parent) { | ||
// If there's no more work in this parent. Complete the parent. |
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 is how completion works by walking up the parent.
I was, however, considering using an explicit stack object that contains the path to the parent currently executing since that can be recreated whenever you start back from the top. That saves us having to store the parent pointer on the fiber itself.
I figured we might need the parent point for other things like finding effects, or dispatching events, but we could also do that using something like "host parent" or "event parent" like we do in the stack reconciler.
abfa64f
to
f75462f
Compare
@sebmarkbage updated the pull request. |
f75462f
to
b1158ca
Compare
@sebmarkbage updated the pull request. |
b1158ca
to
b704646
Compare
b704646
to
fd4f74e
Compare
Implemented the feedback. I'll leave the yield hack in for now. |
@sebmarkbage updated the pull request. |
const fiber = exports.createFiberFromElementType(element.type); | ||
if (typeof element.type === 'object') { | ||
// Hacky McHack | ||
element = ReactElement(fiber.input, null, element.ref, null, null, null, element.props); |
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.
What is this case for?
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.
Never mind, I get it now. element.type
comes in as object, so fiber
is just element.type
, and we apply the props to the continuation type.
@@ -184,7 +184,8 @@ function validatePropTypes(element) { | |||
var ReactElementValidator = { | |||
|
|||
createElement: function(type, props, children) { | |||
var validType = typeof type === 'string' || typeof type === 'function'; | |||
var validType = typeof type === 'string' || typeof type === 'function' || | |||
(type !== null && typeof type === 'object'); |
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.
Actually I guess this is a minor-version change as it allows objects as element types. Should we maybe do a backport of this and exclude this change? We might also be able to get away with not cherry-picking this at all…
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 only changes the warning behavior, but it would be nice if we could be a little more strict here. Forgetting to export anything from a CommonJS module lands you an empty object 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.
We could add and Object.keys(type).length
check.
Regardless we probably don't want this part in 15 since it will change the warning behavior (at least before if you had the case you talk about you know something is about to go wrong).
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 is going to be throwing later on if you tried to render this anywhere before. It is also going to be throwing through out version 15 so even if you try a later version and then downgrades, it'll still not warn. So I think this is pretty safe.
We can be more specific once we know a bit more about the data structures that will be allowed here. I suspect "module components" might end up here if we do those. As well as yields.
[Fiber] Child Reconciler + New Coroutines Primitive (cherry picked from commit 0f4a4df)
[Fiber] Child Reconciler + New Coroutines Primitive (cherry picked from commit 0f4a4df)
First commit is expanding the structure of child reconciliation. The steps are organized around phase rather than type of component. I found this helpful for now but I'm sure other structures make sense too.
New Coroutine Primitive. Alternative APIs are possible. The important part is getting the implementation details right to have all the pieces available in the reconciler.