DEV Community: Miroslav Nikolov

Writing Developer-Friendly React Unit Tests

Miroslav Nikolov — Tue, 30 Mar 2021 07:09:19 +0000

You want to write React unit (component) tests in a human-readable manner. In conjunction with the best practices today it should make your life (and the life of your colleague developers) easier and reduce the number of production bugs.

it("should render a button with text", () => {
  expect(
    <Button>I am a button</Button>,
    "when mounted",
    "to have text",
    "I am a button"
  );
});

This component test is for real. Back on it soon... [🔖]

The Problem

Snapshots and direct DOM comparison are fragile while JQuery like chaining syntax reads bad and makes tests wordy. How to address the readability issue in that case? How to keep up testing components' data flow in isolation by hiding their implementation details?

Below is my approach to unit testing in React. It aims to follow the consensus with a pinch of clarity on top.

The Component (A Button)

A trivial Material UI-like button will be used for this demonstration. It is simple enough to unfold the concept with the help of several test examples.

// Button.js

export default function Button({
  children,
  disabled = false,
  color,
  size,
  onClick,
}) {
  const handleClick = () => {
    if (!disabled) {
      if (typeof onClick === "function") {
        onClick();
      }
    }
  };

  return (
    <button
      className={classNames("Button", {
        [color]: color,
        [size]: size,
      })}
      disabled={disabled}
      onClick={handleClick}
    >
      {children}
    </button>
  );
}

Testing Library

Getting back to the test case on top [🔖]. It uses UnexpectedJS—an assertion library compatible with all test frameworks—supplemented by a few plugins to help you working with React components and the DOM.

Jest is the test runner and behind the scenes, it has react-dom and react-dom/test-utils as dependencies.

Testing Setup

There is an example GitHub repo you can use as a ref. Head over there for the full picture.

Otherwise here are some of the more interesting moments:

Project Structure

-- src
    |-- components
    |   |-- Button
    |   |   |-- Button.js
    |   |   |-- Button.scss
    |   |   |-- Button.test.js
    |-- test-utils
    |   |-- unexpected-react.js

Test Plugins

package.json

"devDependencies": {
  ...
+ "sinon": "9.2.4",
+ "unexpected": "12.0.0",
+ "unexpected-dom": "5.0.0",
+ "unexpected-reaction": "3.0.0",
+ "unexpected-sinon": "11.0.1"
}

Sinon is used for spying on functions—callback component props executed as a result of specific user interactions with the UI.

Test Helper

A test helper named unexpected-react.js has the following structure:

// unexpected-react.js

import unexpected from "unexpected";
import unexpectedDom from "unexpected-dom";
import unexpectedReaction from "unexpected-reaction";
import unexpectedSinon from "unexpected-sinon";

const expect = unexpected
  .clone()
  .use(unexpectedDom)
  .use(unexpectedReaction)
  .use(unexpectedSinon);

export { simulate, mount } from "react-dom-testing";

export default expect;

It simply exports all necessary functions to put together the Button's tests.

Button Component Tests

// Button.test.js

import expect, { mount, simulate } from "../../test-utils/unexpected-react";
import React from "react";
import sinon from "sinon";

import Button from "./Button";

describe("Button", () => {
  // Test cases
});

Individual unit/component tests are placed within a describe() block. See below.

1. Render with text.

it("should render with text", () => {
  expect(
    <Button>I am a button</Button>,
    "when mounted",
    "to have text",
    "I am a button"
  );
});

Checking if a button renders with the specified text.

2. Render with custom markup.

it("should render with markup", () => {
  expect(
    <Button>
      <span>Download</span>
      <span>⬇️</span>
    </Button>,
    "when mounted",
    "to satisfy",
    <button>
      <span>Download</span>
      <span>⬇️</span>
    </button>
  );
});

If you want to compare the DOM structure—which in this case may make sense—this is the way to go.

You can also use data-test-id with its relevant assertion. Fx.

it("should render with markup", () => {
  expect(
    <Button>
      <span>
        <i />
        <span data-test-id="button-text">
          Download
        </span>
      </span>
    </Button>,
    "when mounted",
    "queried for test id"
    "to have text",
    "Download"
  );
});

3. Render a primary button.

it("should render as primary", () => {
  expect(
    <Button color="primary">Primary</Button>,
    "when mounted",
    "to have class",
    "primary"
  );
});

There are two supported color prop values: primary and secondary. These are then set as CSS classes.

4. Render a small button.

it("should render as small", () => {
  expect(
    <Button size="small">Small</Button>,
    "when mounted",
    "to have class",
    "small"
  );
});

Similar to color there are two values for the size prop: small and large.

5. Render as disabled.

it("should render as disabled", () => {
  expect(
    <Button disabled>Disabled</Button>,
    "when mounted",
    "to have attributes",
    {
      disabled: true,
    }
  );
});

Checking for the disabled attribute. That's all.

6. Don't trigger click handlers.

it("should NOT trigger click if disabled", () => {
  const handleClick = sinon.stub();

  const component = mount(
    <Button onClick={handleClick} disabled>Press</Button>
  );

  simulate(component, { type: "click" });

  expect(handleClick, "was not called");
});

The onClick callback should not be executed on disabled-buttons.

7. Handle a click.

it("should trigger click", () => {
  const handleClick = sinon.stub();

  const component = mount(
    <Button onClick={handleClick}>Click here</Button>
  );

  simulate(component, { type: "click" });

  expect(handleClick, "was called");
});

The was called assertion here has a better alternative if you need to test for arguments passed to the handler. Fx.

// Passing a checkbox state (checked) to the callback
expect(handleClick, "to have a call satisfying", [true]);

8. Tests output.

This is what you will see in the terminal if all unit tests are passing.

Final Words

There is a trend for testing in React (and testing in general) which has been started by React Testing Library and seems the majority of our community is going after it. Its guiding principle is:

...you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended.

This statement translates to something like "you should not test against components' DOM structure but rather focus on data flow." Changes in your component DOM should not break your tests.

UnexpectedJS comply with this principle by allowing you to easily test for data-test-id (or aria-* attributes) while at the same time encourages writing human-readable unit tests by its custom assertions.

PS: Would such an approach be of a value to you?

Join My Programming Newsletter

I send it out once a month. It contains my latest write-up plus useful links and thoughts on topics I can't easily find answers by just Googling.

If it sounds interesting head over and add your email.
Spam-free.

What Is Your Aha Moment With React

Miroslav Nikolov — Wed, 24 Mar 2021 16:39:06 +0000

My early days with React were... difficult.

Things didn't go straight. So many bumps and new concepts. It was slow to grasp Redux, rendering and class components.

Partly because I was so used to OOP in JavaScript, partly due to the new component UI patterns, I have to admit the whole journey was full of surprises and not easy.

Hooks didn't make things easier, either.

🙀 What is your latest React Aha moment?

Evergreen CSS Flex Layouts With Live Demos

Miroslav Nikolov — Wed, 10 Mar 2021 12:05:02 +0000

I have to deal with CSS Flex layouts very often but noticed building them from scratch every time. That's irritating.

So I put together a growing list of 9 demos with copy-paste ready code snippets to help me start with a proper base next time.

Head to the previews and tell me what is the template you are missing there.

React HoC vs Hooks vs Render Props in 2021

Miroslav Nikolov — Tue, 23 Feb 2021 06:48:03 +0000

Did React hooks took over or there is still room for the HoC and render prop patterns?

In 2021 React hooks are everywhere and many serious OSS projects are using functional components already.

During ReactEurope Erik Rasmussen did a good round-up of how things started with HoCs, went through their replacement — render props — and ended up today with hooks. It also compares several use cases.

If I have to make my own conclusion it would sound like that:

HoC, hooks and render props have their own use cases and none of them is a full replacement of the others. In some cases HoCs and components with a render prop my even make more sense.

A good example of the above is the connect() function from React Redux used to connect your component to the store. It does return a HoC.

// This will return a HoC wrapper around MyComponent
connect()(MyComponent);

With the modern Redux you can get data and dispatch actions to the store directly using the useSelector and useDispatch hooks, so connect() is no longer required. While it's true, this is one of these moments where I find the HoC pattern still useful for production apps. The main reason is... testing. It's very easy to test a component in isolation via props.

function MyComponent({
  name,           // own prop
  size,           // own prop
  count,          // redux store selector
  activateAction  // redux action
});

With the hooks your tests won't be that straightforward as per some tradeoffs but this is the recommended way to go in the React community.

To wrap up: Functional components and react hooks are our preferred way of working with React these days but hooks are not always your silver bullet. Collaboration, testing, reusability, and logic explicitness, should determine what is a better fit and not the mainstream.

React Patterns: A Component with Many Content Variants

Miroslav Nikolov — Tue, 09 Feb 2021 07:56:03 +0000

A dumb component renders any text passed while its visual appearance remains static. It is also unknown how many new content variations are about to come. What would be a useful React pattern in this scenario?

The Problem

Look at the right side of the picture below.

It displays two lines of text and a link. You will face no issues representing it with a single component until the content becomes dynamic and texts/link need to change. In such case presentation (aka design) is the same, but content may have fluid variations.

The challenge is to organize your code, so it remains simple and allows for painless future changes.

There are three things to take care of along the way: styling, data, and business logic.

The Solution

It aims for flexibility and maintainability. Making future changes should be straightforward as that is the real pain point here — prepare the code for hidden information causing new uses cases to pop in.

Folder Structure

-- components
   |-- Box
       |-- Box.js
       |-- Box.css
       |-- components
           |-- Text1.js
           |-- Text2.js
           |-- Text3.js
           |-- Text4.js

The solution involves two-component levels — parent component (<Box />) and several child components for each textual case (<TextN />). Note that child component names above are chosen to simplify the picture. Ideally, you should name them after each specific use case, fx. StorageEmptyText.js, StorageAboveAverageText.js, StorageFullText.js, etc.

Box Component

That's the parent (container) component. Its purpose is to manage business logic and styling.

// Box.js

import StorageEmptyText from "./components/StorageEmptyText";
import StorageAboveAverageText from "./components/StorageAboveAverageText";
import StorageFullText from "./components/StorageFullText";

export function Box({
  storage,
  openDialogAction,
  manageStorageAction,
  upgradeToProPlanAction
}) {
  let TextComponent = () => null;
  let handleClick = () => null;

  // 1️⃣ Use case logic: conditionally assign text component and click action
  if (storage === 0) {
    TextComponent = StorageEmptyText;
    handleClick = openDialogAction;

  } else if (storage > 50 && storage < 80) {
    TextComponent = StorageAboveAverageText;
    handleClick = manageStorageAction;

  } else if (storage >= 90) {
    TextComponent = StorageFullText;
    handleClick = upgradeToProPlanAction;
  }
  // 2️⃣ More cases to follow

  return (
    <div className="Box">
      {/* 3️⃣ A component with render prop is famous for its flexibility */}
      <TextComponent>
        {({ title, description, link }) => (
          <>
            {/* 4️⃣ Box.js (the parent) holds these elements' styling */}
            <h3>{title}</h3>
            <p>{description}</p>
            <span onClick={handleClick}>{link}</span>
          </>
        )}
      </TextComponent>
    </div>
  );
}

Several benefits emerge from such a structure:

The markup around each text is part of Box.js so you can style it here.
The use case logic is explicit.
Child components are nearby.

Having texts encapsulated in <TextComponent />s instead of a function or hooks will also lighten the tests. You will need to check the className or data-test-id presence for each use case, not the actual texts.

// Box.test.js

expect(
  <Box storage={95} />,
  "when mounted",
  "to contain elements matching",
  ".StorageFullText"
);

Text Components

You may have any number of these components. They share the same structure — dumb component with a render prop function to accept the texts. File names should be descriptive as that gives you a hint of what's going on by both, looking at the folder structure and maintaining the logic in Box.js

// StorageFullText.js

export default function StorageFullText({ children }) {
  return (
    <div className="StorageFullText">
      {/*
        Passes down its texts to a children() function
        That allows for custom styling in the parent
      */}
      {children({
        title: "Looks like you have too many items",
        description: "Upgrade to our Pro plan or free up more space in your box.",
        link: "See all plans"
      })}
    </div>
  );
}

<StorageFullText /> uses render prop to send back data and is not aware of how texts are consumed later on. One of the reasons for using this pattern is the flexibility render prop components provide over hooks fx.

Final Words

Handling text components may look simple on the surface, but in some situations requires you to take a different approach and the extra step.

If a component doesn't change its visual representation and structure but may have many content variants, it makes sense to involve fewer wrappers if possible. The guiding principle is to avoid being smart about code reusability. Instead, go explicit and minimal expecting things to change.

📩

I maintain a monthly blog newsletter with more posts like this.

How Can Developers Save a Failing Project

Miroslav Nikolov — Mon, 18 Jan 2021 07:22:33 +0000

Quick summary: A project is about to fail. Everybody feels it won't meet the hard deadline. But the app ended up released on time and bug-free. How is that possible?

I want to tell you the real story behind an ambitious two-month project my team completed, with a huge impact on our organization. A very stressful, challenging, and full of surprises journey, marked by developers being the leaders. I intend to reveal why things went bad and how with a proper smart set of decisions the front-end team managed to navigate its boat.

The Project
- Project Context
- Project Goal
What Compromised the Project (Early Signs)
Developers in Charge
Developers' Strategy to Deal with Impediments
- No Clear Leadership
- Lack of Domain Knowledge
- Incomplete Requirements
- Too Many Teams
Best Practices Summary
Final Words
Resources

The Project

The project is intentionally interpreted mostly from a front-end perspective to avoid the risk of having a blurry presentation.

Which parties were involved:

Product owner (PO)
Front-end team (2 devs)
Backend team (2 devs)
QA team (2 testers)
UX/Designer
Content manager (translations)

In total 9 people from 6 departments were allocated for this two-month effort (around 9 weeks). The UX design was done in advance, so it's not included in the total duration.

Project Context

Rapidly growing companies are usually investing in new hires and changes in the hierarchy structure. From all the 9 people involved, 2 were new employees (PO and design), 2 had a year of experience in the organization, and from all 6 teams 3 were newly formed while the rest were restructured to an extent. The newly formed UX team was extensively focused on the UIs in Figma backed with translations delivered by a content manager who switched departments. On top of that building applications with a PO was new for us - these duties used to be fulfilled by a project manager in the past.

Where was I in the whole picture? You probably know the answer. Yes, I was too part of a newly formed web apps team of front-end developers. Up until this moment we were located in different cross-functional teams formed around specific long-term company products.

So many new, new, new.

To summarize:

Dynamic environment, new colleagues, new company structure. A dangerous combination for ambitious projects with tight deadlines.

Project Goal

The purpose of the application was to allow customers easily find and operate on their subscription data, reducing, as a side effect, the number of related support tickets significantly.

To make things more complicated the project must account for all services, add-on products, and user edge cases dragged in over the years of product development.

What Compromised the Project (Early Signs)

Getting back from vacation I was immediately thrown into the process, having no idea what this new project is about. All planning and grooming sessions were already in the past, and teams were formed. At the same time, it was left to the individual parties to self-organize somehow and find their way in. I felt very uncomfortable and anxious: no information to start with, no initial setup, but probably the the most noticeable fact was the lack of clear leadership. To fill the gap many project management tasks got "naturally" assigned to the front-end team and from that point on required additional time for coordination.

A quick side note: Often a project failure is determined by a few common factors. In one of his recent newsletters ("Thoughts on mistakes") Nicholas Zakas grouped them like so: skills, luck, and hidden information. In such a combination they influence the outcome of a decision, but all of them apply to IT projects in general.

With a few exceptions, you can control the amount of skill you bring into making a decision, and you can work to uncover hidden information (though sometimes it's not obvious where to look), but luck is completely out of your control.

Getting back to the story, and I have to admit, it was a minefield of hidden information popping up until the final release. All the skills required were present and even more of that. No unexpected event, call it luck if you want, has ever occurred. To uncover and deal with invisible use cases or wrong assumptions was the project's most common bottleneck.

What prompted hidden information:

No clear leadership.

Not having a dedicated PM or a fully available project lead resulted in recurring distractions to handle organizational activities.

Lack of domain knowledge.

Not understanding the domain well enough — especially by new employees — is interconnected with the number of changes coming later in the development process. The higher the position, the worse.

Incomplete requirements.

Gaps in domain knowledge led to unclear or too narrow requirements driven by not actively involving people with good matter understanding in the planning stage.

Too many teams.

Having to coordinate six different teams would be a needless effort if people were otherwise grouped around the project in a single cross-functional unit.

All these implications didn't give us up, of course, but forced (the front-end devs at least) to deliberately address problematic areas both code and management-wise.

But why should developers share the organizational burden, you may ask? Couldn't you simply pass it down to the PO or someone from the upper management? After all, it is their job and you are just writing code, right? These are legit questions and we asked them ourselves many times, nevertheless the project ended up deliberately led by the dev team. We were developers in charge.

Developers in Charge

The IT practice confirms whenever a team finds itself in a project storm, the best strategy is to allow experience developers to navigate the ship. This should go on until the process can be run in a normal temp with planning phases and iterations — in other words when the storm has already passed.

Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not.

The quote from when should XP be used well describes the situation I was in at that moment. Our tech fellowship took the lead, because: we knew QA and backend devs well understand the domain, our front-end team can provide fast feedback loops, we are closer to the UI and flexible enough to allow for late changes.

It was the right move. Situations like this should be considered extraordinary and avoided whenever possible, though. There is nothing better than working in a constant phase, doing what you do best, while PM handles the cross-team links. Everybody is on their seats and no huge surprises are to be expected. By saying this I also understand it's largely wishful thinking. The harsh truth is most of the companies are not agile or don't follow any structured methodology or apply frameworks like SCRUM or Kanban. I am a Kanban fan, but even its obvious benefits are rarely enough to convince organizations to give it a try nowadays. Despite the endless sugary talks and big investments in agile frameworks like SCRUM fx., most of the companies rely on XP even if they don't realize it. Developers' responsibilities overlap with PM, marketing, SEO, design, etc., and that is not a coincidence.

Developers' Strategy to Deal with Impediments

We, in the front-end, built a flexible strategy to deal with project uncertainty, quickly realizing that great code alone won't be enough for our success.

My colleagues are skilled people who rarely face technical challenges they can't solve, while sporadic events (like the Covid-19 crisis) are very much unpredictable and difficult to prepare for. With this in mind, the strategy's focus is put primarily on dealing with hidden information and minimizing its negative impact project-wise.

Once more, the four impediments:

No clear leadership.
Lack of domain knowledge.
Incomplete requirements.
Too many teams.

Solving each problem will eventually catalyze more data discoveries throughout the process, providing you, alongside, with handy tools to handle incoming change requests.

Let's take a closer look.

No Clear Leadership

I decided to act proactively on this sudden project and conducted a kick-off meeting to organize everybody and build-up some confidence. The agenda was:

Project requirements
Duties between teams
Front-end tasks
Project repo and codebase
Communication channels
Split and estimation

This was an opportunity to meet for the first time and get a feeling the project is finally moving. Further on regular sync meetings were set to discuss blockers, progress, or new information collected previously.

Lack of Domain Knowledge

It became obvious the QA and backend teams best understand most of the underlying use cases. Two activities helped in this situation:

Quick short iterations and early releases.

Deployments were performed daily so that QA and backend always had something usable to exercise on.

Frequent sync meetings.

This is the place to discuss any new findings since the last release and to turn them into development tasks.

Incomplete Requirements

Incomplete requirements are often "dressed" in a "final" UI design and are usually captured late when QA puts their hands on the front-end prototype. The following recipe was used to answer back:

Deploy incomplete prototypes.

Releasing usable prototypes with fake backend and English texts to allow for a quick feedback loop is a good idea as often endpoints may not yet exist, translations and production-ready texts may also be in progress.

Break the DRY principle.

The DRY principle is of no use when working with frequently changing prerequisites where a WET codebase will enable quick interventions with almost no side effects.

Accompany every change with refactoring.

Frequent changes often introduce tech debt. Writing explicit code and conveying each tweak with a small refactoring in the same place/component is one way to deal with it. This investment pays off with every subsequent change.

Test it thoroughly.

Keep high testing standards no matter what. They guarantee bug-free releases. Writing tests for every new feature or an edge case is important because it also leverages our confidence level in the chaos of thousands of new additions and deletions.

Too Many Teams

One of the worst combinations is an actively coding programmer who at the same time is required to manage a project. It is something to be avoided in any means or, if not possible, used very wisely for a short period.

How did the front-end team compensate for the coordination cost:

Passing duties between each other.

I and my colleague shared the burden by having shifts when organizing sync meetings and handling iteration loops.

Set direct communication channels.

That was done in Slack for everything from status updates, through requirements discussions, to meetings planning.

Best Practices Summary

The table below summarizes the practical principles to deal with certain project bottlenecks:

Approach	Benefits
Hold a kick-off meeting	Builds confidence and reduces stress.
Hold regular sync meetings	Polishes requirements by giving a chance to parties with domain knowledge to share.
Keep iterations short	Quick feedback and testing ideas.
Release a static prototype early	Potentially catching major assumption flaws ahead of time.
Use WET vs DRY principle	Painless and frequent changes with minor side effects.
Make changes in conjunction with refactoring	High codebase quality and quicker future changes.
Test the edge cases	Minimizes code fragility over time. High chances of releasing bug-free products.
Share management duties	Reduces multitasking and allows for focus on technological challenges.

Final Words

I have to admit that I didn't work overtime for this project. That creates a false feeling of success which in turn tricks you to repeat the same mistakes next time.

Surprising results were achieved by applying the strategy above and I would like to bring some numbers. The project itself was not lengthy (9 weeks), but appeared to be heavy in terms of tasks and iterations completed. Launched within its hard deadline we had zero bugs reported on the front-end two months after its release - I basically hit the deploy button and moved on. Simultaneously our work had a great effect support-wise with around 250 fewer domain-related tickets per week reported.

What had happened comes to confirm

XP projects unanimously report greater programmer productivity when compared to other projects within the same corporate environment.

Remember this little guide if your next project gets in peril.

📩

If you face process or code challenges Google Search can't help you with, join my readers group. I send monthly updates with posts like this.

Resources

"Thoughts on mistakes" - a "Top of the Month newsletter" issue by Nicholas Zakas
When should Extreme Programming be Used? - requirements for XP's implementation
Scrum Is Dead. All Hail Kanban, the New King - some of the benefits of Kanban over SCRUM from a practical perspective
Don't repeat yourself - what does DRY mean (Wikipedia)
The WET Codebase - a video by Dan Abramov on why WET approach is often better for code collaboration.

Sticky Table Header with React Hooks

Miroslav Nikolov — Wed, 02 Dec 2020 08:11:55 +0000

Using a <table /> element instead of flexbox for data presentation is a good thing. How to turn the table header sticky with the help of React in that case? How to apply the solution into a production code? This blog post is all about that.

What follows is not a trivial tutorial on how you should solve the task. It is not a theory or fictional implementation, either. Instead, the focus is around a possible solution tested in real projects that you can easily reuse. It also sorts out some of the edge cases when working with <table />.

Go straight to the code, if that's mostly what your are looking for.

Tables vs Flexbox

Whenever you have to deal with data presentation, often the first intention is to create a <div /> based layout with flexbox. People are somehow biased to tables. Tables have a bad reputation of being used for building web pages in the past. But if done right, they can save you a ton of problems. Tables do also play very well with React.

On the other side, it doesn't come very handy to loop over your data and place it in a flexbox based grid. A good illustration on the problem is described in Accessible, Simple, Responsive Tables.

^{Table layout with flexbox. The screenshot is taken from here.}

The table-like layout above is styled with flex and looks very similar to:

<div class="table">
  <h3 class="header">Eddard Stark</h3>
  <div class="row">Has a sword named Ice</div>
  <div class="row">No direwolf</div>
  <div class="row">Lord of Winterfell</div>

  <h3 class="header">Jon Snow</h3>
  <div class="row">Has a sword named Longclaw</div>
  <div class="row">Direwolf: Ghost</div>
  <div class="row">Knows nothing</div>

  ...
</div>

A question quickly arises: How easy would be to iterate over the headers and rows data with the given markup?

Contrary, some of the table benefits include:

Column width control via header cells
Painless component-wise split between header and content (table rows)
Works out of the box (no css)

All these are closely related to the challenges behind turning table headers (<thead />) into sticky items. Understanding them, should help you better follow the code solution after.

You can build table layouts by using the usual <table /> tag or achieve the same via css with display: table and semantic elements (<div />).

// This
<table>
  <thead />
  ...
</table>

// is the same as
<div style={{ display: "table" }}>
  <div style={{ display: "table-header-group" }} />
  ...
</div>

Same visual result. The first one, though, will cause React to complain (also in tests) if you place <thead /> outside its <table /> parent.

<div>
  <thead />
</div>

- Warning: validateDOMNesting(...): <thead> cannot appear as a child of <div>.

For the sake of simplicity and to be more explicit, all examples that come after are based on the <table /> element.

Back on the benefits.

Control Columns via Header Cells

It may appear counterintuitive since the header and body cells are placed far from each other in the DOM.

<table>
  <thead>
    <tr>
      <th style="width: 200px;">Header cell</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Table cell 1</td>
    </tr>
    <tr>
      <td>Table cell 2</td>
    </tr>
  </tbody>
</table>

In this example the width of all <td /> elements will be the same as the width set with <th style="width: 200px;">Header cell</th>.

You get a side effect that allows for easy control over columns size with no additional cost of setting extensive css rules.

Header and Content Component Split

Apart from column sizing, sorting and filtering features are too mostly attached to the headers. It turns out they are very powerful unit for ruling the whole table. Such dependencies pop in especially whenever you need to split the table into React components.

Look into this Table component interface (without getting into details):

  <Table sortable headers={["Country", "Population"]} data={data}>
    {dataAfterSorting => (
      dataAfterSorting.map(country =>
        <TableDataRow data={country} />
      )
    )}
  </Table>

This structure comes natural because:

It follows how tables render in the DOM (with separate header and body sections).
Sorting functionality is attached to the header.

Headers set their own styles. That includes sorting indicators, hover states, but behavior (click handlers) too. A separate component that orchestrates the whole content being decoupled from it.

The content is not aware of its context.

Components like <TableDataRow /> may live outside the table. It accepts a slice of a pre-sorted data and simply renders a row with its own styling. This component is not aware of its context and doesn't need to. With one exception: the amount of cells (<td />) it displays must be the same as in the header.

Tables Work Out of the Box

Tables are straightforward and well known. You don't need additional code to achieve a basic presentation for a given data set. By simply using the <table /> structure you already have a form for the numbers.

The same is not true for flexbox as discussed earlier.

Sticky Header (code solution)

This is the demo implementation and its code can be found in the CodeSandbox project. The stickiness is achieved by a simple <Table /> component and a useStickyHeader React hook.

Reuse it by adding your custom table styles in styles.css.

<Table /> Component Interface

The Table component itself is rendered like so

// App.js
const tableHeaders = ["Country", "Code", "Area", "Flag"];

export const tableData = [
  {
    country: "Brazil",
    code: "BR",
    area: "8,515,767 km2",
    flag: "🇧🇷"
  },
  ...
];

<Table headers={tableHeaders} data={tableData} />

^{See App.js}

where its headers prop accepts an array of strings and data is an array of objects.

<Table />'s interface is not so crucial for the actual sticky implementation and you can build your own abstraction.

<Table /> Component Implementation

Below is the code behind Table.js. It serves as a wrapper for the table and its sticky header.

// Table.js
function Table({ headers = [], data = [] }) {
  const { tableRef, isSticky } = useStickyHeader();

  const renderHeader = () => (
    <thead>
      <tr>
        {headers.map(item => <th key={item}>{item}</th>)}
      </tr>
    </thead>
  );

  return (
    <div>
      {isSticky && (
        <table
          className="sticky"
          style={{
            position: "fixed",
            top: 0,
            left: 0,
            right: 0
          }}
        >
          {renderHeader()}
        </table>
      )}
      <table ref={tableRef}>
        {renderHeader()}
        <tbody>
          {data.map(item => (
            <tr key={item.code}>
              <td>{item.country}</td>
              <td>{item.code}</td>
              <td>{item.area}</td>
              <td>{item.flag}</td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

^{View Table.js in CodeSandbox.}

A few important aspects require a bit of details here.

const { tableRef, isSticky } = useStickyHeader();

The custom React hook with two props exposed:

tableRef - used to ref the table element you want to have a sticky header for.
isSticky - a flag turning true whenever the table is over the page's top edge.

// Render if isSticky is true.
{isSticky && (
  // This is a required <table /> wrapper for the sticky header.
  // .sticky class distinguishes from the original table
  // and the additional style enables the stickiness.
  <table
    className="sticky"
    style={{
      position: "fixed",
      top: 0,
      left: 0,
      right: 0
    }}
  >
    {/* Render the same table header */}
    {renderHeader()}
  </table>
)}

That part renders a sticky header if isSticky is true.

The sticky element above should inherit the original <table />'s styling in order to achieve the same appearance.

Another thing to note - there are two calls of renderHeader(). It means two <thead />s in the markup if stickiness is enabled. This is required. The original header needs to fill the physical space on top of the table. And it can't go sticky since position: fixed takes elements out of their context. In this case introducing a second copy of the header is one way to address the issue.

useStickyHeader() Implementation

The useStickyHeader hook is probably the only piece of code you would need given the notes on the <Table /> component.

// useStickyHeader.js
const useStickyHeader = (defaultSticky = false) => {
  const [isSticky, setIsSticky] = useState(defaultSticky);
  const tableRef = useRef(null);

  const handleScroll = useCallback(({ top, bottom }) => {
    if (top <= 0 && bottom > 2 * 68) {
      !isSticky && setIsSticky(true);
    } else {
      isSticky && setIsSticky(false);
    }
  }, [isSticky]);

  useEffect(() => {
    const handleScroll = () => {
      handleScroll(tableRef.current.getBoundingClientRect());
    };
    window.addEventListener("scroll", handleScroll);

    return () => {
      window.removeEventListener("scroll", handleScroll);
    };
  }, [handleScroll]);

  return { tableRef, isSticky };
};

^{View useStickyHeader.js in CodeSandbox.}

Quickly going through the code chunk by chunk.

const [isSticky, setIsSticky] = useState(defaultSticky);
const tableRef = useRef(null);

useState provides a way to update the isSticky flag based on some calculations. It takes a default value passed by the parent (the page may load with the table in the middle). tableRef is simply a ref to the table element required for some calculations later on.

const handleScroll = useCallback(({ top, bottom }) => {
  // The number 68 is hardcoded here and is the header's height.
  // It could also be skipped
  if (top <= 0 && bottom > 2 * 68) {
    !isSticky && setIsSticky(true);
  } else {
    isSticky && setIsSticky(false);
  }
  // returns a new memoized callback
  // whenever the value of isSticky changes
}, [isSticky]);

And here follow the necessary calculations. { top, bottom } describes the table's position on the screen. Once it starts passing off (top <= 0) or there is a visual space for at least two headers (bottom > 2 * 68) - the sticky mode is enabled.

The second part of the hook's implementation is its side effect. It does the scroll event binding and passes the current table dimensions down to the evaluation callback.

useEffect(() => {
  const handleScroll = () => {
    // Pass the current bounding rect of the table
    handleScroll(tableRef.current.getBoundingClientRect());
  };
  window.addEventListener("scroll", handleScroll);

  // Clear the effect
  return () => {
    window.removeEventListener("scroll", handleScroll);
  };
  // Recreate the effect if handleScroll is a new function
}, [handleScroll]);

Final Words

The full solution lives here.

Turning a table header sticky could be challenging in contrast to something made out of flexbox. It is frustrating to see that simply applying position: fixed to the header doesn't magically work. And perhaps having to render two <thead />s is too much.

On the other hand tables come very handy at presenting array-like data with many default benefits. That's why a separate blog post was dedicated to the header challenge. The minimum you would need to untangle it is a custom React hook being the main bolt.

📩

If you face process or code challenges Google Search can't help you with, join my readers group. I send monthly updates with posts like this.

Resources

A Complete Guide to the Table Element - deep into tables by Chris Coyier.
Accessible, Simple, Responsive Tables - approaching table layouts with flexbox.
Fragments - React docs on Fragments with table splitting examples.
Building Your Own Hooks - the official guide behind custom hook extraction.
CSS: Cascading Style Sheets - position - more about position: fixed on MDN.
Render Props vs React Hooks - pattern comparison to help when deciding on component interfaces.

Render Props vs React Hooks

Miroslav Nikolov — Thu, 12 Nov 2020 07:51:28 +0000

Can you guess which code snippet is more efficient and why?

I started a twitter discussion with the same questions, trying to understand if people have strong opinion about hooks and render props. Opposing the two is not a fantasy, but comes from a practical concern.

When it comes to state management render prop component:

is often more flexible and less error-prone than pure hooks solution.
is still suitable for the common case.

In reality, hooks and render props shake hands and play well together. But if you must decide between either of the two, though, let's put that decision on stress.

Want to see the end benchmark? Skip to the comparison, otherwise read on...

If your are not familiar with hooks and the render props pattern - don't worry - a good starting point is Render Props, Use a Render Prop! and Hooks at a Glance. A list of resources is also available at the end.

Render Props are Not Dead

A talk with that name by Erik Rasmussen was the trigger for this writing. It outlines how we got from HoCs to hooks. Watch it, it should make things clearer.

I remember the voice in my head hitting the play button on that React Europe video: "Wait, should I do another rewrite of my library, getting rid of the render props I so much like". At that time v2 of Enform was released and I was happy with it. An immediate v3 rewrite would ruin my motivation.

May be you:

work with hooks, but don't fully understand them
see hooks as a magic solution
want to rewrite it all with hooks

If so, then what follows may be a surprise.

The Problem

Hooks and render props can solve the same problem. It is conceptually about moving state away from your components, so that it is reusable. The question is which one does a better job? When? Does it matter to bother with wrapper components and render props since we already have the hooks API?

To answer, let's work with the common form example below throughout this journey. It's trivial and you have probably seen it many times:

class Form extends Component {
  constructor(props) {
    super(props);

    this.state = {
      name: props.name || "",
      email: props.email || ""
    }
  }

  render() {
    return (
      <form>
        <input
          value={this.state.name}
          onChange={e => {
            this.setState({ name: e.target.value });
          }}
        />
        <input
          value={this.state.email}
          onChange={e => {
            this.setState({ email: e.target.value });
          }}
        />
      </form>
    );
  }
}

^{The form is intentionally kept simpler.}

The snippet may force you to think: "This is a recipe for disaster". Right, and state is the primary suspect. Adding to that, usually you have more fields involved in the form and need to handle validation, submission, API calls, error messages too. Of course, as a result your component will grow and you may need to mitigate the state logic by abstracting it somehow.

Handling State Abstraction with Hooks

Look at this simplified code:

function Form() {
  const [name, setName] = useState("");
  const [email, setEmail] = useState("");

  return (
    <>
      <h1>This is a simple form!</h1>
      <form>
        <input
          value={name}
          onChange={e => {
            setName(e.target.value);
          }}
        />
        <input
          value={email}
          onChange={e => {
            setEmail(e.target.value);
          }}
        />
      </form>
    </>
  );
}

^{Try it out in codesandbox}

It is the same form component, but using a function instead of a class and the useState hook. Simple move that already made things nicer. Including more fields to this controlled form is as easy as handling more state in the component.

const [name, setName] = useState("");
const [email, setEmail] = useState("");
const [phone, setPhone] = useState("");
const [address, setAddress] = useState("");
...

Using hooks and functional components is already a win. OK, but you bump into another trouble - component state is growing together with the form. From that point there are two options. Create a separate form component or a custom hook to hold the state heavy lifting.

Form Custom Hook

I assume you know how to build one. There are many examples out there, so let's not focus on the useForm implementation below. What is interesting is how it improves our component and how it gets consumed. Remember we are slowly getting to the pain point - would custom hook be the best approach here.

Lastly, please excuse once again the simplicity as the idea is just to illustrate the pattern.

function Form() {
  const { values, setValue } = useForm();

  return (
    <>
      <h1>This is a simple form!</h1>
      <form>
        <input
          value={values.name}
          onChange={e => {
            setValue("name", e.target.value);
          }}
        />
        <input
          value={values.email}
          onChange={e => {
            setValue("email", e.target.value);
          }}
        />
      </form>
    </>
  );
}

^{This codesandbox contains all the details.}

Ideally adding more logic would result in just the jsx (the render) part growing, while useForm manages the state for you.

Side note:
useForm() (it's a pretty common name) may miss-reference you to react-hook-form. The name matches, but the idea is different. react-hook-form is not solving the state problem described here, but avoiding it by having the form as uncontrolled instead.

Getting back to our example. Adding errors and submit features:

function Form() {
  const { values, setValue, errors, submit } = useForm();

  return (
    <>
      <h1>This is a simple form!</h1>
      <form onSubmit={submit}>
        <input
          value={values.name}
          onChange={e => {
            setValue("name", e.target.value);
          }}
        />
        <input
          value={values.email}
          onChange={e => {
            setValue("email", e.target.value);
          }}
        />
        <input
          value={values.phone}
          onChange={e => {
            setValue("phone", e.target.value);
          }}
        />
        <p>{errors.phone}</p>
      </form>
    </>
  );
}

Still, it scales pretty good. You can move more logic into the hook and make it reusable for all form components in your project.

The state no longer resides in <Form />, but the component will continue to react on field changes. At the end, it is the same useState usage, but moved in useForm.

The obvious benefits of this approach are that it's intuitive (no weird syntax), scales pretty well and it's probably part of the React future.

Ok, but how about render props?

Handling State via Render Props

Unloading the Form component state-wise using the render props approach requires you to create a wrapper component. So, no hooks on the surface, but a regular component. In this example it is children that serves as a render prop, but you may use render (or something else) instead.

function Form() {
  return (
    <>
      <h1>This is a simple form!</h1>
      <FormManager>
        {({ values, setValue }) => (
          <form>
            <input
              value={values.name}
              onChange={e => {
                setValue("name", e.target.value);
              }}
            />
            <input
              value={values.email}
              onChange={e => {
                setValue("email", e.target.value);
              }}
            />
          </form>
        )}
      </FormManager>
    </>
  );
}

^{Curious about FormManager's implementation? Here is the codesandbox.}

Abstracting the state away in a weird way, right? Yes, this is how it is.

From the official docs:

The term “render prop” refers to a technique for sharing code between React components using a prop whose value is a function.

"...using a prop whose value is a function" - exactly what seems awkward when you see render props for the first time.

Other than that it works similar to useForm except <FormManager /> is just a normal component. This pattern might be familiar, especially if you are working on third party libraries or using such.

The render props approach has similar benefits to hooks, but looks strange and sometimes doesn't scale efficiently. Why is that?

Imagine the following:

function MyComponent() {
  return (
    <Swipeable
      onSwipeLeft={handleSwipeLeft}
      onSwipeRight={handleSwipeRight}
    >
      {innerRef => (
        <div ref={innerRef}>
          <DragDropContext onDragEnd={handleDragEnd}>
            {() => (
              <Droppable>
                {() => (
                  <Draggable>
                    {provided => (
                      <div
                        ref={provided.innerRef}
                        {...provided}
                      />
                    )}
                  </Draggable>
                )}
              </Droppable>
            )}
          </DragDropContext>
        </div>
      )}
    </Swipeable>
  );
}

^{This snippet is actually a real example.}

Nested wrapper components with render props. Oh, that doesn't look very promising. It may even trick some people to believe the pattern is obsolete in favor of "do everything with hooks".

Hooks don't suffer the nesting issue, that's true.

But if render props had no pros over hooks the article is leading to a dead end. There is something else, though, which is not about the syntax.

Keep on...

Reality Check

Let's recap. Remember this part from the beginning?

<>
  <h1>This is a simple form!</h1>
  <form>
    ...
  </form>
</>

I intentionally left more elements (<h1 />) than just the <form /> in the jsx. It is supposed to serve as a hint, because in reality some components aren't that simple. Often they render more code which you don't have control over.

A more realistic example would look like so:

function Page() {
  const { values, setValue } = useForm();

  return (
    <>
      <Header />
      <Navigation />
      <SomeOtherThirdPartyComponent />
      <form>
        <input
          value={values.name}
          onChange={e => {
            setValue("name", e.target.value);
          }}
        />
        <input
          value={values.email}
          onChange={e => {
            setValue("email", e.target.value);
          }}
        />
      </form>
      <Footer />
    </>
  );
}

Now, I know you may say: who uses jsx like that? You can obviously extract the form logic into another component and render it here instead. Yes and you would be right - seems the correct thing to do, but not always.

There are three general restrictions with hooks:

you need react@16.8.0 (the one with hooks)
you have to use functional components
you may fall into re-render issues

Skipping the first two... If you have class components and a lower version of react you can't use hooks obviously. The third one, however, is the cornerstone when deciding between hooks and render props.

You may Fall into Re-render Issues

Given the last example, every time you type in the form fields setValue will be called causing the whole <Page /> component to re-render. And because you are updating the state, this is expected. But not desirable. Suddenly filling a form may become a very expensive operation.

React is clever enough to protect you from unnecessary renders, but it won't go against its principles. Every component has its own catch-ups and you need to work around these, so it's safe against renders.

Unfortunately, it may not be the case with <Header />, <Navigation /> and <Footer /> because, let's imagine, you don't have time to refactor them. And with <SomeOtherThirdPartyComponent /> you may even not be able to do so.

Not many options here. Extracting the from in a separate component is the way to go with hooks. As a consequence - you will need to repeat that for every form in your project, forcing the tree to grow inevitably.

What if you are building a form library that exports a hook like useForm? Do you prefer your users to do the extra extraction step above? Not a big deal you may say. Not a big one, but a less flexible one.

Hooks are not remedy for all problems and they are not intended to serve that purpose. The hypothetical (or not) primer above is one of these cases where you may need the extra flexibility.

Use the hooks, but add some sugar.

Re-render only What Is Relevant

Render props don't suffer the same re-render issue hooks do. Here is why.

function Page() {
  return (
    <>
      <Header />
      <Navigation />
      <SomeOtherThirdPartyComponent />
      <FormManager>
        {({ values, setValue }) => (
          <form>
            <input
              value={values.name}
              onChange={e => {
                setValue("name", e.target.value);
              }}
            />
            <input
              value={values.email}
              onChange={e => {
                setValue("email", e.target.value);
              }}
            />
          </form>
        )}
      </FormManager>
      <Footer />
    </>
  );
}

<FormManager /> ensures whatever change is made in the form it will be isolated in that form. <Page /> is immune to unnecessary renders. You can add up more jsx with no side effects.

Of course you can always break the useful pattern. Imagine updating some <Page /> related state as a result of form manipulation. It will result in additional renders. But then, it won't be FormManager's fault.

Now if your form library exports component with a render prop instead, its users get that extra flexibility. They are no longer forced to create additional components.

Comparison in Action

Putting these two implementations side by side:

^{Feel free to play with the set up.}

Voilà. You can now see the render outcome of each form. The one on the left (custom hook) is causing re-renders in all Page children, while the one on the right (render prop) doesn't.

Final Words

Render props are very useful if you want to isolate part of the jsx and inject some state without introducing side effects to your components.

It is very common for many render prop implementations to use hooks internally so saying "it's hooks or nothing" would be extreme. Hooks support the pattern pretty well and gain the extra flexibility they lack in some situations. This is to consider when deciding between one OR the other approach.

But hey, your form library can also export both the wrapper component and the hook. This too is very common. That makes working on open source so fun.

📩

If you face process or code challenges Google Search can't help you with, join my readers group. I send monthly updates with posts like this.

Resources

The list here is not extensive. Some of the topics are more advanced, some are touching just the basics. You are welcome to add to it.

Render Props (React docs)
Hooks at a Glance (React docs)
Use a Render Prop! (Michael Jackson)
Awesome React Render Props (Jared Palmer)
Render Props are Not Dead (Erik Rasmussen)

How to Do a Device Based Code Split in React

Miroslav Nikolov — Fri, 06 Nov 2020 07:31:53 +0000

This article is a mix of arguments, reality checks and a code solution at the end. Its focus: device (touch/desktop) driven code split in React with no backend.

Often the road leading to an actual implementation is long and bumpy - priorities, design, budget, colleagues with their own views, talking in different languages. These obstacles are challenging and usually take more energy to deal with than just coding. For that reason they deserve a separate preface here.

Jump to the code section, if this is what you are looking for, otherwise let's continue.

It would be helpful if you already know what code splitting is. If not yet, the "Code Splitting" writeup in the React docs is a good start.

Reality Check

Many companies today prefer to build their web apps/sites targeting both touch and desktop devices, but would rather not invest in a separate mobile app.

Chiefs may not admit it, but the reasons spin around:

Building for the browser is fast and cheap.
No need to involve the backend.
Prizing "mobile first", but don't really align with that principle.
Technical impediments to deliver a mobile app to the store.
No budget.

Working in the browser is fast and reliable. There are many static site generators (Gatsby, Nextjs, Docusaurus) to support website creation with no backend knowledge required. Jamstack principles and tools make production deployments of a product easier than ever. Such tools are capable of bringing the "mobile first" concept to life, though it still remains wishful thinking.

At the same time publishing a standalone mobile app to some app stores may turn into a nightmare. Read about the Hey saga fx. In contrast, javascript devs can quickly mockup a mobile version with the help of Chrome tools, so why hire an iOS/Android guy?

All valid points and to add more, often you as a frontend professional won't get the chance to influence the final decision (especially in big companies). It is to be taken by product, marketing or finance teams.

Native app or web app... Let's assume a decision is taken and you are left with no choice - a web app must be delivered (for desktop and mobile users).

If You Must Code Split

Splitting react apps touch/desktop wise can be tricky if you have to do it in the frontend.

Things to be considered:

1️⃣ consider touch and desktop devices (when to serve each app)
2️⃣ decide on the split starting point (where in the code)
3️⃣ import only app specific components (how to implement it)

An answer to these three questions is important since maintainability, time, team motivation and other aspects very much depend on it.

When a Device Is Considered Touch 1️⃣

Usually you modify component's css to account for mobile devices.

Perhaps the following

.TopBar {
  height: 60px;
  background-color: #fff;
  ...
}

/* Mobile */
@media (max-width: 768px) {
  .TopBar {
    height: 100px;
    background-color: #ccc;
    ...
  }
}

works well for you most of the time. Same component, but with different appearance based on browser's width. There is no problem with this approach and very often it is enough. Now one may argue that max-width: 768px is sufficient to properly tell if a user is on a mobile device. Probably not. May be something like that is more accurate:

@media (pointer: coarse) and (hover: none) {
  ...
}

You can read more about interaction media features and their potential to determine device capabilities. Consider it when deciding on the criteria for serving your mobile web app.

Challenges arise when your company starts getting more serious about mobile users ("mobile first"). This could happen due to a separate strong design/UX and product teams being formed. In this reality your desktop and mobile websites/apps may end up drastically different. Business logic, pages, interactions and overall appearance are now unalike. Two independent versions of the same software.

How does that translate in the React's language?

For sure you won't be able to reuse every single component in both apps (touch and desktop). Same components/pages will require different data sets and behave non-identically (javascript logic). Others will be completely unique per app. In that case css adjustments as the one above may no longer be sufficient. Interactions and data (javascript) need to be considered along with styling (css).

This is where a proper split in the frontend must be done and it can't reside in your .css files alone.

Where to Split the App 2️⃣

It really depends. You have a few options considering requirements and design. One is to split the app in its root. Maybe you have PageRouter.js or just App.js where page components are rendered based on the URL path. Second option - split individual components. It is a good choice if pages for mobile and desktop are the same (or very similar), but some child components differ. You can also pick the third option of using media queries in the css.

Split in the App's Root

This approach makes sense if your mobile and desktop apps are very different - separate pages, behavior, data and business logic in components.

Let's say there is a product details page (<ProductDetails />) on touch which doesn't exist in your desktop site. It displays detailed product information that otherwise would be part of <Products /> when viewing on PC. On a phone, though, it might be too "noisy" to present so much data in a single page.

-- src
   |-- components
   |-- pages
   |   |-- touch
   |   |   |-- Products.js
   |   |   |-- ProductDetails.js
   |   |-- desktop
   |   |   |-- Products.js
   |   |-- common
   |       |-- Checkout.js
   |-- App.js

^{See a working example in Codesandbox.}

Why is this structure OK?

More control

You can look at /touch and /desktop folders as two separate apps, allowing for full control over their content.

Easier maintenance

Most pages in your app will be common - same names component-wise, but implementing app specific logic, which is great for maintenance.

Bug fixing in isolation

Having a bug in the products page on touch tells you that the cause is probably in touch/Products.js. Fixing it there ensures your desktop page won't be affected.

Less side effects

Few more buttons for mobile or a dropdown on desktop? You can feel more comfortable implementing feature requests like that next time.

Adequate team collaboration

Implementing a products page means you have to do it for each app (two components). With the folder split above, it's easy to divide the work within the team without stepping on each other's toes.

Split on Component Level

Root level code split is often supplemented by splitting the /components folder in a similar way. On the other hand, sometimes your desktop and mobile apps won't be very different. Only a few components deep in the tree may have an unalike data model or behavior. If you find yourself in any of these cases it might be useful to do a split per component.

-- src
   |-- components
   |   |-- touch
   |   |   |-- TopBar.js
   |   |   |-- TopBar.css
   |   |-- desktop
   |   |   |-- TopBar.js
   |   |   |-- TopBar.css
   |   |-- common
   |       |-- Footer.js
   |       |-- Footer.css
   |-- pages
   |-- App.js

<TopBar /> component has some data/behavior differences that require you to implement it separately for each app. In the same time /common folder still contains all shared components.

You can see how that is done for /components in products page example.

Why is this structure OK?

Adding to the pros of the previous section you will have less code to maintain, since only a few components may require a split. Reusing app specific and shared components is also going to be straightforward.

import ProductDescription from "../../components/desktop/ProductDescription";

export default function Products() {
  ...
}

^{pages/desktop/Products imports only components from components/desktop.}

Components with Styling Differences

Should you create two copies of a component if it contains the same logic, but differs in styling? Looks like it should be shared and placed in the /common folder, but at the same time its css will need the good old media query approach.

@media (max-width: 768px) { ... }

/* OR */

@media (pointer: coarse) and (hover: none) { ... }

That looks ok. Is it the best thing you can do, though? What if the logic detecting mobile capabilities changes? Should you change it everywhere? This is not optimal.

Ok, what to do?

Ideally the logic for detecting touch devices should be central for the app. Getting a desktop or mobile component to render should be a matter of simply tweaking a prop.

Imagine this structure:

-- src
   |-- components
   |   |-- touch
   |   |   |-- TopBar.js
   |   |   |-- TopBar.css
   |   |-- desktop
   |   |   |-- TopBar.js
   |   |   |-- TopBar.css
   |   |-- common
   |       |-- TopBarLinks.js
   |       |-- TopBarLinks.css
   |-- pages
   |-- App.js

<TopBarLinks /> is a shared component and may have some visual diffs. In its css this is addressed with a class.

.TopBarLinks { ... }         /* Desktop */
.TopBarLinks.touch { ... }   /* Mobile */

Then it is used both in desktop/TopBar and touch/TopBar:

// desktop/TopBar.js
export const TopBar = () => (
  <div className="TopBar">
    <img alt="Logo" src="../../assets/logo.png" />
    <TopBarLinks />
  </div>
);

and

// touch/TopBar.js
export const TopBar = () => (
  <div className="TopBar">
    <img alt="Logo" src="../../assets/logo.png" />
    <TopBarLinks touch />
  </div>
);

That's it. This is how you can render shared components with visual diffs. As a result the css file is cleaner and independent of the device detection logic.

Enough said on the possibilities for organizing the codebase. Now, how to glue things together.

Load Components on Demand 3️⃣

No matter where the split resides in - application root or individual components, or perhaps both - its implementation is going to be the same. Ultimately the pages from all earlier examples are also components.

The task is to load only desktop OR touch related code in the browser. Loading the whole bundle (all components), but using (rendering) only device specific slices may work, but it's not optimal. A proper implementation requires you to use dynamic import().

React docs tell you that Suspense relies on that principle underneath and will probably do the job. You could also base your solution on loadable-components library. For the sake of simplicity and to cover the specific use case of touch/desktop based split, let's further focus on a plain solution.

Conditionally Import and Render Components

I personally imagine the following in the application root (App.js):

import Import from "./Import";

function App() {
  return (
    <div className="App">
      <h1>Product page</h1>
      <Import
        touch={() => import("./touch/Products")}
        desktop={() => import("./desktop/Products")}
      >
        {Product => <Product />}
      </Import>
    </div>
  )
}

^{See it in the example Codesandbox app.}

The <Import /> component (you can name it differently) accepts two props - desktop and touch. They expect a function returning a dynamic import call. In the example above there are two independent <Product /> page components that you may want to import/render conditionally.

The third prop is a children function that does the actual rendering. An obvious benefit of using render prop function here is the opportunity to explicitly pass any props to your component if needed.

{Product =>
  <Product
    title={product.title}
    description={product.description}
  />
}

Implementation Details

What will Import do internally is to: evaluate which component to load and pass it down as an argument to the render prop function.

Basic implementation may look like:

// Detect touch enabled devices based on interaction media features
// Not supported in IE11, in which case isMobile will be 'false'
const isMobile =
  window.matchMedia("(pointer: coarse) and (hover: none)").matches;

export function Import({ touch, desktop, children }) {
  const [Component, setComponent] = useState(null);

  useEffect(() => {
    // Assign a callback with an import() call
    const importCallback = isMobile ? touch : desktop;

    // Executes the 'import()' call that returns a promise with
    // component details passed as an argument
    importCallback().then(componentDetails => {
      // Set the import data in the local state
      setComponent(componentDetails);
    });
  }, [desktop, touch]);

  // The actual component is assigned to the 'default' prop
  return children(Component ? Component.default : () => null);
}

^{More on Import and its usage - check the app context.}

Some notes:

window.matchMedia("(pointer: coarse) and (hover: none)") - you can use any other mechanism for detecting touch capabilities here. Going a step further, isMobile may come from the store instead (if you are using redux, mobx or other global state management mechanism).
importCallback().then(componentDetails) - the actual component is set in componentDetails.default and you have to export it using default export (export default function Products()).
Finally, imported data is set to the local state and your component passed down to the children function for rendering.

Using import() requires some prerequisites to allow for proper parsing and dividing the final bundle in parts. You may need to additionally set these up.

Webpack Config

For the split to work there are some adjustments in the webpack config file to be made. An example config by Dan Abramov can be found on github. If you are using Create React App that is done by default.

module.exports = {
  entry: {
    main: './src/App.js',
  },
  output: {
    filename: "bundle.js",
    chunkFilename: "chunk.[id].js",
    path: './dist',
    publicPath: 'dist/'
  }
};

Babel Plugin

If you are using Babel the @babel/plugin-syntax-dynamic-import plugin is required in order to properly parse dynamic imports.

Eslint Config

eslint-plugin-import is also required to support export/import syntax. Don't forget to update your eslint config file:

{
  parser: "babel-eslint",
  plugins: ["import"]
  ...
}

Again code splitting is supported by default with Create React App and you can skip the config steps in that case.

Final Words

Check the full code implementation in Codesandbox for details on device based code splitting.

I would like to wrap up by sharing my own motivation for having app structure like the one described. It may not be your case, but my observations show a common mindset especially in big corps where a clear separation between product, backend and frontend is in place.

In that reality it's much easier (and often the only thing you can do) to overcome process issues with a tech solution, instead of trying to change people.

Here is an example: you know that backend will deliver the API in a week, but you also know that you can deliver the UI today. Waiting one week for the backend? The slow backend delivery might be due to organizational issues. The tech solution in that case is to mock the payload and deliver to QA and Product teams early.

The same motive plays its role when trying to avoid the backend by carefully code splitting the app.

Frontend-only app split will allow for:

development speed as per less backend deps
flexibility when changes are requested

It also means less headache by not having to confront colleagues and management, and higher confidence as you remain in the javascript land - your comfortable area of expertise.

📩

If you face process or code challenges Google Search can't help you with, join my readers group. I send monthly updates with posts like this.

Resources

Code-Splitting - React - from React's official docs.
Code Splitting - Create React App - words on code splitting in create-react-app.
Suspense for Data Fetching - get an overview on how and when to use React Suspense.
Webpack Code Splitting - configure webpack to support code split in your React app.
Loadable Components - Guide - Getting started guide for loadable-components.
Interaction Media Features and Their Potential - how to better determine device capabilities with media queries.

DEV Community: Miroslav Nikolov

Writing Developer-Friendly React Unit Tests

The Problem

The Component (A Button)

Testing Library

Testing Setup

Project Structure

Test Plugins

Test Helper

Button Component Tests

1. Render with text.

2. Render with custom markup.

3. Render a primary button.

4. Render a small button.

5. Render as disabled.

6. Don't trigger click handlers.

7. Handle a click.

8. Tests output.

Final Words

Join My Programming Newsletter

What Is Your Aha Moment With React

Evergreen CSS Flex Layouts With Live Demos

React HoC vs Hooks vs Render Props in 2021

React Patterns: A Component with Many Content Variants

The Problem

The Solution

Folder Structure

Box Component

Text Components

Final Words

📩

How Can Developers Save a Failing Project

Table of Contents

The Project

Project Context

Project Goal

What Compromised the Project (Early Signs)

Developers in Charge

Developers' Strategy to Deal with Impediments

No Clear Leadership

Lack of Domain Knowledge

Incomplete Requirements

Too Many Teams

Best Practices Summary

Final Words

📩

Resources

Sticky Table Header with React Hooks

Table of Contents:

Tables vs Flexbox

Control Columns via Header Cells

Header and Content Component Split

Tables Work Out of the Box

Sticky Header (code solution)

<Table /> Component Interface

<Table /> Component Implementation

useStickyHeader() Implementation

Final Words

📩

Resources

Render Props vs React Hooks

Render Props are Not Dead

The Problem

Handling State Abstraction with Hooks

Form Custom Hook

Handling State via Render Props

Reality Check

You may Fall into Re-render Issues

Re-render only What Is Relevant

Comparison in Action

Final Words

📩

Resources

How to Do a Device Based Code Split in React

Reality Check

If You Must Code Split

When a Device Is Considered Touch 1️⃣

Where to Split the App 2️⃣

Split in the App's Root

Split on Component Level