a3b348eacb
Summary: `RCTSurfaceHostingProxyRootView` surfaces are still automatically started right after the initialization to match `RCTRootView` interface, but `RCTSurfaceHostingView` must be started explicitly now. Also fixed some internal stuff so start and register are clear and distinct. Background / initial motivation: One tricky bit - we render the template as part of init`ing the rootView, so we don't know what the surfaceId will be before hand to register the UITemplate. Two possible solutions: 1) Require start be called explicitly after initializing the rootView, and setup the context in between. 2) Do something like "setUITemplateConfigForNextSurface" before creating the rootView, and have some hook when the surfaceId is assigned that associates the surfaceId with that "next" UITemplate stuff before. (1) seems a lot cleaner, but it requires ever user of rootView to explicitly call start on it - how do you feel about that? Seems like we could also use that start call to decide if the initial render should be synchronous or not? start vs. startSync? Reviewed By: mdvacca Differential Revision: D13372914 fbshipit-source-id: 6db297870610e6c231f8a78c0dd74d584cb64910 |
||
|---|---|---|
| .. | ||
| RCTFabricSurface.h | ||
| RCTFabricSurface.mm | ||
| RCTFabricSurfaceHostingProxyRootView.h | ||
| RCTFabricSurfaceHostingProxyRootView.mm | ||
| RCTFabricSurfaceHostingView.h | ||
| RCTFabricSurfaceHostingView.mm | ||