DEV Community: Sarath Kumar CM

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

Sarath Kumar CM — Mon, 12 Jun 2023 12:54:45 +0000

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:

const [isVisible, setIsVisible] = useState(false);
const [order, setOrder] = useState(null);
const [customer, setCustomer] = useState(null);

const deleteOrder = async (orderId) => {
  // 1: Data fetched/computed before showing the modal
  const order = await fetchOrder(orderId);
  const customer = await fetchCustomer(order.customerId);
  const canDeleteOrder = await isDeleteAllowed(customer);
  if (!canDeleteOrder) {
    return;
  }
  // 2: Set the data in state so that modal can use it and
  setOrder(order);
  setCustomer(customer);
  // 3: Show the modal
  setIsVisible(true);
};

const onDeleteConfirm = (dataFromModal) => {
  // 4: Handle modal confirmation, process with data captured
  // from the modal and data fetched before showing the modal
  doSomethingWith(dataFromModal, order, customer);

  // 5: Hide modal
  setIsVisible(false);

  // 6: reset the state variables, because they were temporary
  setOrder(null);
  setCustomer(null);
};

const hideModal = () => {
  // 7: User cancelled, we need to cleanup and hide the modal.
  setIsVisible(false);
  setOrder(null);
  setCustomer(null);
};

return (
  <View>
    ....
    <Button 
        onPress={() => deleteOrder("123")} 
        title="Delete Order" />
    <Modal visible={isModalVisible}>
      <Text>{/* Display order and customer details */}</Text>
      <TextInput>{/*  capture data here */}</TextInput>
      <Button
        onPress={() => onDeleteConfirm(capturedData)}
        title="Confirm Delete"
      />
    </Modal>
    ....
  </View>
);

There is a lot going on here!

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.

Solution: Awaitable modals

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.

Here's how it would look like:

const { openModal, renderModal } = useAwaitableModal((modal, params) => (
  <View>
    <Text>
      {/* Display content from params or any state variable */}
      {params}
    </Text>
    <TextInput>{/* Capture some data*/}</TextInput>
    <Button
      onPress={() => modal.closeWithResult(capturedData)}
      title="Submit"
    />
    <Button
      onPress={() => modal.closeWithError("Error Message")}
      title="Cancel"
    />
  </View>
));

const deleteOrder = async (orderId) => {
  const order = await fetchOrderDetails(orderId);
  const customer = await fetchCustomerDetails(order.customerId);
  const canDeleteOrder = await isDeleteAllowed(customer);
  if (!canDeleteOrder) {
    return;
  }
  try {
    const dataFromModal = await openModal({
      /* Pass parameters to the modal */
    });
    await doSomethingWith(dataFromModal, order, customer);
  } catch (error) {
    // User cancelled the modal
    // Do anything you want here
  }
};

return (
  <>
    {renderModal()}
    <Button onPress={deleteOrder} title="Show Modal" />
  </>
);

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

To begin with - we have no state variables now! Not even for controlling the modal. We just call openModal whenever we want to show the modal.
There is only one method for handling the modal logic, instead of three in the previous example!! Also we can await for the modal to be closed!
Since there is only one method, we can share data between the pre-open, success and cancelled scenarios just by using the variables in scope. Data fetched/computed before opening the modal is still available after closing it. No need of cleaning up temporary state variables.
We can pass parameters to the modal! The modal can receive data directly via openModal method. No need to setup state variables for this too, in contrast to the previous example.

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.

Implementation

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 View elements to div's or semantically appropriate elements, and use your favourite modal library for the Modal.

First let's make a hook called useAwaitableModal that takes a render function as parameter. It should return an object with renderModal and openModal properties. We need a state variable as well here for controlling the visibility of the modal.

export const useAwaitableModal = (render) => {
  const [isVisible, setIsVisible] = useState(false);

  const renderModal = () => {
    return <Modal visible={isVisible}>{render()}</Modal>;
  };

  return () => ({
    openModal: () => setIsVisible(true),
    renderModal,
  });
};

If you notice in the previous example, render takes two arguments: modal as the API object, and params for taking in additional parameters when opening the modal. Let's make the change.

export const useAwaitableModal = (render) => {
  const [isVisible, setIsVisible] = useState(false);

  const modalAPI = {
    closeWithResult: (result) => {
      setIsVisible(false);
      return Promise.resolve(result);
    },
    closeWithError: (error) => {
      setIsVisible(false);
      return Promise.reject(error);
    },
  };

  const renderModal = () => {
    return (
      <Modal visible={isVisible}>
        {render(modalAPI, params)} // 1. WHERE DO params COME FROM??
      </Modal>
    );
  };

  const openModal = (params) => {
    // 2. We Recieve params here. 
    // Need to make it available for rendering.

    // 3. This should return a promise.
    // The promise should be resolved/rejected when we call modal.close
    return new Promise((resolve, reject) => {
      setIsVisible(true);
    });
  };

  return () => ({
    openModal,
    renderModal,
  });
};

