Permalink
Switch branches/tags
Commits on Jun 9, 2016
  1. Fix missing images

    nicklockwood authored and Facebook Github Bot 3 committed Jun 9, 2016
    Summary:
    Under rare and as-yet-to-be determined circumstances, images can sometimes fail to load/download and get "stuck", without producing an error.
    
    Because the `RCTNetworkTask` for these images is stuck in the "in progress" state, they clog up the RCTImageLoader task queue, which has a limit of 4 concurrent in-progress tasks.
    
    This was previously masked by the fact that we automatically cancelled image requests when the RCTImageView moved offscreen, but we no longer do that.
    
    This diff adds logic to detect some types of stuck task and remove them, thereby unblocking the queue. I've also restored the functionality of cancelling downloads for offscreen images (but not unloading the image itself) so that stuck images will be cancelled when you move to another screen, instead of using up space in the queue forever.
    
    Reviewed By: fkgozali
    
    Differential Revision: D3398105
    
    fbshipit-source-id: 75ee40d06a872ae8e1cb57f02f9cad57c459143c
  2. Converted zIndex to integers

    nicklockwood authored and Facebook Github Bot 3 committed Jun 9, 2016
    Summary: Converted the zIndex property on iOS to NSInteger instead of double. This is consistent with the CSS spec, and helps to simplify the Android implementation.
    
    Reviewed By: javache
    
    Differential Revision: D3411491
    
    fbshipit-source-id: 902ebc29aac39a65f7e8707a28607655f9f5052c
Commits on Jun 8, 2016
  1. Fixed ART views

    nicklockwood authored and Facebook Github Bot 0 committed Jun 8, 2016
    Summary: Fixed ART views, which were broken by the zIndex diff
    
    Reviewed By: wwjholmes
    
    Differential Revision: D3403679
    
    fbshipit-source-id: cc3cdccd19c21223ce6bddeda3d914937ecb73b6
Commits on Jun 7, 2016
  1. Fixed unit tests

    nicklockwood authored and Facebook Github Bot 7 committed Jun 7, 2016
    Reviewed By: bestander
    
    Differential Revision: D3399766
    
    fbshipit-source-id: ebc72a9d02ff812eccae13efc1492d2fec3f95c3
  2. Fix unit tests

    nicklockwood authored and Facebook Github Bot 3 committed Jun 7, 2016
    Reviewed By: bestander
    
    Differential Revision: D3398431
    
    fbshipit-source-id: 37561bea78c933673595625530cf083c85c3fbbd
  3. Open sourced KeyboardAvoidingView

    nicklockwood authored and Facebook Github Bot 8 committed Jun 7, 2016
    Summary:
    KeyboardAvoidingView is a component we built internally to solve the common problem of views that need to move out of the way of the virtual keyboard.
    
    KeyboardAvoidingView can automatically adjust either its position or bottom padding based on the position of the keyboard.
    
    Reviewed By: javache
    
    Differential Revision: D3398238
    
    fbshipit-source-id: 493f2d2dec76667996250c011a1c5b7a14f245eb
  4. Implement CSS z-index for iOS

    nicklockwood authored and Facebook Github Bot 8 committed Jun 7, 2016
    Summary:
    This diff implement the CSS z-index for React Native iOS views. We've had numerous pull request for this feature, but they've all attempted to use the `layer.zPosition` property, which is problematic for two reasons:
    
    1. zPosition only affects rendering order, not event processing order. Views with a higher zPosition will appear in front of others in the hierarchy, but won't be the first to receive touch events, and may be blocked by views that are visually behind them.
    2. when using a perspective transform matrix, views with a nonzero zPosition will be rendered in a different position due to parallax, which probably isn't desirable.
    
    See #7825 for further discussion of this problem.
    
    So instead of using `layer.zPosition`, I've implemented this by actually adjusting the order of the subviews within their parent based on the zIndex. This can't be done on the JS side because it would affect layout, which is order-dependent, so I'm doing it inside the view itself.
    
    It works as follows:
    
    1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
    2. `didUpdateReactSubviews` is called, which in turn calls `sortedSubviews` (which lazily generates a sorted array of  `reactSubviews` by zIndex) and inserts the result into the view.
    3.  If a subview is added or removed, or the zIndex of any subview is changed, the previous `sortedSubviews` array is cleared and  `didUpdateReactSubviews` is called again.
    
    To demonstrate it working, I've modified the UIExplorer example from #7825
    
    Reviewed By: javache
    
    Differential Revision: D3365717
    
    fbshipit-source-id: b34aa8bfad577bce023f8af5414f9b974aafd8aa
  5. Simplified Image.js

    nicklockwood authored and Facebook Github Bot 2 committed Jun 7, 2016
    Summary:
    Now that we no longer have a separate NetworkImageView implementation, we can remove that code path from Image.js
    
    I've also moved the prefetch method into RCTImageViewManager for consistency with the getImageSize method, which means we no longer need to export the RCTImageLoader module to js.
    
    Reviewed By: javache
    
    Differential Revision: D3398157
    
    fbshipit-source-id: fbbcf90a61549831ad28bad0cb3b50c375aae32c
  6. Refactored subview management

    nicklockwood authored and Facebook Github Bot 7 committed Jun 7, 2016
    Summary:
    This diff refactors the view update process into two stages:
    
    1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
    2. The `didUpdateReactSubviews` method is called, which actually inserts the reactSubviews into the view hierarchy.
    
    This simplifies a lot of the hacks we had for special-case treatment of subviews: In many cases we don't want to actually insert `reactSubviews` into the parentView, and we had a bunch of component-specific solutions for that (typically overriding all of the reactSubviews methods to store views in an array). Now, we can simply override the `didUpdateReactSubviews` method for those views to do nothing, or do something different.
    
    Reviewed By: wwjholmes
    
    Differential Revision: D3396594
    
    fbshipit-source-id: 92fc56fd31db0cfc66aac3d1634a4d4ae3903085
