| #
8bd57a9a |
| 27-Jul-2022 |
Łukasz Kosmaty <[email protected]> |
[sweet API][Kotlin] Improve JSI error handling (#18259)
# Why
Improves error handling in functions that are called via JSI.
All API errors should look like this:
```
expo.modules.kotlin.jni.Pr
[sweet API][Kotlin] Improve JSI error handling (#18259)
# Why
Improves error handling in functions that are called via JSI.
All API errors should look like this:
```
expo.modules.kotlin.jni.PromiseException: Call to function 'f.TestModule' has been rejected.
→ Caused by: java.lang.IllegalStateException
```
# How
- Exported `CodedError` and use it to wrap the bare Kotlin exceptioThathat makes expressions like this `exception instanceOf CodedError` work.
- Added more `exceptionDecorator` blocks to add more context to the exceptions inside of exported functions.
- Mocked `CodedError` class in the test environment.
# Test Plan
- unit tests ✅
show more ...
|
| #
380376ea |
| 21-Jun-2022 |
Bartłomiej Klocek <[email protected]> |
[e-m-c][ios] Expose `NativeModulesProxy` config as a JSI module (#17741)
- Created the `NativeProxyModule` - a Sweet expo-module which is a counterpart of the `NativeUnimoduleProxy` RN module (`EXNa
[e-m-c][ios] Expose `NativeModulesProxy` config as a JSI module (#17741)
- Created the `NativeProxyModule` - a Sweet expo-module which is a counterpart of the `NativeUnimoduleProxy` RN module (`EXNativeModulesProxy`)
- it is registered manually in `ExpoBridgeModule`, right after the creation of `AppContext`
- currently, it only exports constants - the same as the `EXNativeModulesProxy` module
- the constants creation logic is still written in Objective-C inside `EXNativeModulesProxy`. It will finally be migrated in the future, but there's no reason to move it in this PR.
- Refactored config creation in `EXNativeModulesProxy constantsToExport`
- created the `EXModulesProxyConfig` class - a store for the module proxy config + some convenience methods for dictionary management
- config for both legacy modules and new sweet expo-modules is now lazy-loaded and cached
- minimized Swift calls from Objective-C, as they were performance bottlenecks - now there is only one such call.
- Yet, both configs are loaded in `NativeModulesProxy.native.ts` - config constants are taken from the JSI module first (with fallback to legacy constants), but method calls are still handled by the legacy proxy module.
- We need to load both (or at least the legacy one) anyway, but this shouldn't be a big issue for now, because the config is created only once and cached.
show more ...
|