You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/the-new-architecture/backward-compatibility-turbomodules.md
+3-31Lines changed: 3 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -347,7 +347,7 @@ For a Turbo Native Module, the source of truth is the `Native<MyModule>.js` (or
347
347
importMyModulefrom'your-module/src/index';
348
348
```
349
349
350
-
The **goal** is to conditionally `export` the proper object from the `index` file , given the architecture chosen by the user. We can achieve this with a code that looks like this:
350
+
Since `TurboModuleRegistry.get` taps into the old Native Modules API under the hood, we need to re-export our module, to avoid registering it multiple times.
If you are using TypeScript and you want to follow the example, ensure to `export` the `NativeModule` in a separate `ts` file called `<MyModule>.ts`.
389
-
:::
390
-
391
-
Whether you are using Flow or TypeScript for your specs, we understand which architecture is running by checking whether the `global.__turboModuleProxy` object has been set or not.
392
-
393
-
:::caution
394
-
The `global.__turboModuleProxy` API may change in the future for a function that encapsulates this check.
395
-
:::
396
-
397
-
- If that object is `null`, the app has not enabled the Turbo Native Module feature. It's running on the Old Architecture, and the fallback is to use the default [`Legacy Native Module` implementation](../native-modules-intro).
398
-
- If that object is set, the app is running with the Turbo Native Modules enabled, and it should use the `Native<MyModule>` spec to access the Turbo Native Module.
Copy file name to clipboardExpand all lines: website/versioned_docs/version-0.70/the-new-architecture/backward-compatibility-turbomodules.md
+3-31Lines changed: 3 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -332,7 +332,7 @@ For a Turbo Native Module, the source of truth is the `Native<MyModule>.js` (or
332
332
importMyModulefrom'your-module/src/index';
333
333
```
334
334
335
-
The **goal** is to conditionally `export` from the `index` file the proper object, given the architecture chosen by the user. We can achieve this with a code that looks like this:
335
+
Since `TurboModuleRegistry.get` taps into the old Native Modules API under the hood, we need to re-export our module, to avoid registering it multiple times.
If you are using TypeScript and you want to follow the example, make sure to `export` the `NativeModule` in a separate `ts` file called `<MyModule>.ts`.
374
-
:::
375
-
376
-
Whether you are using Flow or TypeScript for your specs, we understand which architecture is running by checking whether the `global.__turboModuleProxy` object has been set or not.
377
-
378
-
:::caution
379
-
The `global.__turboModuleProxy` API may change in the future for a function that encapsulate this check.
380
-
:::
381
-
382
-
- If that object is `null`, the app has not enabled the Turbo Native Module feature. It's running on the Old Architecture, and the fallback is to use the default [`Legacy Native Module` implementation](../native-modules-intro).
383
-
- If that object is set, the app is running with the Turbo Native Modules enabled, and it should use the `Native<MyModule>` spec to access the Turbo Native Module.
0 commit comments