Commits on Jun 6, 2016
  1. Reverted commit D3392214

    nicklockwood authored and Facebook Github Bot 1 committed Jun 6, 2016
    Reviewed By: javache
    
    Differential Revision: D3392214
    
    fbshipit-source-id: 4136c8b0eb160f4b245df2e4b5d67d00efd7b1a7
  2. Refactored subview management

    nicklockwood authored and Facebook Github Bot 4 committed Jun 6, 2016
    Reviewed By: javache
    
    Differential Revision: D3392214
    
    fbshipit-source-id: 6f16841df5cf866dda5ac27dd244e266ec85a86e
  3. Replaced isMainThread checks with a proper test for main queue

    nicklockwood authored and Facebook Github Bot 6 committed Jun 6, 2016
    Summary:
    As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
    
    This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
    
    I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
    
    Reviewed By: javache
    
    Differential Revision: D3384910
    
    fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
  4. Fixed removeClippedSubviews

    nicklockwood authored and Facebook Github Bot 6 committed Jun 6, 2016
    Summary:
    The `removeClippedSubviews` feature works by umounting views from the hierarchy if they move outside the bounds of their parent.
    
    This was previously restricted to clipping views which had `overflow: hidden`, since we cannot efficiently check whether the subviews of a view go outside its bounds, and so clipping a view that has potentially overflowing children becomes an expensive recursive operation.
    
    The problem with this is that `overflow: visible` is the default, and it's not well documented nor easy to tell that `removeClippedSubviews` has been set up correctly (i.e. with all children having `overflow: hidden`).
    
    When I checked, I found that `removeClippedSubviews` was not working on any of the examples in UIExplorer, nor in several of our internal apps, because the views inside the ListView has `overflow: visible`. This was probably caused by an infra change at some point, but I'm not sure how long it's been broken.
    
    It's vanishingly unlikely that anyone would ever deliberately want subviews to overflow their bounds in this scenario, so I've updated the logic to simply ignore the `overflow` property and assume that views should be clipped if you are using the `removeClippedSubviews` property on the parent.
    
    Cons / Breaking changes: in some rare circumstances, a view might get clipped prematurely if its parent is outside the scrollview bounds, but it itself is inside. This doesn't occur in practice in any of our products, and could be worked around with additional wrapper views if it did.
    
    Pros: removeClippedSubviews is now much easier to use, and much more likely to work as intended, so most list-based apps should see a performance improvement.
    
    Reviewed By: javache
    
    Differential Revision: D3385316
    
    fbshipit-source-id: 1c0064a4c21340a971ba80d794062a356ae6cfb3
  5. Fixed bug where layoutSubviews was called continuously for scrollview

    nicklockwood authored and Facebook Github Bot 2 committed Jun 6, 2016
    Summary:
    RCTScrollView was calling `dockClosestSectionHeader` in `reactBridgeDidFinishTransaction`, which triggers a layout update. The reason for this was in case the `stickyHeaderIndexes` property was updated, which would require the headers to be adjusted.
    
    However, doing this in `reactBridgeDidFinishTransaction` had the affect of causing `layoutSubviews` to be called repeatedly every frame even if nothing had changed and the scrollview wasn't moving, which was especially expensive when combined with the `removeClippedSubviews` logic, that loops through every view to calculate if it needs to be clipped.
    
    This fix moves the `dockClosestSectionHeader` call into `didUpdateProps`, and checks that the stickyHeaderIndexes have actually changed before calling it.
    
    Reviewed By: javache
    
    Differential Revision: D3387607
    
    fbshipit-source-id: c71e00c6fac48337a63d7fee7c7c23e016acf24e
