Commit Graph

3 Commits

Author SHA1 Message Date
Héctor Ramos 1151c096da Update copyright headers to yearless format
Summary: This change drops the year from the copyright headers and the LICENSE file.

Reviewed By: yungsters

Differential Revision: D9727774

fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
2018-09-11 15:33:07 -07:00
Valentin Shergin 0792fba63f Fabric: Using ShadowView instead of ShadowNode in Mutations
Summary:
@public
This is quite a big diff but the actual meaningful change is simple: now we use ShadowView class instead of ShadowNode in mutation instructions.
Note:
 * In some places (especially during diffing) we have to operate with ShadowNodeViewPair objects (which represents a pair of ShadowNode and ShadowView). The reason for that is that we cannot construct child ShadowViews from parent ShadowViews because they don't have any information about children.
 * `ShadowTree::emitLayoutEvents` is now much simpler because ShadowView better represents the specifics of this kind of object.
 * The code in RCTMountingManager also became simpler.

This change will allow us to implement more cool tricks soon.

Reviewed By: mdvacca

Differential Revision: D9403564

fbshipit-source-id: dbc7c61af250144d6c7335a01dc30df0005559a2
2018-09-03 23:04:20 -07:00
Valentin Shergin 5c83855c75 Fabric: Introducting `ShadowView` and `ShadowViewMutation`
Summary:
@public
We need some another object like ShadowNode (but not ShadowNode) to represent an instance of the component in the mutation instructions. This is
the main motivation for introducing ShadowView.

Why not use ShadowNode? ShadowNode is designed to represent a node in ShadowTree, not be a part of a mutation instruction.
 * ShadowNode exposes some APIs that should not be exposed to the mounting layer;
 * ShadowNode is an immutable data structure, so we cannot mutate it in some way which can be meaningful for mounting;
 * We should not add to ShadowNode any functionality which is needed only for mounting;
 * ShadowNode is a bit more heavy object to share that it needs to be; it's exposed (embedded into Mutation) as a `shared_ptr` which is not optimal from the performance perspective;
 * Retaining ShadowNode from mounting code can unnecessarily extend its lifetime which can negatively affect memory usage.

Reviewed By: mdvacca

Differential Revision: D9403562

fbshipit-source-id: 72ad81ed918157a62cd3d1a03261f14447649d0b
2018-09-03 23:04:20 -07:00