Offload animated #2

brentvatne · 2016-02-07T22:35:13Z

skevy · 2016-02-08T23:29:56Z

In it's current version, this now is merged into exp-latest. Let's open a new PR down the road if it needs to be re-pulled in.

Summary: > It also must be useful considering that the majority of readers only speak English. So, each app in the showcase should link to either: 1/ An English-language news article discussing the app, built either by a funded startup or for a public company 2/ An English-language technical post on a funded startup or public company blog discussing React Native For each app in the showcase, use infoLink and infoTitle to reference this content. - We wrote a technical post on [medium](https://engineering.huiseoul.com/building-a-conversational-e-commerce-app-in-6-weeks-with-react-native-c35d46637e07#.776ll9ram) - My company was funded, also. Reference [#1](http://besuccess.com/2015/08/huiseoul/), [#2](https://www.crunchbase.com/organization/trillionaire#/entity) Closes facebook#9807 Differential Revision: D3843024 Pulled By: lacker fbshipit-source-id: d76b2996f8aade42923d268f9308ae8796364083

Summary: AaaChiuuu See: facebook#11329 Closes facebook#11505 Differential Revision: D4338559 Pulled By: AaaChiuuu fbshipit-source-id: 6cd1fd366a2bc30d496b7e907242e7f89a384a19

Summary: We are removing support of nesting views inside <Image> component. We decided to do this because having this feature makes supporting intrinsinc content size of the <Image> impossible; so when the transition process is complete, there will be no need to specify image size explicitly, it can be inferred from actual image bitmap. And this is the step #2: Yellow Box. <ImageBackground> is very simple drop-in replacement which implements this functionality via very simple styling. Please, use <ImageBackground> instead of <Image> if you want to put something inside. Reviewed By: yungsters Differential Revision: D5139264 fbshipit-source-id: 99442107e10a321618fd34802c57a8c205ce66fb

Summary: A blog post with notes from the second React Native monthly meeting. I've gathered notes after the meeting in this blog post. No test plan, submitting just a documentation file. cc hramos Closes facebook#15257 Differential Revision: D5528121 Pulled By: hramos fbshipit-source-id: c9688596d0f4b13600f3f1f18d7c122665de1fc2

Summary: In D17439957, I noted that YogaLogger#log throws a NoMethodFoundException when called from C++ b/c C++ and Java's signatures of that method don't match. C++ uses YogaNodeJNIBase for the first param, Java uses YogaNode. Both my attempts to fix this failed. Attempt #1 - Make Java use YogaNodeJNIBase. This doesn't work because the :java-interface target includes YogaLogger but not YogaNodeJNIBase. Moving YogaLogger to the impl target doesn't work either b/c other files in :java-interface reference YogaLogger. Attempt #2 - Make C++ use YogaNode. This doesn't work b/c we try to call the log method with objects of fbjni type YogaNodeJNIBase. This would be fine in Java since YogaNodeJNIBase extends YogaNode. But fbjni's typing isn't advanced enough to know this, so the Yoga C++ fails to compile. At this point, I was wondering what the value of having this param in the log function at all was. None of the implementations in our codebase use it today. It might be easier to just remove it all together. This also removes a bug with YGNodePrint where we pass a null layout context that eventually causes a SIG_ABRT when we use it to try to find a YogaNode to pass to this function. (https://fburl.com/diffusion/ssw9h8lv). Reviewed By: amir-shalem Differential Revision: D17470379 fbshipit-source-id: 8fc2d95505971a52af2399a9fbb60b63f27f0ec2

…ent #2 Summary: We need to migrate to HostComponent instead of the exported type from codegenNativeComponent which is the same type Changelog: [Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent Reviewed By: rickhanlonii Differential Revision: D17563307 fbshipit-source-id: 01c8fea8c67b33bed42ae28ffb8c132be87b9a7a

Summary: This implements proposal #2 in our State architecture doc: https://fb.quip.com/bm2EAVwL7jQ5 Problem description: see the text in the comment of TreeStateReconciliation.h Solution: see also comments in TreeStateReconciliation.h. Changelog: [internal] Reviewed By: mdvacca Differential Revision: D19617329 fbshipit-source-id: 845fb5fe27f2591be433b6d77799707b3516fb1a

Summary: While in theory we should never delete views before removing them from the hierarchy, there are some exceptions: (1) Some mysterious cases that don't seem like bugs, but where the child still seems to keep a reference to the parent: (2) When deleting views as part of stopSurface. On #1: in the past we had issues when we assumed that ViewManager.getChildCount() would return an accurate count. Sometimes it's just... wrong. Here, I've found at least one case where a View still has a parent after it's removed from the View hierarchy. I assume this is undocumented Android behavior or an Android bug, but either way, there's nothing I can do about it. On #2: there are valid cases where we want to delete a View without explicitly removing it from the View hierarchy (it will eventually be removed from the hierarchy when the Root view is unmounted, but it may still be "in" a View hierarchy when it's deleted). Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D22321374 fbshipit-source-id: 9667bbe778c418f0216550638dc26ca48a58e5fa

Summary: Previous iteraton of this diff that was reverted is D30678341 (facebook@8009459). With the power of selects, we can move the base AppleTVOS flags into the regular base Apple flags. While I'm here, drop the third `p` in `get_application_apppletvos_flags()` as it's driving me insane. Note - This puts get_visibility_option() on all Apple builds. I believe this is the right thing to do as everything except macOS static libraries already do it, and it shouldn't affect binaries. Changelog: [Internal] Reviewed By: aniketmathur Differential Revision: D30868627 fbshipit-source-id: 86441ff40db15dd7cb3ac800d248ce1e074c2773

…ake #2) Differential Revision: D30868627 (facebook@abd0f38) Original commit changeset: 86441ff40db1 fbshipit-source-id: eb040f8174f8f0f05943dcd5ae1e2077318810ff

Summary: In D30104853 (facebook@e35a963), we added fix to the issue where touches on the child view that is outside of its parent view's boundary are not registered. The only exception to that is if the parent view has overflow style `overflow: hidden`. In that case, touches happen outside of the parent view should be ignored. {F686521911} That fix works, but it increases the complexity for the DFS algorithm used to find the touch target in two ways: 1. Before we only traverse views that contain the touch event point. If the touch event point is outside of the view, we won't step in and traverse that part of the tree. This is actually what caused the initial problem. The fix removed that boundary check (where `isTransformedTouchPointInView` used to do) and push it later. This increases the number of tree traversal a lot. 2. The check for `overflow: hidden` is happened after we find a potential target view, which means we've spent time to find the target view before we decide if the target view is even a candidate. This diff aims to update for the #2 item above. Since we are checking the style of the parent view, not the target view, it's not necessary to check that after we find the target view. We could check the parent view and if it has `overflow: hidden` on it, any pointer event that are not in the boundary can be ignored already. Changelog: [Internal][Android] Reviewed By: mdvacca, ShikaSD Differential Revision: D33079157 fbshipit-source-id: c79c2b38b8affb9ea0fd25b5e880b22466ab7ed9

Summary: VirtualizedList would more gracefully handle out of range cells than VirtualizedList_EXPERIMENTAL, which treats it as an invariant violation. D39244112 (facebook@7aa203b) attempted to fix an issue where recalculation of cells around viewport can include out of range cells, but it is still showing up later. This change adds a bounds check to the remaining branch we control, and an assertion that `computeWindowedRenderLimits` is not returing something out of range to discover if that is the cause. Reviewed By: yungsters Differential Revision: D39267445 fbshipit-source-id: 64c99da28b5b01ef61784079b586e355f73764a1

Summary: Pull Request resolved: facebook#41466 ## Context In open source, all apps use the same turbomodulemanager delegate (i.e: the default delegate). This diff introduces the buck infra that makes the oss default delegate work for meta apps. Concretely, we are going to make React Native use the same delegate for **all** Meta apps. Each Meta app will: 1. At build time, generate a unique TMProvider map 2. At app init time, initialize the default delegate with the TMProvider map. ## Implementation **Step #1:** At build time, generate a unique TMProvider map **Insight:** Buck genrules can accept, as input, the output of a buck query. So, here's how we get this done: 1. Buck query (i.e: input to Genrule): Given the app's deps, query all the schemas in the app. 2. Genrule: Read the schemas to generate the TMProvider map. The TMProvider map will also contain **all** the app's C++ module codegen. Concretely: 1. This diff introduces a macro: rn_codegen_appmodules(deps). 2. rn_codegen_appmodules(deps) generates appmodules.so, which contains the TMProvider map. **Step #2:** At app init time, initialize the default delegate with the TMProvider map. This is how we'll initialize the DefaultTurboModuleManagerDelegate: 1. DefaultTurboModuleManagerDelegate will load appmodules.so during init. 2. When loaded, appmodules.so will assign the code-generated TMProvider map to DefaultTurboModuleManagerDelegate. ## Impact This should allow us to: 1. Get one step closer to getting rid of the `js1 build turbomodule-manager-delegates --target <app>` script 3. Remove the TurboModuleManagerDelegate from React Native's public API. (Because we use one delegate for all React Native apps in Meta and OSS) Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D50988397 fbshipit-source-id: 0ca5dec14e2dae89ec97f5d39a182c7937c5c7bf

Offload animated

6a01bfb

skevy closed this Feb 8, 2016

ide deleted the offload_animated branch August 8, 2016 21:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Offload animated #2

Offload animated #2

brentvatne commented Feb 7, 2016

skevy commented Feb 8, 2016

Offload animated #2

Offload animated #2

Conversation

brentvatne commented Feb 7, 2016

skevy commented Feb 8, 2016