I left a few comments in the code. These are the pending dots that need to be connected to make it work. A ref variable works well here, which would hold all these values and methods for us.

Here's how it the finished hook would look:

export const useAwaitableModal = (render) => {
  const [isVisible, setIsVisible] = useState(false);

  const promiseRef = useRef({
    resolve: () => {},
    reject: () => {},
    params: {},
  });

  const renderModalWithParamsAndContext = () => {
    const closeWithError = (error) => {
      promiseRef.current.reject(error);
      setIsVisible(false);
    };

    const closeWithResult = (result) => {
      promiseRef.current.resolve(result);
      setIsVisible(false);
    };

    const modalAPI = {
      isVisible,
      closeWithError,
      closeWithResult,
    };
    return (
      <Modal visible={isVisible} style={{ flex: 1 }} transparent={true}>
        {render(modalAPI, promiseRef.current.params)}
      </Modal>
    );
  };

  const openModal = (params) => {
    return new Promise((resolve, reject) => {
      promiseRef.current = {
        resolve,
        reject,
        params,
      };
      setIsVisible(true);
    });
  };
  return {
    openModal,
    renderModal: renderModalWithParamsAndContext,
  };
};

We can use it as shown in the example under Solution: Awaitable modals

Demo

Here's a demo of the hook in action.
The code and sample usage are available at: sarathkcm/react-native-awaitable-modals

Remarks

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.

Lazy loading React Native components from a server

Sarath Kumar CM — Thu, 11 Mar 2021 17:16:19 +0000

TL;DR

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.

Foreword

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.

This post was published on my blog. If you wish, you can continue reading there ➔.

Step 1: React.lazy and Suspense

React has already provided us with components that help with lazy loading. React.lazy and React.Suspense.
React.lazy takes in a promise that will resolve to a component function (or class) and returns a component that can be rendered within a <React.Suspense> component. These components were introduced to support dynamic imports, as shown below.

import React, { Suspense } from 'react';
const Component = React.lazy(() => import('./HeavyComponent'));

function MyComponent() {
  return (
    <div>
      <Suspense fallback={null}>
        <Component />
      </Suspense>
    </div>
  );
}

Even though React.lazy 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 fetchComponent and try to write a DynamicComponent that renders it.

import React, { useMemo, Suspense } from 'react';
import { Text, View } from 'react-native';

const DynamicComponent = ({ __id, children, ...props }) => {
    const Component = useMemo(() => {
        return React.lazy(async () => fetchComponent(__id))
    }, [__id]);

    return (
        <Suspense fallback={<View><Text>Loading...</Text></View>}>
            <Component {...props}>{children}</Component>
        </Suspense>
    )
};

export default React.memo(DynamicComponent);

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

Luckily for us, JavaScript comes with eval, so we don't have to write our own parser for parsing source code of remote components. People generally have reservations about using eval, rightly so. However I see this as one of those occasions where it's fine to use it, and instead of using eval, we'll use its cousin - the Function constructor - to be safer from unforeseen bugs.

There are still hurdles though.

Javascript doesn't understand JSX. Solution is to use a module bundler and babel to transform JSX to javascript code and bundle everything together. We'll do this in step 3.
We'll need to use a module loader to evaluate the bundle and give us the exported component. We'll write our own basic require function.
There has to be exactly one instance of React in our application (and the same might be true for some of the other libraries we use), therefore we'll need to specify all packages in node_modules as external dependencies while building the remote components. Then we need a way to provide instances of these packages to the remote components from the App's code. Since we're going to write our own version of require, we'll write it in a way to make this possible.

Below is a version of require function I found here, which I tweaked to our needs.

function getParsedModule(code, moduleName) {
    const _this = Object.create({
        "package-a": () => A // provide packages to be injected here.
    });

    function require(name) {
        if (!(name in _this) && moduleName === name) {
            let module = { exports: {} };
            _this[name] = () => module;
            let wrapper = Function("require, exports, module", code);
            wrapper(require, module.exports, module);
        } else if (!(name in _this)) {
            throw `Module '${name}' not found`
        }
        return (_this[name]()).exports;
    }

    return require(moduleName);
}

We can inject packages from our app into the remote components by defining them as properties of _this. Please note that each property of _this 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 packages.js in the app and write code as shown below.

import React from "react";
import ReactNative from "react-native";
import * as ReactRedux from "react-redux";
import * as ComponentsFromMyApp from "./components-from-my-app"
const Packages = {
    "react": () => ({ exports:  React }),
    "react-native":() => ({ exports: ReactNative }),
    "react-redux": () => ({ exports: ReactRedux }),
    "components-from-my-app"; () => ({ exports: ComponentsFromMyApp }),
}

