Expo is great. One of it's goals is to use only javascript to write React Native apps.
How do you determine if a third party React Native library will work in the Expo development environment?
The simplest approach is to look at the install instructions of the library.
If react-native link is mentioned then it won't work with Expo.
You can run any library by Detaching to ExpoKit but you will lose some of the benefits of using Expo in the first place.
Related
I am implementing API to connect app with server. I have to use deviceId there. As mentioned in here we can use third party library 'react-native-device-info'. But when I am using it I am getting errors as attached screenshots. As per error it's saying to do linking but as I am using react version 0.62, so autolinking is there. So What can be issue? It took too much time to search it but till now I didn't get a proper solution.
react-native-device-info library wont work in Expo , since it requires linking of native modules hence the error.It will only work in pure react native apps.
You can check this by expo itself : expo-device
hopeit helps.feel free for doubts
You can use react-native-device-info even in Expo projects. You need to replace Expo Go with a custom build that has react-native-device-info library baked in.
By default, Expo Go used on Android, iPhone Emulators implies managed workflow (aka only expo-* modules are being used). However, using any pure react-native-* libraries falls under bare workflow, so you cannot use Expo Go - the error you see is from Expo Go, not your app.
Build your custom Expo app with expo-dev-client, react-native-device-info libraries included, and install that on your emulators. This needs to be done once when you add a react-native-* library.
Now continue to add code to your project that uses features from react-native-device-info.
npx expo start --dev-client and choose your emulator. Your custom build will be launched and you can make live changes as always like in Expo Go.
Do check out the section on Development Builds from Expo. Needless to say, I have successfully used react-native-device-info on my Expo project, because expo-device cannot provide what I needed.
I have an Expo hybrid app (Managed workflow), running on Expo SDK v37 (React Native v0.61).
I'm struggling to find the best way to measure the time it takes from the moment when the user starts the app until the splash screen disappears.
How would you approach this?
PS: I would use Firebase Performance Monitoring instead, if it was available for Expo Managed apps. But it isn't yet.
Basically I see two approaches:
For pure react-native projects you can use react-native-startup-time library.
However I'm not sure, whether you can just add this library and start to use it, since it's required linking.
But in any case you can eject your project and add this library.
If you don't want to eject expo project I can suggest you to update your project to SDK 38. It has support for RN 0.62.2 and flipper integration as well. So you can setup flipper-plugin-react-native-performance and check the performance.
I hope I helped a bit.
How would you like to eject your app?
Bare: I'd like a bare React Native project.
ExpoKit: I'll create or log in with an Expo account to use React Native and the Expo SDK.
Cancel: I'll continue with my current project structure.
What is the difference between ExpoKit and Bare?
What are the advantage and disadvantage on choosing this?
The two ways to use Expo tools are called the "managed" and "bare" workflows.
Managed workflow
Apps are built with the managed workflow using the expo-cli, the Expo client on your mobile device, and expo various services: push notifications, the build service, and over-the-air (OTA) updates. Expo tries to manage as much of the complexity of building apps for you as they can.
Bare workflow
This is workflow where you use some of the Expo tools in a vanilla React Native app. Unlike in the managed workflow where you don't touch the underlying native code directly, in this workflow the developer has complete control, along with the complexity that comes with that.
ExpoKit
ExpoKit is another way to use Expo tools in a vanilla React Native app. The problem with ExpoKit is it is, compared to the "bare workflow", very monolithic — you essentially include the entire runtime from the Expo "managed workflow" in your app, rather than only the pieces of it that you want
I did a lot of research now to find out the exact differences and trade-offs between a React Native project, CRNA and an Expo project.
My main guidance was this
However I still don't understand what (dis-)advantages I have using ExpoKit with native code vs. a normal React Native project with native code, apart from the fact that I can't use Expo APIs in a normal React Native project.
I know that when I start a project in Expo I can eject it either as ExpoKit project or as React Native project.
In both I can use native code. In ExpoKit I can still use the Expo APIs in a normal React Native project I can't.
So my questions:
What would be my interest to use a react native project if I can use native code and all Expo APIs in an ExpoKit project? In an ExpoKit project I can still use all Expo APIs and all React Native APIs, right?!
Could I use Expo APIs in a React Native project if I install expo with npm install --save expo?
What is the difference between React Native API and Expo API?
ExpoKit is kind of a hybrid between "pure JS" Expo apps and "vanilla" React Native. At its core it's still a React Native project, but a few things differ about the build system, developer experience, and features available.
Features
As of today, most of the APIs in Expo's SDK are not available in a vanilla React Native project, but they are available in ExpoKit. We think this might change in the future, but it'll be a lot of work.
Expo's push notification service does not currently work in ExpoKit, nor for vanilla React Native.
Build System
Both vanilla RN apps and ExpoKit apps use Xcode and Android Studio to build the native code. iOS ExpoKit apps use CocoaPods to install dependencies, which can add a little bit of complexity to managing the native build. Android ExpoKit apps have additional Gradle configuration to build multiple versions of React Native into the same binary (this is used to enable over-the-air updates of multiple SDK versions of JS), which can sometimes increase the complexity of adding other React Native libraries.
The JavaScript for an ExpoKit and React Native project is built by Metro, although in ExpoKit you need to run Metro using Expo's XDE or exp tools so that they can handle extra configuration for the project. This means you run a command like exp start rather than react-native run-android.
Due to the current design of ExpoKit (although this may change in the future), some open source React Native libraries may have compatibility issues with ExpoKit. For example, if a native library expects to be able to request a reference to React Native's OkHttp instance on Android, there may be a type mismatch when running inside ExpoKit due to the namespacing Expo uses to allow multiple versions of React Native to compile. That said, these issues tend to be pretty rare, and we're working on a few different ways for ExpoKit to be more and more compatible with libraries in the ecosystem.
This multi-version support also means that ExpoKit binaries tend to be larger than corresponding vanilla React Native binaries, although that may change in the future.
Your subquestions
Some developers prefer to manage how their JS bundles and assets are distributed themselves, or they may need a library which isn't currently compatible with ExpoKit. Binary size is another reason why you may prefer vanilla RN.
It's not currently possible to use most Expo APIs in a React Native project. Some APIs available in the Expo SDK are bundled from open source projects (such as react-native-maps) and can be used with a vanilla RN project.
I'm not sure how to parse this question -- Expo APIs are currently just React Native APIs which know how to talk to each other and make certain assumptions about the environment they're running in.
Question from comment 1: You can modify the ExpoKit build all you want, although it may make it slightly harder to upgrade to a newer SDK release depending on how heavily you edit it.
Note to anyone who stumbles across this after 2020 ... ExpoKit has been deprecated so this whole question is moot.
From Expo's documentation: "ExpoKit is deprecated and support for ExpoKit will be removed after SDK 38. We recommend ejecting to the bare workflow instead."
I have developed only by native CLI since I started RN, but I have become interested in CRNA or Expo recently.
But if I want to use a library which expo does not support, I heard I have to do a eject.
I often make mobile apps for IoT products, so I think I should use Bluetooth or Wi-Fi library, so I think I should use a library that is not supported by expo unconditionally.
In such an environment where an unconditional eject must be made, does using expo or crna have advantages over using the native CLI?
One possible advantage of using Expo even after ejecting is that after ejecting, you can opt to have a native project linked to ExpoKit. ExpoKit is a native library that allows you some of the same conveniences that you would have when using the Expo client.
https://docs.expo.io/versions/latest/guides/expokit.html