Skip to content

chore: Testing Danger bot#1

Closed
gabrieldonadel wants to merge 1 commit into
0.0-stablefrom
test-danger-bot
Closed

chore: Testing Danger bot#1
gabrieldonadel wants to merge 1 commit into
0.0-stablefrom
test-danger-bot

Conversation

@gabrieldonadel
Copy link
Copy Markdown
Owner

Summary

Changelog

[CATEGORY] [TYPE] - Message

Test Plan

facebook-github-bot pushed a commit to facebook/react-native that referenced this pull request Jan 19, 2022
…anches (#32917)

Summary:
## Summary

Update dangerfile in order auto-label pull requests opened against release branches

Closes #32692

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[Internal] [Added] -  Auto-label pull requests opened against release branches

Pull Request resolved: #32917

Test Plan:
As I don't have admin rights to this repo I tested this script on [a PR in my fork](gabrieldonadel#1) by running

```
 yarn danger pr gabrieldonadel#1
```

https://user-images.githubusercontent.com/11707729/150026370-4cce7831-c4ee-4269-b6a8-646f965826c5.mov

As you can see in the video once I run the script it automatically adds the label

Reviewed By: lunaleaps

Differential Revision: D33647174

Pulled By: yungsters

fbshipit-source-id: a7e7cab458b4cb7ff2cf318c4df1e9fb5d91a9f7
@gabrieldonadel gabrieldonadel deleted the test-danger-bot branch January 23, 2022 23:40
gabrieldonadel pushed a commit that referenced this pull request Dec 20, 2023
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
gabrieldonadel pushed a commit that referenced this pull request Mar 21, 2024
…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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant