DEV Community: Seif Ghezala 🇩🇿

Using Next.js and Vercel to instantly load a data-heavy website

Seif Ghezala 🇩🇿 — Tue, 06 Jul 2021 15:03:43 +0000

Article originally published on Tinloof.

A React application is JavaScript code that gets transformed into static HTML. This transformation is called "rendering".

Whenever you build a React application, you're inevitably making a decision on when to render it and you usually have 3 choices:

Client-side rendering: the application is rendered on the browser when the script loads.
Server-side rendering: the application is rendered on the server at every page request.
Static site generation: the application is rendered on the cloud provider (e.g. AWS, Vercel, Netlify) at every deployment.

A while ago, we faced this scenario when building illuminem, an energy news aggregator that showcases thousands of posts daily.

In this article, we'll talk about the performance problems we faced and how we ended up leveraging Next.js and Vercel to solve them.

The architecture

illuminem's architecture consists of a service that crawls RSS feeds and web pages for energy-related posts, categorizes them, and pushes them to a headless CMS called Sanity.

On the CMS, content managers create collections of these posts based on filters like "category".

For example, they can create a collection called "Renewables" and use the "category" filter to only include posts that match the "renewables" category:

Renewables category created from the CMS

The frontend is a Next.js application that fetches these collections and displays them as carousels.

illuminem's architecture

Using server-side rendering on all pages

Building a product is not easy because requirements change throughout the process, so we played it safe to make sure we can be flexible enough to handle these changes and reach the finish line ahead of time.

We were not sure how often we'd get new posts from the crawler, so we rendered most of our pages server-side.

We used getServerSideProps to fetch pages data from the CMS at every request.

Here's a simplified example from the homepage:

export default function HomePageContainer({ data }) {
  return (
    <Layout>
      <HomePage data={data} />
    </Layout>
  );
}

// Called on the server after each request
export async function getServerSideProps() {
  try {
    const data = await fetchHomeDataFromCMS();

    return {
      props: { data },
    };
  } catch (error) {
    console.error("Error fetching homepage data", error);
  }
}

The problem with server-side rendering

By the time we were done, the crawler had been running for 2 months and we started to feel the heavy page load.

Even after limiting the number of posts per collection, each carousel could have hundreds of posts and most of our pages had dozens of carousels, so we're talking about thousands of posts per page.

On average, it took 5 seconds to load a page on a very good WiFi connection.

It was no surprise that our TTFB (Time to First Byte) was heavily impacted since every time a user visits a page:

The server had to make a request with a huge query to the CMS.
The CMS had to parse that query and form the response data.
Once the server received a response from the CMS with thousands of posts, it had to render the React application before sending it to the browser.

Why not making pages static?

Some of the pages were not making any requests in getServerSideProps to get data before rendering. Next.js made these pages static by default.

But what if a page needs to fetch data before building?

Well, Next.js provides a getStaticProps that allows to fetch the data and render the page at build time. This would create static pages that load instantly.

export default function HomePageContainer({ data }) {
  return (
    <Layout>
      <HomePage data={data} />
    </Layout>
  );
}

// Called at build time
export async function getStaticProps() {
  try {
    const data = await fetchHomeDataFromCMS();

    return {
      props: { data },
    };
  } catch (error) {
    console.error("Error fetching homepage data", error);
  }
}

Unfortunately, most of the other pages could not be completely static. In fact, most of them have a "Most Trending" carousel to display the most viewed posts in the past 48 hours, so it had to be up-to-date with the actual views metrics.

If we fetch the data at build time, the "Most Trending" carousel wouldn't be updated until the next build.

Most Trending carousel

Why not making pages render client-side?

At this point, we wondered: why not make these pages render client-side?

The server wouldn't have to make any heavy work querying data and rendering the page.

Instead, each carousel can make a request to fetch its collection of data and then render it.

The main advantage would be that the TTFB would drastically decrease, making the page reach the browser pretty fast.

However, knowing that each page has on average 12-15 carousels, that would result in 12-15 queries per page visit. Our CMS payment plan is based on the number of queries we make, so this would make us reach the limit in no time and would certainly blow up when illuminem picks up more users.

On top of that, what we gain in performance in the server is lost in the client. The page would reach the browser fast, but it will be mostly a bunch of spinners. Each carousel would yet have to make a request to get its data and then render it.

Because of these two reasons, client-side rendering was out of the table.

Generating static pages dynamically

Note: if you prefer video format, here's a video explaining this section.

Next.js introduced incremental static regeneration in the 9.5 version release, making it possible to generate static pages at run-time.

We can now generate static pages at build time, which makes them load instantly.

But, how can we keep the "Most Trending" carousel content up-to-date?

Every time a user visits one of these pages, getStaticProps is run by the Next.js server in the background.

When the result of getStaticProps is different from the previous run because the CMS data changed, the stale page is replaced by an updated one.

The updated page is generated at run-time without affecting the user experience.

The best part is that we only had to set the revalidate property to 3600 to revalidate the page every hour.

export default function HomePageContainer({ data }) {
  return (
    <Layout>
      <HomePage data={data} />
    </Layout>
  );
}

// Called at build and run-time
export async function getStaticProps() {
  try {
    const data = await fetchHomeDataFromCMS();

    return {
      props: { data },
      // Revalidates the page every hour
      revalidate: 60 * 60,
    };
  } catch (error) {
    console.error("Error fetching homepage data", error);
  }
}

For pages that depend on a route parameter (e.g. /[category]), we were able to generate a static page for each possible parameter by using the getStaticPaths method:

import categories from "../categories";

export default function CategoryPageContainer({ data }) {
  return (
    <Layout>
      <CategoryPage data={data} />
    </Layout>
  );
}

export async function getStaticProps({ params: { category } }) {
  try {
    const data = await fetchCategoryDataFromCMS(category);

    return {
      props: { data },
      revalidate: 1,
    };
  } catch (error) {
    console.error("Error fetching homepage data", error);
  }
}

export async function getStaticPaths() {
  const categories = await fetchCategoriesFromCMS();

  return {
    paths: categories.map((category) => ({
      params: { category },
    })),
  };
}

Solving edge-cases with client-side rendering

Users can click on a post to see its details in a modal and share it on social media.

Modal to share social media

Each post modal has a URL and we could add the meta-data tags required to show a card preview snippet on the social media platforms.

Unfortunately, when such URLs are shared, social media platforms could not get the right meta-data tags since they are only added once the modal appears in the client.

To fix that, we generated at run-time a static page for each post.

Such pages only have the post modal rendered statically with the right meta-data. The rest of the page is rendered client-side.

We then used the URLs of these pages when sharing on social media.

export default function PostPage({ postData }) {
  const [homeData, setHomeData] = React.useState({});

  React.useEffect(() => {
    fetchHomeDataFromCMS().then(setHomeData);
  }, []);

  return (
    <>
      <Layout>{!homeData ? null : <HomePage data={homeData} />}</Layout>
      <PostModal data={postData} />
    </>
  );
}

export async function getStaticProps({ params: { postId } }) {
  const postData = await fetchPostDataFromCMS(postId);

  try {
    return {
      props: { postData },
      revalidate: 60 * 60,
    };
  } catch (error) {
    console.error("Error fetching post data", error);

    // Fallback to 404 page in case of error
    return { notFound: true };
  }
}

// Nothing is generated at build time
export async function getStaticPaths() {
  return {
    paths: [],
    fallback: "blocking",
  };
}

We set fallback to blocking in getStaticPaths to only return the page once it has finished loading. You can read more about the other fallback possibilities Next.js offers here.

The first request to such pages might be a bit slow, but all the following requests resolve immediately because their static version was already generated.

Social media platforms display now a proper snippet of the shared post because its required meta-data tags are available immediately in the HTML response.

Twitter card validation

Are you building a product with Vercel and Next.js?

If you plan to build or need help building a product using Vercel and Next.js, get in touch.

How to create React Toasts/Notifications with 0 dependencies

Seif Ghezala 🇩🇿 — Tue, 03 Nov 2020 23:23:51 +0000

Article originally published on Tinloof.

In this article, we'll build from scratch React Notifications (toasts) without using any third-party library (except React).

The notification component has the following requirements:

Four color variations: info (blue), success (green), warning (orange), and error (red).
It's positioned on the top right of the screen.
It's animated to slide in when it's added and slide out when it's removed. The other notifications should slide vertically when a notification is removed.
I can create notifications that close automatically after 10 seconds.
I can create notifications declaratively in JSX (e.g <Notification color="success" />).
I can create notifications imperatively by calling a function (e.g. success()).

The final source code can be found here and a demo can be viewed here.

Note about the boilerplate and CSS in this article

I used create-react-app to generate the boilerplate for this project and CSS modules to style it.

You're free to use any other tools to generate the boilerplate and style the component.

Creating the Notification component

Here's our directory structure, we'll go through every single file in it:

├── App.css
├── App.js
├── index.css
├── index.js
└── notify
   ├── Notification
   |  ├── Notification.module.css
   |  ├── index.js
   |  └── times.svg
   ├── createContainer
   |  ├── container.module.css
   |  └── index.js
   └── index.js

The Notification component

// notify/Notification/index.js

import React from "react";
import PropTypes from "prop-types";
import cn from "classnames";

import { ReactComponent as Times } from "./times.svg";
import styles from "./Notification.module.css";

export default function Notification({ color = Color.info, children }) {
  return (
    <div className={cn([styles.notification, styles[color]])}>
      {children}
      <button className={styles.closeButton}>
        <Times height={16} />
      </button>
    </div>
  );
}

export const Color = {
  info: "info",
  success: "success",
  warning: "warning",
  error: "error",
};

Notification.propTypes = {
  notificationType: PropTypes.oneOf(Object.keys(Color)),
  children: PropTypes.element,
};

The Notification component so far has 2 props:

color: a string value that determines the background color of the notification and can be either info, success, warning, or error.
children: any React elements we want to render inside the notification.

And here are its styles:

/* notify/Notification/Notification.module.css */

.notification {
  max-width: 430px;
  max-height: 200px;
  overflow: hidden;
  padding: 12px 48px 12px 12px;
  z-index: 99;
  font-weight: bold;
  position: relative;
}

.notification:not(:last-child) {
  margin-bottom: 8px;
}

.notification.info {
  background-color: #2196f3;
}

.notification.success {
  background-color: #4caf50;
}

.notification.warning {
  background-color: #ff9800;
}

.notification.error {
  background-color: #f44336;
}

.notification .closeButton {
  position: absolute;
  top: 12px;
  right: 12px;
  background: transparent;
  padding: 0;
  border: none;
  cursor: pointer;
}

.notification, .notification .closeButton {
  color: #fff;
}

Rendering notifications in the document's body

Our notifications should be rendered separately from the DOM structure of the application using them.

createContainer is a helper function that creates a container element for the notifications (if it doesn't exist already) and append it directly to the document's body:

// notify/createContainer/index.js
import styles from "./container.module.css";

export default function createContainer() {
  const portalId = "notifyContainer";
  let element = document.getElementById(portalId);

  if (element) {
    return element;
  }

  element = document.createElement("div");
  element.setAttribute("id", portalId);
  element.className = styles.container;
  document.body.appendChild(element);
  return element;
}

It has a fixed position and is placed on the top right as per our requirements:

/* notify/createContainer/container.module.css */

.container {
  position: fixed;
  top: 16px;
  right: 16px;
}

We can then use ReactDOM.createPortal to render the notification in the container we create:

// notify/Notification/index.js

const container = createContainer();

export default function Notification({ color = Color.info, children }) {
  return createPortal(
    <div className={cn([styles.notification, styles[color]])}>
      {children}
      <button className={styles.closeButton}>
        <Times height={16} />
      </button>
    </div>,
    container
  );
}

First demo

Before writing a demo, let's expose Notification and its Color object in notify/index.js so that they can be imported and used:

// notify/index.js

export { default as Notification, Color } from "./Notification";

Now let's write a demo to showcase the different notifications:

// App.js

import React from "react";
import "./App.css";
import { Notification, Color } from "./notify";

function App() {
  const [notifications, setNotifications] = React.useState([]);

  const createNotification = (color) =>
    setNotifications([...notifications, { color, id: notifications.length }]);

  return (
    <div className="App">
      <h1>Notification Demo</h1>
      <button onClick={() => createNotification(Color.info)}>Info</button>
      <button onClick={() => createNotification(Color.success)}>Success</button>
      <button onClick={() => createNotification(Color.warning)}>Warning</button>
      <button onClick={() => createNotification(Color.error)}>Error</button>
      {notifications.map(({ id, color }) => (
        <Notification key={id} color={color}>
          This is a notification!
        </Notification>
      ))}
    </div>
  );
}

export default App;

Our demo simply renders a list of notifications and has 4 different buttons to add colored notifications to our list.

First demo: showing basic colored notifications

Closing notifications

Let's make it possible to close notifications by adding an onDelete prop to Notification and making the close button invoke that function on click:

// notify/Notification/index.js

export default function Notification({
  color = Color.info,
  onDelete,
  children,
}) {
  return createPortal(
    <div className={cn([styles.notification, styles[color]])}>
      {children}
      <button onClick={onDelete} className={styles.closeButton}>
        <Times height={16} />
      </button>
    </div>,
    container
  );
}

Now, in App.js, we pass an onDelete prop function that deletes the corresponding notification from the list:

// App.js

function App() {
  const [notifications, setNotifications] = React.useState([]);

  const createNotification = (color) =>
    setNotifications([...notifications, { color, id: notifications.length }]);

  const deleteNotification = (id) =>
    setNotifications(
      notifications.filter((notification) => notification.id !== id)
    );

  return (
    <div className="App">
      <h1>Notification Demo</h1>
      <button onClick={() => createNotification(Color.info)}>Info</button>
      <button onClick={() => createNotification(Color.success)}>Success</button>
      <button onClick={() => createNotification(Color.warning)}>Warning</button>
      <button onClick={() => createNotification(Color.error)}>Error</button>
      {notifications.map(({ id, color }) => (
        <Notification
          key={id}
          onDelete={() => deleteNotification(id)}
          color={color}
        >
          This is a notification!
        </Notification>
      ))}
    </div>
  );
}

Closing notifications

Adding "slide-in" and "slide-out" animations

Notifications are added and deleted too fast, which might confuse users. By adding "slide-in" and "slide-out" animations, we make notifications behave more naturally and improve the user experience.

To slide the notification in, we simply use the translateX CSS transform and translate it from 100% to 0. Here's the corresponding animation created with keyframes:

/* notify/Notification/Notification.module.css */

@keyframes slideIn {
  from {
    transform: translateX(100%);
  }

  to {
    transform: translateX(0%);
  }
}

.notification.slideIn {
  animation-name: slideIn;
  animation-duration: 0.3s;
  animation-timing-function: ease-in-out;
}

"slide-out" is a bit more tricky. When hitting the close button, we need to have a "closing" phase before calling the onDelete prop function. During the closing phase, we can slide the notification out using translateX(150%) and add a transition to notification to smoothen the "slide-out".

Here are the styles corresponding to the "slide-out" animation:

/* notify/Notification/Notification.module.css */

.notification {
  ...
  transition: transform 0.3s ease-out;
}

.notification.slideOut {
  transform: translateX(150%);
  flex: 0;
}

To achieve the closing phase in Notification, we can use a boolean state variable isClosing (set to false by default) . When we hit the close button, we set isClosing to true , wait for a the transition duration (300ms here), and then call the onDelete function.

We only use the slideIn animation styles when we're not in the closing phase (i.e. isClosing=false) and slideOut animation styles when we're in the closing phase (i.e. isCloseing=true).

// notify/Notification/index.js

let timeToDelete = 300;

export default function Notification({
  color = Color.info,
  onDelete,
  children,
}) {
  const [isClosing, setIsClosing] = React.useState(false);

  React.useEffect(() => {
    if (isClosing) {
      const timeoutId = setTimeout(onDelete, timeToDelete);

      return () => {
        clearTimeout(timeoutId);
      };
    }
  }, [isClosing, onDelete]);

  return createPortal(
    <div
      className={cn([
        styles.notification,
        styles[color],
        { [styles.slideIn]: !isClosing },
        { [styles.slideOut]: isClosing },
      ])}
    >
      {children}
      <button onClick={() => setIsClosing(true)} className={styles.closeButton}>
        <Times height={16} />
      </button>
    </div>,
    container
  );
}

Adding "slide-in" and "slide-out" animations

Animating notifications shift

When a notification is deleted, the ones below it shift suddenly to the top to fill up its position.

To make this shift more natural, let's add a container around the notification that shrinks smoothly during the closing phase:

// notify/Notification/index.js

let timeToDelete = 300;

export default function Notification({
  color = Color.info,
  onDelete,
  children,
}) {
  const [isClosing, setIsClosing] = React.useState(false);

  React.useEffect(() => {
    if (isClosing) {
      const timeoutId = setTimeout(onDelete, timeToDelete);

      return () => {
        clearTimeout(timeoutId);
      };
    }
  }, [isClosing, onDelete]);

  return createPortal(
    <div className={cn([styles.container, { [styles.shrink]: isClosing }])}>
      <div
        className={cn([
          styles.notification,
          styles[color],
          { [styles.slideIn]: !isClosing },
          { [styles.slideOut]: isClosing },
        ])}
      >
        {children}
        <button
          onClick={() => setIsClosing(true)}
          className={styles.closeButton}
        >
          <Times height={16} />
        </button>
      </div>
    </div>,
    container
  )

The container has a max-height of 200px by default and shrinks to 0 during the closing phase. We should also move the margin definition to the container:

/* notify/Notification/Notification.module.css */

.container {
  overflow: hidden;
  max-height: 200px;
  transition: max-height 0.3s ease-out;
}

.container:not(:last-child) {
  margin-bottom: 8px;
}

.container.shrink {
  max-height: 0;
}

Animating notifications shift

Making notifications close automatically

Let's add an autoClose boolean prop to the Notification component and use useEffect to close the notification after 10 seconds if the prop is set to true.

// notify/Notification/index.js

export default function Notification({
  color = Color.info,
  autoClose = false,
  onDelete,
  children,
}) {
  const [isClosing, setIsClosing] = React.useState(false);

  React.useEffect(() => {
    if (autoClose) {
      const timeoutId = setTimeout(() => setIsClosing(true), timeToClose);

      return () => {
        clearTimeout(timeoutId);
      };
    }
  }, [autoClose]);

Now let's modify our demo to pass autoClose=true to the notifications:

// App.js

function App() {
  const [notifications, setNotifications] = React.useState([]);

  const createNotification = (color) =>
    setNotifications([...notifications, { color, id: notifications.length }]);

  const deleteNotification = (id) =>
    setNotifications(
      notifications.filter((notification) => notification.id !== id)
    );

  return (
    <div className="App">
      <h1>Notification Demo</h1>
      <button onClick={() => createNotification(Color.info)}>Info</button>
      <button onClick={() => createNotification(Color.success)}>Success</button>
      <button onClick={() => createNotification(Color.warning)}>Warning</button>
      <button onClick={() => createNotification(Color.error)}>Error</button>
      {notifications.map(({ id, color }) => (
        <Notification
          key={id}
          onDelete={() => deleteNotification(id)}
          color={color}
          autoClose={true}
        >
          This is a notification!
        </Notification>
      ))}
    </div>
  );
}

Now notifications close automatically after 10 seconds of their creation:

Making notifications close automatically

Creating notifications imperatively

We want to be able to create notifications imperatively, by calling functions such as success() or error().

The trick is to create a component similar to our App one that is rendered by default and provides us a function to create notifications.

Let's create NotificationsManager to serve that purpose:

// notify/NotificationsManager

import React from "react";
import PropTypes from "prop-types";

import Notification from "./Notification";

export default function NotificationsManager({ setNotify }) {
  let [notifications, setNotifications] = React.useState([]);

  let createNotification = ({ color, autoClose, children }) => {
    setNotifications((prevNotifications) => {
      return [
        ...prevNotifications,
        {
          children,
          color,
          autoClose,
          id: prevNotifications.length,
        },
      ];
    });
  };

  React.useEffect(() => {
    setNotify(({ color, autoClose, children }) =>
      createNotification({ color, autoClose, children })
    );
  }, [setNotify]);

  let deleteNotification = (id) => {
    const filteredNotifications = notifications.filter(
      (_, index) => id !== index,
      []
    );
    setNotifications(filteredNotifications);
  };

  return notifications.map(({ id, ...props }, index) => (
    <Notification
      key={id}
      onDelete={() => deleteNotification(index)}
      {...props}
    />
  ));
}

NotificationsManager.propTypes = {
  setNotify: PropTypes.func.isRequired,
};

NotificationsManager receives one prop setNotify , which is used to give access to the createNotification function to create notifications imperatively.

Now let's render NotificationsManager in the same container as Notfication and create our notification creation functions. We access createNotification function through the setNotify prop and use it to create our notification creation functions:

// notify/index.js

import React from "react";
import ReactDOM from "react-dom";

import NotificationsManager from "./NotificationsManager";
import Notification, { Color } from "./Notification";
import createContainer from "./createContainer";

const containerElement = createContainer();
let notify;

ReactDOM.render(
  <NotificationsManager
    setNotify={(notifyFn) => {
      notify = notifyFn;
    }}
  />,
  containerElement
);

export { Notification, Color };

export function info(children, autoClose) {
  return notify({
    color: Color.info,
    children,
    autoClose,
  });
}

export function success(children, autoClose) {
  return notify({
    color: Color.success,
    children,
    autoClose,
  });
}

export function warning(children, autoClose) {
  return notify({
    color: Color.warning,
    children,
    autoClose,
  });
}

export function error(children, autoClose) {
  return notify({
    color: Color.error,
    children,
    autoClose,
  });
}

Now let's test these functions out in App.js . Let's also make 2 changes to improve our demo:

Make it possible to show both declarative and imperative approaches.
Use react-highlight to show a code snippet for each approach.

// App.js

import React from "react";
import Highlight from "react-highlight";

import "./App.css";
import "./highlight-js-night-owl.css";

import { Notification, Color, info, success, warning, error } from "./notify";

const message = "This is a notification!";

function DeclarativeDemo() {
  const [notifications, setNotifications] = React.useState([]);

  const createNotification = (color) =>
    setNotifications([...notifications, { color, id: notifications.length }]);

  const deleteNotification = (id) =>
    setNotifications(
      notifications.filter((notification) => notification.id !== id)
    );

  return (
    <>
      <Highlight>
        {`const [notifications, setNotifications] = React.useState([]);

const createNotification = (color) =>
  setNotifications([...notifications, { color, id: notifications.length }]);

const deleteNotification = (id) =>
  setNotifications(
    notifications.filter((notification) => notification.id !== id)
  );

return (
  <>
    <button onClick={() => createNotification(Color.info)}>Info</button>
    <button onClick={() => createNotification(Color.success)}>Success</button>
    <button onClick={() => createNotification(Color.warning)}>Warning</button>
    <button onClick={() => createNotification(Color.error)}>Error</button>
    {notifications.map(({ id, color }) => (
      <Notification
        key={id}
        onDelete={() => deleteNotification(id)}
        color={color}
        autoClose={true}
      >
        {message}
      </Notification>
    ))}
  </>
);`}
      </Highlight>
      <button onClick={() => createNotification(Color.info)}>Info</button>
      <button onClick={() => createNotification(Color.success)}>Success</button>
      <button onClick={() => createNotification(Color.warning)}>Warning</button>
      <button onClick={() => createNotification(Color.error)}>Error</button>
      {notifications.map(({ id, color }) => (
        <Notification
          key={id}
          onDelete={() => deleteNotification(id)}
          color={color}
          autoClose={true}
        >
          {message}
        </Notification>
      ))}
    </>
  );
}

function ImperativeDemo() {
  return (
    <>
      <Highlight>
        {`<>
  <button onClick={() => info(message, true)}>Info</button>
  <button onClick={() => success(message, true)}>Success</button>
  <button onClick={() => warning(message, true)}>Warning</button>
  <button onClick={() => error(message, true)}>Error</button>
</>`}
      </Highlight>
      <button onClick={() => info(message, true)}>Info</button>
      <button onClick={() => success(message, true)}>Success</button>
      <button onClick={() => warning(message, true)}>Warning</button>
      <button onClick={() => error(message, true)}>Error</button>
    </>
  );
}

function App() {
  const [demo, setDemo] = React.useState("declarative");

  return (
    <div className="App">
      <select onChange={(e) => setDemo(e.target.value)}>
        <option value="declarative">Declarative demo</option>
        <option value="imperative">Imperative demo</option>
      </select>
      {demo === "declarative" ? <DeclarativeDemo /> : <ImperativeDemo />}
    </div>
  );
}

export default App;

Note: we'd love to help you build beautiful and fast web applications. Get in touch with us.

How we boosted the performance of a Gatsby website by 80%

Seif Ghezala 🇩🇿 — Sun, 19 Jul 2020 00:00:00 +0000

Article originally published on Tinloof.

Final perf

Sbaï Dentaire is the number 1 user-rated dental practice in Casablanca (Morocco) by Google users:

Google Reviews results for Sbaï Dentaire

Many patients book appointments through the website on the go from their mobile, therefore page speed is critical to avoid a high bounce rate.

This article explains how we improved the performance of their website, which is built with Gatsby.

Note about Gatsby: this is just a simple presentation website, it would have made sense to implement it with pure HTML, CSS, and JavaScript. It would avoid the cost of extra JavaScript that comes with Gatsby and React, and the performance should be better than anything we'd try to achieve with Gatsby.

However, there is a plan to integrate a blog to the website in the future and Gatsby makes it easier.

Measuring performance

Measuring performance steers our work by identifying potential performance issues and making sure we're progressing in the right direction after making any changes.

How to measure performance?

To measure the performance, we use Google's Lighthouse tool, which is available out of the box in Chrome:

Google Lighthouse tool

To keep the test conditions as close to the live version, we make sure of the following:

The tests are made on the production build.
We focus on mobile users since they tend to be the ones with the most critical network connection. Having a high performance on mobile is also often followed by an even higher one on desktop.
The tests are made in Chrome Incognito mode, to avoid getting affected by Chrome Extensions. This is recommended by Lighthouse itself:

Lighthouse recommendation about Chrome extensions

The Simulated Throttling option is enabled in Lighthouse. This enables us to simulate a realistic slow network connection:

Network throttling option

Lighthouse scores vary for each time you run it. To improve the accuracy of our measured progress, we conduct 3 runs per performance test instead of 1.

We also keep track of 3 metrics:

Performance score (the most important one): overall performance of the page.
First Contentful Paint: time (in seconds) it takes for the first element in the DOM to render.
Time to Interactive: time (in seconds) it takes for the page to fully load and the buttons/inputs to be usable.

About the current performance

When we run the first 3 tests with Lighthouse, we get the following:

Current situation (Test 1)

Current situation (Test 2)

Current situation (Test 3)

When we average the metrics in the 3 tests, we get the following:

Metric	Value
Performance	54
First Contentful Paint	2.1 s
Time to Interactive	10.6 s

Although the First Contentful Paint time is acceptable, the performance score and the Time to Interactive should definitely be improved.

Where do we stand against competitors?

We ran the same tests with the other top 4 ranked dental practice websites and gathered the following data:

Comparing performance with competitors

From what we see in the graph above, Sbaï Dentaire's website is performing well relative to competitors (aside from Competitor C).

C outperforms Sbaï Dentaire in the overall performance score and in the Time to Interactive.

This emphasizes the importance of prioritizing these 2 metrics. Nonetheless, we should try to improve the First Contentful Paint if possible.

Improving the performance of images

One problem we quickly notice is that the website is making huge network requests to fetch images (mostly greater than 600 KB of payload):

Enormous image requests

Another issue is spotted in the Network Tab where we see that images are fetched simultaneously at page load:

Images fetched simultaneously

We can do so by:

Using WebP format for images for browsers that support it. This format provides an image compression that is way more efficient than png, which shaves a lot of kBs from our images.
Lazy-loading images to only fetch the ones visible in the viewport. This improves the work done by the browser when loading the page for the first time since a large part of the images won't even be loaded.
Saving on request payload by reducing the requested size on mobile. This technique is known as Art Direction.

We'd normally use gatsby-image to handle the previous issues, but there is a bug in the library affecting Art Direction. Fortunately, we can use the module gatsby-plugin-sharp with the native <picture> tag to achieve the same result.

gatsby-plugin-sharp can apply the necessary transformations through GraphQL queries. Here's an example query we used to transform home.png, the image used in the home section:

function getImageSources() {
  const data = useStaticQuery(graphql`
    query {
      mobileImage: file(relativePath: { eq: "home.png" }) {
        childImageSharp {
          fixed(width: 500) {
            ...GatsbyImageSharpFixed_withWebp_noBase64
          }
        }
      }
      desktopImage: file(relativePath: { eq: "home.png" }) {
        childImageSharp {
          fixed(width: 900) {
            ...GatsbyImageSharpFixed_withWebp_noBase64
          }
        }
      }
    }
  `);

  return {
    mobileImage: data.mobileImage.childImageSharp.fixed,
    desktopImage: data.desktopImage.childImageSharp.fixed
  };
}

The function getImageSources :

Gets two different sizes for home.png (500px for mobile and 900px for desktop).
Uses GatsbyImageSharpFixed_withWebp_noBase64 fragment to get the src , srcSet, webpSrc, and webSrcSet data for both sizes. These attributes are then used to apply proper Art Direction with a picture tag.

We can then use the data to tell the browser to:

Fetch the mobile image for screens less than 480px of width.
Use webp format when possible (since not all browsers support it).

To avoid code redundancy, and make sure loading=lazy attribute is used with all images, we create an Image component to use whenever we want to render images:

function Image({ image, desktopImage, styles, alt }) {
  return (
    <picture>
      {desktopImage && (
        <>
          <source media="(min-width: 480px)" srcSet={desktopImage.srcSet} />
          <source
            media="(min-width: 480px)"
            srcSet={desktopImage.srcSetWebp}
            type="image/webp"
          />
        </>
      )}
      <source srcSet={image.srcWebp} type="image/webp" />
      <img
        src={image.src}
        srcSet={image.srcSet}
        alt="Homepage"
        loading="lazy"
        css={styles}
        alt={alt}
      />
    </picture>
  );
}

const imageShape = PropTypes.shape({
  src: PropTypes.string.isRequired,
  srcSet: PropTypes.string,
  srcWebp: PropTypes.string,
  srcSetWebp: PropTypes.string
});

Image.propTypes = {
  image: imageShape.isRequired,
  desktopImage: imageShape
};

Here's how the home section component uses it:

function Home() {
  const { mobileImage, desktopImage } = getImageSources();

  return (
    <div id="home" css={styles.home}>
      <section css={styles.textContainer}>
        <section>
          <h1>Un beau sourire à Casablanca</h1>
          <p>Assuré par un soin dentaire de qualité depuis 30 ans</p>
        </section>
        <a className="button primary" href="#contact">
          Nous contacter
        </a>
      </section>
      <div css={styles.imageContainer}>
        <Image
          image={mobileImage}
          desktopImage={desktopImage}
          alt="Homepage"
          styles={styles.img}
        />
      </div>
    </div>
  );
}

For sections that require fetching a batch of images, we use the relativeDirectory filter in the GraphQL query to fetch all images in a certain directory and create a map of imageId -> imageData to use when rendering these images.

Here's an example of the query used to fetch images for the Reviews section:

 function getImagesMap() {
  const data = useStaticQuery(graphql`
    query {
      allFile(filter: { : { eq: "reviews" } }) {
        nodes {
          childImageSharp {
            fixed(width: 90) {
              ...GatsbyImageSharpFixed_withWebp_noBase64
            }
          }
          name
        }
      }
    }
  `);

  return imagesToMap(data.allFile.nodes);
}

And here's the body of imagesToMap :

function imagesToMap(images) {
  return images.reduce(
    (acc, { name, childImageSharp: { fixed } }) => ({ ...acc, [name]: fixed }),
    {}
  );
}

We then iterate through the images data and render them with our Image component:

function Reviews() {
  const imagesMap = getImagesMap();

    return (
        ...
        {data.map(review => (
          <Image
            alt={review.name}
            image={imagesMap[review.image]}
            styles={styles.img}
          />
        }
    ...
);

Let's check if images are optimized

All images are fetched in webp format and their sizes got dramatically reduced. The Network Tab shows the following:

Optimized images

We also see that images are lazy-loaded on scroll whenever they're close to appearing in the viewport:

Images are lazy-loaded

Resulting performance

Now that all images issues are fixed, let's run Lighthouse again and check the website's performance:

Optimizing images (Test 1)

Optimizing images (Test 2)

Optimizing images (Test 3)

Metric	Initial value	New value	Overall Progress
Performance	54	63.3	+ 9.3 (+ 17%)
First Contentful Paint	2.1 s	1.8 s	- 0.3 s
Time to Interactive	10.6 s	9.2 s	- 1.4 s

We solved the issues with images, which resulted in a noticeable performance improvement:

The overall Performance improved by 17%.
The First Contentful Paint is 300 ms faster.
The Time to Interactive is 1.4 s faster.

Lazy-loading Google Maps

When we look at Lighthouse reported problems, we find an issue with the Google Maps used in the Contact section:

Google Maps issue

We see 2 problems:

Google Maps scripts and images are not lazy-loaded.
Google Maps images are not efficiently compressed since they're using either jpg or png.

Lazy-loading Google Maps when the user scrolls close enough to the Contact section should solve these issues.

To detect when an element (in our case the Contact section) appears in the viewport, we create a useInViewPort hook which leverages the power of IntersectionObserver to do its job:

const THRESHOLD = 0;

export default function useInViewPort() {
  let nodeRef = React.useRef(null);
  let observerRef = React.useRef(null);

  const [isVisible, setIsVisible] = React.useState(false);

  React.useEffect(() => {
    observerRef.current = new IntersectionObserver(
      entries => {
        setIsVisible(entries[0].isIntersecting);
      },
      { THRESHOLD }
    );

    observerRef.current.observe(nodeRef.current);

    return () => {
      observerRef.current.disconnect();
    };
  }, []);

  React.useEffect(() => {
    if (isVisible) {
      observerRef.current.disconnect();
    }
  }, [isVisible]);

  return [nodeRef, isVisible];
}

We then use it in the Contact section to lazy-load Google Maps:

function Contact() {
  const mapRef = React.useRef();
  const [nodeRef, isVisible] = useInViewport();

  function initialize() {
    new window.google.maps.Map(mapRef.current, mapOptions);
  }

  React.useEffect(() => {
    if (isVisible) {
      const script = document.createElement("script");
      script.src = `https://maps.googleapis.com/maps/api/js?key=${API_KEY}&language=fr`;
      script.addEventListener("load", initialize);
      document.body.appendChild(script);
    }
  }, [isVisible]);

  return (
    <div ref={nodeRef}>
            ...
        <section>
          <div ref={mapRef} css={styles.map}></div>
        </section>
            ...
    </div>
  );
}

Checking if Google Maps is lazy-loaded

We do so by checking the Network Tab while scrolling:

Google Maps lazy-loaded

Measuring the new performance

Lighthouse gives the following new performance metrics:

Lazy-loading Google Maps (Test 1)

Lazy-loading Google Maps (Test 2)

Lazy-loading Google Maps (Test 3)

Metric	Initial value	New value	Overall Progress
Performance	54	97.3	+ 43.3 (+ 80%)
First Contentful Paint	2.1 s	2.1 s	0
Time to Interactive	10.6 s	2.6 s	- 8 s

Let's summarize what we achieved:

We brought the page performance from 54 to 97.3 (an improvement of 80%).
We reduced the time it takes for the page to be interactive by 8 s.

Improving font loading speed

When using the url provided by Google fonts to load fonts, we're actually loading a CSS file that loads a big number of variations of the font we want to use.

We can improve that by manually loading only the latin variations of the the fonts used in the page:

  @font-face {
    font-family: "Montserrat";
    font-style: normal;
    font-weight: 400;
    font-display: swap;
    src: local("Montserrat Regular"), local("Montserrat-Regular"),
      url(https://fonts.gstatic.com/s/montserrat/v14/JTUSjIg1_i6t8kCHKm459WlhyyTh89Y.woff2)
        format("woff2");
    unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA,
      U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212,
      U+2215, U+FEFF, U+FFFD;
  }

  @font-face {
    font-family: "Montserrat";
    font-style: normal;
    font-weight: 500;
    font-display: swap;
    src: local("Montserrat Medium"), local("Montserrat-Medium"),
      url(https://fonts.gstatic.com/s/montserrat/v14/JTURjIg1_i6t8kCHKm45_ZpC3gnD_vx3rCs.woff2)
        format("woff2");
    unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA,
      U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212,
      U+2215, U+FEFF, U+FFFD;
  }

  @font-face {
    font-family: "Montserrat";
    font-style: normal;
    font-weight: 700;
    font-display: swap;
    src: local("Montserrat Bold"), local("Montserrat-Bold"),
      url(https://fonts.gstatic.com/s/montserrat/v14/JTURjIg1_i6t8kCHKm45_dJE3gnD_vx3rCs.woff2)
        format("woff2");
    unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA,
      U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212,
      U+2215, U+FEFF, U+FFFD;
  }

We also emphasize to the browser that we want to fetch these fonts as early as possible. To do so, we use the preload attribute in the links used to load the fonts:

        <link
          rel="preload"
          as="font"
          href="https://fonts.gstatic.com/s/montserrat/v14/JTUSjIg1_i6t8kCHKm459WlhyyTh89Y.woff2"
          crossOrigin="true"
        />
        <link
          rel="preload"
          as="font"
          href="https://fonts.gstatic.com/s/montserrat/v14/JTURjIg1_i6t8kCHKm45_ZpC3gnD_vx3rCs.woff2"
          crossOrigin="true"
        />
        <link
          rel="preload"
          as="font"
          href="https://fonts.gstatic.com/s/montserrat/v14/JTURjIg1_i6t8kCHKm45_ZpC3gnD_vx3rCs.woff2"
          crossOrigin="true"
        />

We also use <link rel=preconnect> to emphasize to the browser the priority of these fonts when loading resources:

<link rel="preconnect" href="https://fonts.gstatic.com/s/montserrat/" />

The final test

Running Lighthouse after this gives the following results:

Improved fonts loading (Test 1)

Improved fonts loading (Test 2)

Improved fonts loading (Test 3)

Metric	Initial value	New value	Overall Progress
Performance	54	97.3	+ 43.3 (+ 80%)
First Contentful Paint	2.1 s	1.8 s	- 0.3 s
Time to Interactive	10.6 s	2.9 s	- 7.7 s

We brought the page performance from 54 to 97.3 (an improvement of 80%).
We reduced the First Contentful Paint by 300 ms.
We reduced the time it takes for the page to be interactive by 7.7 s.

Looking back at the competition

Here's how we're performing now compared to the rest of the competition:

Comparing performance with competitors

Compared to its fastest competitor (C), Sbaï Dentaire overall performance score is 32% higher and its Time to Interactive is almost 3 times faster.

Note: we'd love to help you improve or build blazing fast web pages. Get in touch with us.

How to make your own SplitPane React component with 0 dependencies

Seif Ghezala 🇩🇿 — Mon, 01 Jul 2019 18:47:20 +0000

A SplitPane is a collection of 2 elements whose heights can be changed by dragging a line that separates them. Based on its layout, a SplitPane can be horizontal or vertical.
If you've ever used the Chrome dev tools, you probably came across both versions of the SplitPane.
For example, the Elements section of the dev tools contains a horizontal SplitPane:

Elements section of the Chrome Dev Tools showing a horizontal SplitPane componentt

You can also find a vertical SplitPane in the Sources section of the dev tools:

Sources section of the Chrome Dev Tools showing a vertical SplitPane component

In this article, we'll create our own SplitPane component without any dependencies. Although we'll only build a vertical version, you can apply the same logic and slightly change it to build the horizontal one.
This is how our final result will look like:

alt="Final result">
Final result

The final source code can be found here.

This article will touch the following React concepts:

Handling state using the React useState hook.
React refs with React.createRef() and React.useRef() . We will their applications to reference DOM elements but also to handle mutating values.
Creating a React Context and subscribing to it using the useContext() React hook.

If you're not familiar with these concepts, this is a good pragmatic guide to get yourself familiar with them.

💡 The trick (spoiler alert)

Our vertical SplitPane has 1 requirement: whenever the separator is dragged, the sizes of the top and bottom panes should be altered accordingly.
Although that's true, there is another way to look at it and that will make our implementation simpler.
If we think about it, dragging the separator is modifying the size of 1 element only. The other element is only taking the remaining space.
When we move separator up, we are only decreasing the size of the top pane. The bottom pane will take whatever remaining space.

Note: It's very important that we take some time to understand this since it's the core of our logic later.

Step 1: basic setup

Let's first have a very basic setup that we can build on top of.
To start with, our SplitPane component is merely a flex container div. It renders its first child, a separator div, and a second child.
SplitPane has 2 sub-components: Top and Bottom. The sub-components are simple divs that accept children so that we can populate them as we like.
Initially, Top & Bottom split equally the height of SplitPane. To make that happen, they both have a flex: 1 in their styling (c.f. /style.css ).

// SplitPlane.js
export default function SplitPane({ children, ...props }) {
  return (
    <div {...props} className="split-pane">
      {children[0]}
      <div className="separator" />
      {children[1]}
    </div>
  );
}

SplitPane.Top = function SplitPaneTop(props) {
  return <div {...props} className="split-pane-top" />;
};

SplitPane.Bottom = function SplitPaneBottom(props) {
  return <div {...props} className="split-pane-bottom" />;
};

/* styles.css */
.split-pane {
  display: flex;
  flex-direction: column;
}

.split-pane-top,
.split-pane-bottom {
  flex: 1;
  overflow: hidden;
}

.split-pane-top {
  background: ...
}
.split-pane-bottom {
  background: ...
}

.separator {
  border: 5px solid black;
  cursor: row-resize;
}

// index.js
function App() {
  return (
    <div className="App">
      <SplitPane>
        <SplitPane.Top />
        <SplitPane.Bottom />
      </SplitPane>
    </div>
  );
}

Step 2: getting the Top pane height

Our logic is based on the Top pane height. Without it, we can't do any calculation.

We have 2 options:

Enforce on the user to pass an absolute height value.
Calculate the height ourselves once the Top pane renders the first time.

If you chose the first option, you can skip the rest of this step.

The height of the Top pane should be in SplitPane

Our logic will be based in the SplitPane component. Thus, the height of Top needs to be available in the state of SplitPane. We can then create a context for the Splitpane component to hold:

The height of the Top pane.
A function to update that height.

// SplitPlane.js
const splitPaneContext = React.createContext();

export default function SplitPane({ children, ...props }) {
  const [topHeight, setTopHeight] = React.useState(null);

  return (
    <div {...props} className="split-pane">
      <splitPaneContext.Provider value={{ topHeight, setTopHeight }}>
        {children[0]}
        <div className="separator" />
        {children[1]}
      </splitPaneContext.Provider>
    </div>
  );
}

SplitPane.Top = function SplitPaneTop(props) {
  return <div {...props} className="split-pane-top" />;
};

SplitPane.Bottom = function SplitPaneBottom(props) {
  return <div {...props} className="split-pane-bottom" />;
};

So, how do we get that height then?

We can obtain the height of the top pane in the component. To do so, we create a reference to the DOM element and get its clientHeight after the first render using React.useEffect .
To detect the first render, we can just see if our height variable has its initial null value.
We can consume both the height of the Top pane and its setter function using the React.useContext method. Using the setter function, we can set the height of the Top pane in the state of the SplitPane component.

// SplitPlane.js
const splitPaneContext = React.createContext();

export default function SplitPane({ children, ...props }) {
  const [topHeight, setTopHeight] = React.useState(null);

  return (
    <div {...props} className="split-pane">
      <splitPaneContext.Provider value={{ topHeight, setTopHeight }}>
        {children[0]}
        <div className="separator" />
        {children[1]}
      </splitPaneContext.Provider>
    </div>
  );
}

SplitPane.Top = function SplitPaneTop(props) {
  const topRef = React.createRef();
  const { topHeight, setTopHeight } = React.useContext(splitPaneContext);

  React.useEffect(() => {
    if (!topHeight) {
      setTopHeight(topRef.current.clientHeight);
      topRef.current.style.flex = "none";
      return;
    }
  });

  return <div {...props} className="split-pane-top" ref={topRef} />;
};

SplitPane.Bottom = function SplitPaneBottom(props) {
  return <div {...props} className="split-pane-bottom" />;
};

Updating the Top pane height

So far, we managed to calculate the height of the Top pane DOM element and store it in the state of SplitPane. Now, we need to handle the opposite case. Whenever the topHeight state value changes, we need to change the height of the Top pane DOM element. We can do that in our previously created effect:

// SplitPlane.js
SplitPane.Top = function SplitPaneTop(props) {
  const topRef = React.createRef();
  const { topHeight, setTopHeight } = React.useContext(splitPaneContext);

  React.useEffect(() => {
    if (!topHeight) {
      setTopHeight(topRef.current.clientHeight);
      topRef.current.style.flex = "none";
      return;
    }

    topRef.current.style.height = `${topHeight}px`;
  });

  return <div {...props} className="split-pane-top" ref={topRef} />;
};

The effect we created runs every time the component renders. We don't want to unnecessarily update the height of the Top pane DOM element at every render. To avoid this, we can pass [topHeight] as a second argument to React.useEffect. By doing so, this effet will only run if the topHeight state value changes:

// SplitPlane.js
SplitPane.Top = function SplitPaneTop(props) {
  const topRef = React.createRef();
  const { topHeight, setTopHeight } = React.useContext(splitPaneContext);

  React.useEffect(() => {
    if (!topHeight) {
      setTopHeight(topRef.current.clientHeight);
      topRef.current.style.flex = "none";
      return;
    }

    topRef.current.style.height = `${topHeight}px`;
  }, [topHeight]);

  return <div {...props} className="split-pane-top" ref={topRef} />;
};

Now that we are detecting the height of the Top pane and updating its DOM element accordingly, it's time to implement the necessary changes that should occur when the user drags the separator element.

Step 3: detecting the drag difference

Whenever the user drags the separator, we want to detect the vertical distance by which the separator has been dragged.
To do so, we need to track 3 mouse events:

MouseDown on the separator: once the user presses on the separator, we want to set that position as the initial vertical position of the drag.
MouseMove on the document: how do we detect the user dragging the separator? If the initial drag position exists and there is a mouse move, then the user is dragging the separator. The drag distance is the difference between the current mouse vertical position and the initial vertical drag position. The new Top pane height is then simply its initial height + the drag difference.
MouseUp on the document: this means that the user released the separator. At this point, we can reset the drag initial value.

Our component function is run every time it renders.
So how do we maintain across renders and mutate the initial drag position? For that, we can use React.useRef() . Yes, React refs are not only used to refer to DOM elements. They can be used to maintain mutable values across renders (pretty cool, hein?):

// SplitPane.js

const splitPaneContext = React.createContext();

export default function SplitPane({ children, ...props }) {
  const [topHeight, setTopHeight] = React.useState(null);
  const separatorYPosition = React.useRef(null);

  const splitPaneRef = React.createRef();

  const onMouseDown = e => {
    separatorYPosition.current = e.clientY;
  };

  const onMouseMove = e => {
    if (!separatorYPosition.current) {
      return;
    }

    const newTopHeight = topHeight + e.clientY - separatorYPosition.current;
    separatorYPosition.current = e.clientY;

    setTopHeight(newTopHeight);
  };

  const onMouseUp = () => {
    separatorYPosition.current = null;
  };

  React.useEffect(() => {
    document.addEventListener("mousemove", onMouseMove);
    document.addEventListener("mouseup", onMouseUp);

    return () => {
      document.removeEventListener("mousemove", onMouseMove);
      document.removeEventListener("mouseup", onMouseUp);
    };
  });

  return (
    <div {...props} className="split-pane" ref={splitPaneRef}>
      <splitPaneContext.Provider value={{ topHeight, setTopHeight }}>
        {children[0]}
        <div className="separator" onMouseDown={onMouseDown} />
        {children[1]}
      </splitPaneContext.Provider>
    </div>
  );
}

👆 One more tiny improvement

The SplitPane has a top and bottom limit. Once the user drags beyond those two borders, it's not necessary anymore to update the Top pane height. Thus, one improvement we can do is to avoid making any state changes when:
The new height of the top pane is equal to the height of the entire SplitPane component.
The new height of the top pane is less than 0.

We can get the height of the SplitPane DOM element using a reference to it that we can create using React.createRef . Then, before making any state update to the top height, we check for our previous 2 conditions:

// SplitPane.js

const splitPaneContext = React.createContext();

export default function SplitPane({ children, ...props }) {
  const [topHeight, setTopHeight] = React.useState(null);
  const separatorYPosition = React.useRef(null);

  const splitPaneRef = React.createRef();

  const onMouseDown = e => {
    separatorYPosition.current = e.clientY;
  };

  const onMouseMove = e => {
    if (!separatorYPosition.current) {
      return;
    }

    const newTopHeight = topHeight + e.clientY - separatorYPosition.current;
    separatorYPosition.current = e.clientY;

    if (newTopHeight <= 0) {
      return topHeight !== 0 && setTopHeight(0);
    }

    const splitPaneHeight = splitPaneRef.current.clientHeight;

    if (newTopHeight >= splitPaneHeight) {
      return topHeight !== splitPaneHeight && setTopHeight(splitPaneHeight);
    }

    setTopHeight(newTopHeight);
  };

  const onMouseUp = () => {
    separatorYPosition.current = null;
  };

  React.useEffect(() => {
    document.addEventListener("mousemove", onMouseMove);
    document.addEventListener("mouseup", onMouseUp);

    return () => {
      document.removeEventListener("mousemove", onMouseMove);
      document.removeEventListener("mouseup", onMouseUp);
    };
  });

  return (
    <div {...props} className="split-pane" ref={splitPaneRef}>
      <splitPaneContext.Provider value={{ topHeight, setTopHeight }}>
        {children[0]}
        <div className="separator" onMouseDown={onMouseDown} />
        {children[1]}
      </splitPaneContext.Provider>
    </div>
  );
}

ReasonML for production React Apps? 🤔 (Part 4)

Seif Ghezala 🇩🇿 — Sat, 01 Jun 2019 21:48:53 +0000

This is the last article of the series. We've built a few things with ReasonReact and now it's time to share my opinion about using Reason to create React applications.

Though, my opinion shouldn't really matter if you're also evaluating ReasonML. That's why I will share an approach that should help you decide whether to use something in production or not.

We will also see 5 tips that I learned while creating this series and that are very useful when building applications with ReasonReact.

Type coverage vs development speed

Type coverage

Ensuring a good type coverage at compile time matters because it makes our code more reliable. A bug happens when the application behaves differently from the way we intended it to behave. Type coverage forces us to be very explicit about that behavior at compile-time, which is also at "code-time" (the time you're implementing it). It's true, not all bugs are related to type. However, the more explicit we are about typing values, the more we can delegate the work of checking for bugs (testing) to the compiler itself.

A side effect of having your code statically typed is enhancing its readability. Code editors and syntax plugins can use the static type information provided by the compiler and give you hints about the code you're reading. The bigger the codebase, the more you actually appreciate that.

Development speed

The speed at which we deliver features is definitely a metric of our efficiency that shouldn't be ignored. In some contexts, it's even the first priority.

Development speed also matters because it's an important factor in the developer's experience. When a tool makes it easy to implement something fast, it's often more accessible to people and also more adopted. This is simply because most of us enjoy the results of what we build, and want to get to them as fast as possible.

So, how to decide?

When picking a tool that you will use every day to build things, it's important that you consider both type coverage and development speed.

Ideally, we would have this:

Type coverage: ██████████ 100%
Development speed: ██████████ 100%

Unfortunately, this is unrealistic.

JavaScript is amazing when it comes to dev speed. The language is super dynamic and this can be used to achieve things fast with just a few lines of code:

Here's a one-liner concatenation function:

let concat = (a, b) => a + b;
// concatenate strings
concat("Hello ", "World"); // output: "Hello World"


// concatenate strings with numbers
concat("hello", 3); // output: "Hello 3

However, JavaScript also doesn't provide any of the predictability & readability benefits we get with static type coverage.

My verdict

I started the series knowing already that ReasonML is for sure around a 💯 score when it comes to type coverage.

Though, my past experience with the library made me very skeptical about the development speed. This was confirmed when I faced certain challenges like:

React Context API.
Async requests.
Deserializing JSON.

However, the new syntax of ReasonReact made the development speed jump to a really high score. We're definitely not at JavaScript's dev speed score, but we're not far either. In fact, the issues I mentioned will not block you when creating applications in production. This is only possible thanks to ReasonML's flexibility and community.

This is great because we have a tool to build React application that provides a very powerful type of coverage without hurting the development speed.

In the next session, I put some tips provided by the Reason community to solve those issues.

ReasonReact tips

Tip #1: React Context

To create & use a React Context, we have to wrap the Context provider in a custom component:

/* MyContextProvider.re */
let context = React.createContext(() => ());
let makeProps = (~value, ~children, ()) => {
  "value": value,
  "children": children,
};


let make = React.Context.provider(context);

We can then use the created Context provider as follows:

[@react.component]
let make = (~children) => {
<MyContextProvider value="foo">
    children
  </MyContextProvider>
}


module ChildConsumer = {
[@react.component]
let make = (~children) => {
  let contextValue = React.useContext(MyContextProvider.context);
};

Tip #2: requiring CSS

BuckleScript provides ways for requiring a JavaScript module without sacrificing type safety. However, when we require a CSS file, we don't really need any typing. Therefore, we can directly use BuckleScript's syntax for embedding raw JavaScript and write a normal JavaScript require statement:

[%raw {|require('path/to/myfile.css')|}];

Tip #3: using JavaScript React components 🤯

Here's an example on how to consume an existing JavaScript React component, without hurting type safety:

[@bs.module "path/to/Button.js"] [@react.component]
external make: (
  ~children: React.element,
  ~variant: string,
  ~color: string,
  ~onClick: ReactEvent.Form.t => unit
) => React.element = "default";

Using SVGR

SVGR is a great tool that lets you automatically transform SVG into React components.

You can use the previous tip to automatically and safely import SVG components as React components through SVGR:

[@bs.module "./times.svg"] [@react.component]
external make: (~height: string) => React.element = "default";

Make sure to install the corresponding Webpack loader and add the necessary Webpack configuration.

Tip #4: performing Fetch network requests

To perform network requests from a React application, we need to use Fetch.

Here's an example on how you can make your own wrapper on top of Fetch to make POST requests:

let post = (url, payload) => {
  let stringifiedPayload = payload |> Js.Json.object_ |>  Js.Json.stringify;


Js.Promise.(
  Fetch.fetchWithInit(
    url,
    Fetch.RequestInit.make(
      ~method_=Post,
      ~body=Fetch.BodyInit.make(stringifiedPayload),
      ~headers=Fetch.HeadersInit.make({"Content-Type":
       "application/json"}),
      (),
    ),
  )
  |> then_(Fetch.Response.json)
);
};

You can adjust this wrapper for other types of requests.

Tip #5: Handling JSON

Reason still doesn't have proper built-in JSON handling. In Part 2 of the series, I managed to deserialize a JSON response without using any third-party library:

/* src/Request.re */

exception PostError(string);

let post = (url, payload) => {
  let stringifiedPayload = payload |> Js.Json.object_ |> Js.Json.stringify;

  Js.Promise.(
    Fetch.fetchWithInit(
      url,
      Fetch.RequestInit.make(
        ~method_=Post,
        ~body=Fetch.BodyInit.make(stringifiedPayload),
        ~headers=Fetch.HeadersInit.make({"Content-Type": "application/json"}),
        (),
      ),
    )
    |> then_(Fetch.Response.json)
    |> then_(response =>
         switch (Js.Json.decodeObject(response)) {
         | Some(decodedRes) =>
           switch (Js.Dict.get(decodedRes, "error")) {
           | Some(error) =>
             switch (Js.Json.decodeObject(error)) {
             | Some(decodedErr) =>
               switch (Js.Dict.get(decodedErr, "message")) {
               | Some(errorMessage) =>
                 switch (Js.Json.decodeString(errorMessage)) {
                 | Some(decodedErrorMessage) =>
                   reject(PostError(decodedErrorMessage))
                 | None => reject(PostError("POST_ERROR"))
                 }
               | None => resolve(decodedRes)
               }
             | None => resolve(decodedRes)
             }

           | None => resolve(decodedRes)
           }
         | None => resolve(Js.Dict.empty())
         }
       )
  );
};

Though, I wasn't satisfied with the solution since it resulted in a huge pattern-matching hell.

Since then, and with the help of the community, I found some nice alternatives using thrid-party libraries.

bs-json

Using bs-json, you can achieve the same result in a much concise way. The goal is to use bs-json to convert our JSON into records.
We first declare our record types. In our case, we needed to handle the response JSON object, which has optionally an error JSON object. We can do it as follows:

type error = {message: string};
type response = {
  error: option(error),
  idToken: string,
};

We can then create functions to decode the JSON objects (response & error):

module Decode = {
  let error = json => Json.Decode.{message: json |> field("message", string)};


let response = json =>
  Json.Decode.{
   error: json |> field("error", optional(error)),
   idToken: json |> field("idToken", string),
  };
};

Finally, we can easily decode the JSON we receive using our decoders:

|> then_(json => {
let response = Decode.response(json);
   switch (response.error) {
     | Some(err) => reject(PostError(err.message))
     | None => resolve(response)
  };
})

ppx_decco

Another elegant way to achieve parsing JSON is to use the ppx_decco module.

We first declare our Records and prepend them with [@decco] decorator:

[@decco]
type error = {message: string};


[@decco]
type response = {error: option(error)};

This will create under the hood 2 functions we can use to deserialize the corresponding JSON values:

error_decode
response_decode

We can then use our declared Records & the created functions to easily decode the JSON values

|> then_(response =>
   switch (response_decode(response)) {
    | Belt.Result.Ok({error: Some({message})}) =>
       reject(PostError(message))
    | response => resolve(response)
  }
)

Conclusion

This series aimed to give a realistic reflection of the ReasonML to build React applications. By building UI features that resemble the ones we would in usual production environments, we managed to grasp a good feel of both the good stuff and struggles you would face if you ever decide to use Reason in production.
It's undeniable that Reason has a powerful type system with a very strong type inference that will make you write reliable code. With this series, we also saw how the development speed of React applications using Reason is also not affected. So, Yes, Reason is definitely ready to create React applications in production!

Special thanks to the Reason community on the Forums & Discord, and especially to @yawaramin for consistently reading the articles and providing help.

ReasonML for production React Apps? 🤔 (Part 3)

Seif Ghezala 🇩🇿 — Sat, 11 May 2019 18:22:13 +0000

A while ago I published this article about building an accessible and reusable modal/dialog component in React.

React modal

The component achieves the following requirements:

A reusable component API: we should be able to easily use our accessible modal anywhere and populate it with content.
Accessible markup.
We should be able to open & close the modal just using the keyboard.
Trap the focus in the modal: since the modal is an inert component, the keyboard navigation should be trapped inside of it once it’s open.

The component makes use of React features like the Context, Portals, and Ref. To evaluate whether ReasonReact is ready for production, I will build the same modal in Reason and report what I like/dislike.

I will be doing that once again in iterations. You can find the final source code here. There is a separate branch for each iteration.

Iteration #1: the modal as a simple div

The modal component

First, let's create the modal component:

/* src/Modal.re */

[%bs.raw {|require('./Modal.css')|}];

[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";

[@react.component]
let make = (~children) =>
  ReactDOMRe.createPortal(
    <div className="modal-container" role="dialog" ariaModal=true>
      <div className="modal-content"> children </div>
    </div>,
    body,
  );

To make the modal accessible, it should be isolated from the main application content. Using the createPortal function of ReactDOMRe, the modal is rendered directly in the body of the document.

But first, we need to access the body...

Reason ships with a Dom module. Unfortunately, the module only contains useful types in it and doesn't provide bindings to the actual DOM.

We can of course just use raw JavaScript to access document.body and type the value using the Dom module:

let body: Dom.element = [%raw "document.body"];

If we look at the compiled Modal.bs.js file, we'll see this totally unnecessary line:

var body = (document.body);

Can you imagine how the compiled code would look like if we start using this approach whenever we want to access a JavaScript value? We can do better than that!

To access the body of the document, we can use BuckleScript's external feature:

[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";

We simply tell BuckleScript to give us the value body of type Dom.element present in the global value document. This syntax is pretty smart and efficient. If we look at the compiled Modal.bs.js file, we'll see that the body is accessed directly from the document object, the same way we would do it in JavaScript!

Opening the modal

/* src/App.re */

[%bs.raw {|require('./App.css')|}];

[@react.component]
let make = () => {
  let (isModalVisible, setIsModalVisible) = React.useState(() => false);
  <div className="App">
    <h1> {"Parent container" |> ReasonReact.string} </h1>
    <h3> {"This is just a demo container" |> ReasonReact.string} </h3>
    <button onClick={_ => setIsModalVisible(_ => true)}>
      {"open modal" |> ReasonReact.string}
    </button>
    {!isModalVisible
       ? ReasonReact.null : <Modal> {"Foo" |> ReasonReact.string} </Modal>}
  </div>;
};

To view/hide the modal, it's rendered in the App component conditionally based on the isModalVisible boolean state value.

The "open modal" button simply sets that value to true, opening the modal.

I like 👍

Using portals is pretty simple.
BuckleSript external syntax makes accessing a DOM element simple and efficient.

I dislike 👎

The absence of actual bindings to the DOM. It would have made accessing the body of the document as easy as it is in JavaScript while benefiting from typing.

Iteration #2: adding close buttons

We want to have 2 buttons to close the modal:

A cross button in the header.
A "Close" button in the footer.

Before doing that, we need first have the modal expose:

A header component that contains the cross closing button and any elements we wish to render in the header of the modal.
A body component that contains any elements we wish to render in the body of the modal.
A footer component that will contain the second closing button and any elements we wish to render in the footer of the modal.

/* src/Modal.re */

[%bs.raw {|require('./Modal.css')|}];

[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";

module Cross = {
  [@bs.module "./cross.svg"] [@react.component]
  external make: unit => React.element = "default";
};

[@react.component]
let make = (~children) => {
  ReactDOMRe.createPortal(
    <div className="modal-container" role="dialog" ariaModal=true>
      <div className="modal-content"> children </div>
    </div>,
    body,
  );
};

module Header = {
  [@react.component]
  let make = (~children) => {
    <div className="modal-header">
      children
      <button className="cross-btn" title="close modal"> <Cross /> </button>
    </div>;
  };
};

module Body = {
  [@react.component]
  let make = (~children) => <div className="modal-body"> children </div>;
};

module Footer = {
  [@react.component]
  let make = (~children) => <div className="modal-footer"> children </div>;

  module CloseBtn = {
    [@react.component]
    let make = (~children) => {
      <button className="close-btn" title="close modal"> children </button>;
    };
  };
};

We can then refactor our App.re and make use of the new modal sub-components:

/* src/App.re */

[%bs.raw {|require('./App.css')|}];

[@react.component]
let make = () => {
  let (isModalVisible, setIsModalVisible) = React.useState(() => false);

  <div className="App">
    <h1> {"Parent container" |> ReasonReact.string} </h1>
    <h3> {"This is just a demo container" |> ReasonReact.string} </h3>
    <button onClick={_ => setIsModalVisible(_ => !isModalVisible)}>
      {"open modal" |> ReasonReact.string}
    </button>
    {!isModalVisible
       ? ReasonReact.null
       : <Modal>
           <Modal.Header> {"Header" |> ReasonReact.string} </Modal.Header>
           <Modal.Body> {"Body" |> ReasonReact.string} </Modal.Body>
           <Modal.Footer>
             <Modal.Footer.CloseBtn>
               {"Close" |> ReasonReact.string}
             </Modal.Footer.CloseBtn>
           </Modal.Footer>
         </Modal>}
  </div>;
};

I like 👍

Reason's module syntax is pretty simple and creating sub-modules is effortless.

Iteration #3: Closing the modal

Just like opening the modal, closing it can be done by setting isModalVisible in App.re to true.

Let's pass to the Modal a function, onModalClose, that does exactly that:

/* src/App.re*/


[%bs.raw {|require('./App.css')|}];

[@react.component]
let make = () => {
  let (isModalVisible, setIsModalVisible) = React.useState(() => false);

  <div className="App">
    <h1> {"Parent container" |> ReasonReact.string} </h1>
    <h3> {"This is just a demo container" |> ReasonReact.string} </h3>
    <button onClick={_ => setIsModalVisible(_ => !isModalVisible)}>
      {"open modal" |> ReasonReact.string}
    </button>
    {!isModalVisible
       ? ReasonReact.null
       : <Modal onModalClose={() => setIsModalVisible(_ => false)}>
           <Modal.Header> {"Header" |> ReasonReact.string} </Modal.Header>
           <Modal.Body> {"Body" |> ReasonReact.string} </Modal.Body>
           <Modal.Footer>
             <Modal.Footer.CloseBtn>
               {"Close" |> ReasonReact.string}
             </Modal.Footer.CloseBtn>
           </Modal.Footer>
         </Modal>}
  </div>;
};

By now, the modal component has a prop function to close the Modal. The only thing left is to make it available to the header and footer close buttons.

To do that we can expose it in a React Context Provider. Any component that needs to access the onModalClose function can then consume it using a useContext hook.

To create a context for the modal, we can use React createContext function and pass to it an initial value. Since the onModalClose function is of type unit => unit, the initial value needs to be of the same type:

let modalContext = React.createContext(() => ());

The provider can't be accessed directly from the modal's context. One way of using it is to create a provider module which exposes a make and makeProps functions:

module ContextProvider = {
  let makeProps = (~value, ~children, ()) => {
    "value": value,
    "children": children,
  };

  let make = React.Context.provider(modalContext);
};

We can then wrap the modal's children inside the context provider and consume our value in the header and footer:

/* src/Modal.re */

[%bs.raw {|require('./Modal.css')|}];

[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";

module Cross = {
  [@bs.module "./cross.svg"] [@react.component]
  external make: unit => React.element = "default";
};

let modalContext = React.createContext(() => ());

module ContextProvider = {
  let makeProps = (~value, ~children, ()) => {
    "value": value,
    "children": children,
  };

  let make = React.Context.provider(modalContext);
};

[@react.component]
let make = (~children, ~onModalClose) => {
  ReactDOMRe.createPortal(
    <div className="modal-container" role="dialog" ariaModal=true>
      <div className="modal-content">
        <ContextProvider value=onModalClose> children </ContextProvider>
      </div>
    </div>,
    body,
  );
};

module Header = {
  [@react.component]
  let make = (~children) => {
    let onModalClose = React.useContext(modalContext);

    <div className="modal-header">
      children
      <button
        className="cross-btn"
        title="close modal"
        onClick={_ => onModalClose()}>
        <Cross />
      </button>
    </div>;
  };
};

module Body = {
  [@react.component]
  let make = (~children) => <div className="modal-body"> children </div>;
};

module Footer = {
  [@react.component]
  let make = (~children) => <div className="modal-footer"> children </div>;

  module CloseBtn = {
    [@react.component]
    let make = (~children) => {
      let onModalClose = React.useContext(modalContext);

      <button
        className="close-btn"
        title="close modal"
        onClick={_ => onModalClose()}>
        children
      </button>;
    };
  };
};

I like 👍

I was able to use the Context to implement the feature, even if it was a workaround.
After getting stuck with using the Context, I managed to get a working solution in no-time through the forum and discord channel.

I dislike 👎

There is no documentation about using the context.
The solution I used is undoubtedly a hack.

Iteration #4: closing the modal through a keyboard shortcut

We want to be able to close the modal by pressing the ESCAPE key. To do so, we need to use the external syntax to access 2 functions:

document.addEventListener (to add a listener).
document.removeEventListener (to remove a listener).

We have to be explicit about the type of event used in both functions. The ReactEvent module provides types for various events. In our case, we are dealing with events of type Keyboard. Since our functions only deal with keyboard events, I decided to name them a bit differently:

[@bs.scope "document"] [@bs.val]
external addKeybordEventListener:
  (string, ReactEvent.Keyboard.t => unit) => unit =
  "addEventListener";

[@bs.scope "document"] [@bs.val]
external removeKeybordEventListener:
  (string, ReactEvent.Keyboard.t => unit) => unit =
  "removeEventListener";

We can then use the 2 functions to create a keydown listener that reacts to the ESCAPE key:

let keyDownListener = e =>
  if (ReactEvent.Keyboard.keyCode(e) === 27) {
     onModalClose();
  };

The useEffect hook can be used to create a function to subscribe to our keyDownListener. The function returns than another function to clean up the effect, wrapped in an option:

/* src/Modal.re */

[%bs.raw {|require('./Modal.css')|}];

[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";

[@bs.scope "document"] [@bs.val]
external addKeybordEventListener:
  (string, ReactEvent.Keyboard.t => unit) => unit =
  "addEventListener";

[@bs.scope "document"] [@bs.val]
external removeKeybordEventListener:
  (string, ReactEvent.Keyboard.t => unit) => unit =
  "removeEventListener";

module Cross = {
  [@bs.module "./cross.svg"] [@react.component]
  external make: unit => React.element = "default";
};

let modalContext = React.createContext(() => ());

module ContextProvider = {
  let makeProps = (~value, ~children, ()) => {
    "value": value,
    "children": children,
  };

  let make = React.Context.provider(modalContext);
};

[@react.component]
let make = (~children, ~onModalClose) => {
  let keyDownListener = e =>
    if (ReactEvent.Keyboard.keyCode(e) === 27) {
      onModalClose();
    };

  let effect = () => {
    addKeybordEventListener("keydown", keyDownListener);
    Some(() => removeKeybordEventListener("keyDown", keyDownListener));
  };

  React.useEffect(effect);

  ReactDOMRe.createPortal(
    <div className="modal-container" role="dialog" ariaModal=true>
      <div className="modal-content">
        <ContextProvider value=onModalClose> children </ContextProvider>
      </div>
    </div>,
    body,
  );
};

module Header = {
  [@react.component]
  let make = (~children) => {
    let onModalClose = React.useContext(modalContext);

    <div className="modal-header">
      children
      <button
        className="cross-btn"
        title="close modal"
        onClick={_ => onModalClose()}>
        <Cross />
      </button>
    </div>;
  };
};

module Body = {
  [@react.component]
  let make = (~children) => <div className="modal-body"> children </div>;
};

module Footer = {
  [@react.component]
  let make = (~children) => <div className="modal-footer"> children </div>;

  module CloseBtn = {
    [@react.component]
    let make = (~children) => {
      let onModalClose = React.useContext(modalContext);

      <button
        className="close-btn"
        title="close modal"
        onClick={_ => onModalClose()}>
        children
      </button>;
    };
  };
};

I like 👍

useEffect being fully typed, it reminds you to clean up the effect. You either explicitly return None or a cleanup function. This avoids memory leaks when adding listeners and not removing them.

I dislike 👎

There is no documentation about the use of useEffect.

Iteration #5: Trapping the focus in the modal

There is one more thing left in order for our modal to be properly accessible: the focus inside of it should be trapped. Once the modal is opened, we should focus the first focusable element in it. From then, pressing the TAB or SHIFT + TAB keys will only allow the user to navigate inside the modal.

Trapping the focus inside the modal

We need to first create a Ref to access the modal dom element:

let modalRef = React.useRef(Js.Nullable.null);

Notice that we have to initiate useRef with a null value through the Js.Nullable module. Fortunatelty, it's pretty easy to convert from a Js.Nullable to an option:

switch(Js.Nullable.toOption(someNullable)) {
    | Some(value) => ...
    | None => ...
}

To select all focusable elements inside the modal, we can use the querySelector function of the DOM element inside the Ref to the modal component.

Due to the absence of proper bindings to the DOM, we either have to write our own bindings, use some 3rd party library, or just use ReactDOMRe.domElementToObj which converts the DOM element inside the modal ref into an object.

For the time being, I choose the 3rd option. This allows us to access the querySelector function easily but lose track of all types:

/* src/Modal.re */

[%bs.raw {|require('./Modal.css')|}];

[@bs.scope "document"] [@bs.val] external body: Dom.element = "body";

[@bs.scope "document"] [@bs.val]
external addKeybordEventListener:
  (string, ReactEvent.Keyboard.t => unit) => unit =
  "addEventListener";

[@bs.scope "document"] [@bs.val]
external removeKeybordEventListener:
  (string, ReactEvent.Keyboard.t => unit) => unit =
  "removeEventListener";

[@bs.scope "document"] [@bs.val]
external activeElement: Dom.element = "activeElement";

module Cross = {
  [@bs.module "./cross.svg"] [@react.component]
  external make: unit => React.element = "default";
};

let modalContext = React.createContext(() => ());

module ContextProvider = {
  let makeProps = (~value, ~children, ()) => {
    "value": value,
    "children": children,
  };

  let make = React.Context.provider(modalContext);
};
[@react.component]
let make = (~children, ~onModalClose) => {
  let modalRef = React.useRef(Js.Nullable.null);

  let handleTabKey = e => {
    let current = React.Ref.current(modalRef);
    switch (Js.Nullable.toOption(current)) {
    | Some(element) =>
      let elementObj = ReactDOMRe.domElementToObj(element);
      let elements =
        elementObj##querySelectorAll(
          "a[href], button, textarea, input[type='text'], input[type='radio'], input[type='checkbox'], select",
        );
      let firstElement = elements[0];
      let lastElement = elements[elements##length - 1];

      if (!ReactEvent.Keyboard.shiftKey(e) && activeElement !== firstElement) {
        firstElement##focus();
        ReactEvent.Keyboard.preventDefault(e);
      };

      if (ReactEvent.Keyboard.shiftKey(e) && activeElement !== lastElement) {
        lastElement##focus();
        ReactEvent.Keyboard.preventDefault(e);
      };

    | None => ignore()
    };
  };

  let keyListenersMap =
    Js.Dict.fromArray([|("27", _ => onModalClose()), ("9", handleTabKey)|]);

  let effect = () => {
    let keyDownListener = e => {
      let keyCodeStr = ReactEvent.Keyboard.keyCode(e) |> string_of_int;

      switch (Js.Dict.get(keyListenersMap, keyCodeStr)) {
      | Some(eventListener) => eventListener(e)
      | None => ignore()
      };
    };

    addKeybordEventListener("keydown", keyDownListener);
    Some(() => removeKeybordEventListener("keyDown", keyDownListener));
  };

  React.useEffect(effect);

  ReactDOMRe.createPortal(
    <div className="modal-container" role="dialog" ariaModal=true>
      <div className="modal-content" ref={ReactDOMRe.Ref.domRef(modalRef)}>
        <ContextProvider value=onModalClose> children </ContextProvider>
      </div>
    </div>,
    body,
  );
};

module Header = {
  [@react.component]
  let make = (~children) => {
    let onModalClose = React.useContext(modalContext);

    <div className="modal-header">
      children
      <button
        className="cross-btn"
        title="close modal"
        onClick={_ => onModalClose()}>
        <Cross />
      </button>
    </div>;
  };
};

module Body = {
  [@react.component]
  let make = (~children) => <div className="modal-body"> children </div>;
};

module Footer = {
  [@react.component]
  let make = (~children) => <div className="modal-footer"> children </div>;

  module CloseBtn = {
    [@react.component]
    let make = (~children) => {
      let onModalClose = React.useContext(modalContext);

      <button
        className="close-btn"
        title="close modal"
        onClick={_ => onModalClose()}>
        children
      </button>;
    };
  };
};

I like 👍

Being able to convert from a Js.Nullable to an option.
I was able to implement the feature regardless of the absence of proper bindings to the DOM.

I dislike 👎

Not being able to use an option with the useRef hook.
The absence of proper bindings to the DOM.

ReasonML for production React Apps? 🤔 (Part 2)

Seif Ghezala 🇩🇿 — Fri, 03 May 2019 13:41:12 +0000

I like to go to the Roadmap of ReasonML from time to time to get excited about what's getting cooked. Whenever I visit the page, I can't help but notice these 2 points:

ReasonML Roadmap

So the official documentation itself admits that the async story and JSON handling are not that great.

This is exactly why, in this second part of the series, we'll build a simple Login page for our words counter. By doing that, I'm pretty sure we will bump into these 2 points among other things and have a better overview of building React applications in Reason.

Just like the previous part, I will approach building this feature in iterations and report what I like/dislike.

Final Result

You can find the final code here.

Iteration #1: separate the words counter into its own component

Our application will no longer be just a words counter page. Therefore, we have to move the content of the App component into a separate component and create another component for the Login page.

/* src/Home.re */

[%bs.raw {|require('./Home.css')|}];

let countWordsInString = text => {
  let spacesRegex = Js.Re.fromString("\s+");

  switch (text) {
  | "" => 0
  | noneEmptyText =>
    noneEmptyText
    |> Js.String.trim
    |> Js.String.splitByRe(spacesRegex)
    |> Js.Array.length
  };
};

module Times = {
  [@bs.module "./icons/times.svg"] [@react.component]
  external make: (~height: string) => React.element = "default";
};

module Copy = {
  [@bs.module "./icons/copy.svg"] [@react.component]
  external make: (~height: string) => React.element = "default";
};

module CopyClipboard = {
  [@bs.module "react-copy-to-clipboard"] [@react.component]
  external make: (~text: string, ~children: React.element) => React.element =
    "CopyToClipboard";
};

[@react.component]
let make = () => {
  let (text, setText) = React.useState(() => "");

  let handleTextChange = e => ReactEvent.Form.target(e)##value |> setText;

  let handleClearClick = _ => setText(_ => "");

  let wordsCountText =
    (text |> countWordsInString |> string_of_int) ++ " words";

  <div className="Home">
    <div className="header">
      <h3> {"Words Counter" |> ReasonReact.string} </h3>
      <span> {ReasonReact.string(wordsCountText)} </span>
    </div>
    <textarea
      placeholder="Express yourself..."
      value=text
      onChange=handleTextChange
    />
    <div className="footer">
      <Button
        title="Clear text"
        onClick=handleClearClick
        disabled={String.length(text) === 0}>
        <Times height="20px" />
      </Button>
      <CopyClipboard text>
        <Button
          title="Copy text"
          disabled={String.length(text) === 0}
          category=Button.PRIMARY>
          <Copy height="20px" />
        </Button>
      </CopyClipboard>
    </div>
  </div>;
};

The App component is also refactored to just render a Home component:

/* src/App.re */

[@react.component]
let make = () => {
  <div className="App"> <Home /> </div>;
};

So far, we've just made minor changes and there is nothing for me to like/dislike.

Iteration 2: add a Router

To make it possible to navigate to our Home and Login pages, we need to add a Router.

Let's first build a simple Login page that we can navigate to:

/* src/Login.re */

[@react.component]
let make = () => {
  <div className="Login"> <h1>{ "Login Page" |> ReasonReact.string }</h1> </div>;
};

ReasonReact comes with a built-in Router: ReasonReactRouter. The Router provides a hook, useUrl(), to consume the current url. To implement navigation, we just have to render a different page component based on the url path we consume from the useUrl() hook:

/* src/App.re */

[@react.component]
let make = () => {
  let url = ReasonReactRouter.useUrl();

  let page =
    switch (url.path) {
    | [] => <Home />
    | ["login"] => <Login />
    | _ => <div> {"Page not found :/" |> ReasonReact.string} </div>
    };

  <div className="App"> page </div>;
};

I like 👍

The built-in Router's API is pretty straight-forward.
Pattern-matching over the url path will always remind you not to forget a fallback page, otherwise, it's not exhaustive.
I can imagine that routing based on certain conditions can be implemented very easily and elegantly since routing is based on pattern-matching.

Iteration 3: build the Login page interface

We've set up the navigation to the Home and Login pages, so let's put actual content in the Login page. To start, let's create a Login template with an email and password fields that store their values in the state:

/* src/Login.re */

[%bs.raw {|require('./Login.css')|}];

[@react.component]
let make = () => {
  let (email, setEmail) = React.useState(() => "");
  let (password, setPassword) = React.useState(() => "");

  let handleEmailChange = e => ReactEvent.Form.target(e)##value |> setEmail;
  let handlePasswordChange = e =>
    ReactEvent.Form.target(e)##value |> setPassword;

  let handleFormSubmit = e => {
    ReactEvent.Form.preventDefault(e);
    /* TODO: add logic for submitting the form */
  };

  <div className="Login">
    <h2> {"Login" |> ReasonReact.string} </h2>
    <form onSubmit=handleFormSubmit>
      <div className="inputField">
        <input
          type_="email"
          placeholder="Email"
          value=email
          onChange=handleEmailChange
          required=true
        />
      </div>
      <div className="inputField">
        <input
          type_="password"
          placeholder="Password"
          value=password
          onChange=handlePasswordChange
          required=true
        />
      </div>
      <Button title="Login" category=Button.PRIMARY>
        {"Login" |> ReasonReact.string}
      </Button>
    </form>
  </div>;
};

Here's how the Login page looks like:

I like 👍

I can say I became quite fast with ReasonReact, despite the few things I dislike and that I mentioned in the previous part (e.g. having to use ReasonReact.string and ReactEvent.Form.target).

Iteration 4: add error handling

Before jumping into the form submit implementation, I want our component first to be able to handle potential errors.

To do so, let's create a Variant that handles 3 possible errors:

EMAIL_NOT_FOUND
INVALID_PASSWORD
OTHER (e.g. error when the user is blocked)

type loginError =
  | EMAIL_NOT_FOUND
  | INVALID_PASSWORD
  | OTHER;

Since server errors messages are strings, let's create a helper function that converts the string into a Variant:

let stringToLoginError = str =>
  switch (str) {
  | "EMAIL_NOT_FOUND" => Some(EMAIL_NOT_FOUND)
  | "INVALID_PASSWORD" => Some(INVALID_PASSWORD)
  | _ => None
  };

Now, we want to add an error field to our state. Since, at any point, we can either have an error or not, the field should be of type option(loginError).

Once we have that, it becomes pretty easy to conditionally render an email or password error using pattern-matching:

/* src/Login.re */

[%bs.raw {|require('./Login.css')|}];

type loginError =
  | EMAIL_NOT_FOUND
  | INVALID_PASSWORD
  | OTHER;

let stringToLoginError = str =>
  switch (str) {
  | "EMAIL_NOT_FOUND" => Some(EMAIL_NOT_FOUND)
  | "INVALID_PASSWORD" => Some(INVALID_PASSWORD)
  | _ => Some(OTHER)
  };

[@react.component]
let make = () => {
  let (email, setEmail) = React.useState(() => "");
  let (password, setPassword) = React.useState(() => "");
  let (error, setError) = React.useState(() => None);

  let handleEmailChange = e => ReactEvent.Form.target(e)##value |> setEmail;
  let handlePasswordChange = e =>
    ReactEvent.Form.target(e)##value |> setPassword;

  let handleFormSubmit = e => {
    ReactEvent.Form.preventDefault(e);
    /* TODO: add logic for submitting the form */
  };

  <div className="Login">
    <h2> {"Login" |> ReasonReact.string} </h2>
    <form onSubmit=handleFormSubmit>
      <div className="inputField">
        <input
          type_="email"
          placeholder="Email"
          value=email
          onChange=handleEmailChange
          required=true
        />
        {switch (error) {
         | Some(EMAIL_NOT_FOUND) =>
           <div className="error">
             {{js| ⚠  Email not found |js} |> ReasonReact.string}
           </div>
         | _ => ReasonReact.null
         }}
      </div>
      <div className="inputField">
        <input
          type_="password"
          placeholder="Password"
          value=password
          onChange=handlePasswordChange
          required=true
        />
        {switch (error) {
         | Some(INVALID_PASSWORD) =>
           <div className="error">
             {{js| ⚠ Invalid password |js} |> ReasonReact.string}
           </div>
         | _ => ReasonReact.null
         }}
      </div>
      <Button title="Login" category=Button.PRIMARY>
        {"Login" |> ReasonReact.string}
      </Button>
    </form>
  </div>;
};

I like 👍

Variants give confidence when dealing with different error types. By relying on them, you end up handling explicitly the different types of errors.

Iteration 5: creating a wrapper for Fetch

When we submit the form, we want to make a login post request to the backend.
If there is an error with the user's credentials, well, we're ready to handle it 😎.
If the login is successful, we will just log a success message.

How do you make requests from the browser? You use the global function fetch.

I usually create a wrapper on top of fetch to make POST/GET requests for the following reasons:

Avoid repetitive boilerplate.
When the request fails, the fetch promise doesn't. So I usually check the status of the response and either resolve the promise or fail it based on it (c.f. the code below).

Here's how my fetch wrapper for post requests usually looks like in JavaScript:

export async function post(url, body) {
  let response = await fetch(url, {
    method: 'POST',
    credentials: 'include',
    body: typeof body === 'string' ? body : JSON.stringify(body),
    headers: {
      'Content-Type': 'application/json'
    },
    mode: 'cors'
  });

  if (response.status >= 200 && response.status < 300) {
    return response;
  }

  throw response;
}

I can then use it anywhere else:

try {
    const response = await post('some/url', { foo: "bar"});
    const jsonContent = await response.json();
} catch(e) {
    // do something with the error
}

Let's try to do the same in ReasonML. There are no built-in bindings to fetch in Reason, so we'll have to use bs-fetch.

/* src/Request.re */

let post = (url, payload) => {
  let stringifiedPayload = payload |> Js.Json.object_ |> Js.Json.stringify;

  Fetch.fetchWithInit(
    url,
    Fetch.RequestInit.make(
      ~method_=Post,
      ~body=Fetch.BodyInit.make(stringifiedPayload),
      ~headers=Fetch.HeadersInit.make({"Content-Type": "application/json"}),
      (),
    ),
  );
};

The function fetchWithInit of the bs-fetch module Fetch is used to make a fetch call with configuration. We pass to it the url and a configuration we make with Fetch.RequestInit.make().

So far, this returns a promise.

Did I mention that I was using Firebase as a backend for authentication? Well, I am using Firebase as a backend for authentication.

Authentication errors returned by Firebase are JSON objects, so we have to use the response.json() method to extract the error object out of a response.

Thus, we want to extract the JSON content out of the fetch response. To do that, we can use the Fetch.Response.json function:

/* src/Request.re */

let post = (url, payload) => {
  let stringifiedPayload = payload |> Js.Json.object_ |> Js.Json.stringify;

  Fetch.fetchWithInit(
    url,
    Fetch.RequestInit.make(
      ~method_=Post,
      ~body=Fetch.BodyInit.make(stringifiedPayload),
      ~headers=Fetch.HeadersInit.make({"Content-Type": "application/json"}),
      (),
    ),
  ) |> Js.Promise.then_(Fetch.Response.json)
};

Since we will be using then_ catch, resolve, and reject often, we can open the Js.Promise module so that we don't have to prepend them with Js.Promise at every call:

/* src/Request.re */

let post = (url, payload) => {
  let stringifiedPayload = payload |> Js.Json.object_ |> Js.Json.stringify;

  Js.Promise.(
    Fetch.fetchWithInit(
      url,
      Fetch.RequestInit.make(
        ~method_=Post,
        ~body=Fetch.BodyInit.make(stringifiedPayload),
        ~headers=Fetch.HeadersInit.make({"Content-Type": "application/json"}),
        (),
      ),
    )
    |> then_(Fetch.Response.json)
  );
};

Just like the JavaScript json() function, Fetch.Response.json() returns a promise that resolves with an object of type Js.Json (you can see that in the editor if you hover over it).

If we want to extract any data from an object of type Js.Json, we'll have to convert it into a Js.Dict (dictionary/map) object using the function Js.Json.decodeObject(). This returns an option, since the JSON response can be empty or simply not an object. Therefore, we will have to use pattern-matching to handle both cases and extract the Js.Dict value:

/* src/Request.re */

let post = (url, payload) => {
  let stringifiedPayload = payload |> Js.Json.object_ |> Js.Json.stringify;

  Js.Promise.(
    Fetch.fetchWithInit(
      url,
      Fetch.RequestInit.make(
        ~method_=Post,
        ~body=Fetch.BodyInit.make(stringifiedPayload),
        ~headers=Fetch.HeadersInit.make({"Content-Type": "application/json"}),
        (),
      ),
    )
    |> then_(Fetch.Response.json)
    |> then_(response => {
      switch (Js.Json.decodeObject(response)) {
        | Some(decodedRes) => {
          resolve(decodedRes);
        }
        | None => resolve(Js.Dict.empty())
      }
    })
  );
};

Now that we have the response object, we need to check if it has an error or not. If the content has an error object, we reject the Promise with an exception containing the error message. Therefore, we will have to create a custom exception type for that. Otherwise, we resolve the Promise with a Js.Dict object containing the response:

/* src/Request.re */

exception PostError(string);

let post = (url, payload) => {
  let stringifiedPayload = payload |> Js.Json.object_ |> Js.Json.stringify;

  Js.Promise.(
    Fetch.fetchWithInit(
      url,
      Fetch.RequestInit.make(
        ~method_=Post,
        ~body=Fetch.BodyInit.make(stringifiedPayload),
        ~headers=Fetch.HeadersInit.make({"Content-Type": "application/json"}),
        (),
      ),
    )
    |> then_(Fetch.Response.json)
    |> then_(response =>
         switch (Js.Json.decodeObject(response)) {
         | Some(decodedRes) =>
           switch (Js.Dict.get(decodedRes, "error")) {
           | Some(error) =>
             reject(
               PostError(
                 "There is an error, but we don't know its message yet",
               ),
             )

           | None => resolve(decodedRes)
           }
         | None => resolve(Js.Dict.empty())
         }
       )
  );
}

All that we have to do now is extract the error message from the Js.Json error, the same way we extracted the error object from the response. The only difference is that the message is a string and not an object:

/* src/Request.re */

exception PostError(string);

let post = (url, payload) => {
  let stringifiedPayload = payload |> Js.Json.object_ |> Js.Json.stringify;

  Js.Promise.(
    Fetch.fetchWithInit(
      url,
      Fetch.RequestInit.make(
        ~method_=Post,
        ~body=Fetch.BodyInit.make(stringifiedPayload),
        ~headers=Fetch.HeadersInit.make({"Content-Type": "application/json"}),
        (),
      ),
    )
    |> then_(Fetch.Response.json)
    |> then_(response =>
         switch (Js.Json.decodeObject(response)) {
         | Some(decodedRes) =>
           switch (Js.Dict.get(decodedRes, "error")) {
           | Some(error) =>
             switch (Js.Json.decodeObject(error)) {
             | Some(decodedErr) =>
               switch (Js.Dict.get(decodedErr, "message")) {
               | Some(errorMessage) =>
                 switch (Js.Json.decodeString(errorMessage)) {
                 | Some(decodedErrorMessage) =>
                   reject(PostError(decodedErrorMessage))
                 | None => reject(PostError("POST_ERROR"))
                 }
               | None => resolve(decodedRes)
               }
             | None => resolve(decodedRes)
             }

           | None => resolve(decodedRes)
           }
         | None => resolve(Js.Dict.empty())
         }
       )
  );
};

That's it, let's see in the next iteration whether our module works or not.

But before that, here's what I like/dislike:

I like 👍

Js.Promise always returns a Promise. This makes their returned value much more predictable than promises in JavaScript, which can either return a Promise or a value.
Js.Post always returns a Promise that resolves with a Js.Dict. It's pretty hard to have an error by using it since its return type is predictable.
Although it was a REAL struggle to extract an error message from the response, I have to admit that it was bullet-proof. I managed to make it work before even looking at the browser.

I dislike 👎

The syntax of the bs-fetch API is quite unnatural.
Although accessing a JSON value is safe, it's undeniably a pain and easily results in a nesting hell that is very hard to read.

Iteration #6: using the Request module in the Login page

We've built a nice module to make POST requests, let's use in the Login page.

Before doing that, we have to handle one issue: we can't directly access an exception from a rejected Promise. Let's follow the official BuckleScript example and build a small helper function that extracts our exception from a rejected Promise:

  let handlePromiseFailure =
    [@bs.open]
    (
      fun
      | Request.PostError(err) => {
          err;
        }
    );

We can now make our POST calls in the handleFormSubmit function:

/* src/Login.re */

  let handleFormSubmit = e => {
    ReactEvent.Form.preventDefault(e);
    let payload = Js.Dict.empty();
    Js.Dict.set(payload, "email", Js.Json.string(email));
    Js.Dict.set(payload, "password", Js.Json.string(password));

    Js.Promise.(
      Request.post(loginUrl, payload)
      |> then_(res =>
           {
             alert("Login successful!");
             setError(_ => None);
           }
           |> resolve
         )
      |> catch(e =>
           (
             switch (handlePromiseFailure(e)) {
             | Some(err) => setError(_ => stringToLoginError(err))
             | None => setError(_ => None)
             }
           )
           |> resolve
         )
      |> ignore
    );
  };

To test the Login form, I created the following user:

{ "email": "demo@demo.com", "password": "demodemo" }

And here's the final outcome:

Final Login form

That's it! The Login page works exactly as we wanted it to! 🎉

I dislike 👎

The extra step I have to make to extract an exception from a rejected Promise.

ReasonML for production React Apps? 🤔 (Part 1)

Seif Ghezala 🇩🇿 — Fri, 19 Apr 2019 12:49:07 +0000

ReasonML is a functional programming language with smartly inferred strict types, that compiles to JavaScript. ReasonReact is Reason bindings for ReactJS (aka the translated ReasonML version of the ReactJS). It has improved a lot lately and even added support for hooks in a release a couple of days ago.

In this series of articles, I will build applications in ReasonReact and try to accomplish most of the tasks I usually do with ReactJS. For each article, I will share what I like/dislike about building React applications in Reason. The goal is to determine how ready is ReasonML for building serious React applications.

What are we going to build?

I decided to start with a simple application. We will build a small words counter with the following features:

There is an input where I can write text.
There is a word count that updates while I write text.
There is a button to clear text.
There is a button to copy text.

Final result

You can find the final source code here. Since we will build the application in iterations, there is a branch for each iteration.

Setting up the project & editor

First, let's download the Reason to JavaScript compiler bs-platform (BuckleScript):

npm install -g bs-platform

The package comes with bsb, a CLI tool to quickly bootstrap a Reason project based on a template.
Let's generate our project based on the react-hooks template:

bsb -init words-counter -theme react-hooks

Let's also use VSCode as our code editor, and download reason-vscode. This is the editor plugin officially recommended by ReasonML.

To take advantage of the formatting feature, let's enable the Format on Save option in the editor's settings:

Enabling the Format On Save option on VSCode

I like 👍

The getting-started experience is very good. The BuckleScript build tool (bsb) is a much faster version of create-react-app or yeoman.
The Editor tooling is also great:
- It formats the code style and syntax (just like configuring ESLint with Prettier).
- It also provides information about types when hovering on values.

Iteration #1: there is an input where I can write text

In this first iteration, we just want to have a nice text area with a title to write text and store it in a state variable:

Iteration #1: there is an input where I can write text

/* src/App.re */

[%bs.raw {|require('./App.css')|}];

[@react.component]
let make = () => {
  let (text, setText) = React.useState(() => "");

  let handleTextChange = e => ReactEvent.Form.target(e)##value |> setText;

  <div className="App">
    <div className="header">
      <h3> {"Words Counter" |> ReasonReact.string} </h3>
    </div>
    <textarea
      placeholder="Express yourself..."
      value=text
      onChange=handleTextChange
    />
  </div>;
};

I dislike 👎

Accessing the target value of a form event is a bit of overhead.
Having to use ReasonReact.string with every string value needs some getting used to, even if the composition operator |> helps a bit.
useState requires a function. Although this is useful when making an expensive initial state computation, it's unnecessary in most cases. I would have preferred having the 2 forms of this hook (one that accepts a value, and one that accepts a function) with different names.

I like 👍

It was pretty easy to get started with a simple app with CSS. Although the syntax for requiring a CSS file is a bit weird, the whole experience is still great.
DOM elements are fully typed, which has 2 benefits:
- You can know before runtime whether you assigned a wrong value to a prop: no more typos! It's like having propTypes built-in for the attributes of all the DOM elements.
- DOM elements are self-documenting. You can instantly hover on an element to see the possible attributes it accepts (no need to Google them anymore).

Iteration #2: there is a word count that updates while I write text

In this iteration, we want to show a count of the words typed so far:

Iteration #2: there is a word count that updates while I write text

First, let's create a function that returns the number of words in a string input:

let countWordsInString = text => {
  let spacesRegex = Js.Re.fromString("\s+");

  switch (text) {
  | "" => 0
  | noneEmptyText =>
    noneEmptyText
    |> Js.String.trim
    |> Js.String.splitByRe(spacesRegex)
    |> Js.Array.length
  };
};

So here's what the function does:

If the text is empty, we just return 0.
Otherwise, we just trim the text and use Js.String.splitByRe to split it by the regular expression \s+ (which basically means 1 or more spaces followed by any character) and return the length of the array we obtain.

/* src/App.re */

[%bs.raw {|require('./App.css')|}];

let countWordsInString = text => {
  let spacesRegex = Js.Re.fromString("\s+");

  switch (text) {
  | "" => 0
  | noneEmptyText =>
    noneEmptyText
    |> Js.String.trim
    |> Js.String.splitByRe(spacesRegex)
    |> Js.Array.length
  };
};

[@react.component]
let make = () => {
  let (text, setText) = React.useState(() => "");

  let handleTextChange = e => ReactEvent.Form.target(e)##value |> setText;

  let wordsCountText =
    (text |> countWordsInString |> string_of_int) ++ " words";

  <div className="App">
    <div className="header">
      <h3> {"Words Counter" |> ReasonReact.string} </h3>
      <span> {ReasonReact.string(wordsCountText)} </span>
    </div>
    <textarea
      placeholder="Express yourself..."
      value=text
      onChange=handleTextChange
    />
  </div>;
};

I like 👍

Reason's smart inference is great:
- Although I didn't provide any type annotations, the countWordsInString function is self-documenting. Hovering over it shows that it accepts a string and returns an int.
- At some point, I returned the split array from countWordsInString instead of its length. I was able to catch that bug at build time before even looking at the application in the browser.

Iteration #3: there is a button to clear text

In this iteration, we want to have a button to clear text:

Iteration #3: there is a button to clear textLet's add a button to clear the text in the textarea.

In JavaScript, I use the svgr Webpack loader to import SVG icons as React components directly from their corresponding .svg files.

Since imports are typed in Reason, I decided to have an icon in the clear button to see how painful it would be to import SVG icons as React components.

Since we will have another button in the next iteration which will look differently (spoiler alert), let's have our button as a separate component and make it have two categories for styling purposes:

PRIMARY: blue button
SECONDARY: gray button

/* src/Button.re */

[%bs.raw {|require('./Button.css')|}];

type categoryT =
  | SECONDARY
  | PRIMARY;

let classNameOfCategory = category =>
  "Button "
  ++ (
    switch (category) {
    | SECONDARY => "secondary"
    | PRIMARY => "primary"
    }
  );

[@react.component]
let make =
    (
      ~onClick,
      ~title: string,
      ~children: ReasonReact.reactElement,
      ~disabled=false,
      ~category=SECONDARY,
    ) => {
  <button onClick className={category |> classNameOfCategory} title disabled>
    children
  </button>;
};

To use svgr, let's add the following rule in the Webpack module configuration:

{
  test: /\.svg$/,
  use: ['@svgr/webpack'],
}

In JavaScript, we can import an svg component by doing this:

import {ReactComponent as Times} from './times';

Since Webpack applies svgr to the JavaScript resulting from compiling our Reason source code, we just need to make BuckleScript translate our Reason import into a named es6 import.

To do so, we first have to configure /bs-config.json (the configuration file for the BuckleScript compiler) to use es6 imports:

  "package-specs": [
    {
      "module": "es6",
      "in-source": true
    }
  ],

ReasonReact make function compiles to a JavaScript React component! This means that if we want to use a component "Foo" that is written in JavaScript, all that we have to do is:
1- Create the component in Reason.
2- Import the JS component as the make function of the Reason component and annotate its props.

So in the module Foo.re, we would have the following:

[@bs.module "./path/to/Foo.js"][@react.component]
external make: (~someProp: string, ~someOtherProp: int) => React.element = "default";

Which means ... that we can use that to import an SVG component with svgr!
Let's use it to import the ./times.svg icon and just annotate the height prop since it's the only one we will be using:

[@bs.module "./times.svg"] [@react.component]
external make: (~height: string) => React.element = "default";

Our ReasonReact components were automatically considered as modules because we created them in separate files (Button.re, App.re). Since the Times component is pretty small (2 lines), we can use Reason's module syntax to create it:

/* src/App.re */

[%bs.raw {|require('./App.css')|}];

let countWordsInString = text => {
  let spacesRegex = Js.Re.fromString("\s+");

  switch (text) {
  | "" => 0
  | noneEmptyText =>
    noneEmptyText
    |> Js.String.trim
    |> Js.String.splitByRe(spacesRegex)
    |> Js.Array.length
  };
};

module Times = {
  [@bs.module "./times.svg"] [@react.component]
  external make: (~height: string) => React.element = "default";
};

[@react.component]
let make = () => {
  let (text, setText) = React.useState(() => "");

  let handleTextChange = e => ReactEvent.Form.target(e)##value |> setText;

  let handleClearClick = _ => setText(_ => "");

  let wordsCountText =
    (text |> countWordsInString |> string_of_int) ++ " words";

  <div className="App">
    <div className="header">
      <h3> {"Words Counter" |> ReasonReact.string} </h3>
      <span> {ReasonReact.string(wordsCountText)} </span>
    </div>
    <textarea
      placeholder="Express yourself..."
      value=text
      onChange=handleTextChange
    />
    <div className="footer">
      <Button
        title="Clear text"
        onClick=handleClearClick
        disabled={String.length(text) === 0}>
        <Times height="20px" />
      </Button>
    </div>
  </div>;
};

I dislike 👎

If I want to make a reusable button that should accept all the attributes a native DOM button does, I would have to list all of those attributes. In JavaScript, I can avoid that by just using the spread operation:

function Button(props) {
    return <button {...props} />
}

However, ReasonReact doesn't allow the spread operator. (I wonder if there is a way to achieve what I want with ReasonReact 🤔)

I like 👍

The ability to specify the type of children is very powerful. This is possible with PropTypes in JavaScript but very limited compared to Reason. We can, for example, specify that the component only accepts 2 children (as a tuple).
Variants were useful to categorize buttons. Categorizing components is something that occurs very often, so being able to do that with an actual reliable type instead of string constants is a huge win.
Using the Webpack svgr plugin to import an SVG as a component was actually pretty painless. It's very simple and yet ensures type safety since we have to annotate the types.

Iteration #4: there is a button to copy text

In this iteration, we want to have a button to copy text to the clipboard:

Iteration #4: there is a button to copy text

To do so, I want to use react-copy-to-clipboard, which is a React component library that allows copying text to the clipboard very easily. Since it's a JavaScript library, we can use the same import approach we used in the previous iteration. The only difference is that we will make a named import and not a default import.

/* src/App.re */

[%bs.raw {|require('./App.css')|}];

let countWordsInString = text => {
  let spacesRegex = Js.Re.fromString("\s+");

  switch (text) {
  | "" => 0
  | noneEmptyText =>
    noneEmptyText
    |> Js.String.trim
    |> Js.String.splitByRe(spacesRegex)
    |> Js.Array.length
  };
};

module Times = {
  [@bs.module "./icons/times.svg"] [@react.component]
  external make: (~height: string) => React.element = "default";
};

module Copy = {
  [@bs.module "./icons/copy.svg"] [@react.component]
  external make: (~height: string) => React.element = "default";
};

module CopyClipboard = {
  [@bs.module "react-copy-to-clipboard"] [@react.component]
  external make: (~text: string, ~children: React.element) => React.element =
    "CopyToClipboard";
};

[@react.component]
let make = () => {
  let (text, setText) = React.useState(() => "");

  let handleTextChange = e => ReactEvent.Form.target(e)##value |> setText;

  let handleClearClick = _ => setText(_ => "");

  let wordsCountText =
    (text |> countWordsInString |> string_of_int) ++ " words";

  <div className="App">
    <div className="header">
      <h3> {"Words Counter" |> ReasonReact.string} </h3>
      <span> {ReasonReact.string(wordsCountText)} </span>
    </div>
    <textarea
      placeholder="Express yourself..."
      value=text
      onChange=handleTextChange
    />
    <div className="footer">
      <Button
        title="Clear text"
        onClick=handleClearClick
        disabled={String.length(text) === 0}>
        <Times height="20px" />
      </Button>
      <CopyClipboard text>
        <Button
          title="Copy text"
          disabled={String.length(text) === 0}
          category=Button.PRIMARY>
          <Copy height="20px" />
        </Button>
      </CopyClipboard>
    </div>
  </div>;
};

I like 👍

Importing a JavaScript React component library is also very simple and ensures type safety.