Commits on Jun 1, 2016
  1. Removed hard-coded DatePicker width

    nicklockwood authored and Facebook Github Bot 6 committed Jun 1, 2016
    Summary: The DatePicker had a hard-coded width of 320 for no reason I can think of. Removing it allows the DatePicker to naturally scale to fit the width of the container, which is how the regular Picker works already.
    
    Reviewed By: lexs
    
    Differential Revision: D3371355
    
    fbshipit-source-id: e06d31f7275de41bb00226232cf47ad022d25b4d
  2. Fixed "Sending `didSendNetworkData` with no listeners registered" war…

    nicklockwood authored and Facebook Github Bot 1 committed Jun 1, 2016
    …ning
    
    Summary:
    XMLHttpRequest was sending the request before registering any listeners, resulting in a warning from the native event emitter.
    
    Since we weren't seeing widespread problems with XHR missing data, this was probably working OK in practice because the queuing of events meant that the listener would have been registered before the message was actually delivered.
    
    Still, this was working more through luck than design. This diff fixes it by registering the listeners *before* sending the request.
    
    Reviewed By: lexs
    
    Differential Revision: D3371320
    
    fbshipit-source-id: c688d4053a61f856eaacccd0106905edbefcc86a
Commits on May 31, 2016
  1. Reduce boxing overhead of arrays in uiBlockWithLayoutUpdateForRootView

    nicklockwood authored and Facebook Github Bot 3 committed May 31, 2016
    Summary: The view update cycle in UIManager was relying on a bunch of boolean values boxes as NSNumbers in parallel arrays. This diff packs those values into a struct, which is more efficient and easier to maintain.
    
    Reviewed By: javache
    
    Differential Revision: D3365346
    
    fbshipit-source-id: d9cbf2865421f76772c1761b13992d40ec3675f0
Commits on May 27, 2016
  1. Updated Linking and PushNotificationIOS modules to use NativeEventEmi…

    nicklockwood authored and Facebook Github Bot 7 committed May 27, 2016
    …tter
    
    Reviewed By: javache
    
    Differential Revision: D3352819
    
    fbshipit-source-id: d218791a16aba597d2544691ef993711cf00522c
  2. Test perf effect of reverting D3269333

    nicklockwood authored and Facebook Github Bot 8 committed May 27, 2016
    Reviewed By: javache
    
    Differential Revision: D3346235
    
    fbshipit-source-id: 2008f8fb9df5d61da59bb0067b25acd5a71f256f
  3. Reduce boxing overhead of arrays in uiBlockWithLayoutUpdateForRootView

    nicklockwood authored and Facebook Github Bot 0 committed May 27, 2016
    Summary: The view update cycle in UIManager was relying on a bunch of boolean values boxes as NSNumbers in parallel arrays. This diff packs those values into a struct, which is more efficient and easier to maintain.
    
    Reviewed By: javache
    
    Differential Revision: D3253073
    
    fbshipit-source-id: 3e1520c27b88bc1b44ddffcaae3218d7681b2cd2
