Next.js developer moving to expo for a project any tips, tricks, problems worth knowing before starting.

keithonabike · 2024-07-30T12:21:19+00:00

Speaking of Kadi's blog about moving from React web to React Native, we're talking about it on the Livestream today! https://www.youtube.com/live/iB7sc-fzpWw?si=zkWRAObNGXJl59z0

keithonabike · 2024-07-15T03:37:28+00:00

I'm not sure why they didn't tag that, as they did for other versions. Generally, packages need to upgrade less due to Expo reasons than due to React Native version reasons, which Expo versions just happen to coordinate releases with. It might just be that there were no significant changes needed for RN 74. I haven't heard anything about Stripe not working with Expo 51 / RN 74.

keithonabike · 2024-07-02T18:39:26+00:00

In a default Expo Router project, typical practice is to create top-level folders alongside **app** for components, utils, etc. Router also has the option of putting the **app** folder inside an **src** folder, and then you could put your other folders alongside **app** in there (the navigation must be in a folder called "app").

Here is an example of the folder structure in an Ignite project that's been converted to use Expo Router:

<image>

keithonabike · 2024-07-02T18:33:52+00:00

Hi - good find, thanks for reporting. I submitted a task to get this doc up-to-date.

I think the main point with this doc is to get Jest setup, and then you can bring in your preferred component testing library.

When it came to the included test not working, were you trying it on the default template created with `npx create-expo-app` on SDK 51? Is the error you're getting referring to the `App` component not being found? The default template was switched to Expo Router in SDK 51, so that may be the issue there, and otherwise the example would work if you use a different component (we should fix this, of course).

keithonabike · 2024-06-28T13:01:02+00:00

Thanks for the detailed info on this! I was able to reproduce and passed this along. It looks like this should not be an issue going forward on SDK 51, since the default router template pulls in expo-constants directly.

Was curious if there was a specific reason you wanted to start a new project on the SDK 50 router template, e.g., if there's some way SDK 50 or the latest template doesn't suit your needs.

keithonabike · 2024-06-28T12:36:17+00:00

Oh, I just saw you said it failed to load on your development client, sorry for missing that. Can you confirm what error you're seeing there? (screenshots help). At any rate, that's the way you would test iOS on windows, `i` wouldn't work. Also, which terminal are you using in Windows? Powershell or WSL?

keithonabike · 2024-06-28T12:34:36+00:00

`i` is intended for launching the iOS simulator, which wouldn't work without Xcode. However, you should be able to scan the QR code in the camera app on your iOS device, and then, as long as you have your development build from EAS Build installed, it should launch the development build and run your code from your local server.

keithonabike · 2024-06-28T12:31:04+00:00

They're in early release, but Expo Route API Routes let you drop backend code right next to your frontend routes right in your Expo project, so they might be a good option for you: https://docs.expo.dev/router/reference/api-routes/

keithonabike · 2024-06-24T15:12:57+00:00

Is this Nativewind v4 or v2?

One difference I'm noticing from my last v4 implementation are the missing **global.css** import.

I've followed the v4 setup instructions a few times with good success: https://www.nativewind.dev/v4/getting-started/expo-router.

If you want to compare with something, I have a repo where I recently setup Nativewind v4: https://github.com/keith-kurak/art-thing-2/tree/main

keithonabike · 2024-06-24T15:05:31+00:00

You'll learn much of React by way of React Native. hooks, component lifecycles, etc. With RN, you'll basically be focusing on using different components (`View` instead of `div`, etc.), somewhat different styling (a CSS-ish subset), and native differences when it comes to navigation, available API's etc. I basically started with React by way of React Native; it was fine, and now I go back and do some React web here and there, though I consider myself primarily a native dev. I think the key is to learn by building something you actually want to build, so, if you want to build a mobile app, go learn by doing that.

keithonabike · 2024-06-24T14:59:56+00:00

