11–20 of 55 posts
Related: I would highly recommend trying out/using Expo.io if you are new to React Native and just want to get something working incredibly fast/easy to "hack" around with. It's a fantastic wrapper around React Native to jumpstart the whole dev experience.
Can someone point me towards some more in-depth explorations or books on this topic?
The official documentation is a good place to start.
I have been working on a large React Native project for several months now. It's great for quick prototyping but once we started doing heavy database stuff it got really slow, especially on Android. Of course we could have ported that part to native code, but that kind of defeats the purpose, doesn't it?
What database were you using and what bottlenecks did you run into? Curious as I have yet to work with dbs in React Native.
I have been working on a large React Native project for several months now. It's great for quick prototyping but once we started doing heavy database stuff it got really slow, especially on Android. Of course we could have ported that part to native code, but that kind of defeats the purpose, doesn't it?
They make heavy use of structures in native memory for argument-passing between JavaScript and Java. Once again someone thought they could outperform the JVM with their C-skills. My critique was dismissed :-/
Even though I showed that giving up RN's native memory and just sending serialised Json-Strings on the Heap over the bridge is 50-100% faster (and doesn't interfere with GC, so it should have less lags as well): [1]
The image library they use, Fresco, does the same. There are many year-old bug-reports open regarding OutOfMemory-errors and crashes, and RN apps tend to get unstable with more images. My bug-report [2] was dismissed as well without proper explanation.
But: At least some guy or girl didn't have to give their custom code up for to the better JVM. scnr
I use Strings for arguments in production and it's faster, so maybe try that out. :)
[0] https://github.com/facebook/react-native/issues/8780
I have been working on a large React Native project for several months now. It's great for quick prototyping but once we started doing heavy database stuff it got really slow, especially on Android. Of course we could have ported that part to native code, but that kind of defeats the purpose, doesn't it?
> Next, plan your Redux store ahead. I feel like I made the mistake of overusing it. Almost every property of my app is managed by Redux and this results in large reducers and many many actions to control all that. It’s very important to figure if some prop will be needed outside a certain component or not and, if not, keep that inside that component. How can you possibly know _in advance_ if a prop will be needed ou…
In engineering, that's what we call the design phase.
I have been working on a large React Native project for several months now. It's great for quick prototyping but once we started doing heavy database stuff it got really slow, especially on Android. Of course we could have ported that part to native code, but that kind of defeats the purpose, doesn't it?
You're running a local db of some sort? I'd assume you'd always want your app to be a thin client and just fetch data via REST or RPC.
I have been working on a large React Native project for several months now. It's great for quick prototyping but once we started doing heavy database stuff it got really slow, especially on Android. Of course we could have ported that part to native code, but that kind of defeats the purpose, doesn't it?
Assuming you don't do heavy work in the UI-loop: I find react-native's bridge memory-management on Android rather questionable: [0] They make heavy use of structures in native memory for argument-passing between JavaScript and Java. Once again someone thought they could outperform the JVM with their C-skills. My critique was dismissed :-/ Even though I showed that giving up RN's native memory and just sending seriali…
Earlier quoted context omitted.
What database were you using and what bottlenecks did you run into? Curious as I have yet to work with dbs in React Native.
We are using SQLite. The performance bottleneck is not the database itself but conversion between the Java and JavaScript environments.
Have you tried appending '... LIMIT [OFFSET ]' to constrain the per-query result set to a reasonable size?
> Next, plan your Redux store ahead. I feel like I made the mistake of overusing it. Almost every property of my app is managed by Redux and this results in large reducers and many many actions to control all that. It’s very important to figure if some prop will be needed outside a certain component or not and, if not, keep that inside that component. How can you possibly know _in advance_ if a prop will be needed ou…