Our mission at Algolia is to make sure that every website or app has the best search experience possible. That’s why we created several clients for iOS (in Swift and objective-C), Android, Windows/C# and JavaScript.

But we’re always looking for new ways to help developers and are very interested in the possibilities introduced by React Native, Facebook’s latest initiative to change the way we build apps.

Based on the awesome React library (that we already use), React Native lets you develop applications for Android and iOS using Javascript, hopefully making the development process easier and more consistent. What’s even cooler is that it can leverage what’s already available on NPM such as algoliasearch-client-js or algoliasearch-helper.

But React Native is a new execution environment different from Node or the web. Some expected features are implemented, some are not. When we tried to use our libraries to build an app using React Native, we hit a few bumps. We want to share with you what those were and how we got over them.

TL;DR : we made our JS libraries compatible with React Native, and it’s available right now! And we made a sample to help you get started.

Not a Node polyfill

The first thing we noticed when working with React-Native is that even though it looks similar to Node, it’s not quite the same. React Native lets you use require() but doesn’t polyfill the Node standard libraries like Browserify or Webpack do. The reason it doesn’t do this is that it’s not using the same tool to do the packaging and they made the choice not to implement this compatibility layer.

In order to make our module work in this new environment, we need to provide the core Node modules used by our libraries. Hopefully, all those Node standard libraries are available on NPM and we just need to add them to our package.json file as we are installing them (--save for the win).

But won’t we now run into issues with the module running on Node because we’ve modified the package.json? Nope! Because of the built-in rules of require() in Node, we know that it will always use the built-in version if it is available.

The web but not exactly

Most of the work in our JS-client library is based on HTTP calls. And hopefully, React Native implements a version of XHR for us. Unfortunately, its XHR implementation comes with some particularities. Some of these differences break stuff, whereas some simplify the work. Let’s see in more detail what differs from the web:

• React-Native is for creating native apps, and they are not restricted to a single domain like web pages, so implementing CORS capabilities doesn’t make sense.
• React-Native doesn’t come in many versions, and the set of features is clearly defined, so there’s no need for web fallbacks/compat hacks such as JSONP.
• Our library also relies on XHR timeout, but it is not implemented there, so we rely on the good old setTimeout to implement this.

Those changes were only needed in the JS Client that handles the request to our API. The JS-Helper only relies on the client and some libraries, so it does not need further modifications.

New JS territories, here we come!

We applied what we learned about React Native to make our JS libraries, the JS client and the JS Helper compatible with it, so now you have a new way to build your mobile applications on Android, iOS and more. Let us know if you have any questions.

Get started with Algolia using React Native using our HN search sample.