nil #1

robz · 2015-01-28T03:45:58Z

No description provided.

Explain how to open the chat example

add react-native android command (wip)

Updating fork

Merge

@interface

Some keyboard types does not have buttons correspondent for keyReturnType such as Next, Done. It is observable on IPhone for numeric keyboard types. That prevents traversing forms with "number" input fields and impacts end-user experience. The improvement allows application for adding extra buttons via inputAccessoryView. Because RCTText is not a project exposed to React application calling all methods to add a handler is done using selectors. Here is a code fragment which has an example on how to achieve it: Within application: facebook#1 Create a keyboard Handle KeyboardAccessory keyboardHandler = ^UIView *(UITextField *textField) { ReactTextAdapter *kAdapter = [[ReactTextAdapter alloc] init:textField]; return [kAdapter getInputAccessory]; }; 2. Register an adapter Class clz = NSClassFromString(@"RCTTextField"); SEL selector = NSSelectorFromString(@"registerForKeyboardType:handler:"); if ([clz respondsToSelector:selector]) { [ clz performSelector:selector withObject:[NSNumber numberWithInt:UIKeyboardTypeNumberPad] withObject:keyboardHandler]; } facebook#3 Example of Keyboard Adapter @interface ReactTextAdapter :UIToolbar -(instancetype) init:(UITextField *)textField; -(UIView *)getInputAccessory; @EnD // // ReactTextAdapter.m // KeyboardTest // // Created by Krivopaltsev, Eugene on 3/11/16. // #import "ReactTextAdapter.h" @interface ReactTextAdapter() @Property (nonatomic) UITextField *textField; //@Property (nonatomic)UIToolbar *toolBar; @Property (nonatomic)UIBarButtonItem *flexible; @EnD @implementation ReactTextAdapter -(instancetype) init:(UITextField *)textField { self = [super init]; if (self) { self.textField = textField; [self setBarStyle:UIBarStyleDefault]; self.translatesAutoresizingMaskIntoConstraints = NO; self.flexible = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemFlexibleSpace target:self action:nil]; // since there is a next field, add a NEXT button to the picker if (self. textField. returnKeyType == UIReturnKeyNext) { NSString *nextText = @"Next"; UIBarButtonItem *nextButton = [[UIBarButtonItem alloc] initWithTitle:nextText style:UIBarButtonItemStyleDone target:self action:@selector(next)]; self.items = [[NSArray alloc] initWithObjects: self.flexible, nextButton, nil]; }else if (self.textField. returnKeyType == UIReturnKeyContinue) { NSString *continueText = @"Continue"; UIBarButtonItem *contButton = [[UIBarButtonItem alloc] initWithTitle:continueText style:UIBarButtonItemStyleDone target:self action:@selector(next)]; self.items = [[NSArray alloc] initWithObjects: self.flexible, contButton, nil]; } else if (self. textField.returnKeyType == UIReturnKeyDone) { NSString *doneText = @"Done"; UIBarButtonItem *doneButton = [[UIBarButtonItem alloc] initWithTitle:doneText style:UIBarButtonItemStyleDone target:self action:@selector(done)]; doneButton.enabled = YES; self.items = [[NSArray alloc] initWithObjects: self.flexible, doneButton, nil]; } } return self; } -(void) done { [self passToReactNative]; [self.textField resignFirstResponder]; } -(void) next { [self passToReactNative]; } -(void) passToReactNative { SEL selector = @selector(textFieldSubmitEditing); if ([self.textField respondsToSelector:selector]) { [self.textField performSelector:selector withObject:nil]; } } -(UIView *)getInputAccessory { return self; }

@interface

Some keyboard types does not have buttons correspondent for keyReturnType such as Next, Done. It is observable on IPhone for numeric keyboard types. That prevents traversing forms with "number" input fields and impacts end-user experience. The improvement allows application for adding extra buttons via inputAccessoryView. Because RCTText is not a project exposed to React application calling all methods to add a handler is done using selectors. Here is a code fragment which has an example on how to achieve it: Within application: facebook#1 Create a keyboard Handle KeyboardAccessory keyboardHandler = ^UIView *(UITextField *textField) { ReactTextAdapter *kAdapter = [[ReactTextAdapter alloc] init:textField]; return [kAdapter getInputAccessory]; }; 2. Register an adapter Class clz = NSClassFromString(@"RCTTextField"); SEL selector = NSSelectorFromString(@"registerForKeyboardType:handler:"); if ([clz respondsToSelector:selector]) { [ clz performSelector:selector withObject:[NSNumber numberWithInt:UIKeyboardTypeNumberPad] withObject:keyboardHandler]; } facebook#3 Example of Keyboard Adapter @interface ReactTextAdapter :UIToolbar -(instancetype) init:(UITextField *)textField; -(UIView *)getInputAccessory; @EnD // // ReactTextAdapter.m // KeyboardTest // // Created by Krivopaltsev, Eugene on 3/11/16. // #import "ReactTextAdapter.h" @interface ReactTextAdapter() @Property (nonatomic) UITextField *textField; //@Property (nonatomic)UIToolbar *toolBar; @Property (nonatomic)UIBarButtonItem *flexible; @EnD @implementation ReactTextAdapter -(instancetype) init:(UITextField *)textField { self = [super init]; if (self) { self.textField = textField; [self setBarStyle:UIBarStyleDefault]; self.translatesAutoresizingMaskIntoConstraints = NO; self.flexible = [[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemFlexibleSpace target:self action:nil]; // since there is a next field, add a NEXT button to the picker if (self. textField. returnKeyType == UIReturnKeyNext) { NSString *nextText = @"Next"; UIBarButtonItem *nextButton = [[UIBarButtonItem alloc] initWithTitle:nextText style:UIBarButtonItemStyleDone target:self action:@selector(next)]; self.items = [[NSArray alloc] initWithObjects: self.flexible, nextButton, nil]; }else if (self.textField. returnKeyType == UIReturnKeyContinue) { NSString *continueText = @"Continue"; UIBarButtonItem *contButton = [[UIBarButtonItem alloc] initWithTitle:continueText style:UIBarButtonItemStyleDone target:self action:@selector(next)]; self.items = [[NSArray alloc] initWithObjects: self.flexible, contButton, nil]; } else if (self. textField.returnKeyType == UIReturnKeyDone) { NSString *doneText = @"Done"; UIBarButtonItem *doneButton = [[UIBarButtonItem alloc] initWithTitle:doneText style:UIBarButtonItemStyleDone target:self action:@selector(done)]; doneButton.enabled = YES; self.items = [[NSArray alloc] initWithObjects: self.flexible, doneButton, nil]; } } return self; } -(void) done { [self passToReactNative]; [self.textField resignFirstResponder]; } -(void) next { [self passToReactNative]; } -(void) passToReactNative { SEL selector = @selector(textFieldSubmitEditing); if ([self.textField respondsToSelector:selector]) { [self.textField performSelector:selector withObject:nil]; } } -(UIView *)getInputAccessory { return self; }

facebook-github-bot · 2016-03-31T04:54:08Z

@robz updated the pull request.

Summary: Pull Request resolved: facebook#51425 # Problem React native's new list component is doing synchronous render. That means it makes synchronous dispatches from main thread to the js thread. (To capture the runtime so that it can execute js on the main thread). But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock. This diff is an attempt to mitigate all those deadlocks. ## Context How js execution from the main thread works: * Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep. * Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep. * Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks. How synchronous js -> main thread calls work: * Js thread puts a ui block on the main queue. * Js thread goes to sleep until that ui block executes on the main thread. ## Deadlock facebook#1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep, waiting for that block to execute. **Result:** The application deadlocks | {F1978009555} | {F1978009612} | ![image](https://github.com/user-attachments/assets/325a62f4-d5b7-492d-a114-efb738556239) ## Deadlock facebook#2 **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep waiting for that block to execute. **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **Result:** The application deadlocks | {F1978009690} | {F1978009701} | ![image](https://github.com/user-attachments/assets/13a6ea17-a55d-453d-9291-d1c8007ecffa) # Changes This diff attempts to fix those deadlocks. How: * In "execute ui code synchronously" (js thread): * Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now". * In "execute js now" (main thread): * This diff makes "execute js now" stateful: it keeps a "pending ui block." * Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists. * While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture. ## Mitigation: Deadlock facebook#1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime capture **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. The main thread wakes up in "execute js now": * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth. * Main thread goes back to sleep, waiting for runtime capture. * The js thread wakes up, moves on to the next task. **Result:** The runtime is captured by the main thread. | {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} | ![image](https://github.com/user-attachments/assets/f53cb10c-7801-46be-934a-96af7d5f5fab) ## Mitigation: Deadlock facebook#2 **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. **Main thread**: execute js now * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth. * Js thread wakes up and moves onto the next task. **Result:** Main thread captures the runtime. | {F1978010525} | {F1978010533} | {F1978010542} | ![image](https://github.com/user-attachments/assets/9e0ca5ef-fab6-4a26-bcca-d79d36624d5d) Differential Revision: D74769326

Summary: Pull Request resolved: facebook#51425 # Problem React native's new architecture will allow components to do sync render/events. That means they'll makes synchronous dispatches from main thread to the js thread, to capture the runtime so that they can execute js on the main thread. But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock. This diff is an attempt to mitigate all those deadlocks. ## Context How js execution from the main thread works: * Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep. * Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep. * Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks. How synchronous js -> main thread calls work: * Js thread puts a ui block on the main queue. * Js thread goes to sleep until that ui block executes on the main thread. ## Deadlock facebook#1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep, waiting for that block to execute. **Result:** The application deadlocks | {F1978009555} | {F1978009612} | ![image](https://github.com/user-attachments/assets/325a62f4-d5b7-492d-a114-efb738556239) ## Deadlock facebook#2 **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep waiting for that block to execute. **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **Result:** The application deadlocks | {F1978009690} | {F1978009701} | ![image](https://github.com/user-attachments/assets/13a6ea17-a55d-453d-9291-d1c8007ecffa) # Changes This diff attempts to fix those deadlocks. How: * In "execute ui code synchronously" (js thread): * Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now". * In "execute js now" (main thread): * This diff makes "execute js now" stateful: it keeps a "pending ui block." * Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists. * While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture. ## Mitigation: Deadlock facebook#1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime capture **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. The main thread wakes up in "execute js now": * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth. * Main thread goes back to sleep, waiting for runtime capture. * The js thread wakes up, moves on to the next task. **Result:** The runtime is captured by the main thread. | {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} | ![image](https://github.com/user-attachments/assets/f53cb10c-7801-46be-934a-96af7d5f5fab) ## Mitigation: Deadlock facebook#2 **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. **Main thread**: execute js now * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth. * Js thread wakes up and moves onto the next task. **Result:** Main thread captures the runtime. | {F1978010525} | {F1978010533} | {F1978010542} | ![image](https://github.com/user-attachments/assets/9e0ca5ef-fab6-4a26-bcca-d79d36624d5d) Differential Revision: D74769326

Summary: # Problem React native's new architecture will allow components to do sync render/events. That means they'll makes synchronous dispatches from main thread to the js thread, to capture the runtime so that they can execute js on the main thread. But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock. This diff is an attempt to mitigate all those deadlocks. ## Context How js execution from the main thread works: * Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep. * Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep. * Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks. How synchronous js -> main thread calls work: * Js thread puts a ui block on the main queue. * Js thread goes to sleep until that ui block executes on the main thread. ## Deadlock facebook#1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep, waiting for that block to execute. **Result:** The application deadlocks | {F1978009555} | {F1978009612} | ![image](https://github.com/user-attachments/assets/325a62f4-d5b7-492d-a114-efb738556239) ## Deadlock facebook#2 **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep waiting for that block to execute. **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **Result:** The application deadlocks | {F1978009690} | {F1978009701} | ![image](https://github.com/user-attachments/assets/13a6ea17-a55d-453d-9291-d1c8007ecffa) # Changes This diff attempts to fix those deadlocks. How: * In "execute ui code synchronously" (js thread): * Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now". * In "execute js now" (main thread): * This diff makes "execute js now" stateful: it keeps a "pending ui block." * Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists. * While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture. ## Mitigation: Deadlock facebook#1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime capture **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. The main thread wakes up in "execute js now": * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth. * Main thread goes back to sleep, waiting for runtime capture. * The js thread wakes up, moves on to the next task. **Result:** The runtime is captured by the main thread. | {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} | ![image](https://github.com/user-attachments/assets/f53cb10c-7801-46be-934a-96af7d5f5fab) ## Mitigation: Deadlock facebook#2 **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. **Main thread**: execute js now * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth. * Js thread wakes up and moves onto the next task. **Result:** Main thread captures the runtime. | {F1978010525} | {F1978010533} | {F1978010542} | ![image](https://github.com/user-attachments/assets/9e0ca5ef-fab6-4a26-bcca-d79d36624d5d) Differential Revision: D74769326

