Permalink
Switch branches/tags
Commits on Oct 16, 2018
  1. Fabric: Making EventEmitter reenableable

    shergin authored and facebook-github-bot committed Oct 16, 2018
    Summary:
    The first implementation of EventEmitter's enable/disable feature didn't not provide a way to enable an object after it was disabled.
    Apparently, we need this functionality due that fact that all nodes of the same family share same event emitter.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10395849
    
    fbshipit-source-id: 0eba54f0bb7ded35d64afb6559e6e27208c2b577
  2. Fabric: Proxying `LayoutConstraints::direction` down to RootNode's st…

    shergin authored and facebook-github-bot committed Oct 16, 2018
    …yles
    
    Summary:
    Trivial.
    We have to proxy layout directions as well as min and max sizes to RootNode's Props to properly communicate the constrains to Yoga.
    
    Reviewed By: sahrens
    
    Differential Revision: D10387798
    
    fbshipit-source-id: a02ec0a20b3ef28f6230738e5b3a4a2b0b8e0961
  3. Fabric: Fixed `accessibilityLabel` implementation in RCTParagraphComp…

    shergin authored and facebook-github-bot committed Oct 16, 2018
    …onentView
    
    Summary: The code fragment `super.accessibilityLabel` always meant "use stored value which came from Props". But after we override the implementation of this getter in the base class, this starts working differently (wrong). This change basically reverts that to original intent.
    
    Reviewed By: sahrens
    
    Differential Revision: D10350597
    
    fbshipit-source-id: 913951eb08c4ede76fc0e9be76b48d86599bcc62
  4. Fabric: Treating empty accessibilityLabel as nil

    shergin authored and facebook-github-bot committed Oct 16, 2018
    Summary: Empty string in AccessibilityProps basically means same as `nil` in iOS Accessibility API.
    
    Reviewed By: sahrens
    
    Differential Revision: D10350596
    
    fbshipit-source-id: fad9cdc914388c72e1b8261b27f14cbfa9a037db
  5. Fabric: TextAttributes::defaultTextAttributes()

    shergin authored and facebook-github-bot committed Oct 16, 2018
    Summary: An `AttributedString` object generated by a cross-platform layer of React Native must have already resolved text styles to make the actual resulting text identical across platforms. To do so we have to have a unified default.
    
    Reviewed By: sahrens
    
    Differential Revision: D10287725
    
    fbshipit-source-id: e8c62b33496be34146182baccd0009d3624a7fe5
  6. Fabric: Defined constants for white, black and clear colors

    shergin authored and facebook-github-bot committed Oct 16, 2018
    Summary: This might be useful to specify some default props.
    
    Reviewed By: sahrens
    
    Differential Revision: D10284657
    
    fbshipit-source-id: b6fbdc6bab75697af67bdbb5d06eb3309500ab8c
  7. Fabric: Support for a bunch of accessiblity props in View

    shergin authored and facebook-github-bot committed Oct 16, 2018
    Summary: We didn't have support for them... and now we have it.
    
    Reviewed By: sahrens
    
    Differential Revision: D10280430
    
    fbshipit-source-id: 7275d4617ed3994366f673a17c24b823293d7092
Commits on Oct 13, 2018
  1. Fabric: Custom border rendering on a separate CALayer

    shergin authored and facebook-github-bot committed Oct 13, 2018
    Summary:
    This diff fixes previously broken custom border rendering.
    We need a dedicated CALayer for border bitmap in order to fully support all UIView capabilities in case if some subclass uses that. Otherwise, any call of `drawRect:`  method can override any content which is stored inside `contents` property of CALayer.
    Q&A:
    How does it work in current RN? - It does not. All `drawRect:` methods in RCTView subclasses are dysfunctional.
    How does text view work in current RN? - RCTTextView does not inherit RCTView, so it does not have this problem.
    How does text view support custom borders in current RN then? - It does not.
    
    Reviewed By: PeteTheHeat
    
    Differential Revision: D10228805
    
    fbshipit-source-id: 22bc31f41ab1914a97f3a5981cd1b24ebca725cd
Commits on Oct 9, 2018
  1. Fabric: Proper parsing of Accessibility Props

    shergin authored and facebook-github-bot committed Oct 9, 2018
    Summary: Previsouly, we basically didn't support Accessibility at all.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10250635
    
    fbshipit-source-id: d33eed8f56374f57310654653f41c312cb5942e6
  2. Fabric: Enabling clang-format for the rest of Fabric

    shergin authored and facebook-github-bot committed Oct 9, 2018
    Summary: This is the second and the final part of adopting clang-format.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10229624
    
    fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
  3. Fabric: Fixed possible race condition in `ShadowTree::complete`

    shergin authored and facebook-github-bot committed Oct 9, 2018
    Summary: Quite obviously, having a `complete` method which accepts only `newRootShadowNode` was a baaad idea. When we `complete` or `commit` we always have to have two nodes (before and after). And only after layout and right before swapping (and acquiring the mutex) we have to verify that *current* root node is still the same as it was when we initialized the transaction (if not, we have to abort).
    
    Reviewed By: mdvacca
    
    Differential Revision: D10201902
    
    fbshipit-source-id: 15adc78c5d31d6fd39fd7fc6e53203a5539717a8
  4. Fabric: Passing size constraints as part of starting Surface

    shergin authored and facebook-github-bot committed Oct 9, 2018
    Summary:
    Size constraints are essential part of the running Surface, decoupling them from starting process means that we will have to perform additional commit later.
    This and previous couple diffs fix a problem with initial zero size of the surface and following visible "jumpy" relayout.
    
    Reviewed By: sahrens
    
    Differential Revision: D10174280
    
    fbshipit-source-id: 0ec48692cb814fd46cc3a1d044c5eb8ab9ecb031
  5. Fabric: `ShadowTree::synchronize` and reliable `constraintLayout`

    shergin authored and facebook-github-bot committed Oct 9, 2018
    Summary:
    New `ShadowTree::synchronize` method allows to perform operations on ShadowTree without a risk of an unsuccessful commit. To make it happen, the `commitMutex_` is now recursive and `synchronize` acquires it before calling the callback.
    Using that we finally can implement reliable `constraintLayout`.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10174281
    
    fbshipit-source-id: 9864ebb5343d40e2da205272a834710f0ab730db
  6. Fabric: `constraintLayout` is now return boolean

    shergin authored and facebook-github-bot committed Oct 9, 2018
    Summary:
    Setting the right expectations: setting layout constraints might fail. Nothing really changed.
    Implementing a reliable `constraintLayout` which locks instead of returning immediately requires some additional work and new/additional API.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10159457
    
    fbshipit-source-id: bb23c7de105629ef086ae0b04667ff32c6ffb81d
  7. Fabric: Proper defaults for ScrollView's alwaysBounce*

    shergin authored and facebook-github-bot committed Oct 9, 2018
    Summary: That's actually proper defaults. That fixes problems with horizontally bouncing ScrollView.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10159458
    
    fbshipit-source-id: b2b6df911b0a23f5e13539caeb48e51cdbc56528
  8. Fabric: Improved thread-safety in ShadowTree

    shergin authored and facebook-github-bot committed Oct 9, 2018
    Summary: With new `ShadowTree::getRootShadowNode()` method all access to rootShadowNode_ is protected by commit mutex.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10159456
    
    fbshipit-source-id: 0bc8676ca2564a8ef95d60e912356e99d9f172c1
Commits on Oct 8, 2018
  1. Fabric: Calling `UIManager`'s `uninstall` function asynchonously

    shergin authored and facebook-github-bot committed Oct 8, 2018
    Summary:
    Calling `uninstall` synchnously was a bad idea. Unfortunatelly, even if it illuminate possible race condition during uninstallation, sometimes it deadlock.
    It's not clear for now how to solve both problems without introducting another layer of indirection between UIManager and JSI.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10081500
    
    fbshipit-source-id: 90d8120603929a8219a3e606d8b3527e297b13ce
  2. Fabric: Proper failCallback handling in EventBeatBasedExecutor

    shergin authored and facebook-github-bot committed Oct 8, 2018
    Summary: That's why we need the previous three diffs. Synchonous executor deadlocks if the beat is missing.
    
    Reviewed By: sahrens
    
    Differential Revision: D10081501
    
    fbshipit-source-id: 9986d0a1844e642048b6f37a1fcb5f623a267663
  3. Fabric: `failCallback` implementation for MessageQueueEventBeat

    shergin authored and facebook-github-bot committed Oct 8, 2018
    Summary: See comments in the code.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10081502
    
    fbshipit-source-id: b55bf019346a44c4b2980c70f547f53e4994e968
  4. Fabric: Introducting EventBeat::setFailCallback

    shergin authored and facebook-github-bot committed Oct 8, 2018
    Summary: In some cases we have to have a way to notify a EventBeat consumer that the beat cannot be (and will not be) delivered, so we introducing special API for that.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10081503
    
    fbshipit-source-id: 4c5a392d32572f426e3744bdba797efcd29b8cb4
