Problem: Modals & the ceremony around managing them

I love that react allows us to write declarative user interfaces using JavaScript and JSX. However, when it comes to modals, I dislike how they are usually implemented in react - as hidden markup alongside main content made visible or hidden in response to state changes. This forces us to split our logic flow to different methods, and adds extra ceremony if we need to share any data between them.

To understand what I mean, look at the below fictitious example:

To start with, we have three methods, one for executing some logic before opening the modal, one to continue executing some logic after users confirms on the modal, and one to cleanup and hide the modal if the user cancelled.

There are multiple state variables for storing current order and customer details. These are temporarily stored during the lifetime of the modal, just so that we can share some data between the two methods and the modal. 

Then there is the visibility state variable for the modal itself.

Now, I am OK with this code even with all the boilerplate and ceremony; as long as there are no other modals on the same page. But if we introduce one more, it doubles the complexity!! Add one more, it becomes a maintainability nightmare.

The solution is what I call 'Awaitable Modals'. Or more appropriately, modals with an imperative API. In general, UI should be declarative and usage of imperative APIs are  not advised. However, I believe modals, alerts and toasts are good examples where an imperative API is so much better and makes sense. It's easier to imagine them as temporary UI elements that show up in response to user actions, instead of something that represents the application state.

This is so much simpler!  Let's list down the differences.

Modelling the modal API like this has made it easier for me to simplify the complexity around them in more than a few projects. I have been doing it like this since the Angular JS days of my early career, and I find it very useful.

Let's dive into how we can implement this API in React Native. Even though I am using React Native here, same pattern can be used with React web as well. Just change all 

's or semantically appropriate elements, and use your favourite modal library for the 

 function as parameter. It should return an object with 

 properties. We need a state variable as well here for controlling the visibility of the modal.

 for taking in additional parameters when opening the modal. Let's make the change.

I left a few comments in the code. These are the pending dots that need to be connected to make it work. A 

 variable works well here, which would hold all these values and methods for us.

Here's how it the finished hook would look:

We can use it as shown in the example under 

Here's a demo of the hook in action.
The code and sample usage are available at: 

sarathkcm/react-native-awaitable-modals

I wanted to acknowledge that this is not something new and if you searched google for an "imperative modal in react" you will find a lot of articles with various implementations. Some of the implementations actually closely resemble what I had implemented before in my projects, using a context and a global placeholder for rendering the modals. The general idea of an imperative modal itself is not new regardless of the framework, and there are many ways to achieve the same result.

The method mentioned in this article is something I came up only for the article. I like that it's isolated and scoped only to the parent page/component. However, since it's not something I use in production (yet), if you wanted to use it in your project, please make sure to test it thoroughly.

Modals in React and React Native for enabling better logic flow and removing code clutter. Awaitable modals expose an imperative API for showing, hiding and getting data from modals.

Awaitable Modals in React and React Native; Easily manage modals without pain.

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 feedback 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 →

Awaitable Modals in React and React Native; Easily manage modals without pain.

Modals in React and React Native for enabling better logic flow and removing code clutter. Awaitable modals expose an imperative API for showing, hiding and getting data from modals.

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