Good Practices: Why you should use JavaScript whenever possible with React Native

Yet many people who are convinced about the benefits of using React Native for a project are not always persuaded that they should attempt to write as much of their app as possible in JS.If it were implemented in JS, it would be cross-platform by default.

It would allow you to ship updates for this feature over the air, to include less native code that could potentially break when the React Native’s native APIs change (much more common than breaking API changes in JS), and many other benefits that we’re all very familiar with.

This would slow down development of your personal project slightly, but you’d be giving back in a big way to the community and improving React Native for everybody, and the next time you need a custom spinner you can write it in JS.react-native-fetch-blob is a library that is a somewhat faithful polyfill of the browser’s Blob API.

So when people come up with one-off native solutions, I completely empathize with the need to ship something, but at the same time feel sad that the development time isn’t directed instead towards improving the core or a generalized solution.How you can make the React Native community betterIf your company benefits from using React Native, you could hire acontractor to generalize the implementation for you and ship it upstream.

We also recently worked with Satyajit, Mike to polish up some existing work on a Blob API for React Native and get it upstream, which will make the experience of uploading files through Firebase (and a bunch of other things) more pleasant out of the box.Next time you consider reaching for native code to solve a problem in React Native, think about what exactly is preventing you from doing it in JS.

When does it make sense to drop down to native, and when should you stay in JavaScript? I believe the decision isn’t as simple as a one-off technical decision of what is easier to do in the moment … @ZymoEnt: Good Practices: Why you should use #JavaScript whenever possible with #ReactNative

When does it make sense to drop down to native, and when should you stay in JavaScript? I believe the decision isn’t as simple as a one-off technical decision of what is easier to do in the moment — the future of React Native as a community depends on the decisions that we all make when building our projects and publishing components, and we need to make decisions with a longer term vision in mind for where we want the community to go.

Instagram stories is a popular UI for people to re-create with React Native: example 1, example 2.

@tlackemann wrote example 1 in Objective C and leveraged iOS APIs that aren’t all exposed in React Native core (it doesn’t make sense for them to be). @yousefkama wrote example 2 and he had to resort to implementing a different UI because it didn’t seem possible from JS from his research. I’ll be the first to admit I know little about 3D graphics, but it certainly seems like the effect should be possible from JS in React Native.

But why use JS if you can do it natively?

This is the same question that anyone could ask about React Native. Yet many people who are convinced about the benefits of using React Native for a project are not always persuaded that they should attempt to write as much of their app as possible in JS.

If it were implemented in JS, it would be cross-platform by default. It would be easier for the React Native community, who usually aren’t particularly experienced with ObjC or UIKit, to remix the code and create their own transitions. It would allow you to ship updates for this feature over the air, to include less native code that could potentially break when the React Native’s native APIs change (much more common than breaking API changes in JS), and many other benefits that we’re all very familiar with. I think it is clear that a pure JS implementation, when possible, is universally preferable.

should present you with a warning before

running:

Warning! react-native-example-library is adding native code to your

iOS and Android projects.

– If you add this code, you should trust that the maintainer keeps it up to date with new releases at the same speed that you expect to, otherwise you may not be able to update your project until they do.

– If you update the library to add some new features, you must re-submit your app to the App Store and Play Store. If you ship an

OTA update, your app may crash for your users.

– If you do not know any Objective-C or Java, you may run into problems that you don’t know how to solve. It may be difficult or impossible for you to customize.

– You may be able to do this with pure JavaScript instead! If not,

consider offering to help the author upstream this code.

in order for this to work. (See source)

support to Android it will work without any changes. You can also try it with Exponent.

I think this is a common problem that React Native developers face — you can almost build something in JS, but React Native core is missing a feature that you would need to do so, and there is no general purpose library to address the problem. Quite often the response by the community is to go off and re-create the entire thing natively and call it a day. I don’t think this is entirely a bad thing; it exposes current pain points in React Native development when projects like this pop up. But we need to be careful and honest with ourselves as a community that this is not an ideal implementation of a library; if we were able to achieve the exact same result in JS, it would be preferred. The native approach is a hack to work around pain points in React Native. Native plugins should be used to expose low level general features that you can then build on top of from JS.

and the native driver for iOS and Android. This would slow down development of your personal project slightly, but you’d be giving back in a big way to the community and improving React Native for everybody, and the next time you need a custom spinner you can write it in JS.

is a well-made general purpose library, I’d just love it to be part of core in this case!).

So when people come up with one-off native solutions, I completely empathize with the need to ship something, but at the same time feel sad that the development time isn’t directed instead towards improving the core or a generalized solution.

If your company benefits from using React Native, you could hire a

(Janic), and tens of other features that you may use in your app today.

was needed to implement a contacts list screen for Brighten, so you could scroll through between 100 and 100,000 contacts and not end up with an empty screen as the JS tries to keep up with the scroll position, rather than bridging an existing native contacts view (which would inevitably end up with 20–30 props and still not be as customizable, portable, etc).

API for React Native and get it upstream, which will make the experience of uploading files through Firebase (and a bunch of other things) more pleasant out of the box.

Next time you consider reaching for native code to solve a problem in React Native, think about what exactly is preventing you from doing it in JS. Please remember that upstream improvements will pay long-term dividends for yourself and our community. Hiring a contractor for a few hours can be an excellent way to upstream a generalized version of native code you’ve used to ship your app. App & Flow, Callstack.io, Apperson Labs, Infinite Red, and Software Mansion are all good choices.

It’s up to the community to shape the future of React Native. I hope we can all agree that the best possible future is one in which the true benefits of React Native have been realized. One where you don’t need to depend on countless native plugins with varying degrees of stability and cross-platform support. A future where you rarely, if ever, need to touch or maintain native code.