Commits on Oct 5, 2018
  1. Fabric: Enabling clang-format for half of Fabric modules

    shergin authored and facebook-github-bot committed Oct 5, 2018
    Summary:
    All code styles are terribly ugly. We have the only choise - choise something and embrace it.
    This particular code style was borrowed from a neibour Fabric-friendly project because it follows established Facebook guides and respects client-side traditions.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10218598
    
    fbshipit-source-id: 8c4cf6713c07768566dadef479191661c79988f0
Commits on Oct 1, 2018
  1. Fabric: Enabling view hierarchy flattening (for <View> component only…

    shergin authored and facebook-github-bot committed Oct 1, 2018
    … for now)
    
    Summary: This change implements `onLayoutOnly` for regular bare <View> component (*not* for its descendants!) After this view flattening is actually starting working for all platforms.
    
    Reviewed By: mdvacca
    
    Differential Revision: D9511001
    
    fbshipit-source-id: 3562dd1b7570a064150f100cc2e1bc4220b81290
Commits on Sep 28, 2018
  1. Fabric: Fixed a bug in LayoutMetrics::operator==

    shergin authored and facebook-github-bot committed Sep 28, 2018
    Summary: Trivial. We missed `pointScaleFactor`.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10112051
    
    fbshipit-source-id: 980b8c310fbb3701008765509dce5b6e61852c0e
  2. Fabric: Using YGNodeLayoutGet* family functions to access Yoga layout

    shergin authored and facebook-github-bot committed Sep 28, 2018
    Summary:
    ... instead of using direction access to `ygNode.getLayout()` object.
    Suddenly, YGLayout object that YGNode exposes contains unresolved/directional-unaware styles. To get resolved directional-aware styles we have to use functions from Yoga.h.
    I am not happy with this solution, I will try to implement something like `ygNode.getResolvedLayout()` and use that instead.
    
    This change fixes strange missing horizontal padding around some views.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10112049
    
    fbshipit-source-id: 4b6ef39d8dd34e78a4592962e8af4eeaa5028768
  3. Fabric: Debug Pretty-printing is now debug only feature

    shergin authored and facebook-github-bot committed Sep 28, 2018
    Summary: That should save us some app size kilobytes.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10081499
    
    fbshipit-source-id: 2b950768c609b412f9be332c22b6b1e96657e5ea
Commits on Sep 26, 2018
  1. Fabric: Free image bitmap data during RCTImageComponentView recycling

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary: Trivial. `imageLocalData` retains a network request, observers and actual bitmaps.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10054430
    
    fbshipit-source-id: 9bea11677b73e9e7ce7bc50bd14ec5515dac60de
  2. Fabric: Fixed crash caused by incorrect bridge transfer annotation

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary:
    Don't ask.
    Really, all those descriptions from official docs like below are useless:
     * `__bridge_transfer` Moves a Core Foundation pointer to Objective-C with transfer of the ownership to ARC.
     * `__bridge` Transfers a pointer between Objective-C and Core Foundation with no transfer of ownership
    
    All that is totally confusing and useless. At the end of the day, we only have to think about which additional `CFRetain` and `CFRelease` ARC will add or will not add for our pointers.
    So, following official docs recommendation, we would like to add `__bridge_transfer` because of course, we do want to ARC managing the variable after we introduced it to ARC here. But we also want to have shared ownership of this. That's the key. If we use `__bridge_transfer` ARC will assume that this variable already retained once (because it exists) and will call CFRelease at the end of the scope. Right before that when we pass this variable down to call stack ARC will retain and then manage the variable according to the rest of the code. But still, from this point, we will have zero-balanced reference counter; the owning by `shared_ptr` bump is already compensated with `CFRelease` at the end of the scope. As soon as the rest of the code release the object, it will be incorrectly deallocated.
    
    So, instead of using `__bridge_transfer` we have to use `__bridge`. That will indicate that *in this block* ARC does not manage the reference counter of the variable (which is kinda true because having `shared_ptr` inside the block already retains that) and will not add `CFRelease` at the end of the block.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10054241
    
    fbshipit-source-id: 6e82c5270fe5d53f1ed68e167b94f70dc4367a9f
  3. Fabric: Fixed missing text on some views with borders

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary: Apparently, after updating CALayer props we have to request redrowing on top of it manually.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10053340
    
    fbshipit-source-id: f87311399bab809c9e13a3076f526bbe3f7f3fb4
  4. Fabric: Safer UIManager deallocation and uninstallation

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary: We have to uninstall UIManager synchronously to avoid a race condition when JS is capable to call already deallocated UIManager.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10033406
    
    fbshipit-source-id: 194d1ae2dd5ab09b036b1c165de289ada8e66014
  5. Fabric: RCTSurfacePresenter & thread-safety

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary:
    Instead of wrapping all public methods into The controller you requested could not be found. blocks/mutexes, RCTSurfacePresenter utilizes a different thread-safety pattern where all instance variable are granularly thread-safe.
    The names of all internal methods were prefixed by '_'.
    
    Reviewed By: mdvacca
    
    Differential Revision: D10033407
    
    fbshipit-source-id: 97fd2879c879dd9ef8d9ece24e25af00f749a871
  6. Fabric: Start/stop Surface calls were moved down to C++ layer

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary:
    There is no need to make JS calls to start or stop React Native apps; Scheduler does it automatically. Yay!
    
    With this change (because we have to change Scheduler API) we are starting slow process migrating away from using term `reactRootTag` when we refer to running a ReactNative app (aka Surface). We will use `surfaceId` instead. We plan to slowly and gracefully retire `reactTag` term entity replacing it with several appropriate entities specific for particular usage, e.g. `viewId` (some id which makes sense for mounting), `surfaceId`, `nodeId` (unique id representing nodes which were cloned from the original one), or `eventTarget`.
    
    Reviewed By: mdvacca
    
    Differential Revision: D9999336
    
    fbshipit-source-id: bbc7303c195b070b8c235c9ca35546d1dc693e98
  7. Fabric: Using EventBeatBasedExecutor to ensure threading during insta…

    shergin authored and facebook-github-bot committed Sep 26, 2018
    …lling UIManager
    
    Summary: This is the last step before making JSIUIManagerInstaller a direct dependency of UIManager (and making UIManager installation process completely seamless/platform-agnostic).
    
    Reviewed By: mdvacca
    
    Differential Revision: D9995781
    
    fbshipit-source-id: 6f8c7177495b01ebaac1dbe330f49dce2e2a552c
  8. Fabric: Introducing EventBeatBasedExecutor

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary:
    EventBeatBasedExecutor is an executor derived from EventBeat and using EventBeat to ensure proper threading.
    Why do we need yet another executor? Because otherwise, we have to make it platform specific-dependency that each platform-specific implementation has to implement and provide. We already have all that we need in already provided EventBeat, so we can just convert that into simple executor in a platform-agnostic way.
    
    Reviewed By: mdvacca
    
    Differential Revision: D9995783
    
    fbshipit-source-id: f8aa72a9744e50ebecbea9ad0e2546f41f5358f2
  9. Fabric: Lazy ContextContainer creation in RCTSurfacePresenter

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary: Besides that it's more simple and straight-forward now, we need that to always instantiate Scheduler with a context full of fresh valid objects derived from the new instance of the bridge.
    
    Reviewed By: mdvacca
    
    Differential Revision: D9995780
    
    fbshipit-source-id: 534a314152d93562b08dd7857962f174b0d06886
  10. Fabric: RCTSurface's start and stop methods

    shergin authored and facebook-github-bot committed Sep 26, 2018
    Summary:
    The original design of RCTSurface implied that the Surface starts on initialization and stops on deallocation. Recently I realized that this not sufficient API in some cases when the application uses ARC with autorelease pools (that can postpone object deallocations, which is highly undesirable).
    And that's simply handy to have those methods sometimes.
    
    Reviewed By: mdvacca
    
    Differential Revision: D9982356
    
    fbshipit-source-id: baa3bd24804d3708606ebd00b8795f2d5c9d4de9