Notes on learning stage of developing my own React Native education app using Expo Framework - Part 3
Stripe related links and info.
1. Stripe vs RevenueCat dashboards
-
Stripe shows the raw payment (customer → Stripe → your account).
-
RevenueCat shows entitlements (whether the user has access to the course).
If you see the charge in Stripe but no entitlement in RevenueCat, it usually means:
-
RevenueCat did not receive or process the webhook from Stripe, OR
-
RevenueCat isn’t properly configured for your product (SKU mismatch or Stripe product not linked correctly in the RevenueCat dashboard).
That’s why the user paid, but isn’t “granted” access in your app.
2. Time difference
Yes — Stripe shows times in UTC (GMT) by default. That’s why it looks ~5h30m behind IST. That part is expected and nothing is wrong there.
3. Retrying purchase → Stripe error
When you retry, Stripe says “already purchased” because that customer’s email/payment method has an existing successful charge.
-
Stripe won’t allow duplicate payments for the same subscription/product if you’re trying to recreate it.
-
For one-time payments, a new charge should normally go through, but in test mode with the same product ID it can block duplicates depending on setup.
4. Deleting vs Refunding in Stripe
Stripe does not allow deleting a payment transaction, even in test mode.
-
The only options are:
-
Refund (full or partial) → puts money back to customer (in test mode it just simulates it).
-
Void (for some pending payments, before they settle).
-
-
In test/sandbox, refunding is the way to “reset” things.
So yes ✅ you can refund that sandbox payment — that’s the correct way to clean it up.
🔑 What you should do next
-
Refund the sandbox payment in Stripe (safe, it won’t affect real money).
-
Double-check RevenueCat → Stripe integration:
-
Go to RevenueCat dashboard → Integrations → Stripe.
-
Make sure the webhook endpoint is set up in Stripe.
-
Ensure your product IDs match exactly between Stripe and RevenueCat (case-sensitive).
-
-
Check RevenueCat logs (there’s a debugging tab in their dashboard) to see if the event from Stripe was even received.
--- end CG response ---
Exactly 👏 — you nailed the key idea.
The safest and most robust test is to match on productIdentifier, not on display names (titles, entitlement labels, etc.), because:
-
Titles / entitlement names are for humans → can change anytime.
-
productIdentifier(e.g.yoga_1999_course_advanced) is the stable ID that ties your product in Stripe/RevenueCat to the actual entitlement granted.
✅ Better test implementation
You can loop through the entitlements and check for a matching productIdentifier:
🔍 Why this is better
-
Stable keys:
productIdentifier(yoga_1999_course_advanced) comes from your product setup and won’t change if you rename the product or entitlement in RevenueCat. -
Resilient to multiple entitlements: Works even if you later grant multiple entitlements for one purchase.
-
Debuggability: If there’s no match, you can clearly log it and handle gracefully (instead of silently failing).
After iteration(s), the suggested code became:
RevenueCat: Amazon Appstore vs Google Play
While exploring RevenueCat (RC) support for Android in-app purchases, I checked whether Amazon Appstore would be a good alternative to Google Play for learning purposes.
-
Amazon Appstore Support in RC:
RC does support Amazon Appstore, but only with extra setup. You need the Amazon-specific RC library, credentials (shared secret / public key), and “Live App Testing” (LAT). RC does not validate receipts from Amazon’s older “App Tester” sandbox. -
Amazon Appstore Developer Account:
Free to register and publish apps (unlike Google Play’s $25 one-time fee). Amazon takes a store commission on IAPs. -
Target Audience:
Amazon Appstore is mainly used on Amazon devices (Fire tablets, Fire TV) and now Windows 11. While it can be installed on any Android device, it is not widely adopted as a general Google Play alternative. -
Comparison with Uptodown:
Uptodown positions itself as a Play alternative and is popular for APK distribution, but it lacks billing integration. RC only supports Google, Apple, Amazon, and Stripe for payments. -
Learning Perspective:
For someone just learning RC and IAPs, the extra effort for Amazon (special SDK setup, LAT testing) does not provide much benefit, since most Android users rely on Google Play.
✅ Conclusion: It’s best to focus on Google Play + RC for learning, as it has cleaner integration, straightforward sandbox testing, and much wider real-world relevance. Amazon Appstore may be useful later if specifically targeting Fire/Windows 11 users, but not worth the time for a first learning project.
Me: For Android apps, RC supports only Google Play and Amazon app store. Am I right?
CG: Yes, you’re exactly right ✅
For Android apps, RevenueCat supports only these two billing providers:
-
Google Play Billing
-
Amazon Appstore Billing
That’s it.
👉 No direct support for other Android app stores like Samsung Galaxy Store, Huawei AppGallery, Uptodown, etc. If you publish to those, you’d have to handle billing yourself (outside RC).
So for Android + RC learning and production, it really comes down to Google Play (mainstream) and optionally Amazon Appstore (niche, Fire/Windows).
========================================
@shopify/react-native-skia can take a minute or two, even on a decent connection.A few reasons why it can feel slow:
-
Native modules compilation
-
Skia has native C++ code that may need to compile or download prebuilt binaries.
-
Even if it uses prebuilt binaries, npm checks dependencies and extracts them, which takes time.
-
-
Multiple dependencies
-
These packages bring in several sub-dependencies (e.g.,
react-native-reanimated,@shopify/skia-*), so npm downloads and links all of them.
-
-
Network speed + npm registry latency
-
At ~10 Mbps, a few MBs of packages can take ~1–2 minutes, especially if there are many small files (extraction overhead).
-
-
Package lock & audit
-
npm also updates
package-lock.jsonand runs an audit automatically, which adds a few seconds.
-
✅ In short, this duration is normal for these types of native-heavy packages on a 4G connection.
1. onHandleCompleteLesson is not a function (it is undefined)
-
In your code, you have:
But at this point in the execution order, onHandleCompleteLesson is not yet defined (because it’s declared later in the component).
In React function components, function declarations defined with const are not hoisted — so when the event listener is registered, it sees onHandleCompleteLesson as undefined.
👉 That explains the (NOBRIDGE) ERROR.
2. "Can't perform a React state update on a component that hasn't mounted yet"
-
This warning comes from your side-effect inside render:
That line runs on every render, before the component is guaranteed to be mounted.
So React complains because the player may still be attaching when you call replace.
👉 This is why sometimes notes don’t show, or the UI glitches.
...
Me: ... The tutorial video shows the author running the code (which I think is in same order as in code I shared with you). He runs it on iOS emulator. He does not get these problems. Any idea why it worked for him?
CG: Let’s break down why the tutorial author didn’t see the problem, but you did:
1. JS Execution & Function Hoisting Differences
-
In your code:
-
onHandleCompleteLessonis defined after this line. -
In plain JavaScript
functiondeclarations, the function would be hoisted (so it works even if defined later). -
But here it’s a const arrow function, which is not hoisted.
So at runtime, during the first render, it’s technically stillundefined.
👉 Why it might have worked for him:
-
If the iOS simulator didn’t trigger the
"playToEnd"event until after the component had fully mounted andonHandleCompleteLessonwas already defined, then it would appear to work fine. -
That’s probably what happened in his demo — he only tested by playing the video through, not triggering the event immediately.
2. Different Event Timing Between iOS & Android/Web
-
The Expo video player and event bridge behave differently across platforms.
-
On iOS, the
"playToEnd"event fires strictly after playback finishes. -
On Android/Web, sometimes events can fire earlier (e.g. when attaching listeners or when media metadata loads).
-
If the event fired before
onHandleCompleteLessonwas ready, you gotundefined.
3. The player.replace side-effect
-
On iOS, the player may tolerate being replaced inside render without warnings.
-
On Android/Web, React is stricter and complains because you’re mutating state before mount.
That’s why the tutorial author never saw:
✅ Summary:
-
The tutorial code appeared to work because:
-
iOS didn’t trigger the event until the handler was ready.
-
iOS player was more forgiving about side-effects inside render.
-
-
On Android/Web, you hit stricter lifecycle checks and different event timing → so the same code shows real issues.
[CG suggested fix did not work but after some iterations got a minimal fix that I wanted.]
Me: The following minimal fix code works for Android and web without showing run time errors (on main screen as against browser console). Some minor bugs are still there but the main issues I raised above seem to be fixed:
[I shared code from related file...]
CG: Perfect! 🎉
This minimal fix is exactly what I would have suggested step by step:
What you did right:
-
Guarded
onHandleCompleteLesson-
if (!lesson) return;ensures TypeScript is happy and prevents runtime errors on Android/web.
-
-
Guarded
player.replace(lesson.video)-
Using
if (lesson?.video)prevents trying to replace the video before it exists.
-
-
Hooks are unconditional
-
useEventListeneris called unconditionally, so React hook rules are respected.
-
-
Maintains tutorial-style code
-
No
useCallbackor other big refactors needed, keeps your code close to the original tutorial.
-
-
Cross-platform safe
-
Works on Android emulator and web. iOS should continue to work as well.
-
Minor remaining issues:
-
Confetti timing / overlap may still need tweaking (
onEndCourse). -
The
player.replaceruns on every render; using auseEffectwith[lesson?.video]dependency could slightly optimize performance. -
Some small layout or safe-area padding differences may appear on devices, but these are cosmetic.
✅ Conclusion: Main functional issues are fixed. You can now proceed with other tutorial steps without runtime crashes related to lesson or player.
If you want, I can also suggest a tiny useEffect tweak for player.replace that is a bit cleaner and avoids calling it on every render. It’s completely optional.
Do you want me to show that?
Me: Also confetti animation (if that's the word), is shown on Android emulator of completing course.
I want to skip the optimization stuff and stay as close to tutorial code as I can. The focus is on learning React Native and how this app uses it. Optimization can be done later as I get into real-life project stuff.
------------
They appear because:
-
Expo’s DOM runtime is printing setup info (
hydrate,rootTag, etc.). -
React Native dev mode logs its settings (
warnings ON,optimizations OFF). -
The
[webview] Logs will also appear…line is from Expo’s DOM shim.
They’re not errors, only environment info, and they’ll keep printing whenever the app reloads.
👉 You can safely ignore them, or if they’re noisy you can filter them in Metro/console, but they won’t appear in a production build (release APK/AAB).
...
Me: In the following, the words 'above error' is misleading then. Isn't it?
LOG [webview] Logs will also appear in the Safari/Chrome debug console
LOG Running application "main" with appParams:
{"hydrate": undefined, "rootTag": "#root"}
Development-level warnings: ON.
Performance optimizations: OFF.
ERROR The above error occurred in the <DOMComponentRoot> component:
at DOMComponentRoot (http://10.50.171.151:8081/node_modules%5Cexpo%5Cdom%5Centry.js.bundle?platform=web&dev=true&hot=false&lazy=true&transform.engine=hermes&transform.baseUrl=%2F&transform.routerRoot=app&transform.dom=.%2F..%2F..%2F..%2Fcomponents%2FRichtTextContent.tsx&unstable_transformProfile=hermes-stable:66286:58)
...
CG: You’re right 👍 — the phrase “The above error” in that log is a bit misleading in this context.
...
So the wording is a bit confusing because it looks like it’s referring to the last LOG, but really it’s React’s generic phrasing for “this error we just caught happened while rendering this component”.
Me: Got it. That helps a good deal as I was quite confused with those words. ... Now about digging in deeper to catch this occassional bug. The lesson code (index.tsx) checks for undefined lesson and so lesson surely is defined before the RichtTextContent component code is reached.
<View className="flex-1 p-4 min-h-[100px]">
<RichtTextContent
colorScheme={colorScheme}
blockContent={lesson.notes}
/>
</View>
------
So only notes can be undefined. Is my analysis correct so far?
[CG agreed. After some more exchages, I added some guard code in lesson index.tsx to check notes before using it in rendering code. But there was some STRAPI related stuff which I have given below...]
Me: In content-type builder, for lesson, notes has TYPE Rich text (Blocks)
...
CG ... In Strapi, a Rich Text (Blocks) field is always returned as an array of blocks (even if empty). So the checks you wrote [suggested by CG] are perfect:
-
lesson.notesexists? ✅ -
Is it an array? ✅
-
Does it have any blocks? ✅
If any of these fail, you can safely log a message or show a fallback UI like “No notes available for this lesson.”
-
Component stack is nested:
-
React will show the first component that threw the error (like
<DOMComponentRoot>in your case) rather than the innermost custom component (RichtTextContent). -
Any async effects or external libraries (like
@strapi/blocks-react-rendereror Expo DOM) can wrap your component, so the “top of the stack” is not your own code.
-
-
Bridging in React Native / Expo for web:
-
On web, Expo uses
DOMComponentRootand other internal wrappers to map React Native components to DOM. -
Errors inside children often bubble up through these wrappers, so the error looks like it’s coming from the wrapper rather than your component.
-
-
Errors in render vs. hooks:
-
If a render tries to use invalid data (
lesson.notesundefined in a component expecting an array), React throws during render. -
React only shows the stack from where it actually threw, which can hide the user-level component in the middle.
-
-
Stack trace minification / bundling:
-
In development, it’s easier to read, but if you bundle or use Hermes (your Android JS engine) it can make the error messages more cryptic.
-
Bottom line:
React is telling you exactly where it crashed, but because of wrappers (Expo DOM, React Native bridges, libraries like Strapi blocks), the actual source of the problem gets “buried” in the stack. You often have to trace back from the stack and reason about which of your components could have produced invalid input.
Tips for friendlier debugging:
-
Use
console.logearly in render to see what props are being passed. -
Wrap components that depend on external data in guards (
if (!data) return <Loading />)—like you did. -
Use TypeScript types carefully—TypeScript will catch some of these cases before runtime.
...
Me: Well, putting more burden on developers by having to code for such stuff is not developer friendly ... Somehow I feel React could have done a better job in reporting this error.
...
Me: ... The backend API for lesson services has:
/**
* lesson service
*/
import { factories } from '@strapi/strapi';
export default factories.createCoreService('api::lesson.lesson');
------
It is similar for lesson controllers and routes
CG: Yes, that makes sense. What you’re seeing is the default Strapi core service behavior:
-
The service
createCoreService('api::lesson.lesson')provides the standardfind,findOne,create, etc. -
It doesn’t throw an error if a
findquery returns no records; it just returns an empty array. -
That’s why your
fetchcall succeeds (response.ok === true), butresult.data[0]isundefinedif the lesson for thatlessonIndexdoesn’t exist.
So the runtime TypeError isn’t a network or HTTP error — it’s simply because the client code assumes result.data[0] exists without checking.
To handle this robustly, your client code must explicitly check for missing lesson, as I suggested:
Or return null and let the React component render a “Lesson not found” message.
Strapi itself isn’t “broken” here — it’s behaving as designed with its core service. The fix has to be in client-side handling of empty responses. ...
expo-video / react-native-video on Android emulators. The playToEnd event (or onEnd in expo-av) can fire spuriously on emulators due to how video buffering and software decoding are handled. On real devices, it’s usually fine.Note on expo-video / Android Emulator Behavior on Windows 11
While working with Expo’s Video component (expo-video / expo-av) in React Native, you might notice that the playToEnd (or onEnd) event sometimes fires unexpectedly on Android emulators running on Windows 11.
Key points:
-
This issue is emulator-specific; it does not occur on real Android devices.
-
The Android emulator often uses software video decoding and may handle video buffering differently from a physical device.
-
As a result, events like
playToEndoronPlaybackStatusUpdatecan trigger spuriously, sometimes immediately on component mount or before the video has actually finished. -
This behavior is not a bug in your app code, but a known limitation of the emulator environment.
-
For tutorial projects or learning purposes, it’s usually best to ignore this emulator quirk and rely on real devices to verify video playback behavior.
-
If needed in production apps, you can use state flags or
Device.isDevicechecks to prevent unintended handling of these events on emulators.
Takeaway:
The Android emulator on Windows 11 is useful for general UI testing, but video playback events may not exactly mirror real device behavior. Always validate video-related logic on a real device before deploying.
=======================
You’ve essentially discovered that:
-
The spurious
playToEndevent—which was originally observed only on the Android emulator— -
is also firing on a dev build running on a real Android device,
-
and that this causes your
onHandleCompleteLesson()logic to run automatically, advancing the course unexpectedly.
...
Me: What do u think? Is it possible that this is a dev build issue?
CG: That’s an excellent and very plausible hypothesis, Ravi — and based on your detailed observations, I’d say:
➡️ Yes, it’s quite possible (even likely) that this is a dev build–only issue.
Let me explain why in detail — step by step.
1. Dev builds behave differently from release builds
When you run a development build (via expo start --dev-client or Metro bundler), the app runs with:
-
Hot reload / Fast Refresh
-
Debug JavaScript mode
-
Extra logging and instrumentation
-
Development version of the
expo-videonative module, with more frequent state syncs
These add overhead and can cause timing glitches, especially in media components like video players that depend on precise native lifecycle handling.
So, even though your playToEnd handler fires as soon as the screen mounts, that might not happen in a release (production) build — where:
-
Dev tooling is removed
-
Frame timing is deterministic
-
No re-render interruptions occur during mount
2. Why video events can misfire in dev mode
The Expo video component (expo-video, or previously expo-av) triggers events like playToEnd through native bridge messages. In development:
-
React Native reloads JS bundles often and reattaches event listeners.
-
The video’s internal state (e.g., playback position = 0, duration known) can lead the JS side to think it has “ended” before playback starts.
-
These phantom events are more common when the player mounts and unmounts rapidly — exactly what happens when you navigate lessons and return via drawer menus.
That’s why:
-
On web, which uses browser-native playback and not RN bridge events → no issue.
-
On emulator and dev build on phone, where native bridge is active and Metro debugger is attached → spurious event.
-
On release build, those extra transitions and reattachments usually don’t occur → event won’t misfire.
expo-av (and by extension expo-video, since it wraps similar native playback logic).And your idea is 100% sound: adding a “component mounted and video ready” guard before responding to the playToEnd() event is both safe and elegant. It’s a preventive filter that ignores early, spurious events fired during initialization or race conditions — especially common in dev builds.
[CG suggested two code options. I took the simpler one, given below ...]
useEffect(() => {
const timer = setTimeout(() => setIsMounted(true), 500); // short grace period
return () => clearTimeout(timer);
}, []);
useEventListener(player, 'playToEnd', () => {
if (!isMounted) {
console.log('Ignoring spurious playToEnd event during mount');
return;
}
onHandleCompleteLesson();
});
Your logs clearly confirm both:
-
The spurious
playToEndevent firing during mount (and now being gracefully ignored), and -
The real event firing correctly at the end of actual playback — invoking
onHandleCompleteLessonas expected.
That confirms the isMounted filter works exactly as intended.
So yes — the core problem (a spurious playToEnd event during component mount in Android dev builds, especially in emulator) is now isolated and neutralized.
[CG provided a short summary note on this issue ...]
Observed that the playToEnd event in expo-video can fire spuriously when a lesson screen mounts in the Android dev build (on a real device as well as emulator on Windows 11), even though the video hasn’t finished playing. This does not occur in the web app and may be a dev build–only issue. Added a simple guard using an isMounted state flag with a short delay before handling playToEnd events. This prevents false triggers while preserving normal behavior. Verified that the workaround fixes the issue on Android phone.
-----
Me: Two minor quirks. 1) Console logs were not showing on Metro. I had to restart it and then they showed. Does that happen or did I mess up somewhere?
2) Initially I skipped the delay in playToEnd(). That did not work ... Seems like delay is necessary. pls explain why.
CG: Ah, both of these are actually normal quirks of React Native / Expo development — nothing you “messed up.” Let me explain each carefully.
1️⃣ Console logs not showing until Metro restart
-
Why it happens:
In a React Native dev build (Expo Go or custom dev client), the Metro bundler maintains a live JS connection to your device. Sometimes, after:-
Hot reloading,
-
Fast refresh, or
-
Navigation between screens,
the console log stream can get “stuck” or fail to attach properly to the device. Metro will still run, but logs don’t appear until you restart the bundler or reload the app.
-
-
Key points:
-
This is common on Android, less common on iOS.
-
It’s not a bug in your code — the logs themselves were being called, they just weren’t streaming to Metro.
-
Restarting Metro or reloading the app ensures a fresh connection for the log stream.
-
💡 Tip: For consistent logging, after adding new console.log statements that aren’t appearing, do a full reload (R or “Reload JS”) or restart Metro.
2️⃣ Why the delay in playToEnd() is necessary
-
Initially you tried guarding
playToEnd()withisMountedwithout a delay, and it didn’t work. Here’s why:
How it works internally:
-
Video component mounts: The native player initializes asynchronously.
-
React Native dev build: Fast Refresh / bridge may immediately trigger playback status updates — including
didJustFinish: true— before JS side has fully mounted. -
Without delay:
isMountedflips totrueimmediately, while the native player is still “settling”, so the first spuriousplayToEndstill fires. -
With a short delay (e.g., 500ms): You give the player time to:
-
Finish initialization,
-
Load the video metadata,
-
Set a proper playback position,
Before
isMountedallows the event to be handled. The first earlyplayToEndevent is ignored, but the real end event (after the user actually plays the video) is handled normally. -
-
Summary: The delay is essentially a grace period to let the video component stabilize, avoiding race conditions between JS mounting and native video status initialization.
✅ So both quirks are expected:
-
Metro logs sometimes need a restart — normal in dev builds.
-
The short delay in
isMountedis necessary to filter the early, spuriousplayToEndevent.
...
Me: Hmm. So my RN component (Page) finishes its mount stuff. But the video component is still initializing and so we have the spurious event. The key thing is to wait till the video component finishes initializing. The delay does that. did i understand correctly?
CG: Exactly — you’ve got it perfectly. ✅
-
Your React Native Page component finishes mounting (
useEffectruns, state updates, etc.). -
But the
<Video>component (expo-video / expo-av) is still initializing its native player asynchronously. -
During that brief initialization window, the native layer can report
didJustFinish: trueto JS even though the video hasn’t actually played — that’s the spuriousplayToEndevent. -
The short delay in
isMountedacts as a grace period, giving the video component time to complete its initialization. Only after this window do you start processingplayToEndevents.
So yes: waiting ensures the video is “ready” before handling the end event, which prevents the false trigger without affecting normal playback behavior.
It’s a classic race condition between component mount and native video initialization — the delay is a simple and effective way to fix it.
If you want, I can also explain a slightly more “robust” alternative that doesn’t rely on an arbitrary delay, using the video’s loaded/ready status. Would you like me to?
Me: That was the next question I had. If the video component provides a loaded/ready event, we can use that instead of a random timeout.
...
[CG had given me a version similar to this 'better' version earlier on itself but at that time, I was looking for a simple fix. ...]
Me: I only want to solve the spurious event problem, so if OnLoad ensures that fix, OnLoad is good for me. But I am using expo-video. Does it have a Load event?
CG: Yes — in Expo Video (expo-video), there is an onLoad event (sometimes also called onLoadStart/onLoaded in docs) that fires when the video metadata has loaded (duration, dimensions, etc.). This is enough for your purpose because:
-
The spurious
playToEndevent happens before the video is fully initialized. -
Waiting for
onLoadensures the video component is ready. -
Once
onLoadfires, any subsequentplayToEndis legitimate.
Example for your case:
Notes:
-
onLoadis called once per video load, so it’s perfect for guarding against the first spurious event. -
You don’t need
setTimeoutor an arbitrary delay anymore.
✅ So yes, onLoad in expo-video is exactly what you need to reliably solve the spurious playToEnd problem.
---- end of chat extracts ----------
Before I try out the above, I saved the current code (with earlier fix) ...
Commit: Workaround fix for spurious PlayEnd event on Android app
------------
Here’s the essence of your point:
-
Current behavior of
markLessonAsCompleted:-
It assumes the lesson was actually completed by the user.
-
Updates “current lesson” and progress in the backend based on that assumption.
-
Works fine if the user actually finished the previous lesson.
-
-
Problem when just navigating via drawer:
-
The user may jump to a lesson without completing the previous one.
-
Calling
markLessonAsCompletedwould incorrectly update progress and current lesson, because the backend doesn’t know the real completion state of prior lessons.
-
-
Ideal solution:
-
Have a method like
setCurrentLessonAndProgressthat only updates the current lesson and progress in the UI/backend without marking it as “completed.” -
This way, navigation via the drawer won’t corrupt progress data.
-
-
Decision:
-
Since this is just tutorial code and you don’t want to modify backend now, it’s reasonable to postpone this fix.
-
For now, leaving the current behavior as-is is okay, because the “next lesson” logic still works correctly for genuinely completed lessons.
-
In short: yes, I understand — you’re aware of the subtle difference between “marking as completed” vs. “just updating current lesson/progress,” and you’re deliberately postponing the fix because changing backend now would be overkill. ✅
================
2️⃣ Why a 404 happens
-
courseIdpassed here must be the documentId of the “user_course” record, not the course itself. -
markLessonAsCompletedinternally callsupdateUserCourseProgresswith the correct user_course documentId, fetched viagetUserCourses(). -
In your useEffect, you’re calling it with
lesson.course.documentId, i.e., the course document, not the user-course document.
✅ Hence, the endpoint doesn’t exist → 404.
[CG suggested some solutions ... ]
In Strapi, the documentId is a system-generated field introduced in version 5 to uniquely identify records across different content types. This identifier is especially important when working with the Document Service API, as it supersedes the traditional id field for referencing records.
🔍 Locating the documentId in the Admin Panel
While the documentId isn't explicitly shown in the Strapi Admin Panel by default, you can retrieve it through the API. Here's how:
-
Access the Collection: Navigate to your collection (e.g.,
user-courses) in the Strapi Admin Panel. -
Use the API to Fetch Records: Make a GET request to the appropriate endpoint, such as:
This request will return a list of records, each containing a
documentIdfield. -
Inspect the Response: Look for the
documentIdin the response data. For example:
🛠️ Understanding the documentId
In Strapi 5, the documentId is used to uniquely identify records when interacting with the Document Service API. This change aligns with the introduction of the Document Service API, which handles content operations at a more granular level. For instance, when updating a record, you should reference it by its documentId instead of the traditional id field. docs.strapi.io
✅ Recommended Approach
To ensure compatibility with Strapi's latest API standards, always use the documentId when performing operations like updates or deletes. For example, when updating a user's course progress, you would use:
This approach ensures your application remains compatible with Strapi's evolving API structure.
[That gave a clearer picture of this documentId stuff. ... I later used some API urls in browser to get key data with documentId from STRAPI backend. The relation part required some variation which CG helped me to get. The data from those API urls is given below ...]
getUserCourses() already filters by clerkId (the current user), you are guaranteed to get only the courses associated with that user. And since your app allows only one row per user-course, your find call is safe. ✅Android vs Web: React Query Race Condition on Course Progress Update
Scenario:
-
User navigates to a lesson via drawer (external navigation) in the Android app.
-
Backend (Strapi) updates the user-course
finished_percentage. -
The My Content page sometimes shows stale progress data despite
invalidateQueries()being called.
Observation:
-
Web app did not show the race condition — updates were reflected immediately.
Root Cause Analysis:
-
React Query & async calls:
-
invalidateQueries()triggers a refetch but does not wait for the preceding async write (updateUserCourseProgress) to complete. -
Race condition: query refetch executes before backend write finishes, leading to stale data in the UI.
-
-
Platform-specific timing differences:
-
Web app: front-end and backend on same PC → fetch returns in milliseconds → write usually completes before refetch → no visible issue.
-
Android app: JS runtime (Hermes/JSC) → bridge → mobile hotspot → backend on PC → network latency + async scheduling → fetch completion delayed → race manifests clearly.
-
-
Stale UI flashes:
-
On Android, even with cached React Query data, the UI renders the old progress until refetch returns updated data — flash of stale value. [Ravi: the flash of stale value happens only with the band-aid fix of refetchOnMount: 'always', in my-content.tsx. Otherwise the new value is not shown even when I waited for some minutes on my-content.tsx related screen.]
-
Solution:
-
Wrap the update and invalidate in an async function and await the update before invalidating queries:
Outcome:
-
Ensures backend update completes before React Query refetch.
-
Eliminates stale UI flashes. [Ravi: Eliminates stale data being shown for long.]
-
Works consistently across web and Android, regardless of network latency.
Takeaway:
-
invalidateQueries()alone does not guarantee ordering with preceding async operations. -
Platform-specific latency can expose hidden race conditions.
-
Always
awaitcritical backend writes when followed by a dependent query refetch.
...
Commit: Fixed drawer menu lesson navigation update bug for Android - race condition due to await not being used for async function
The code you’ve shown can definitely cause a race condition, for exactly the same reason as before. Let’s break it down carefully:
🔍 What’s happening
You have:
Here, markLessonAsCompleted() is an async function (it returns a Promise), but you’re not awaiting it.
So the next two lines — the invalidateQueries() calls — run immediately, without waiting for the backend write to finish.
⚠️ Why this is risky
React Query’s invalidateQueries() only triggers a refetch — it does not pause execution or ensure order.
That means:
-
The refetches (
lessonsanduserCourses) can start before Strapi has saved the updated progress. -
The new fetch gets old data from the backend (still 40%, say, instead of 50%).
-
The cache updates with stale info.
-
When the backend write finally completes, you now have a stale cache — until the next natural refresh.
This exact pattern caused the earlier “Android race condition” problem.
✅ The correct (safe) pattern
Just like you fixed before, wrap the code in an async function or mark the caller itself async:
🧠 Why this fix matters
-
Web: The race may not show visibly because Strapi writes and reads happen on localhost (fast I/O).
-
Android: The bridge, async I/O, and hotspot latency amplify the delay → race becomes visible.
So yes — technically speaking, even if it seems to work fine, this is a latent bug waiting to appear under slower conditions or heavier load.
[Discussion on async function usage in StrapiProvider.tsx and in components that use them like in lesson/index.tsx ... ]
Me: So if we don't do an await for invalidateQueries and we go to some mounted screen which uses the same query, the query will return stale data till the background refetch happens.
But when the background refetch does happen, does React and Tanstack together ensure that the screen is updated with the freshly fetched data?
CG: ✅ Yes — exactly right.
Even if you don’t await invalidateQueries(), React Query (TanStack Query) will absolutely ensure that the UI eventually updates itself automatically when the background refetch finishes. Let’s go step by step to make this behavior crystal clear 👇
⚙️ Step-by-step flow (no await case)
Let’s assume:
-
Screen A (e.g., “Lesson”) updates progress and calls:
-
Screen B (“My Content”) is already mounted and using: const { data, isFetching } = useQuery({ queryKey: ['userCourses'], queryFn: getUserCourses });
Here’s what happens internally:
① invalidateQueries() is called
-
The
['userCourses']query in the cache is marked as stale immediately (synchronous). -
TanStack schedules a background refetch.
-
The function then returns immediately (if you didn’t
await).
🧠 The query’s cache entry now looks like this:
② The background refetch starts
TanStack automatically re-runs getUserCourses().
Since your “My Content” screen already has useQuery(['userCourses']) mounted, it stays subscribed to this cache entry.
React Query emits internal state updates:
-
isFetching: true -
data: oldData(still shown until the new fetch resolves)
Your UI might show a spinner or shimmer here — depending on your config.
③ Refetch completes successfully
The new data (e.g., progress: 60%) is written to the cache.
TanStack then notifies all components subscribed to that query key.
This includes:
-
“My Content” page on Android/web
-
Any other component with
useQuery(['userCourses'])
④ React re-renders automatically
React Query uses a useSyncExternalStore-based subscription under the hood (in v5).
That means as soon as the cache changes, React automatically re-renders any component using that data.
So the “My Content” screen updates instantly when the fresh data arrives — no manual setState() or re-navigation needed.
⚠️ The only issue without await
While the eventual refresh is guaranteed, the timing isn’t:
-
If network latency is high (like on mobile hotspot), the UI will show stale data for longer.
-
If user navigates away and comes back before the background refetch finishes, they might still see old data briefly.
[Some more discussion ...]
Me: ... So the nuance here is that:
A) if we only do await for updateUserCourseProgress and not for invalidateQueries that follow then we may get short-lived stale data for the same query.
B) If we do not await for updateUserCourseProgress and do not await for invalidateQueries that follow then we may get long-lived stale data for the same query (won't change at all unless user initiates some action that refetches the query data). That is clearly a bug in the app showing wrong data to user.
C) If we do await for updateUserCourseProgress and await for invalidateQueries that follow then we are assured to get fresh data for the same query used by any component. The downside is that the app will be blocked till the fresh data is retrieved.
Is my above analysis correct?
CG: Yes — your analysis is spot on! Let me just elaborate slightly for full clarity:
✅ Your points in context
A) Await only updateUserCourseProgress, not invalidateQueries
-
Backend update completes first → the new progress is in Strapi.
-
invalidateQueriesfires without awaiting → React Query starts the refetch in the background. -
UI may briefly render stale data until the refetch finishes.
-
This is short-lived stale data — user will see old value only for a short moment.
-
Usually tolerable, not a bug, just a minor UX glitch.
B) Do not await either updateUserCourseProgress or invalidateQueries
-
invalidateQueriesfires immediately, before backend update completes. -
React Query refetches → gets old progress from backend.
-
Cache updates with old data → React Query thinks it’s fresh.
-
Backend update completes later, but query cache is already “fresh” → React Query does not automatically refetch again.
-
Result: long-lived stale data — the wrong progress is displayed indefinitely.
-
This is clearly a bug in the app, because the user sees incorrect information.
C) Await both updateUserCourseProgress and invalidateQueries
-
Guarantees backend update completes first → new progress in Strapi.
-
invalidateQuerieswaits for refetch → cache updates with correct data. -
UI components reading that query immediately see fresh data.
-
Slight downside: app is temporarily “blocked” until both network calls finish, but it ensures data consistency.
-
This is the technically correct and safe approach.
...
Me: Now you have said, C is the technically correct and safe approach. Hmm. So you mean that it is better to have the user wait for fresh data before being shown, say the My courses screen in our case, than show the My courses screen right away but possibly with stale data which gets updated in a short period of time.
CG: Exactly. Option C — await updateUserCourseProgress and await queryClient.invalidateQueries — guarantees that by the time the user sees the next screen (like My Courses), the query has already refetched and contains fresh data.
The trade-off is a slightly longer wait for the UI to render. But in cases like your app, where showing stale course progress could confuse the user, correctness and data consistency outweigh minimal speed gains.
So yes, it’s better to make the user wait a fraction longer for guaranteed fresh data than to risk showing outdated progress, even briefly.
Me: Ah! So it is an app functionality based decision on what is more suitable - C or A. If showing user some new screen ASAP is what is needed the option A may be more suitable, with an extra step of using an in-progress icon for the data that is being retrieved so that stale data is never shown.
CG: Exactly! It’s a UX/design decision.
-
Option A (await only
updateUserCourseProgress, notinvalidateQueries) gives a faster screen transition. But to avoid showing stale data, you’d typically show a loading spinner or skeleton UI while the query refetches in the background. That way, the user doesn’t see incorrect data. -
Option C (await both) guarantees data correctness at the cost of a slightly longer wait before rendering the screen. No additional loading indicators are strictly needed because the screen only appears once data is fresh.
So it really depends on whether your priority is speed of UI response or guaranteed correctness at render time. You can even combine both strategies for different parts of the app.
Me: In our case, the 'skeleton UI' is actually almost the full UI except for the progress percentage figure which can be made a suitable mini-spinner icon.
CG: Exactly! That’s a perfect fit for Option A.
You can render the entire “My Courses” UI immediately, and only replace the progress percentage with a mini-spinner or shimmer while the userCourses query refetches. Once the data arrives, you swap in the correct percentage.
This gives the user an instant screen load without risking showing stale progress, and it’s much less intrusive than a full-page loader. It’s a classic pattern in React/React Native apps for async data that updates small parts of the UI.
Me: What is a shimmer in this context
CG: In this context, a shimmer is a lightweight loading placeholder that indicates data is being fetched. Instead of leaving a blank space or showing incorrect/stale data, you display a visual effect—usually a grey or gradient animated bar or shape—to mimic the layout of the content that will appear.
For example, in your “My Courses” screen:
-
Instead of showing
10% finished(stale progress), you show a small animated shimmer bar or mini spinner in place of the percentage. -
Once the fresh
userCoursesdata arrives, the shimmer is replaced by the correct percentage.
It’s a common UX pattern in modern apps (used in Facebook, Instagram, etc.) to communicate that content is loading without blocking the rest of the UI.
In React Native, you can implement it using libraries like react-native-shimmer-placeholder or just a small Animated.View gradient.
...
Me: https://github.com/tomzaku/react-native-shimmer-placeholder has a great README showing shimmer usage via animation. Got it. Thanks.
...
Me: Using Option A without a shimmer or mini-spinner and thus showing stale data briefly would be viewed as an immature UI by tech pros. Am I right?
CG: Yes, that’s exactly right. Experienced developers consider showing stale or placeholder data without any visual indication of loading as a UI “anti-pattern.” Even if the data updates shortly after, users can be confused or think the app is buggy.
A small shimmer, mini-spinner, or subtle placeholder for the changing part (like your progress percentage) signals that the app is actively fetching fresh data. That keeps the UI feeling polished, responsive, and professional—even if the rest of the screen renders immediately.
Me: Very useful discussion. It is a good learning for me.
Now back to tutorial code. There are only two or three or maybe four data modifier functions in StrapiProvider.tsx. We don't need to worry about the get functions as surely the callers would be waiting for the data and so use await either through tanstack or directly.
We need to only go through the data modifier functions and ensure that await is used where appropriate and thus prevent possibility of some race condition bugs cropping up.
CG: Exactly! That’s a very practical way to audit your code. You don’t need to overthink the read/get functions—they naturally return promises, and the caller (through React Query or a direct await) usually handles them correctly.
The key focus should be on data-modifier functions in StrapiProvider.tsx that change backend state:
-
markLessonAsCompleted– Already async; just ensure all dependent actions that rely on updated backend data (likeupdateUserCourseProgressorinvalidateQueries) are properly awaited to avoid race conditions. -
updateUserCourseProgress– Already async; callers shouldawaitit when the UI must reflect the updated state immediately. -
addUserToCourse– Async; the caller should await it if subsequent UI or query invalidation depends on the new user-course data. -
createUser– Async; usually called during signup/registration, so it’s important toawaitthe full operation before moving to the next step (like navigating to a new screen or fetching related data).
In short:
-
Any function that modifies backend data should be awaited when the UI depends on that data being fresh.
-
Query invalidations (
invalidateQueries) should also be awaited if the subsequent screen or component relies on the updated query. -
Pure getters (
getCourses,getLessonsForCourse, etc.) don’t need special treatment beyond what React Query already handles.
This approach keeps your app safe from race conditions while avoiding unnecessary blocking where it’s not needed.
=========================================
-
queryFncan be async or return a promise.
In your code:If
getLessonsForCourseisasync(as it is), it returns a promise. TanStack Query handles this perfectly. -
How TanStack uses
queryFn:
Internally, TanStack Query automatically awaits the promise returned byqueryFn. You do not need to manuallyawaitit here. It looks roughly like this under the hood: -
What this means:
-
queryFnreturning a promise is expected and standard practice. -
datawill be populated with the resolved value of the promise. -
isLoadingwill betrueuntil the promise resolves. -
If the promise rejects, TanStack sets
isErrortotrue.
-
✅ So your code is correct. TanStack Query does the awaiting internally, which is why you can just pass an async function (or a function returning a promise) as queryFn.
await for updateUserCourseProgress and for invalidateQueries, which is exactly what was needed to avoid the race.Two small things to call out (one correctness/consistency item, one small polish), and then I’ll give two short, ready-to-drop variants you can pick from.
🧠 Why await response.json() is usually still done
When you call fetch(), you get a streaming HTTP response object.
The response body isn’t automatically read — it’s a readable stream that must be consumed (via .json(), .text(), .arrayBuffer(), etc.).
If you don’t read it:
-
The connection may stay open briefly until the body times out or is garbage-collected.
-
In browsers and React Native’s fetch implementations, this can lead to dangling network handles or warnings (“body stream not consumed”).
-
In practice, these are small, but in apps doing many such requests, it can affect network throughput or caching.
So:
✅ Best practice is to consume or explicitly discard the response body before returning.
Let me restate that clearly:
✅ Two clean ways to “finish” the response
-
Consume it (read it fully):
This reads the body stream completely — letting the network layer close the connection cleanly.
-
Explicitly discard it (without parsing):
or even:
This tells the runtime: “I’m done with this response; don’t keep this connection hanging.”
👉 await response.body?.cancel() is more efficient because:
-
It immediately closes the response stream without reading or buffering data.
-
It frees the connection slot faster (important when multiple parallel fetches happen).
-
It avoids unnecessary JSON parsing and CPU work when the body isn’t needed.
-
Functionality remains identical if you don’t depend on the response content.
So, your function can elegantly end like this:
And then just return void.
That’s a very clean, technically solid pattern for “fire-and-forget” POSTs or PUTs.
It’s actually how many telemetry or update endpoints are handled in production apps.
...
4. Conclusion
-
All modifier functions now properly await network calls and query invalidations, so there should be no race condition bugs in the current implementation.
-
Get functions are read-only and safe.
-
Your handling of
response.body?.cancel()vsresponse.json()is consistent with best practices.
unknown or unexpected option: --initial-url
1️⃣ The root cause
-
_layout.tsxalready wraps the entire app in<ClerkProvider>(good). -
soon.tsxusesWaitlistfrom@clerk/clerk-react. -
On web,
@clerk/clerk-reactrequires that<Waitlist>be rendered inside aClerkProvider— which it is, via_layout.tsx. ✅ Works fine. -
On Android (Expo Dev Client), you are using
@clerk/clerk-expo+@clerk/clerk-reactimports.
The problem is that @clerk/clerk-react’s Waitlist cannot find a ClerkProvider in the native environment, because the global _layout.tsx ClerkProvider is a @clerk/clerk-expo provider, not the same React context expected by @clerk/clerk-react.
Hence the error:
-
Wrapping
soon.tsxinClerkProviderfixes native (Android) because nowWaitlistsees the correct provider. -
But on web,
_layout.tsxalready providesClerkProvider, so now you have two providers, which React doesn’t allow → error.
2️⃣ Why the web vs Android difference
-
Web:
@clerk/clerk-reactexpectsClerkProviderfrom@clerk/clerk-react -
Expo Native:
@clerk/clerk-expois needed, andWaitlistimported from@clerk/clerk-reactdoes not find a provider because the native provider is not compatible.
So you basically have a “provider mismatch”: the same Waitlist component behaves differently depending on platform.
3️⃣ Correct solution
You need to conditionally import and render platform-appropriate Waitlist:
1️⃣ About @clerk/clerk-expo/web + 'use web'
-
Importing
Waitlistfrom@clerk/clerk-expo/webis essentially a “web-only” component trick. -
The tutorial author is probably relying on React Native for Web to render the web component inside the Expo Dev Client.
-
In pure native mobile (iOS/Android), this isn’t officially supported. That’s why the Clerk docs say: “This component can be used in Expo Web projects, but it isn't available in native environments (iOS or Android). For native apps, build a custom UI using Clerk hooks.”
-
So your
use webtrick may work in Expo Dev Client for development/testing, but it’s not guaranteed on real native builds (like EAS Build on device).
2️⃣ What that means practically
-
On web:
Waitlistworks normally. ✅ -
On Expo Dev Client (mobile):
Waitlistmay sometimes fail because the “web trick” requires the device to handle web rendering inside the RN environment. That explains why you saw:
@clerk/clerk-react: Waitlist can only be used within the <ClerkProvider /> component
-
Wrapping
soon.tsxinClerkProviderfixes it temporarily because now the component finds a provider, but then web throws “provider used twice” because_layout.tsxalready has one.
3️⃣ Official approach for mobile
Clerk’s docs recommend:
-
Do not use Waitlist component on native mobile.
-
Instead, build a custom waitlist screen using Clerk hooks, like:
import { useSignUp } from '@clerk/clerk-expo';
-
Then you can implement your own form/UI to collect emails for waitlist.
-
Works consistently across web and native.
4️⃣ Why your platform-specific approach works
The pattern I suggested earlier — conditional imports:
if (Platform.OS === 'web') {
const { Waitlist } = require('@clerk/clerk-react');
} else {
const { Waitlist } = require('@clerk/clerk-expo');
}
-
On web, uses the official Waitlist. ✅
-
On mobile, uses Expo-native hooks (
useSignUp) and your custom UI. ✅
This aligns with Clerk’s official recommendation and avoids “double provider” errors.
5️⃣ Key takeaway
-
The
use webtrick is hacky — works in Expo Dev Client sometimes, but not officially supported. -
For a robust solution across web + Android + iOS:
-
Web: use
Waitlistcomponent -
Mobile: use custom waitlist form built with Clerk hooks (
useSignUpetc.)
-
If you want, I can rewrite your soon.tsx as a cross-platform waitlist that:
-
Uses the Clerk
Waitliston web. -
Uses a custom native form on Android/iOS.
-
Works with
_layout.tsx’s singleClerkProvider.
This will eliminate both the provider errors and platform-specific bugs.
Do you want me to do that?
1️⃣ Why Android mobile fails
-
You are using native
useSignUp()from@clerk/clerk-expo. -
Clerk’s waitlist restriction feature is web-only.
-
On native apps, if Waitlist Restriction is enabled: “Sign ups are currently unavailable. Join the waitlist in web.”
This is exactly the error you are seeing.
-
Key point: Clerk does not automatically add native users to the waitlist. The mobile SDK does not create waitlist entries — it only allows signups if Waitlist Restriction is off.
2️⃣ What happens
-
On web:
-
Waitlistcomponent handles waitlist creation automatically → entry appears on dashboard ✅
-
-
On Android/iOS:
-
signUp.create({ emailAddress })fails because native SDK enforces waitlist restriction -
You see the modal error
"Sign ups are currently unavailable..." -
Nothing is added to Clerk dashboard ❌
-
3️⃣ Clerk’s official recommendation
From Clerk docs: “This component can be used in Expo Web projects, but it isn’t available in native environments (iOS or Android). For native apps, build a custom UI using Clerk hooks.”
-
The custom UI does not automatically add users to the waitlist — you have to implement a backend endpoint that sends the email to your own waitlist table.
-
Native users cannot be automatically queued on Clerk dashboard.
4️⃣ How to handle this in your app
Option A — Native users redirected to web waitlist page
-
In your mobile form:
Alert.alert(
'Join the waitlist',
'Sign ups are currently unavailable on mobile. Please visit our web waitlist to join.',
[
{ text: 'Open Web', onPress: () => Linking.openURL('https://yourapp.com/soon') },
{ text: 'Cancel', style: 'cancel' },
]
);
-
This is what most apps do — mobile users go to web for waitlist.
Option B — Custom backend waitlist
-
Create a serverless function or API endpoint in your backend (or Strapi) that saves email addresses.
-
On mobile, submit form via
fetch('/api/waitlist', { method: 'POST', body: { email } }). -
This keeps mobile waitlist entries visible in your own database, independent of Clerk.
5️⃣ Key takeaway
-
Web: Clerk
Waitlistworks perfectly. -
Mobile native: Waitlist cannot be automatically created in Clerk dashboard.
-
Any attempt to
signUp.create()while Waitlist Restriction is ON → blocked.
If you want, I can update your mobile native waitlist form to:
-
Detect Waitlist Restriction is active
-
Show a message and redirect to web waitlist OR
-
Send email to a backend waitlist collection
This way your mobile users can join the waitlist even though Clerk doesn’t allow native waitlist entries.
Do you want me to do that?
Me: https://clerk.com/docs/reference/javascript/clerk#join-waitlist indicates that there is JS API to join the wait list.
CG: You're correct — Clerk does provide a JavaScript API to add users to the waitlist, but it's important to note that this API is intended for use in server-side environments, not directly within client-side code running on mobile devices. ...
[I then asked CG for earlier Option A implementation code. Had some interations with CG provided code. ... ]
Me: That worked. Some questions and points:
1) Mixing require and import - is that acceptable? Could we use a soon.tsx and soon.web.tsx approach to avoid that?
2) I will modify button label to indicate it is join waitlist via web.
3) On Android, should we provide an additional button to Exit App on this waitlist message screen?
4) I am considering to use an env. variable like CLERK_WAITLIST_ON with values of true/false and using that to have conditional code of showing soon.tsx or login.tsx.
[CG agreed with above suggestions and provided code. ... Some iterations with me asking additionally for light/dark mode support, using EXPO_PUBLIC_CLERK_WAITLIST_ON as env var.]
Me: Is EXPO_PUBLIC_CLERK_WAITLIST_ON=true
a good definition? I think it assigns string 'true' to it. In which case, it may be better to go for 1 or 0. What do u say?
CG: Excellent question — and you’re absolutely right to think carefully about this 👍
Let’s clarify exactly how Expo handles this:
🔍 What actually happens
In .env, everything is stored as a string.
So when you write:
EXPO_PUBLIC_CLERK_WAITLIST_ON=true
it is literally interpreted as:
process.env.EXPO_PUBLIC_CLERK_WAITLIST_ON === 'true'; // ✅ true
process.env.EXPO_PUBLIC_CLERK_WAITLIST_ON === true; // ❌ false
So you always have to compare with the string 'true'.
💡 Option 1: Keep 'true' / 'false' (recommended)
✅ Most common in Expo and React ecosystems
✅ Readable and compatible with web environments
✅ Avoids confusion when reading environment files
Usage:
const waitlistOn = process.env.EXPO_PUBLIC_CLERK_WAITLIST_ON === 'true';
.env
EXPO_PUBLIC_CLERK_WAITLIST_ON=true
💡 Option 2: Use 1 / 0
✅ Slightly shorter
⚠️ But less standard — Expo and Node.js both read these as strings too,
so you’d still need to write:
const waitlistOn = process.env.EXPO_PUBLIC_CLERK_WAITLIST_ON === '1';
.env
EXPO_PUBLIC_CLERK_WAITLIST_ON=1
✅ My Recommendation
Stick with the 'true' / 'false' convention.
It’s clearer, self-documenting, and matches how most modern JavaScript projects handle boolean env flags — including official Expo examples like:
EXPO_PUBLIC_API_MOCKING=true
EXPO_PUBLIC_FEATURE_FLAG=false
So your current definition:
EXPO_PUBLIC_CLERK_WAITLIST_ON=true
✅ is perfect and standard.
Would you like me to show a one-line helper function that safely parses environment booleans (like "true", "1", "yes") into actual booleans — just for clarity and reusability?
About your “Exit App” behavior:
✅ You’re right — on Android BackHandler.exitApp() (or similar logic) only closes the app’s foreground activity and returns to the home screen.
The process itself often stays alive in the background until Android decides to reclaim it (for performance and UX reasons).
This is expected behavior in modern Android (since Android 10+).
...
---------------- end chat segment extracts ----------
Mobile vs Web UX: Sign-in Navigation from a Waitlist Page
On web apps, navigating from a waitlist page to a login page typically uses standard browser history (router.push), so users can press the Back button to return to the waitlist. This matches web user expectations.
On mobile (React Native / Expo Router), we recommend using router.replace when moving from the waitlist to the login page. This removes the waitlist page from the navigation stack, ensuring a clean, linear flow: once the user starts signing in, the waitlist page is considered “done.” Users can still revisit it by closing and reopening the app.
Why the difference?
-
Mobile UX favors simple, predictable navigation stacks and avoids confusing behavior with the hardware back button.
-
Web UX expects full history support and back navigation using the browser.
Key takeaway: Stack behavior can and should differ across platforms to provide the most natural experience for the user.
==================
Comments
Post a Comment