Pretty standard as far as i am aware, created with expo init, then i have (via npm) installed react-native-crypto, and react-native-randombytes etc (many variations on this, including removing and re-installing versions and allsorts, to no avail).
At the moment i have a shim here that seemingly isnt doing anything, or changing anything.
when i do a ‘expo start’ the app runs, and boots on my phone via expo-go, but errors with one of the errors mentioned in my original post. atm its " TypeError: null is not an object (evaluating ‘RNRandomBytes.seed’)" which seems to be the nearest i am getting to solving it - if i could only just fix, polyfill or whatever i have to do, to get RNRandomBytes to not be null…
If i try to do something like: let RNRandomBytes = require(‘react-native’).NativeModules.RNRandomBytes then i get back to the “secure random number generation is not available in this browser”, seems like i keep going in circles
I would prefer, if possible, to use any Expo modules that provide this functionality, as opposed to trying to use the variety of react-native-* modules i keep finding across the internet and in help forums. Is there such a thing? i haven’t been able to locate one that does what i need, and i’ve tried ‘react-native-expo-crypto’ but had the exact same errors.
Wow. That makes a lot of sense… I never realised that the code wouldn’t even be being sent to the device when using Expo-Go! Does this essentially mean that Expo-Go is unusable in these circumstances, when we have these requirements?
I will see to doing some dev builds instead (feels like it would make for a much slower pace of development though, but i’d prefer that if it at least accurate )
Expo Go contains only the native code needed by things included in the Expo SDK. So if you install something that is partly native or depends on some other native code that is not part of the Expo SDK, then it “will not work in Expo Go”.
This is basically the truth, but you could technically still use Expo Go to test other parts of the app.
It shouldn’t really. Basically you’d only need to rebuild the dev client if you add more dependencies. In theory you could add all the dependencies you anticipate needing up front and then use it like Expo Go. Also, because Expo’s OTA updates do not include native code, this would also allow you to use OTA updates to enable functionality that depends on that native code. (But of course you should avoid violating the Stores’ policies.)
e.g. let’s say your app initially does not display any SVGs, but you anticipate adding some SVGs to some screens later to make things look better. You could add react-native-svg as a dependency up front, even though you don’t need it yet. Then later use an OTA update to add SVGs where you need them. If you did not have react-native-svg built in, then you would have to build a new binary later when adding SVGs to the app.
Of course this is a balancing act because the more dependencies you add, the bigger your app becomes. So you might still decide not to add too many things up front to keep the app size down.
Interesting, thanks for your reply. i think it confirms that i cannot use expo-go for my particular project, as i need crypto libraries/modules available to use.
I am essentially struggling to get RNRandomBytes to be available in my app, and i have no idea what to try next. Going by what you say, i should be able to add those dependencies in up-front and they will then be available in the app (though not via expo-go right?).
I’m currently trying the dev build route, as suggested, but (of course) there are errors i’m trying to figure out now, seems that something fundamental has changed but the expo process isn’t catering for it: (Could not find method compile() for arguments [com.facebook.react:react-native:+] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.