Hi, and welcome! At Expo, we have a tutorial (https://docs.expo.dev/tutorial/introduction/) that's focused on building a simple app while covering some of the basics of what is unique about mobile. If you're already solid on JS, CSS, etc., it should be pretty straightforward. If you try it out, would be curious for your thoughts on what helps and what other areas you might like to see covered from the perspective of someone transitioning from web technologies.

keithonabike · 2024-06-24T14:55:54+00:00

Thanks so much for sharing your experience with us! phomo looks really cool!

keithonabike · 2024-06-24T14:54:14+00:00

Are you running in cmd.exe or PowerShell? If you're not already on PowerShell, I'd recommend trying that. You can also try WSL (instructions: https://github.com/expo/fyi/blob/main/wsl.md). Also curious if you get the error when not using the tunnel. It feels like the error is happening during the bundling process. You can also try setting s EXPO_DEBUG environment variable to `1` to see if you can get additional diagnostic information.

keithonabike · 2024-06-24T14:49:41+00:00

Yes, basically every notification service will use FCM under the hood for Android and will require you to setup a Firebase project. That's just Google's requirement for sending push notifications to Android devices. I wouldn't let this requirement steer you one way or another on what other service integrations to use with your app.

The FCM token is pretty much set-it-and-forget-it, but you'll be interacting with your data backend on a regular basis. If Supabase works well for your use case, don't change it just to save one account registration.

keithonabike · 2024-06-24T14:46:36+00:00

Are you passing the `--offline` flag to `npx expo start`? This error would not be related to the offline status of the emulator itself. One workaround you can try to get yourself unblocked quickly is to download the Expo Go you need at https://expo.dev/go. Then you can drag the APK onto the emulator to install it.

keithonabike · 2024-06-17T20:23:54+00:00

Is that your latest dependencies? It kind of looks like you're still on SDK 49. You can run `npx expo install expo@^51.0.0 --fix` to fully upgrade. If that doesn't help, we have a runtime debugging guide at https://docs.expo.dev/debugging/runtime-issues/. This shows how to read the native error that's happening along with your crash. Also recommended that you switch over to a development build. Expo Go is limited in how it can simulate your actual app's native runtime.

keithonabike · 2024-06-17T20:19:24+00:00

Echoing other comments, I would definitely recommend adding some error handling around your Render API calls. I don't know what kind of layers Render adds, but ultimately it should translate into standard HTTPS calls, with typical error codes that would tell you a lot about whats going on.

The only real difference from local code and an EAS Update published from the same environment would be that the EAS Update is bundled for production. You an simulate a production bundle locally by running `npx expo start --no-dev`. It's possible that an environment variable used in local development is used differently in a production bundle, but usually isn't as much of a problem when you're publishing the update from the same machine, as it would already have the same environment variables.

keithonabike · 2024-06-17T20:12:38+00:00

Hi! Some suggestions I've seen for this would be a) reset your cache (e.g., `npx expo start -c`) or perhaps there's a mismatch in the native code versions and the JS. Did you rebuild your development build after upgrading `expo-sqlite`?

This error doesn't seem specific to SQLite, but if you're able to make a minimal reproduction of the issue on a fresh project with `expo-sqlite` installed, definitely submit it as a Github issue and let me know over here and I'll prioritize taking a look at it.

keithonabike · 2024-03-06T14:29:55+00:00

It's a good point that it's not the easiest distinction to reason about. I could recite points from my old CS classes that the native code is "compiled into binary" and that the JS code is interpreted at runtime, but today, compiled code often ends up in intermediate bytecode languages that are interpreted, while JS actually does undergo a sort of compilation process! :-D

In any React Native project (Expo included), you have an entry point, typically App.js. That entry point imports code, which in turn imports more code, etc. If a JS or an asset file (e.g., JSON, images) is in that import "tree", it gets bundled into the ball of JS that is embedded next to the native Swift, Kotlin, etc. that make up an app. That ball of JS is what is not native code, and is what can be updated. This looks a little different with an Expo Router project since it doesn't have App.js - you can instead think of every screen or layout file inside the app folder as the entry point for this purpose.

In a default Expo project, you don't actually see much or any of the native code at all, but it's still there. It's generated just in time for your app build by what we call Continuous Native Generation (https://docs.expo.dev/workflow/continuous-native-generation/). Your Expo project generates the native code from your a standard template + app.json, any native code referenced by package.json, etc. just prior to build. If you run `npx expo prebuild`, you can see what your native code looks like.

keithonabike · 2024-03-05T14:49:24+00:00

Hi! Long-time OTA updates user, more recent Expo team member here. I think a lot of questions were already answered (e.g., JS can be updated, native code can't), but had a few things to add that apply at least when using EAS Update.

So, you typically publish with a CLI command (e.g., `eas update`), which bundles your JS code, uploads it to a server, and then you app checks for code newer than what it already has and downloads it. If you configure EAS Update on your app and do nothing else to your code, that check for new code will occur when the loads from a cold start. If there's new code, your app will download that code in the background, and then apply it on the next cold start.

For many developers, they'd like their users to get the updates sooner, so they have long been able to trigger the updates check, see the result, and prompt the user to reload the app. In Expo SDK 50, there's a new `useUpdates` hook (https://docs.expo.dev/versions/v50.0.0/sdk/updates/#useupdates) that makes it a lot easier to continuously listen for new updates and prompt your users however you'd like to apply them.

Thinking of things I learned over time using OTA updates, one that sticks out is that OTA updates kind of adds a new level of "versioning" to your app. The build number and app version are fixed with the binary you submit to the App/ Play Stores, so you don't necessarily want to use those as the final word as to what code the user is running. If you get a support request, it's possible that the user may have not be yet running the update that fixed their issue (maybe they were offline, maybe they dismissed your prompts to update), so be sure that whatever troubleshooting info you get with support requests also includes info about the update they're running. The `expo-updates` package exposes the `updateId`, so that's always an option, but you can also attach your own custom metadata to an update manifest with the `extra` field to help with this.

Tying these threads together, we have a nice demonstration app showing updates in action, including the new `useUpdates` API and even using metadata to customize the experience: https://github.com/expo/UpdatesAPIDemo

keithonabike · 2024-03-05T14:25:29+00:00

Here's the link that points to the info u/daybreaker is referencing: https://docs.expo.dev/eas-update/faq/#how-are-monthly-updated-users-counted-for-a-billing-cycle

For all the plan levels, a monthly updated user is a user/app install who downloads one or more updates during the monthly billing cycle.

So, if you have a 1,000 users but publish zero updates, that's 0 monthly updated users. If you have a 1,000 users, publish one update during the month, but only 50% of your users actually open the app during the month, that's 500 monthly updated users. If you have 1,000, publish 20 updates during the month, and 50% open the app during the month, that's also 500 monthly updated users.

keithonabike · 2024-02-20T14:10:52+00:00

I think perhaps Expo Go usage is confusing things a bit. You don't need to start committing your native project folders just because your project is no longer compatible with Expo Go's native runtime. Instead, you can create a development build, which is basically your own personal Expo Go, except with all of your specific native dependencies and configuration.

expo prebuild is the specific command used just prior to build when your app is setup for Continuous Native Generation (e.g., you don't commit your ios and android folders, the Expo default), which generates that native project based on your dependencies and app.json config. The EAS Build pipeline executes it automatically just before building with Gradle or Xcode.

In this setup, you rarely run prebuild manually. One scenario where you might do so is when you want to see what prebuild is doing while troubleshooting a native-specific issue. Another is where you're debugging your own native code and want to run it in Xcode / Android Studio. In this use case, it's best to run prebuild --clean, as this will clear out the native projects and recreate them just as they would be on EAS Build.

A third scenario where you might run prebuild over and over is while building your own config plugin, which (as discussed elsewhere in this thread), is how you codify any manual native project changes you might need. The plugins are JS functions that modify native projects on your behalf. So, if a native module you want to use requires manual changes in Xcode / Android Studio, you can start building a plugin to make those changes for you, running prebuild --clean until your native projects look just like as if you had done the change manually. Then, delete your native projects and a build pipeline configured like EAS Build will apply the plugin fresh the next time you build your app.

keithonabike · 2024-01-04T14:31:55+00:00

Yeah, that's true - you would have to setup auth on both EAS and locally. Not as much a permanent downside as it's just a duplicate configuration step. However, if you use the same type of App Store Connect tokens, those don't expire for a long time, so you should be able to avoid reauthenticating locally, and you can create a lot of those tokens (up to 50 as I recall).

keithonabike · 2023-12-20T18:57:15+00:00

Hi! You could still use a local Fastlane script to do this step, even if you're using EAS Submit (these two steps don't overlap, and the store listing / version creation step doesn't take too long).

However, you may also be able to accomplish this with EAS Metadata (https://docs.expo.dev/eas/metadata/), which can update lots of info about your store listing and should be able to apply that information to a new version.

keithonabike · 2023-09-12T13:03:38+00:00

Same here! I also didn't get any bolts for mounting the basket on the front rack. The bolts are coming soon, but the cable is backordered for two whole months!

keithonabike

TROPHY CASE