bndkt
Clip File Extension (JS bundle size fix!)
Introduction
React Native generally allows for platform-specific extensions to allow for better bundle optimization and platform specific imports. This PR adds functionality and an example for how to implement this same behavior with *.clip.* files. This solves the JS bundle size issue since developers can just inject a .clip file wherever they feel the bundle is getting too large. This can be done on a component-by-component basis, or on an app-wide basis using an App.clip.tsx file.
This solution can also fix issues in reliability in determining whether the current process is an app clip or not (#26). Developers can instead create the following trivial files which are resolved at bundle time, rather than runtime, meaning all potential flakiness in the native call is eliminated.
[isClip.ts]
const isClip = false;
export default isClip;
[isClip.clip.ts]
const isClip = true;
export default isClip;
I have the .clip extension resolution disabled by default in the example metro.config.js since it likely impact bundling performance. See this comment in react-native-tvos.
Usage
const USE_CLIP_FILE_EXT = true;
if (USE_CLIP_FILE_EXT && process.env.BUILDING_FOR_APP_CLIP) {
console.info("Building for App Clip");
config.resolver = {
...config.resolver,
sourceExts: [].concat(
config.resolver.sourceExts.map(e => `clip.${e}`),
config.resolver.sourceExts,
),
}
}
We've been using this in production for a month now and it works fantastically! Would highly recommend this for reducing bundle size and having reliable app clip specific behaviors.
@nathan-ahn do you use this change for local development as well? Do you have to set the env variable manually when running the metro server in that case?
@jbaxleyiii As far as I can tell, it's not possible to run app clip in a local development build. I test app clip by building a "production" build version locally: i.e. expo run:ios --scheme ___Clip --configuration Release for which the env variable is baked in the build step.
@nathan-ahn ah gotcha okay thank you! I've been able to run my clips locally with expo-dev-client off and on but never reliably. If I build with EAS then install the clip on the sim it will boot up and report as the clip 🎉 but isn't installed as something I can close and re-open the way I'd expect
@jbaxleyiii Yeah, I believe that's a quirk of App Clips -- they tend to not show up reliably. Here's my solution from a previous thread for how to reliably open your App Clip on simulator.
@nathan-ahn amazing! You should write a blog or something about your experiences with clips 😆. I'm so eager to get them working but ouch its been tough
@nathan-ahn been using your command xcrun simctl launch <UUID> <APP_CLIP_BUNDLE_ID> to launch my app clip on simulator, super helpful!
I have a question though, I can't seem to invoke the app clip via deep link though something like xcrun simctl openurl booted 'https://www.myapp.com/deep/link' (it just opens in Safari), though if I install the full app these deep links are handled properly. Do you think that this is an symptom of the same bug that prevents app clips from being invoked easily on simulators, and if so do you know of any workaround to test this? The clip doesn't really do anything/make sense without some parameters that need to come from the invocation url.
@ary31415 Unfortunately, I haven't yet found a good solution for testing deep links in app clip. I always end up testing deep links in the main app while developing, then I try them out once my App Clip is pushed to TestFlight. But I understand that development flow doesn't make sense for my App Clips.