Skip to content

[Fiber] Host Side Effects#7154

Merged
sebmarkbage merged 7 commits intofacebook:masterfrom
sebmarkbage:sideeffects
Jun 30, 2016
Merged

[Fiber] Host Side Effects#7154
sebmarkbage merged 7 commits intofacebook:masterfrom
sebmarkbage:sideeffects

Conversation

@sebmarkbage
Copy link
Copy Markdown
Contributor

@sebmarkbage sebmarkbage commented Jun 30, 2016

This adds a linked list of side-effects and calls the host environment with those side-effects after a tree
has fully reconciled.

Also a rudimentary DOM renderer.

Review individual commits.

// us to reuse a slice of the linked list when we reuse the work done within
// this fiber.
firstEffect: ?Fiber,
lastEffect: ?Fiber,
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need the firstEffect field on every node? It seems like we could make lastEffect point to the root or a placeholder instead of being null and then save a field.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any node can end up being reused and then you need the start of that slice of the list.

We could potentially make them non-nullable for type purposes. I'll have to think about that some more. Would pointing to the root by you anything more than pointing to any random placeholder fiber?

For context, a parent can schedule itself before or after its children. That's a feature I take advantage of in subsequent diffs.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, no reason to use the root.

What do you mean, "Any node can end up being reused and then you need the start of that slice of the list."?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the work on a bunch of parents was aborted, because a higher priority update touched them, we can still reuse the work done on a child that wasn't touched. But we need to know which side-effects it had - separately from the aborted work.

This adds tracking of side-effects that gets scheduled during an
update.

As the tree gets reconciled, the side-effectful fibers are linked
together in an ordered singly linked list. That way we can walk
the linked list to commit only the work that needs to be
synchronous - quickly.

We also store first and last nodes within a fiber. That
way when we reuse an already processed subtree, we can reuse that
subset of the linked list.
This just makes them instantiable so that we can get access to the
host config in these.
This creates a new API for processing side-effects on the host
environment.

During initial reconciliation host instances are created during
the time sliced periods.

During updates there is an opportunity for the host
to prepare something on the instance during the time slicing, and
to determine whether there were any changes. The could be thrown
away.

At the commit phase, these changes are finally committed to the
host instance.
This updates the host container root with new children.
Currently, this is always called for updates because we don't
track if any children reordered.
This is only for host nodes so that the DOM tree is fully updated
by the time we've flushed.

Classes will schedule their life-cycles *after* their children's
side-effects.
*/

/**
* This is a renderer of React that doesn't have a render target output.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale.

@sophiebits
Copy link
Copy Markdown
Collaborator

👍

@sebmarkbage sebmarkbage merged commit cf259a4 into facebook:master Jun 30, 2016
if (!child) {
return;
}
if (child.tag === TERMINAL_TAG) {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really happy with this model of determining terminalness by testing the host environment's type. I'd like to structure the output so that I always know if the next value is terminal or not.

One thing I could do is skip the propagation of single values up the tree and just output the child for those cases. More to traverse but you have to do it at some point I guess. Then I'd just check if the tag is a host node and if so, then I know the output is terminal.

@spicyj Any ideas?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None yet, sorry.

@zpao zpao added this to the 15-next milestone Jul 7, 2016
zpao pushed a commit that referenced this pull request Jul 8, 2016
[Fiber] Host Side Effects
(cherry picked from commit cf259a4)
@zpao zpao modified the milestones: 15-next, 15.2.1 Jul 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants