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.

Sign up for GitHub

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

Jump to bottom

Enable JSX files extension #1

Closed
wants to merge 1 commit into from
Closed

Enable JSX files extension #1

wants to merge 1 commit into from

Conversation

kdemoya
Copy link

@kdemoya kdemoya commented Jan 9, 2016

JSX extension is much used in React, this would be a natural addition for React Native.

@kdemoya
Copy link
Author

kdemoya commented Jan 9, 2016

See: facebook#2303

@kdemoya
Copy link
Author

kdemoya commented Jan 10, 2016

Closing in favor of: facebook#5233

@kdemoya kdemoya closed this Jan 10, 2016
ide pushed a commit that referenced this pull request Jan 26, 2016
@yamill
Merge pull request #1 from facebook/master
bed0ede 
Merge
skevy pushed a commit that referenced this pull request Jun 23, 2016
@bestander
Open sourced more instrumentation tests #1
2aad616 
Reviewed By: avaly

Differential Revision: D3366104

fbshipit-source-id: 1c77b29e28726a6a105317d9f6944bbf78b707d7
ide pushed a commit that referenced this pull request Sep 13, 2016
@johnwook
Add 惠首尔(huiseoul) to showcase
2ee910a 
Summary:
> It also must be useful considering that the majority
of readers only speak English. So, each app in the showcase should link to either:
1/ An English-language news article discussing the app, built either by a funded startup or for a public company
2/ An English-language technical post on a funded startup or public company blog discussing React Native
For each app in the showcase, use infoLink and infoTitle to reference this content.

