Commit Graph

35 Commits

Author SHA1 Message Date
Alex Dvornikov d1fb892715 Clean up after recent RCT_EXPORT_BLOCKING_SYNCHRONOUS_METHOD changes
Reviewed By: javache

Differential Revision: D4969636

fbshipit-source-id: 49785dcf02e6544a313d82ccb26839ac2302c7d9
2017-04-28 05:35:41 -07:00
Alex Dvornikov db0c22192c Added support for synchronous methods in native modules on iOS
Reviewed By: javache

Differential Revision: D4947556

fbshipit-source-id: 0ef73dc5d741201e59fef1fc048809afc65c75b5
2017-04-27 12:03:30 -07:00
Mehdi Mulani 0a06250d24 Add build-time check that module methods are exported correctly
Summary:
This prevents someone from only putting `RCT_EXPORT_METHOD(...)` around some of the arguments to a method and generally causing confusion. Yes, before this diff it would still compile correctly if you did something like:

```
RCT_EXPORT_METHOD(lol:(NSNumber *)lol)
blah:(id)blah
{
  NSLog(@"%@ %@", lol, blah);
}
```

Reviewed By: fkgozali

Differential Revision: D4660019

fbshipit-source-id: 1829a47e5c8d5e8ce93edca2ac7efd7e2bfdf840
2017-03-07 10:45:36 -08:00
Pieter De Baets e1577df1fd Move all header imports to "<React/..>"
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.

Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".

Reviewed By: mmmulani

Differential Revision: D4213120

fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
2016-11-23 07:58:39 -08:00
Dave Miller 0c5f279c9d Standardize Error objects for Promises
Summary:
public

Promises are coming.  And as part of it, we are standardizing the error objects that will be returned.  This puts the code in place on the Android side to always send the proper error format.

It will be an error object like this
  {
    code : "E_SOME_ERROR_CODE_DEFINED_BY_MODULE", // Meant to be machine parseable
    message : "Human readable message",
    nativeError : {} // Some representation of the underlying error (Exception or NSError) , still figuring out exactly, but hopefully something with stack info
  }

Reviewed By: nicklockwood

Differential Revision: D2840128

fb-gh-sync-id: 174d620e2beb53e1fc14161a10fd0479218d98a6
2016-01-19 12:20:37 -08:00
Nick Lockwood 64edddadcc Fixed race condition in RCTModuleData.methodQueue
Summary:
public
The implementation of the `methodQueue` lazy initializer in `RCTModuleData` could result in the queue being set twice, because calling `methodQueue` for a module that hasn't been instantiated would call `RCTModuleData.instance` to create the module, which itself calls `methodQueue`.

It's not clear if this was causing a bug, but it may be related to an occasional bug where the `RCTViewManager.methodQueue` returns nil.

Reviewed By: majak

Differential Revision: D2783320

fb-gh-sync-id: 9194da0fd7392f63825da1f5c450363dd300b635
2016-01-04 06:24:28 -08:00
Justin Spahr-Summers c25c98c00c Flush UI blocks as soon as they're accumulated
Summary:
public

Currently, we wait to invoke `-flushUIBlocks` until the JavaScript batch to native has completed. This means we may be waiting an unnecessarily long time to perform view hierarchy changes and prop changes.

By instead invoking this after each chunk of enqueued UI blocks, we can perform some updates more eagerly, increasing our utilization of the main thread while splitting up the amount of time we spend running upon it.

This shouldn't affect layout, which is still tied to `-batchDidComplete`, so any visual inconsistencies should be limited to prop changes, which seems acceptable for the dramatic improvement in performance.

Reviewed By: javache

Differential Revision: D2658552

fb-gh-sync-id: 6d4560e21d7da1b02d2f30d1860d60735f11c4b5
2015-12-02 06:03:27 -08:00
Nick Lockwood 060664fd3d Refactored module access to allow for lazy loading
Summary: public

The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed.

This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead.

The rules are now as follows:

* Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created
* Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but  `constantsToExport:` will still be called on the main thread.
* All other modules will be initialized lazily when a method is first called on them.

These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily.

I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results:

Out of the 65 modules included in UIExplorer:

* 16 are initialized on the main thread when the bridge is created
* A further 8 are initialized when the config is exported to JS
* The remaining 41 will be initialized lazily on-demand

Reviewed By: jspahrsummers

Differential Revision: D2677695

fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
2015-11-25 04:49:45 -08:00
Nick Lockwood fa0b45c58b Replaced RCTSparseArray with NSDictionary
Reviewed By: jspahrsummers

Differential Revision: D2651920

fb-gh-sync-id: 953e2ea33abfc7a3a553da95b13e9ab2bccc5a1c
2015-11-14 10:28:28 -08:00
Nick Lockwood c5b990f65f Added lightweight generic annotations
Summary: public

Added lightweight genarics annotations to make the code more readable and help the compiler catch bugs.

Fixed some type bugs and improved bridge validation in a few places.

Reviewed By: javache

Differential Revision: D2600189

fb-gh-sync-id: f81e22f2cdc107bf8d0b15deec6d5b83aacc5b56
2015-11-03 14:49:30 -08:00
Marc Horowitz a87ba4ab4c Prepare the bridge for C++
Reviewed By: @nicklockwood

Differential Revision: D2432291
2015-09-18 15:04:28 -07:00
Pieter De Baets 371aeceb72 Small perf improvement to RCTPerfStats and RCTBridgeModuleNameForClass 2015-08-25 04:48:39 -08:00
Nick Lockwood deba13f698 Refactor RCTUIManager
Summary:
Moved the view creation & property binding logic out of RCTUIManager into a separate RCTComponentData class - this follows the pattern used with the bridge.

I've also updated the property  binding to use pre-allocated blocks for setting the values, which is more efficient than the previous system that re-contructed the selectors each time it was called. This should improve view update performance significantly.
2015-08-06 15:49:35 -08:00
Nick Lockwood 9229eadff0 Fixed ART Text
Summary:
ART text was crashing due to a bug in the release logic.
2015-07-10 08:31:21 -08:00
Alex Akers 3c541ca540 [React Native] Update native error callback handling
Summary:
This introduces a new `RCTResponseErrorBlock` block type that allows a bridge module writer to call it with an `NSError` instance rather than a dictionary.
2015-07-07 08:54:05 -08:00
Tadeu Zagallo 336e18d20b [ReactNative] Move module info from bridge to RCTModuleData
Summary:
@public

The info about bridge modules (such as id, name, queue, methods...) was spread
across arrays & dictionaries on the bridge, move it into a specific class.

It also removes a lot of information that was statically cached, and now have
the same lifecycle of the bridge.

Also moved RCTModuleMethod, RCTFrameUpdate and RCTBatchedBridge into it's own
files, for organization sake.

NOTE: This diff seems huge, but most of it was just moving code :)

Test Plan:
Tested UIExplorer & UIExplorer tests, Catalyst, MAdMan and Groups. Everything
looks fine.
2015-06-24 17:42:12 -08:00
Nick Lockwood c8c254ce13 Changed methodQueue to a property 2015-06-19 04:20:39 -08:00
Tadeu Zagallo d270dca210 [ReactNative] Avoid method clashing on categories
Summary:
@public

Include `js_name` and `__LINE__` on exported methods' generated names + use the
method implementation instead of `objc_msgSend` on the bridge, so it still works
in case of clashing.

Test Plan: Everything still working, otherwise it'd crash at startup.
2015-06-15 06:13:45 -08:00
Tadeu Zagallo e9095b2f42 [ReactNative] Remove module info from the data section + allow external modules
Summary:
@public

The information we required about the exported methods were previously stored
on the binary's DATA section, which didn't allow to access methods on different
static libraries, or in any dynamic library at all. Instead of fetching information
from all the DATA segments, this diff changes the macro in order to create a
new method, that returns the required information about the original method. The
module itself is registered at load time, and on the bridge initialization all
the auto-generated methods are called to gather the methods' information.

Test Plan:
UIExplorer previously had a dependency on `RCTTest`, because it had a `TestModule`
that had to be on the same library. `RCTTest` is now a dependency of
`UIExplorerIntegrationTests`. So the tests themselves running should test it.
2015-06-10 03:42:10 -08:00
James Ide 90439cec26 [Bridge] Add support for JS async functions to RCT_EXPORT_METHOD
Summary:
Adds support for JS async methods and helps guide people writing native modules w.r.t. the callbacks. With this diff, on the native side you write:

```objc
RCT_EXPORT_METHOD(getValueAsync:(NSString *)key
                       resolver:(RCTPromiseResolver)resolve
                       rejecter:(RCTPromiseRejecter)reject)
{
  NSError *error = nil;
  id value = [_nativeDataStore valueForKey:key error:&error];

  // "resolve" and "reject" are automatically defined blocks that take
  // any object (nil is OK) and an NSError, respectively
  if (!error) {
    resolve(value);
  } else {
    reject(error);
  }
}
```

On the JS side, you can write:

```js
var {DemoDataStore} = require('react-native').NativeModules;
DemoDataStore.getValueAsync('sample-key').then((value) => {
  console.log('Got:', value);
}, (error) => {
  console.error(error);
  // "error" is an Error object whose message is the NSError's description.
  // The NSError's code and domain are also set, and the native trace i
Closes https://github.com/facebook/react-native/pull/1232
Github Author: James Ide <ide@jameside.com>

Test Plan: Imported from GitHub, without a `Test Plan:` line.
2015-06-09 14:25:31 -08:00
Nick Lockwood 45d8fb0ef6 Removed deprecated RCT_EXPORT + code paths 2015-06-05 09:58:25 -08:00
Chace Liang 1ed2542b46 Revert "[Bridge] Add support for JS async functions to RCT_EXPORT_METHOD" 2015-06-01 20:26:37 -08:00
James Ide d548c85da6 [Bridge] Add support for JS async functions to RCT_EXPORT_METHOD
Summary:
Adds support for JS async methods and helps guide people writing native modules w.r.t. the callbacks. With this diff, on the native side you write:

```objc
RCT_EXPORT_METHOD(getValueAsync:(NSString *)key
                       resolver:(RCTPromiseResolver)resolve
                       rejecter:(RCTPromiseRejecter)reject)
{
  NSError *error = nil;
  id value = [_nativeDataStore valueForKey:key error:&error];

  // "resolve" and "reject" are automatically defined blocks that take
  // any object (nil is OK) and an NSError, respectively
  if (!error) {
    resolve(value);
  } else {
    reject(error);
  }
}
```

On the JS side, you can write:

```js
var {DemoDataStore} = require('react-native').NativeModules;
DemoDataStore.getValueAsync('sample-key').then((value) => {
  console.log('Got:', value);
}, (error) => {
  console.error(error);
  // "error" is an Error object whose message is the NSError's description.
  // The NSError's code and domain are also set, and the native trace i
Closes https://github.com/facebook/react-native/pull/1232
Github Author: James Ide <ide@jameside.com>

Test Plan: Imported from GitHub, without a `Test Plan:` line.
2015-06-01 10:50:06 -08:00
Tadeu Zagallo dd6bce78e1 [ReactNative] Allow bridge modules to run on the JavaScript thread 2015-04-25 19:29:00 -08:00
Robert Payne b72acc2313 Add support for exporting Swift modules
Summary:
External modules are any Objective-C class in which the implementation is private. This currently will be most useful for Swift classes but also has potential to allow exposing methods on 3rd party libraries to the bridge.
Closes https://github.com/facebook/react-native/pull/982
Github Author: Robert Payne <robertpayne@me.com>

Test Plan: Imported from GitHub, without a `Test Plan:` line.
2015-04-23 09:20:18 -08:00
Nick Lockwood 5ce9fa4dda Changed default method queue to a background queue. 2015-04-20 12:02:04 -08:00
Nick Lockwood ead0f2e020 Implemented thread control for exported methods 2015-04-18 11:13:39 -08:00
James Ide e193a13ef7 [Bridge] `RCT_REMAP_METHOD(js_name, selector)`
Summary:
cc @a2 @nicklockwood

This diff introduces a new macro called `RCT_EXPORT_NAMED_METHOD`, which is like `RCT_EXPORT_METHOD` but lets you choose the name of the method in JS. This diff is backwards compatible with the `RCT_EXPORT_METHOD` and legacy `RCT_EXPORT` macros.

The entries in the data segment now contain `__func__`, the Obj-C selector signature, and the JS name. If the JS name is `NULL`, we take the legacy `RCT_EXPORT` code path. If the JS name is an empty string, we use the Obj-C selector's name up to the first colon (that is, the behavior of `RCT_EXPORT_METHOD`).

Since there are three values in each data segment entry, the macros now specify 1-byte alignment. Without the byte alignment, the compiler defaults to 2-byte alignment meaning that each entry takes up 4 bytes instead of 3. The extra byte isn't a concern but being explicit about the alignment should reduce compiler surprises.
Closes https://github.com/facebook/react-native/pull/802
Github Author: James Ide <ide@jameside.com>

Test Plan: Imported from GitHub, without a `Test Plan:` line.
2015-04-14 12:55:19 -08:00
Nick Lockwood 26fd24dc50 Cleanup 2015-04-11 14:19:49 -08:00
Tadeu Zagallo f5f80da80c [ReactNative] Remove bridge retaining cycles 2015-04-10 07:20:37 -08:00
Alex Akers 8a57c4e980 [React Native] RCT_EXPORT lvl.2 2015-04-08 08:34:10 -08:00
Nick Lockwood bf4868edda Added non-class-scanning-based approach fror registering js methods 2015-04-08 05:45:20 -08:00
Ben Hiller 220e116dce [fbobjc] revert rFBOBJCdba3daf9a595f452d069f2a74a9a11f251999b2e 2015-04-07 20:44:11 -08:00
Tadeu Zagallo 6854da9b86 [ReactNative] Remove bridge retaining cycles 2015-04-07 19:42:46 -08:00
Tadeu Zagallo 20291a02df [ReactNative] s/ReactKit/React/g 2015-03-26 02:42:24 -08:00