export default Packages

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.

Notice that we have provided a components-from-my-app, which are custom components from our app that we want to use in the remote components.

Now, we can tweak our getParsedModule function to accept a packages argument, and pass the object export from packages.js file.

function getParsedModule(code, moduleName, packages) {
    const _this = Object.create(packages);
    function require(name) {
        if (!(name in _this) && moduleName === name) {
            let module = { exports: {} };
            _this[name] = () => module;
            let wrapper = Function("require, exports, module", code);
            wrapper(require, module.exports, module);
        } else if (!(name in _this)) {
            throw `Module '${name}' not found`
        }
        return (_this[name]()).exports;
    }

    return require(moduleName);
}

It's time to write our fetchComponent 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.

import { Text } from  "react-native";
import packages from "../packages";

export async function fetchComponent(id) {
    try {
        const text = await fetch(`http://10.0.2.2:8080/${id}.js?time=${Date.now()}`).then(a  => {
            if (!a.ok) {
                throw new Error('Network response was not ok');
            }
            return a.text()
        });
        return { default:  getParsedModule(text, id, packages ) };
    } catch (error) {
        console.log(error)
        return { default() { return <Text>Failed to Render</Text> } }
    }

}

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

Step 3: Setting up the remote components project.

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

.   ├── components/
        └── hello-world-component.js
    ├── babel.config.js 
    ├── rollup.config.js 
    └── package.json

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.

Here's my rollup.config.js file:

import babel from 'rollup-plugin-babel'
import commonjs from 'rollup-plugin-commonjs'
import resolve from 'rollup-plugin-node-resolve'
import { terser } from "rollup-plugin-terser";

const fs = require("fs");
const pkg = JSON.parse(require("fs")
                .readFileSync(require("path")
                .resolve('./package.json'), 'utf-8'));
const external = Object.keys(pkg.dependencies || {});

const allComponents = fs.readdirSync("./components");

const allFiles = allComponents
    .filter(a => a.endsWith(".js"))
    .map(a => `./components/${a}`)

const getConfig = (file) => ({
    input: file,
    output: [{ dir: "dist", format: 'cjs' }],
    plugins: [
        resolve(),
        babel(),
        commonjs(),
        terser()
    ],
    external
})

export default allFiles.map(getConfig)

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

babel.config.js file looks like this:

const presets = [
  [
    "@babel/preset-env", { modules: false }],
    "@babel/preset-react"
]
const plugins = []

plugins.push(["@babel/plugin-proposal-class-properties"])

module.exports = {
  presets,
  plugins
}

The package.json file will contain all the packages needed to write the react native components. In fact we can copy the dependencies from our app's package.json file, so that the remote components will have access to the same packages.

The file looks like this:

{
  "name": "remote-components",
  "scripts": {
    "start": "http-server ./dist",
    "build": "rollup --config ./rollup.config.js"
  },
  "dependencies": {
    // copy dependencies from app
  },
  "devDependencies": {
    "@babel/plugin-proposal-class-properties": "^7.13.0",
    "@babel/preset-env": "^7.13.9",
    "@babel/preset-react": "^7.12.13",
    "babel-core": "^6.26.3",
    "babel-plugin-module-resolver": "^4.1.0",
    "babel-preset-env": "^1.7.0",
    "http-server": "^0.12.3",
    "rollup": "^2.40.0",
    "rollup-plugin-babel": "^4.4.0",
    "rollup-plugin-commonjs": "^10.1.0",
    "rollup-plugin-node-resolve": "^5.2.0",
    "rollup-plugin-terser": "^7.0.2"
  }
}

We can now start writing our first remote component.

A counter component example is provided below:

import React, { useState } from 'react'
import { StyleSheet, Text, View, Button } from 'react-native'

const Counter = () => {
    const [count, setCount] = useState(0)
    return (
        <View style={{ margin: 15 }}>
            <Text>{count}</Text>
            <Button onPress={() => setCount(count+1)} title="Click Me!"/>
        </View>
    )
}
export default Counter

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 connect(). We should be able to access contexts and navigation objects as well.

Once the components are written, we can build them using npm run build command, and start a development server using npm start. Once you are ready to deploy, the files in dist 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.

import React, { useState } from 'react';
import ReactNative, { Text, View, Button } from 'react-native';
import DynamicComponent from "./dynamic-component";

export default function App() {
  const [show, setShow] = useState(false);
  return (
    <View className="App">
      <Text>Press the button below to load the component</Text>
      <Button onPress={() => setShow(!show)} title={show ? "Hide" : "Show"}></Button>
      {show && <DynamicComponent __id="counter"/>}
    </View>
  );
}

Demo

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 github repo

Remarks

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. :-)