5c83855c75
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 |
||
|---|---|---|
| .. | ||
| attributedstring | ||
| components | ||
| core | ||
| debug | ||
| events | ||
| graphics | ||
| imagemanager | ||
| sample | ||
| textlayoutmanager | ||
| uimanager | ||