What if we could add placeholders in our apps that can display content fetched from a server; and what if we're able to build and host those content at the server as react-native components?

This would mean we could push new, feature-rich content to our apps without pushing app store updates. We could create dynamic home pages that change over short time periods. We could change the look and feel of the whole app to match the ongoing festival mood. We could even launch new journeys and experiences in the app without waiting for app reviews and app store approvals.

Below is a method I put together to achieve this. The idea is rather simple and straightforward, and I hope you like it.

If you have ever looked into implementing always changing home pages in mobile apps, you would have come across the term Server Driven UI or Server Driven Rendering.  It's a mechanism to render the pages in apps using configuration stored in a server.

In simple words - we define basic building blocks of the UI in the app, create a JSON configuration object describing the layout and building blocks of the page to render, fetch the configuration from the app, and render the layout with the components corresponding to the configuration.

Most implementations use a JSON configuration, and some use HTML or JSX renderers to push new components that are not present in the app.

SDUI is great, and helps lots of apps deliver a great user experience, often tailored for the logged in user. However, the UI rendered using this technique can usually only have predefined behavior, and to change that we'll need to push app updates. It'll also need us to learn the semantics of creating the configuration, which very well could evolve into a complex language in case of advanced and more capable frameworks.

Here I will describe a way to write UI components using a language we already know - react native, fetch them on-demand from a server, and render them in a react native app. Using this method, we can provide dynamic experiences within the app using full-fledged react (native) components and without pushing app store updates.

There are services like Microsoft Codepush that provide Over The Air app updates without pushing app store updates. You're probably better off with those if you are just looking for a way to provide updates to your app.

What's about to follow is purely a hobby exercise, and not fine-tuned to be used in production just yet.

React has already provided us with components that help with lazy loading. 

 takes in a promise that will resolve to a component function (or class) and returns a component that can be rendered within a 

 component. These components were introduced to support dynamic imports, as shown below.

 is supposed to be used with dynamic imports, it supports just about any Promise that resolves to a react component. This fits perfectly with our needs. As our components are going to be stored in server, and fetching and parsing them should give us a promise that resolves to a react component.

Let's abstract fetching and parsing of remote components into a method called 

Here, I chose to name the __id prop with underscores to make sure they don't conflict with the properties of the actual component fetched from the server. We also memoize the component based on the value of __id because we don't want to re-fetch the component on every render from the server.

Step 2: Fetching and parsing the remote components

, so we don't have to write our own parser for parsing source code of remote components. People generally have reservations about using 

, rightly so. However I see this as one of those occasions where it's fine to use it, and instead of using 

 constructor - to be safer from unforeseen bugs.

follow link to open the article

We can inject packages from our app into the remote components by defining them as properties of 

 is a function, since I did not want to load un-necessary modules which are not needed by the remote components.

Now in-order to inject the packages, we need to create a file called 

 in the app and write code as shown below.

For convenience, I have included only few packages, but ideally this should contain all packages from the app's package.json dependencies, and this file should be auto-generated during the build step.

, which are custom components from our app that we want to use in the remote components.

 function to accept a packages argument, and pass the object export from 

 function now, which is fairly straight-forward at this point. For convenience I'm going to hard-code the URL in the code itself. Since I'll be hosting the server in my laptop, I've used the host system's IP address when testing in android simulator. There is also a time query string added to the URL, to avoid caching of the remote components while developing.

It's time to setup and write the remote components now.

Step 3: Setting up the remote components project.

 as the bundler. The directory structure of the remote components project is very simple, as follows.

In rollup.config, we need to export an array of configs - one per each remote component bundle - otherwise rollup will extract common code into a common bundle. For our use case, we want everything the component refers in a single bundle file.

Instead of defining configs for each entry file, we generate configs for each file in the components folder.

 file will contain all the packages needed to write the react native components. In fact we can copy the dependencies from our app's 

 file, so that the remote components will have access to the same packages.

We can now start writing our first remote component.

A counter component example is provided below:

The code is exactly how we would have written this component in the app, and we can use any libraries available in the app. In theory we can add even new libraries - we just need to tweak the build process and bundle it along with the component.

We can access redux store using either hooks or 

. We should be able to access contexts and navigation objects as well.

Once the components are written, we can build them using 

 command, and start a development server using 

. Once you are ready to deploy, the files in 

 folder can be deployed and served as static files.

Step 4: Add placeholders in the app for dynamic components to render

These components can be placed anywhere and can render anything from a small button on a page to entire pages, or even a stack of pages.

Here's a demo of an App using lazy loaded remote-components. The source code for the demo app and the remote components are available at this 

This has been a long article. If you are still reading this, I hope you find the article interesting and useful. I haven't done any performance tests on this yet, but I believe there shouldn't be any significant degradation apart from the network and parsing delay during the initial load of the components. Once parsed, we can cache the parsed components in-memory to avoid subsequent fetches and parses.

Let me know how you feel about this technique in the comments.  Any suggestions to improve the code and any feedbacks or alternate approaches are always welcome. 🙂

Create and deliver up-to-date dynamic experiences in your React Native apps without app store updates.

Recent Articles tagged with react-native →

Lazy loading React Native components from a server

Create and deliver up-to-date dynamic experiences in your React Native apps without app store updates.

Subscribe to get notified about new posts