Commit Graph

1 Commits

Author SHA1 Message Date
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