- We wrote a technical post on [medium](https://engineering.huiseoul.com/building-a-conversational-e-commerce-app-in-6-weeks-with-react-native-c35d46637e07#.776ll9ram)
- My company was funded, also. Reference [#1](http://besuccess.com/2015/08/huiseoul/), [#2](https://www.crunchbase.com/organization/trillionaire#/entity)
Closes facebook#9807

Differential Revision: D3843024

Pulled By: lacker

fbshipit-source-id: d76b2996f8aade42923d268f9308ae8796364083
ide pushed a commit that referenced this pull request Jul 7, 2017
@tenodi @facebook-github-bot
Blog post for React Native monthly meeting #1
31e1f37 
Summary:
A blog post with notes from the first React Native monthly meeting.

I've gathered notes after the meeting in this blog post. Think it might be useful for a broader audience in React Native community.

No test plan, submitting just a documentation file.

cc hramos ericvicenti
Closes facebook#14665

Differential Revision: D5294423

Pulled By: hramos

fbshipit-source-id: be7641622902cda47f391a2364e0f5aac45403ea
ide pushed a commit that referenced this pull request Apr 4, 2019
@RSNara @facebook-github-bot
Force JS null to be translated to ObjC nil
58cd204 
Summary:
In D14571128, we made it so that when a JS object's property was `undefined`, we wouldn't insert that property into the corresponding NSDictionary. Here are two important observations about that diff:
1. ALL JS `null`s were now being converted to `NSNull`, and JS `undefined`s were now being converted to `nil`.
2. If a JS object's property was explicitly `null`, then we'd insert `NSNull` into the corresponding dictionary.

Considering that when a property doesn't exist in a `NSDictionary`, property access returns `nil`, I've made it so that if a JS object's property is either `null` or `undefined`, then we simply do not insert it in the corresponding `NSDictionary`. Also, I've reverted #1 and made it so that `undefined` and `null` always map to the ObjC `nil`.

This shouldn't unfix the problem that D14571128 was trying to fix.

Here's my understanding of the problem that D14571128 was trying to fix (to make sure I'm not breaking something by this diff).

This method was invoked from JS.
```
RCT_EXPORT_METHOD(logEvents:(NSDictionary *)events)
{
  RCTAssert(events, @"You should provide events for logger");
  [[NSNotificationCenter defaultCenter] postNotificationName:@"FBReactPerfLoggerDidReceiveEventsNotification"
                                                      object:nil
                                                    userInfo:@{@"FBReactPerfLoggerUserInfoPerfEventsKey" : [events copy]}];
}
```

The above dispatch calls into this method, which appends `events` into `_pendingJSPerfEvents`.

```
- (void)reactPerfLoggerDidReceiveEvents:(NSNotification *)notification
{
  NSDictionary *events = notification.userInfo[@"FBReactPerfLoggerUserInfoPerfEventsKey"];
  if (events) {
    dispatch_async(_eventQueue, ^{
      if (self->_sessionData.perfLoggerFlagId != nil) {
        if ([self processJSPerfEvents:events]) {
          [self reportMetricsIfFinished];
        }
      } else {
        [self->_pendingJSPerfEvents addObject:events];
      }
    });
  }
}
```

Then, in `_processJSPerfEvents`, we do the following (link: https://fburl.com/tr4wr2a7):
```
NSNumber *actionId = events[@"actionId"];
if (actionId) {
  self->_sessionData.actionId = actionId;
}
```

So, if `undefined` or `null` was passed in as the `actionId` property of the `events` JS object in `FBReactPerformanceLogger logEvents:`, then we'd default the `NSDictionary` to have `NSNull` in the corresponding property. This is bad because we had this line in FBReactWildePerfLogger (link: https://fburl.com/2nsywl2n):  `actionId ? [actionId shortValue] : PerfLoggerActions.SUCCESS`. Essentially, this is the same problem that my diff is trying to fix.

Reviewed By: fkgozali

Differential Revision: D14625287

fbshipit-source-id: c701d4b6172484cee62494256175e8b205b23c73
ide pushed a commit that referenced this pull request Oct 9, 2019
@usikder @facebook-github-bot
BREAKING: rm YogaNode parameter from YogaLogger#log
94e8ccf 
Summary:
In D17439957, I noted that YogaLogger#log throws a NoMethodFoundException when called from C++ b/c C++ and Java's signatures of that method don't match. C++ uses YogaNodeJNIBase for the first param, Java uses YogaNode. Both my attempts to fix this failed.

Attempt #1 - Make Java use YogaNodeJNIBase. This doesn't work because the :java-interface target includes YogaLogger but not YogaNodeJNIBase. Moving YogaLogger to the impl target doesn't work either b/c other files in :java-interface reference YogaLogger.

Attempt #2 - Make C++ use YogaNode. This doesn't work b/c we try to call the log method with objects of fbjni type YogaNodeJNIBase. This would be fine in Java since YogaNodeJNIBase extends YogaNode. But fbjni's typing isn't advanced enough to know this, so the Yoga C++ fails to compile.

At this point, I was wondering what the value of having this param in the log function at all was. None of the implementations in our codebase use it today. It might be easier to just remove it all together. This also removes a bug with YGNodePrint where we pass a null layout context that eventually causes a SIG_ABRT when we use it to try to find a YogaNode to pass to this function. (https://fburl.com/diffusion/ssw9h8lv).

Reviewed By: amir-shalem

Differential Revision: D17470379

fbshipit-source-id: 8fc2d95505971a52af2399a9fbb60b63f27f0ec2
ide pushed a commit that referenced this pull request Oct 9, 2019
@elicwhite @facebook-github-bot
Migrate NativeComponentType from codegenNativeComponent to HostCompon…
1b4eaeb 
…ent #1

Summary:
We need to migrate to HostComponent, this is the first batch.

Changelog:
[Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent

Reviewed By: rickhanlonii

Differential Revision: D17562879

fbshipit-source-id: ce1993b64a79cede3598c89ddff0dadf07fde92f
ide pushed a commit that referenced this pull request Jul 10, 2020
@JoshuaGross @facebook-github-bot
Remove useless Mounting diagnostic error
0aa8ed6 
Summary:
While in theory we should never delete views before removing them from the hierarchy, there are some exceptions:

(1) Some mysterious cases that don't seem like bugs, but where the child still seems to keep a reference to the parent:
(2) When deleting views as part of stopSurface.

On #1: in the past we had issues when we assumed that ViewManager.getChildCount() would return an accurate count. Sometimes it's just... wrong. Here, I've found at least one case where a View still has a parent after it's removed from the View hierarchy. I assume this is undocumented Android behavior or an Android bug, but either way, there's nothing I can do about it.

On #2: there are valid cases where we want to delete a View without explicitly removing it from the View hierarchy (it will eventually be removed from the hierarchy when the Root view is unmounted, but it may still be "in" a View hierarchy when it's deleted).

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D22321374

fbshipit-source-id: 9667bbe778c418f0216550638dc26ca48a58e5fa
alanjhughes pushed a commit that referenced this pull request Mar 21, 2024
@RSNara @facebook-github-bot
Create genrule to generate appmodules.so (facebook#41466)
3ee4b8f 
Summary:
Pull Request resolved: facebook#41466

## Context
In open source, all apps use the same turbomodulemanager delegate (i.e: the default delegate).

This diff introduces the buck infra that makes the oss default delegate work for meta apps.

Concretely, we are going to make React Native use the same  delegate for **all** Meta apps.

Each Meta app will:
1. At build time, generate a unique TMProvider map
2. At app init time, initialize the default delegate with the TMProvider map.

## Implementation
**Step #1:** At build time, generate a unique TMProvider map

**Insight:** Buck genrules can accept, as input, the output of a buck query.

So, here's how we get this done:
1. Buck query (i.e: input to Genrule): Given the app's deps, query all the schemas in the app.
2. Genrule: Read the schemas to generate the TMProvider map. The TMProvider map will also contain **all** the app's C++ module codegen.

Concretely:
1. This diff introduces a macro: rn_codegen_appmodules(deps).
2. rn_codegen_appmodules(deps) generates appmodules.so, which contains the TMProvider map.

**Step #2:** At app init time, initialize the default delegate with the TMProvider map.

This is how we'll initialize the DefaultTurboModuleManagerDelegate:
1. DefaultTurboModuleManagerDelegate will load appmodules.so during init.
2. When loaded, appmodules.so will assign the code-generated TMProvider map to DefaultTurboModuleManagerDelegate.

## Impact
This should allow us to:
1. Get one step closer to getting rid of the `js1 build turbomodule-manager-delegates --target <app>` script
3. Remove the TurboModuleManagerDelegate from React Native's public API. (Because we use one delegate for all React Native apps in Meta and OSS)

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D50988397

fbshipit-source-id: 0ca5dec14e2dae89ec97f5d39a182c7937c5c7bf
alanjhughes pushed a commit that referenced this pull request Mar 21, 2024
@motiz88 @facebook-github-bot
RuntimeTarget refactor - Add this-scoped async executors to all Tar…
d4468fb 
…gets

Summary:
Changelog: [Internal]

# This diff

1. Provides all Targets with an `executorFromThis()` method, which can be used from within a Target to access a *`this`-scoped main thread executor* = a `std::function` that will execute a callback asynchronously iff the current Target isn't destroyed first.
2. Refactors how (all) Target objects are constructed and retained, from a plain constructor to `static shared_ptr create()`. This is because `executorFromThis()` relies internally on `enable_shared_from_this` plus two-phase construction to populate the executor.
3. Creates utilities for deriving scoped executors from other executors and `shared_ptr`s.

The concept is very much like `RuntimeExecutor` in reverse: the #1 use case is moving from the JS thread back to the main thread - where "main thread" is defined loosely as "anywhere it's legal to call methods on Target/Agent objects, access session state, etc". The actual dispatching mechanism is left up to the owner of each `PageTarget` object; for now we only have an iOS integration, where we use `RCTExecuteOnMainQueue`.

Coupling the ownership/lifetime semantics with task scheduling is helpful, because it avoids the footgun of accidentally/nondeterministically moving `shared_ptr`s (and destructors!) to a different thread/queue .

# This stack
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.

Overall, this will let us:

* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.

The core diffs in this stack:

* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. ~~
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). ~~
* ~~Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.~~
* ~~Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.~~
* ~~Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.~~
  * Provide RuntimeTarget with mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event. *← This diff*

## Architecture diagrams

Before this stack:
https://pxl.cl/4h7m0

After this stack:
https://pxl.cl/4h7m7

Reviewed By: hoxyq

Differential Revision: D53356953

fbshipit-source-id: 152c784eb64e9b217fc2966743b33f61bd8fd97e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@kdemoya