We’re looking at moving an existing RN project to Expo. It seems mostly perfect for us, but we could use a bit of advice.
In our current version of the app we have some native code, mostly for dealing with multi-environment (dev/stage/prod) setups in specific per-env builds. We think we should be able to replicate the per-env configurations by using Expo release channels, but we’re not sure how to deal with adding Authorization: headers to “normal” HTTP requests triggered by the app, e.g. for images or data files stored behind basic auth on dev and stage environments.
Right now we do this in per-target build scheme scripts on iOS, by overriding sendRequest: withDelegate: in RCTHTTPRequestHandler.m, and by implementing a custom HTTP Interceptor on Android. This way any HTTP requests our app makes to our dev/stage environments have the Authorization: header automatically added, using per-environment/build target credentials taken from config in Info.plist or build.gradle.
Not sure how we’d go about this in Expo. I’m guessing it’d need to have similar overrides as part of the underlying RN bundle, with some way of exposing them for host/credential configuration in the JS code, which I imagine would probably be done better by someone closer to the RN code.
Has anyone else come up against this? Is this something to raise a feature request for? Or how else should we approach it? We’ve considered using IP-based instead of basic auth, but that would be considerably less convenient for us, as we have devs working behind dynamic IPs, etc, and as even dev & stage are over HTTPS, basic auth is a decent option for us.
Hi @igorclark - thanks for the thoughtful question. You can certainly do this if you detach, in much the same way as you described for your existing RN project. On iOS, you can override the same selector you did before, and on Android, we expose the OkHttp client builder in MainApplication so you can add any interceptors you please. However, as you’ll still be building and maintaining the native projects yourself, this could negate a lot of the reasons for moving to Expo in the first place.
There is no great way to do exactly what you described through only JS currently, so if that’s what you’re wanting, then creating a feature request on canny would be the way to go.
I hope this helps – sorry to not have a better & more convenient answer!!
Hey, thanks for getting back to me @esamelson. Yes, ejecting would defeat the object of moving to Expo somewhat for us. I’ll raise a feature request. Is there a way to create pull requests for the Expo project itself, in the event that it’s not a popular enough request to merit Expo team time? Or does it just track mainline RN, in which case I guess this would have to be a RN PR?
