[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 ...
[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.
[modules-core] Move js code (#13895)# Why Moves js code from `@unimodules/core` and `react-native-adapter` to `expo-modules-core` # How - Move js code. - Make sure everything is compiling
[modules-core] Move js code (#13895)# Why Moves js code from `@unimodules/core` and `react-native-adapter` to `expo-modules-core` # How - Move js code. - Make sure everything is compiling # Test Plan - bare-expo - ios ✅ - android ✅ - expo go - ios ✅ - android ✅