Commits on May 25, 2016
  1. Fixed image test flakiness by tying decoded image cache to module lif…

    nicklockwood authored and Facebook Github Bot 4 committed May 25, 2016
    …ecycle
    
    Summary: The decoded image cache was previously static, meaning that cached images could persist beyond the lifetime of the module. This resulted in some flakiness in the RCTImageLoaderTests due to the loader returning cached image instanced from previous tests instead of the correct instance.
    
    Reviewed By: bestander
    
    Differential Revision: D3346329
    
    fbshipit-source-id: 375af8894cef1c5b6303c6cdfd7eb57ebcfe3251
  2. Fixed multiline textinput onChange event

    nicklockwood authored and Facebook Github Bot 4 committed May 25, 2016
    Summary: Broken in d973757
    
    Reviewed By: tadeuzagallo
    
    Differential Revision: D3346276
    
    fbshipit-source-id: 0cd67edb38b9f80b0976616059f9c2454cb34448
  3. Update RCTNetworking, RCTNetInfo and RCTLocationManager to use new ev…

    nicklockwood authored and Facebook Github Bot 1 committed May 25, 2016
    …ents system
    
    Summary: Updated networking and geolocation to use the new events system.
    
    Reviewed By: bestander
    
    Differential Revision: D3346129
    
    fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
Commits on May 24, 2016
  1. Update RCTNetworking, RCTNetInfo and RCTLocationManager to use new ev…

    nicklockwood authored and Facebook Github Bot 3 committed May 24, 2016
    …ents system
    
    Summary: Updated networking and geolocation to use the new events system.
    
    Reviewed By: javache
    
    Differential Revision: D3339945
    
    fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
  2. Fixed UIExplorer

    nicklockwood authored and Facebook Github Bot 9 committed May 24, 2016
    Summary: CI_USE_PACKAGER flag was set only for testing, not running.
    
    Reviewed By: nathanajah
    
    Differential Revision: D3334982
    
    fbshipit-source-id: 3f98e697bd144a4ac6d8d7cfabf546bb55de1695
Commits on May 23, 2016
  1. Updated AppState module to use new emitter system

    nicklockwood authored and Facebook Github Bot 3 committed May 23, 2016
    Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
    
    Reviewed By: javache
    
    Differential Revision: D3310488
    
    fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
  2. Fixed tests

    nicklockwood authored and Facebook Github Bot 1 committed May 23, 2016
    Reviewed By: bestander
    
    Differential Revision: D3334669
    
    fbshipit-source-id: ba0ae2ec5ea06c27d40ceed3ca8bf7a9da27dda9
  3. Added small decoded image cache to prevent images flashing when compo…

    nicklockwood authored and Facebook Github Bot 2 committed May 23, 2016
    …nent is reloaded
    
    Summary:
    In RN we cache image data after loading/downloading an image, however the data we store is the compressed image data, and we decode this asynchronously each time it is displayed.
    
    This can lead to a slight flicker when reloading image components because the decoded image is discarded and then re-decoded.
    
    This diff adds a small (5MB) cache for decoded images so that images that are currently on screen shouldn't flicker any more if the component is reloaded.
    
    Reviewed By: bnham
    
    Differential Revision: D3305161
    
    fbshipit-source-id: 9969012f576784dd6f37d9386cbced2df00c3e07
Commits on May 16, 2016
  1. Expose UIManager queue via a static function to prevent race conditions

    nicklockwood authored and Facebook Github Bot 9 committed May 16, 2016
    Summary: Having UI modules access the shadowQueue via UIManager.methodQueue is fragile and leads to race conditions in startup, sometimes resulting in an error where the methodQueue is set twice, or not at all.
    
    Reviewed By: javache
    
    Differential Revision: D3304890
    
    fbshipit-source-id: 7198d28314dbec798877fcaaf17ae017d50157e9
  2. Fixed NativeEventListener deregistration

    nicklockwood authored and Facebook Github Bot 1 committed May 16, 2016
    Summary:
    The `EmitterSubscription.remove()` method was previously calling `this.subscriber.removeSubscription(this)` directly, bypassing the mechanism in `NativeEventEmitter` that keeps track of the number of subscriptions.
    
    This meant that native event modules (subclasses of `RCTEventEmitter`) would keep sending events even after all the listeners had been removed. This wasn't a huge overhead, since these modules are singletons and only send one message over the bridge per event, regardless of the number of listeners, but it's still undesirable.
    
    This fixes the problem by routing the `EmitterSubscription.remove()` method through the `EventEmitter` so that `NativeEventEmitter` can apply the additional native calls.
    
    I've also improved the architecture so that each `NativeEventEmitter` uses its own `EventEmitter`, but they currently all still share the same `EventSubscriptionVendor` so that legacy code which registers events via `RCTDeviceEventEmitter` still works.
    
    Reviewed By: vjeux
    
    Differential Revision: D3292361
    
    fbshipit-source-id: d60e881d50351523d2112473703bea826641cdef
Commits on May 12, 2016
  1. Updated Websocket to use new event system

    nicklockwood authored and Facebook Github Bot 6 committed May 12, 2016
    Reviewed By: javache
    
    Differential Revision: D3292473
    
    fbshipit-source-id: f9a9e0a1b5a12f7fa8b36ebdba88405370f91c54
Commits on May 11, 2016
  1. Added native event emitter

    nicklockwood authored and Facebook Github Bot 0 committed May 11, 2016
    Summary:
    This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/
    
    I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).
    
    Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.
    
    JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:
    
        const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
        RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });
    
    You'd now write:
    
        const Keyboard = require('Keyboard');
        Keyboard.addListener('keyboardWillShow', (event) => { ... });
    
    Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:
    
         this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);
    
    Write:
    
        this.addListenerOn(Keyboard, 'keyboardWillShow', ...);
    
    This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.
    
    As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.
    
    For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.
    
    Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).
    
    Reviewed By: javache
    
    Differential Revision: D3269966
    
    fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
Commits on May 9, 2016
  1. Fixed XHR tests

    nicklockwood authored and Facebook Github Bot 6 committed May 9, 2016
    Summary:
    The XMLHttpRequest jest tests were attempting to call a private method in XMLHttpRequestBase.js (denoted by an _ prefix).
    
    JS doesn't actually have any language-level support for private methods, the use of _ prefix is just a convention. But to prevent casually calling private methods externally, we have a transform that mangles the names of prefixed methods so that that attempting to call them will fail.
    
    Using a double _ bypasses this name-mangling mechanism, while still making it clear that the method is intended to be private.
    
    Reviewed By: javache
    
    Differential Revision: D3276261
    
    fb-gh-sync-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
    fbshipit-source-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
  2. Fixed crash due to inserting a nil object into an array

    nicklockwood authored and Facebook Github Bot 2 committed May 9, 2016
    Summary: Fixed a crash where making a network request with unrecognized/unsupported scheme would crash by attempting to insert a nil RCTNetworkTask into an array.
    
    Reviewed By: javache
    
    Differential Revision: D3275810
    
    fb-gh-sync-id: be208c6bf87d882209901b850dcc25da4ba79a08
    fbshipit-source-id: be208c6bf87d882209901b850dcc25da4ba79a08
Commits on May 4, 2016
  1. Added explicit init to observer modules

    nicklockwood authored and Facebook Github Bot 7 committed May 4, 2016
    Summary:
    Modules which call JS methods directly, or use `sendDeviceEventWithName:`, can trigger effects in JS without ever being referenced from the JS code. This breaks some assumptions in my earlier diff about when modules can be lazily loaded.
    
    Pending a better solution, I've put explicit `init` methods in these modules to ensure they are eagerly initialized (the downside to this is that they'll still be initialized even if they are never used).
    
    Reviewed By: javache
    
    Differential Revision: D3258232
    
    fb-gh-sync-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2
    fbshipit-source-id: f925bc2e5339c1fbfcc244d4613062c5ab848fc2