Summary: Pull Request resolved: facebook#51425 # Problem React native's new architecture will allow components to do sync render/events. That means they'll makes synchronous dispatches from main thread to the js thread, to capture the runtime so that they can execute js on the main thread. But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock. This diff is an attempt to mitigate all those deadlocks. ## Context How js execution from the main thread works: * Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep. * Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep. * Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks. How synchronous js -> main thread calls work: * Js thread puts a ui block on the main queue. * Js thread goes to sleep until that ui block executes on the main thread. ## Deadlock facebook#1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep, waiting for that block to execute. **Result:** The application deadlocks | {F1978009555} | {F1978009612} | ![image](https://github.com/user-attachments/assets/325a62f4-d5b7-492d-a114-efb738556239) ## Deadlock facebook#2 **JS thread**: execute ui code synchronously: * Js thread schedules a block on the ui thread * Js thread then goes to sleep waiting for that block to execute. **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime to be captured **Result:** The application deadlocks | {F1978009690} | {F1978009701} | ![image](https://github.com/user-attachments/assets/13a6ea17-a55d-453d-9291-d1c8007ecffa) # Changes This diff attempts to fix those deadlocks. How: * In "execute ui code synchronously" (js thread): * Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now". * In "execute js now" (main thread): * This diff makes "execute js now" stateful: it keeps a "pending ui block." * Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists. * While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture. ## Mitigation: Deadlock facebook#1 **Main thread**: execute js now: * Main thread puts a block on the js queue, to capture the runtime. * Main thread then then goes to sleep, waiting for runtime capture **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. The main thread wakes up in "execute js now": * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth. * Main thread goes back to sleep, waiting for runtime capture. * The js thread wakes up, moves on to the next task. **Result:** The runtime is captured by the main thread. | {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} | ![image](https://github.com/user-attachments/assets/f53cb10c-7801-46be-934a-96af7d5f5fab) ## Mitigation: Deadlock facebook#2 **JS Thread**: execute ui code synchronously: * Js thread puts its ui block on the ui queue. * ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up. * Js thread goes to sleep. **Main thread**: execute js now * Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth. * Js thread wakes up and moves onto the next task. **Result:** Main thread captures the runtime. | {F1978010525} | {F1978010533} | {F1978010542} | ![image](https://github.com/user-attachments/assets/9e0ca5ef-fab6-4a26-bcca-d79d36624d5d) Differential Revision: D74769326

nil

6221ab4

sophiebits force-pushed the patch-1 branch from 52b0637 to 6221ab4 Compare January 29, 2015 22:07

sophiebits changed the title ~~fixed readme step orderding~~ nil Jan 29, 2015

sophiebits closed this Jan 29, 2015

sophiebits deleted the patch-1 branch January 29, 2015 22:08

pilwon mentioned this pull request Mar 31, 2015

react-packager: Switch from Q to Bluebird as promises library #516

Closed

marcshilling mentioned this pull request May 14, 2015

[Perf] Small delay displaying RCTRootView after a push #1277

Closed

harrykiselev pushed a commit to harrykiselev/react-native that referenced this pull request Aug 5, 2015

Merge pull request facebook#1 from spicyj/patch-1

a74c542

Explain how to open the chat example

ide referenced this pull request in expo/react-native Sep 15, 2015

Merge pull request #1 from foghina/master

40fa39e

add react-native android command (wip)

sdaulibin mentioned this pull request Sep 16, 2015

react native init project #2766

Closed

brentvatne mentioned this pull request Nov 7, 2015

[ViewPager] Add setPageWithoutAnimation #3621

Closed

brentvatne pushed a commit that referenced this pull request Nov 9, 2015

Merge pull request #1 from facebook/master

49df1cb

Updating fork

popbee mentioned this pull request Nov 10, 2015

Document new asset system #3545

Merged

idibidiart mentioned this pull request Nov 30, 2015

Make Babel major version configurable #4437

Closed

martinbigio mentioned this pull request Dec 28, 2015

Incorrect resolve js file as directory #2825

Closed

jaysoo mentioned this pull request Jan 6, 2016

Use getRealMetrics for display metrics. Closes #4934 #4935

Closed

chirag04 pushed a commit that referenced this pull request Jan 25, 2016

Merge pull request #1 from facebook/master

bed0ede

Merge

joshbuchea mentioned this pull request Feb 16, 2016

Add My IP to showcase #5867

Closed

Chenjm08 mentioned this pull request Mar 21, 2016

[ios][API 0.20.0]Assertion failure in -[RCTTouchEvent coalesceWithEvent:] #6554

Closed

jordaaash mentioned this pull request Mar 26, 2016

Include ListViewDataSource docs somewhere #410

Closed

facebook-github-bot added the GH Review: review-needed label Mar 31, 2016

andpor mentioned this pull request Apr 2, 2016

EXC_BAD_ACCESS on iOS using RN 0.21 & 0.22 - in ShadowQueue #6775

Closed

javache mentioned this pull request Apr 8, 2016

[RFC] Add support for missing XHR response types #6870

Closed

pomelio mentioned this pull request Apr 15, 2016

How a Image component showing by a absolute local path #6998

Closed

melihmucuk mentioned this pull request Apr 20, 2016

Android crashes on some samsung devices (5.1.1+) #7087

Closed

satya164 mentioned this pull request Apr 24, 2016

Add Share module #5904

Closed

Andreyco mentioned this pull request May 20, 2016

Improve Docs navigation on handheld devices. #7640

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

nil #1

nil #1

Uh oh!

robz commented Jan 28, 2015

Uh oh!

facebook-github-bot commented Mar 31, 2016

Uh oh!

Uh oh!

nil #1

nil #1

Uh oh!

Conversation

robz commented Jan 28, 2015

Uh oh!

facebook-github-bot commented Mar 31, 2016

Uh oh!

Uh oh!