Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Tue June 9th #1576

Merged
merged 33 commits into from Jun 10, 2015
Merged

Update Tue June 9th #1576

merged 33 commits into from Jun 10, 2015

Conversation

sahrens
Copy link
Contributor

@sahrens sahrens commented Jun 10, 2015

No description provided.

nicklockwood and others added 30 commits June 5, 2015 15:21
Summary:
@public

Previously, our XMLHttpRequest implementation would only update the readyState when the download was fully completed. This diff adds support for receiving incremental data updates as the download happens, which can be monitored by adding the onreadystatechange event handler.

As a performance optimization, incremental data updates are only sent if the onreadystatechanged handler has been set in the JS, otherwise it just sends the whole data block once download is complete, as before.

Test Plan:
* Run the UIExplorer XMLHttpRequest example (in both OSS and Catalyst) to see incremental downloads working.
* Run the Movies app to see regular (non-incremental) downloads in action
* Run any network-based app in Catalyst shell to verify RKDataManager still works
Summary:
@public

Bridge modules were being invalidate on the main thread, what could lead to
racing conditions, move the calls to invalidate on happen to the module's
methodQueue

Test Plan: Run the tests
Summary:
@public

`RCTDispatchEvent` and `RCTTiming` weren't being paused when there wasn't any
work left to be done.

Test Plan:
Run the timers example - check everything still works as expected
Test the ListView paging example - check scroll events are still fired as expected
Launch UIExplorer, let it idle, and put a break point on `-[RCTBridge dispatchBlock:moduleID:]`,
it should never fire.
Summary:
The logic for this is incorrect when the `state.transitionToIndex === 0`, and will return false and not capture the touch.

@public

Test Plan: Try to repro bugs on device and simulator
Summary:
@public

For every call that comes from JS to Native we'd call dispatch_async so the
method would be cllead on the queue/thread it's expecting. This diff
buckets the calls by target queue, dispatches only once to that queue, and then
call all the methods for it inside the same dispatch.

Test Plan: {F22510090}
Summary: constants were refactored to be enums.

Test Plan:
@public

navIOS example doesn't fatal.
…e modules (RCTURLRequestHandlers)

Summary:
@public

This is a refactor of @philikon's original diff that decouples the dependencies between the Network and Image modules, and replaces RCTDataQueryExecutor with a more useful abstraction.

I've introduced the RCTURLRequestHandler protocol, which is a new type of bridge module used for loading data using an NSURLRequest. RCTURLRequestHandlers can be registered using RCT_EXPORT_MODULE() and are then available at runtime for use by the RCTDataManager, which will automatically select the appropriate handler for a given request based on the handler's self-reported capabilities.

The currently implemented handlers are:

- RCTHTTPRequestHandler - the standard open source HTTP request handler that uses NSURLSession
- RKHTTPRequestHandler - the internal FB HTTP request handler that uses FBNetworking
- RCTImageRequestHandler - a handler for loading local images from the iOS asset-library

Depends on D2108193

Test Plan:
- Internal apps still work
- OSS port still compiles, Movies app and a sample Parse app still work
- uploading image to Parse using the above code snippet works
- tested `FormData` with string and image parameters using http://www.posttestserver.com/
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 facebook#1232
Github Author: James Ide <ide@jameside.com>

Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
@public

`[Bridge] Add support for JS async functions to RCT_EXPORT_METHOD` was imported but broke some internal code, reverting the `MessageQueue` that caused the issues and add a test, since the method is not used yet.

Test Plan: Run the test o/
Summary:
@public

There have been multiple instances of confusion about whether a redbox means the
developer did something they shouldn't but things will keep working, or if
something went horribly wrong and the app will crash in prod.  This diff
introduces an orange background color to the redbox for `console.error` and
`RCTLogError` to indicate that something bad happened, but that the app will
continue working.

Test Plan:
see orange error for geo permissions:

{F22541375}
Summary:
@public

This is the first of a few diffs that change the way the executors are handled
by the bridge.

For they are just promoted to modules, so they are automatically loaded by the bridge.

Test Plan:
Tested on UIExplorer, Catalyst and MAdMan.
Tested all the 3 executors, everything looks fine.
Summary:
@public

`validAttributes` strikes again.

Test Plan: secure box in example is actually secure
@facebook-github-bot facebook-github-bot added GH Review: review-needed CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. labels Jun 10, 2015
sahrens added a commit that referenced this pull request Jun 10, 2015
@sahrens sahrens merged commit a5212c8 into facebook:master Jun 10, 2015
@sahrens sahrens deleted the Update_Tue_9_Jun branch June 10, 2015 21:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet