Tweaks to Authentication Recipe

[morganick]

Summary

• Correct onPress action for sign up
• Denoting initial session storage and edits for encryption
• Adding missing error style
• Adding warning about environment variables with EAS build

Thanks to @mazenchami for reporting these!

[morganick]

@mazenchami I agree. I'm not really a fan of this as I would much rather this be a secret loaded from EAS Secrets. I realize that this key can be public and even looking through the documentation across Supabase and Expo they just mostly inline it right into the code:

• https://docs.expo.dev/guides/using-supabase/
• https://supabase.com/docs/guides/getting-started/tutorials/with-expo-react-native#initialize-a-react-native-app

The dynamic config you were talking about referenced here: https://docs.expo.dev/eas-update/environment-variables/#using-variables-in-appconfigjs This appears to be the pre-SDK-49 way of doing things?

Even still we'd be committing those environment variables to the repo because they'd have to exist in eas.json for the particular profile: https://docs.expo.dev/build-reference/variables/#for-use-by-your-expo-config

Honestly, the easiest method is just to push the env into secrets right from the CLI:
https://docs.expo.dev/build-reference/variables/#adding-secrets-with-eas-cli

eas secret:push --scope project --env-file .env

The only issue with this is that they'd be the same across any of the EAS profiles because EAS secrets does not care about which environment they are loaded in.

It feels like there's a missing piece here. What am I missing?

@frankcalise thoughts?

[frankcalise]

Two thoughts:

1. You don't have to solve that problem of environments here, as that could be explained in detail elsewhere (for example, this recipe which is an older Ignite 8 one that should be more inline with Expo builds
2. But on how to actually execute different vars per environment, you would likely define some env in eas.json for example, like APP_VARIANT or APP_ENV in each one. Then in the dynamic config, app.config.ts, switch off that to call on the proper secrets. You'd have to store unique secrets per environment in this case, so prefixing them in some consistent way I guess would work.

It would be cool though, if there was a dropdown in the dashboard (and eas secret command) to specify that it belongs to a specific build profile. Maybe there is a reason they don't have that but I'll bring it up at Appjs next week

[mazenchami]

I agree with Frank's thoughts here, mainly: "You don't have to solve that problem of environments here..."