Forem: Suhan Wijaya

Intro to React Server Side Rendering

Suhan Wijaya — Tue, 12 Jan 2021 13:44:39 +0000

How to build a React SSR app without any tooling or framework

Source: Reddit and Dilbert by Scott Adams

This is the first in (hopefully) a series of articles to document the lessons I learned building and maintaining SSR apps.

This article does not cover the pros/cons of SSR, or the pros/cons of not using tooling or frameworks (e.g., Create React App, Next.js, etc).

I fully acknowledge that manually setting up build configs is painful. There is plenty of great tooling out there to abstract away these configs, so you probably don’t even need to touch any of this stuff to build awesome apps.

But for those ready to embrace the pain…

Overview

Let’s start with the basics. We will use React , webpack , and Express to build an SSR app that works as follows:

Browser sends HTTP request to server to load a page.
Server receives HTTP request and turns React JSX into HTML markup.
Server inserts the markup into a HTML template and sends the HTML response back to the browser.
Browser renders the HTML, downloads the client-side JavaScript bundle, and “hydrates” the HTML.

Also, I will focus on dev mode to keep this article short. I’m saving production mode for a future(ish 😅) article.

Project structure

Before diving into the code, let’s get situated with the project structure.

.
+-- client
| +-- components
| | +-- App
| | | +-- index.js
| | | +-- style.less
| +-- index.js
+-- server
| +-- index.js
+-- babel.config.js
+-- package.json
+-- webpack.client.config.js
+-- webpack.server.config.js
+-- webpack.shared.config.js

A quick rundown of the files in this project:

./client/components contains React and CSS code.
./client/index.js is the client-side entry point for webpack, where we “hydrate” the HTML rendered on the server-side.
./server/index.js is the server-side entry point for webpack, where we define the route to serve the HTML page.
./babel.config.js is the thing that enables you to use React JSX and ES6+ features in the browser and Node.js. You may have seen alternative versions of this file (.babelrc, babel.config.json, etc).
./webpack.shared.config.js is the config that webpack uses for both client-side and server-side code.
./webpack.client.config.js is the config specific to the client-side code.
./webpack.server.config.js is the config specific to the server-side code.

Dependencies

Here are the dependencies (and versions) used at the time of this writing. I will also mention which relevant dependencies to install in each of the following sections.

Now let’s look at each file in our project in more detail.

webpack

If you are accustomed to building SPAs (Single Page Apps), you may not have needed webpack to process your server-side code. But to enable SSR, the server must be able to read React code, or specifically — JSX. This means, we now need webpack to work its magic on our server-side code. Plus, you’ll also get to use ES6+ syntax that may not be natively supported in Node.js, e.g., import and export. (Sidenote: you don’t need webpack if you choose not to write JSX at all. 😬)

I won’t go through every webpack option in great detail, but here is a great explainer if you are interested.

Common webpack config for client-side and server-side

Install the relevant dependencies:

npm i webpack webpack-cli babel-loader

Annotations of the code comments above:

[A] For our purposes, we want to explicitly set mode to development. If we go with the default value of production , we may lose useful console warnings/errors from libraries like React, and the error stack traces are incredibly hard to read due to code minification. Read more about production and development modes here.

[B] This tells webpack to preprocess .js files with babel-loader, which transpiles ES6+ and JSX code into JavaScript code that is readable by browsers and Node.js servers. This loader uses the options we specify in babel.config.js.

[C] This means I don’t have to type out .js or .less when importing files with those extensions. For example, import App from ‘./components/App’.

Babel config

Install the relevant dependencies:

npm i babel-loader @babel/core @babel/preset-env @babel/preset-react

Annotations of the code comments above:

[A] This tells webpack to transpile ES6+ features into JS code that’s natively supported in Node.js and (most modern) browsers. Read the docs for more details.

[B] This tells webpack to transpile React JSX into JavaScript code. Read the docs for more details.

Client-side webpack config

Install the relevant dependencies:

npm i webpack webpack-cli webpack-merge webpack-dev-server mini-css-extract-plugin css-loader less-loader less

Annotations of the code comments above:

[A] This is the entry point for the client-side code, where we render the React app into the DOM.

[B] This tells webpack to save the transpiled client-side JS bundle output as ./build/client/scripts/bundle.js. Not super important for dev mode because we are using webpack-dev-server to transpile the client-side bundle “in memory”. Per the docs:

webpack-dev-server doesn’t write any output files after compiling. Instead, it keeps bundle files in memory and serves them as if they were real files mounted at the server’s root path.

[C] The publicPath option tells webpack where we will be serving the client-side bundle. Notice that we are using the same clientPort for devServer, which tells webpack-dev-server to serve the client-side bundle from http://localhost:8080/. And since the filename option tells webpack to nest bundle.js in a scripts folder, the client-side bundle will be served from http://localhost:8080/scripts/bundle.js.

[D] CSS modules and CSS preprocessors (e.g., Less, Sass) deserve an article. But in a nutshell, this piece of config tells webpack to:

transpile .less files into CSS code that the browser understands,
allow us to import style from ‘./style.less’ which is scoped locally to the component importing it (i.e., we don’t have to worry about CSS class naming collisions or specificity issues as the app grows),
generate a CSS bundle that’s served separately from the JS bundle. In this instance, the MiniCssExtractPlugin tells webpack to serve the CSS bundle from http://localhost:8080/styles/bundle.css in dev mode.

[E] Remember webpack.shared.config.js? This line merges webpack.shared.config.js with webpack.client.config.js.

Server-side webpack config

Hang in there, this is the last webpack config that we’ll cover.

Install the relevant dependencies (and grab a ☕️):

npm i webpack webpack-cli webpack-node-externals css-loader

Annotations of the code comments above:

[A] The default value is web, so we need to explicitly set it to node for webpack to work its magic on the server-side code.

[B] This is the entry point for the server-side code.

[C] This tells webpack to save the transpiled server-side JS bundle output as ./build/server/bundle.js.

[D] This tells webpack not to include the code from node\_modules in the server-side bundle.

[E] This tells webpack not to do any work over the CSS code on the server-side, but simply to make sure that every HTML element’s className matches that in the CSS code being served on the client-side.

[F] Remember webpack.shared.config.js? This line merges webpack.shared.config.js with webpack.server.config.js.

React component

Install the relevant dependencies:

npm i react

Let’s create a simple React component App, which renders our favorite greeting with some basic styles, as well as a button that displays an alert dialog when clicked. We will render this component on the server-side and hydrate it on the client-side.

Server-side code

Install the relevant dependencies:

npm i express react react-dom

Let’s create an Express server and define a route that serves an HTML page when a user visits http://localhost:3000/.

Annotations of the code comments above:

[A] This turns the React component App into HTML string, which we then insert in between the div with the ID “ssr-app”.

[B] Remember the devServer option in webpack.client.config.js to start webpack-dev-server in dev mode? These script and link tags tell the browser to fetch the client-side JS and CSS bundles respectively from the webpack-dev-server running on http://localhost:8080.

Client-side code

Install the relevant dependencies:

npm i react react-dom

In the client-side entry point, we will “hydrate” the React component that was SSR-ed into the root DOM container with the ID “ssr-app”.

Per the docs:

If you call ReactDOM.hydrate() on a node that already has this server-rendered markup, React will preserve it and only attach event handlers, allowing you to have a very performant first-load experience.

So in this example, the client-side code simply attaches the button’s click handler without having to re-render any markup in the App component.

Putting it all together

Install the relevant dependencies:

npm i rimraf webpack webpack-cli webpack-dev-server npm-run-all nodemon

This is the scripts key in the package.json file, where we define several npm scripts to build and start the app in dev mode.

Let’s look at each of them:

clear — This uses rimraf to delete the ./build folder.
build:server — This tells webpack to build the server-side code and save the bundle output to ./build/server/bundle.js (as per ./webpack.server.config.js).
start:server — This starts the Express server on http://localhost:3000.
dev:server — This uses nodemon to monitor any file changes in the working directory (minus ./build), and npm-run-all to re-run clear, build:server, and start:server whenever there are file changes.
dev:client — This tells webpack to “build” the client-side code, save the bundle output “in memory”, and serve it from http://localhost:8080 (as per ./webpack.client.config.js).
dev — This runs all of the above with a single command.

Run npm run dev in the terminal to spin up the SSR app. Open up http://localhost:3000 in your browser. 🎉🥳

Server-side rendering and client-side hydration

And click on the button Say Hello Back! 🙌🎊

Clicking the button triggers the alert dialog

Now, let’s disable client-side JavaScript…

Disable client-side JavaScript

…and refresh the page. IT’S NOT A BLANK PAGE! 🤯

Server-side rendered page

Sidenote: nothing will happen if you click on the button. That’s because the event handlers are attached by the client-side code (aka “hydration”). Recall the docs:

If you call ReactDOM.hydrate() on a node that already has this server-rendered markup, React will preserve it and only attach event handlers, allowing you to have a very performant first-load experience.

And since we disabled client-side JavaScript, what you see is just plain HTML.

Source: CoderPedia

In future(ish 😅🤞🏻) articles, I plan to cover more advanced features like routing, data fetching, caching, code-splitting, lazy-loading, and deploying a production app.

Resources

📫 Let’s connect on LinkedIn or Twitter!

Decouple Data from UI in React Part 2

Suhan Wijaya — Tue, 29 Dec 2020 21:47:57 +0000

A further exploration of the Hooks, Render Props, and HOC patterns

c. 1512, Oil on canvas, Source: programming-memes.com

In Part 1, I presented an approach to decouple the data fetching/management layer from the UI, which would free us from being locked into any particular data library or framework. Let’s call this Approach A.

Approach A. Custom Hook

Let’s create a custom hook — useSomeData — that returns the properties someData, loading, and error regardless of the data fetching/management logic. The following are 3 different implementations of useSomeData.

With Fetch API and component state:

With Redux:

With Apollo GraphQL:

The 3 implementations above are interchangeable without having to modify this UI component:

But, as Julius Koronci correctly pointed out, while the data fetching/management logic is decoupled, the SomeComponent UI is still coupled to the useSomeData hook.

In other words, even though we can reuse useSomeData without SomeComponent, we cannot reuse SomeComponent without useSomeData.

Perhaps this is where Render Props and Higher Order Components do a better job at enforcing the separation of concerns (thanks again to Julius for highlighting this).

Approach B. Render Props

Instead of a custom hook that returns someData, loading, and error, let’s create a Render Props component — SomeData — that wraps around a function (i.e., children needs to be a function), implements the data logic, and passes in someData, loading, and error into the function.

You can replace line 4 in the snippet above with Redux, Apollo GraphQL, or any data fetching/management layer of your choice.

We can now reuse SomeComponent (UI component) without SomeData (Render Props component). We can also reuse SomeData without SomeComponent.

Approach C. Higher Order Components (HOC)

Let’s create a HOC — withSomeData — that accepts a React component as an argument, implements the data logic, and passes someData, loading, and error as props into the wrapped React component.

You can replace line 5 in the snippet above with Redux, Apollo GraphQL, or any data fetching/management layer of your choice.

We can now reuse SomeComponent (UI component) without withSomeData (HOC). We can also reuse withSomeData without SomeComponent.

Today I learned.

Which approach do you prefer and why?

Resources

📫 Let’s connect on LinkedIn or Twitter!

Decouple SDK Code From Core React Code

Suhan Wijaya — Sat, 26 Dec 2020 18:04:48 +0000

And reduce the size of your future PRs with the Open/Closed Principle

KNOW YOUR ENEMY
(image by Klara Kulikova, meme from Programming Memes)

Suppose I use an external service provider to process payments for my E-commerce app, and I need to embed some external SDK code to integrate the payment service into my app.

In this oversimplified example, let’s say the payment service is responsible for checking whether a given payment method (e.g, Apple Pay and Google Pay) is available based on the customer’s device, region, etc. While my “core” UI component PaymentOptions is responsible for rendering the available payment methods as options. Lastly, I want the flexibility of adding new payment methods in the future (for 📈💰reasons).

I can write it this way.

However, the UI code is tightly coupled with the external code from the payment service, i.e., I have to modify the PaymentOptions component in order to add a new payment method or to make SDK updates.

I can perhaps break out the SDK code into a separate hook.

However, I still have to modify PaymentOptions and any other components that share the usePaymentMethods hook if I wanted to add, for example, isPaypalAvailable.

To minimize the size of future PRs, I’ve been thinking about the Open/Closed Principle, the “O” in SOLID (check out this excellent explainer): “A software artifact should be open for extension but closed for modification.”

In my own words: I should design this feature in such a way that I don’t have to touch any of the original code I wrote (closed for modification) if I were to add new payment methods in the future (open for extension).

Here’s my take on this principle. Let’s separate the payment service into its own module: a simple object where each key represents a payment method. Every payment method key points to an object with an isAvailable property (a function that uses the SDK code) and a component property (the UI component for the payment option).

Import paymentServiceModule into the PaymentOptions component.

PaymentOptions is now decoupled from the SDK implementation details, and is ignorant of the particular payment methods.

When I want to extend this feature with a new payment method (i.e., PayPal), I simply slot in a new key/value pair to paymentServiceModule without having to modify either the PaymentOptions component or the original payment methods.

The UI code should in theory also be protected against modification if I were to change payment service providers (for 💸 reasons) as long as the payment method’s duck typing remains unchanged.

Am I applying the Open/Closed Principle correctly? Curious to learn other React or JavaScript patterns in the wild that follow this principle.

Bonus

In paymentServiceModule, lazy load each payment option using the React.lazy API.

In PaymentOptions, wrap each payment option in Suspense, to lazy load the component based on availability.

Resources

📫 Let’s connect on LinkedIn or Twitter!

Traditional versus Arrow functions in JavaScript Classes

Suhan Wijaya — Thu, 17 Dec 2020 22:28:01 +0000

Source: Programmer Humor

This is a spiritual sequel to this article.

Create a class with a method using Traditional function like so. Let’s call this Approach A.

// APPROACH A

class SomeClass {
    constructor() {
        this.someProp = 'someValue';
    }

    someMethod() { // Traditional function
        console.log(this.someProp);
    }
}

Create an instance of that class. When invoking the method on the instance, this refers to the instance. So far, it’s behaving as expected.

let instance = new SomeClass();

instance.someMethod(); // logs 'someValue'

But, as soon as we assign the method to a variable and call that function variable, the method loses its context, and you get Uncaught TypeError: Cannot read property ‘someProp’ of undefined.

let instance = new SomeClass();

let funcVariable = instance.someMethod;
funcVariable(); // logs error

OK.

Now, let’s create the class with a method using Arrow function like so. Let’s call this Approach B.

// APPROACH B

class SomeClass {
    constructor() {
        this.someProp = 'someValue';
    }

    someMethod = () => { // Arrow function
        console.log(this.someProp);
    }
}

This now works.

let instance = new SomeClass();

let funcVariable = instance.someMethod;
funcVariable(); // logs 'someValue'

const { someMethod } = instance; // destructuring also works!
someMethod(); // logs 'someValue'

Why, JavaScript, why?

As per MDN docs, “the class keyword is introduced in ES2015, but is syntactical sugar, JavaScript remains prototype-based.” So if we were to write in pre-ES6 syntax, Approach A looks like this.

// Equivalent to APPROACH A

'use strict';

var SomeClass = function() {
    this.someProp = 'someValue';
}

SomeClass.prototype.someMethod = function() {
    console.log(this.someProp);
}

var instance = new SomeClass();

The property someMethod is defined on the constructor function’s prototype.

But not on the instance.

You can access instance.someMethod through prototypal inheritance.

But when you assign instance.someMethod to another variable, the function variable loses its context.

Further, since “code within the class body's syntactic boundary is always executed in strict mode”, this will be undefined instead of defaulting to window or global.

OK.

Now, Approach B looks like this in pre-ES6:

// Equivalent to APPROACH B

'use strict';

var SomeClass = function() {
    this.someProp = 'someValue';

    var _that = this;

    this.someMethod = function() {
        console.log(_that.someProp);
    }
}

var instance = new SomeClass();

The property someMethod is not defined on the constructor function’s prototype.

Instead, it is defined on the instance.

Further, an Arrow function is bound to its surrounding lexical context by default (where it physically sits in the code), which seems equivalent to a Traditional function having access to an outer function variable that points to this (i.e., closure).

Hence, even when you assign instance.someMethod to another variable, the function variable remains bound to the instance context.

Note: I’m not 100% sure about the actual ‘under the hood’ mechanism by which Arrow functions derive this, so feel free to comment if you do know.

In any case, I went down this rabbit hole because I’ve been using Arrow functions for writing methods in classical React components, instead of binding Traditional functions (i.e., this.someMethod.bind(this)) in the constructor or when passing it down as prop.

import React from 'react';

class SomeComponent extends React.Component {
    constructor(props) {
        super(props);

        this.state = { /* some state */ };
    }

    someMethod = () => { // Arrow function
        // will have access to `this.state`
    }

    render() {
        // may attach `this.someMethod` as an event handler or 
        // pass it down as a prop to child components
    }
}

Not endorsing one approach or the other, just describing the difference. Oh, and guess which browser is completely irrelevant to this whole discussion.

📫 Hit me up on LinkedIn or Twitter!

Decouple Data from UI with React Hooks

Suhan Wijaya — Mon, 23 Nov 2020 09:53:55 +0000

And how I “program to an interface” with JavaScript functions

Source: Imgur

I‘m certain you have seen (or written) this common React pattern: (a) render a placeholder/ loader/spinner while some data is fetched via AJAX, then (b) re-render the component based on the data received. Let’s write a functional component leveraging the Fetch API to accomplish this.

Let’s say my app grows, and there are X components that use the same data fetching logic because… reasons. To avoid spamming the server with data requests, I decide to use Local Storage to cache the data.

OK… does that mean I need to update the data logic X times? 😬😱

Nope, let’s DRY it up by writing a custom hook useSomeData.

The components that share this data logic now look concise.

OK… DRY code is great, but so what?

Let’s say my app becomes complex, so I decide to use Redux to handle AJAX requests and maintain a global app state. I simply update the implementation of useSomeData without touching the UI components.

Then GraphQL comes along and I jump on the bandwagon. Again, I simply update the implementation of useSomeData without touching the UI components.

Rinse and repeat whenever I’m compelled to update the data layer with the latest/hottest state management framework or API paradigm.

To me, this looks a lot like the classic Dependency Inversion Principle, the “D” in SOLID (check out this excellent explainer by Matthew Lucas). While this is not OOP by any means, where we formally define an abstract Interface and create a concrete Class that implements that Interface, I would argue that there is a de facto “interface” that useSomeData provides to the various UI components using it. In this example, the UI doesn’t care how useSomeData works, as long as it receives someData, loading, and error from the hook.

So in theory, this frees the UI from being locked into any particular implementation of the data layer, and enables migrating to new implementations (frameworks/libraries/etc) without having to update the UI code, as long as the “interface” contract is honored.

Curious to hear your thoughts.

Source: Pinterest

P.S. The Container pattern, Render Props, and HOC are popular options to decouple the data layer from the UI layer for classical components. This article is not meant to be a debate as to whether Hooks is better or worse. I’m simply sharing how I learned to use Hooks to apply the same separation of concerns.

📫 Let’s connect on LinkedIn or Twitter!

Async/await is awesome, but don’t abandon Promises

Suhan Wijaya — Sun, 15 Nov 2020 12:26:56 +0000

Shoutout to Cassidy Williams 😀

Let’s create a button that will:

perform an expensive synchronous operation,
fire 2 AJAX requests, and
update the DOM based on the AJAX responses.

Here is the markup.

Here are the functions. Let’s also measure the duration of each operation with the Performance API, which visualizes when and how long each function executes on the Chrome DevTools Performance Timeline. (Thanks to JSONPlaceholder for the dummy endpoints.)

You’re still here? Good, here comes the interesting part: writing the onclick handler for the button. Since all the cool kids are doing it, let’s use async / await.

async function handleClick() {
   someSyncOperation(); // Expensive sync operation 

   const postJson = await fetchPost(); // AJAX request #1

   const commentsJson = await fetchComments(); // AJAX request #2

   appendPostDOM(postJson);
   appendCommentsDOM(commentsJson);
}

Here is the Performance Timeline after clicking the button.

Let’s take a closer look.

Makes sense, plenty of articles out there about how async / await turns asynchronous code into blocking code. FYI, each bar is about 2 seconds when throttling the network to “Slow 3G”.

So a total execution time of 6 seconds.

OK. The fetchPost and fetchComments can be executed in parallel, so let’s use the await Promise.all combo.

async function handleClick() {
  someSyncOperation();

  const [postJson, commentsJson] = await Promise.all([
    fetchPost(), 
    fetchComments()
  ]);

  appendPostDOM(postJson);
  appendCommentsDOM(commentsJson);
}

The total execution time is now 4 seconds since fetchPost and fetchComments execute in parallel.

OK. Since someSyncOperation is not dependent on the AJAX requests, let’s see if moving it to the last line in the function speeds things up.

async function handleClick() {
  const [postJson, commentsJson] = await Promise.all([
    fetchPost(), 
    fetchComments()
  ]);

  appendPostDOM(postJson);
  appendCommentsDOM(commentsJson);

  someSyncOperation();
}

Nope, the total execution time is still 4 seconds.

OK. It’s time to go “full Promise”.

function handleClick() {
  Promise.all([
    fetchPost(),
    fetchComments()
  ]).then(([postJson, commentsJson]) => {
    appendPostDOM(postJson);
    appendCommentsDOM(commentsJson)
  });

  someSyncOperation();
}

Going “full Promise” cuts total execution time to 2 seconds.

The reason why this works deserves its own article, but here is an awesome explainer.

Today I learned.

Source: Programmer Humor

Bonus

For the die-hard async / await fans out there, I learned (literally on the day of writing this story) that the following snippet actually does the same thing. Credit to this article by Moon.

async function handleClick() {
  const postPromise = fetchPost();
  const commentsPromise = fetchComments();

  someSyncOperation();
  const postJson = await postPromise;
  const commentsJson = await commentsPromise;

  appendPostDOM(postJson);
  appendCommentsDOM(commentsJson);
}

📫 Hit me up on LinkedIn or Twitter!

Accessible UI: Stop making clickable DIVs

Suhan Wijaya — Mon, 09 Nov 2020 15:34:27 +0000

Source: Make a Meme

I used to think that accessibility is at best a UX improvement, and at worst “compliance work”. But as the pandemic turned Boxed.com into an essential service for many of our customers, I have read a good number of heartbreaking customer service tickets that revealed my biases and the unintended exclusions caused by my code. Now, I’m convinced that making the web accessible is the right thing to do.

Accessibility is a broad topic, and a subset of loftier inclusive design principles that I won’t pretend to be an expert on. I’m just sharing one of the many a11y lessons I learned as a developer.

So let’s move on to the main topic.

We love our div tags. But, simply from a developer experience standpoint without even discussing the merits of semantic HTML (which deserves its own article), a button is more accessible with less code compared to a clickable div. To illustrate, let’s go ahead and create a clickable div.

<div>Click me</div>

<script>
  function doSomething() {
    console.log('do something'); 
  }

  document.querySelector('div').onclick = doSomething;
</script>

Not good enough, we need to visually indicate through the cursor type that the div is clickable (which apparently is also debatable). Let’s add some CSS.

<style>
  .someDiv {
    cursor: pointer;
  }
</style>

<div class='someDiv'>Click me</div>

Not good enough, we need to verbally indicate through screen readers that the div is a clickable button, and it needs to be keyboard accessible via Tabbing navigation. Let’s add role and tabindex attributes.

<div class='someDiv' tabindex='0' role='button'>Click me</div>

Not good enough, the div also needs to be keyboard accessible via Enter and Space Bar keys. Let’s add more JavaScript (which may not even be 100% cross-browser compatible).

<script>
  function doSomething() {
    console.log('do something'); 
  }

  function handleKeydown(e) {
    if (e.key === 'Enter' || e.key === ' ') {
      doSomething();
    }
  }

  document.querySelector('div').onclick = doSomething;
  document.querySelector('div').onkeydown = handleKeydown;
</script>

So finally, we end up with this.

<style>
  .someDiv {
    cursor: pointer;
  }
</style>

<div class='someDiv' tabindex='0' role='button'>Click me</div>

<script>
  function doSomething() {
    console.log('do something'); 
  }

  handleKeydown(e) {
    if (e.key === 'Enter' || e.key === 'Space Bar') {
      doSomething();
    }
  }

  document.querySelector('div').onclick = doSomething;
  document.querySelector('div').onkeydown = handleKeydown;
</script>

Source: CoderPedia

Whereas, the button version that’s equally accessible looks like this.

<button>Click here</button>

<script>
  function doSomething() {
    console.log('do something'); 
  }

  document.querySelector('button').onclick = doSomething;
</script>

What’s your approach to creating clickable UI components? Let me know in the comments.

Note: I decided not to discuss aria attributes because I think they deserve their own article.

📫 Hit me up on LinkedIn or Twitter!

Missing cookie in HTTP request when using Fetch API

Suhan Wijaya — Mon, 02 Nov 2020 13:02:48 +0000

Image source: Programmer Humor

Here is an explainer of how cookies work. TLDR:

Browser sends HTTP request to server.
Server sends HTTP response with Set-Cookie: cookie=monster header, which sets the cookie in the browser.
Every subsequent request the browser sends to the server will have the Cookie: cookie=monster header.

I store a CSRF token in a cookie, which is used by the server to validate client-side HTTP POST requests. The server responds with a 403 if the cookie is missing in the HTTP request.

On the client-side, I have been using the cross-fetch package via the ponyfill approach.

import fetch from 'cross-fetch';

fetch('/some-route', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json'
    },
    body: { /* some payload */ }
});

One day, I decided to switch to the polyfill approach in order to use the native window.fetch.

import 'cross-fetch';

fetch('/some-route', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json'
    },
    body: { /* some payload */ }
});

A bunch of users started getting 403s.

Image source: Know Your Meme

After scouring Stack Overflow and the interwebs (and many tears later), the answer was in the MDN docs all along:

The users getting 403s were using browsers older than the versions listed above. So this was the fix:

import 'cross-fetch';

fetch('/some-route', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json'
    },
    body: { /* some payload */ },
    credentials: 'same-origin' // the fix
});

You might ask: what about Internet Explorer, your favorite problem child? Well, since it supports nothing, the polyfill kicks in with a version of fetch that sets same-origin as the default credentials policy, so no 403s.

Today I learned.

📫 Hit me up on LinkedIn or Twitter!

Forem: Suhan Wijaya

Intro to React Server Side Rendering

How to build a React SSR app without any tooling or framework

Overview

Project structure

Dependencies

webpack

Common webpack config for client-side and server-side

Babel config

Client-side webpack config

Server-side webpack config

React component

Server-side code

Client-side code

Putting it all together

Resources

Read More

Decouple Data from UI in React Part 2

A further exploration of the Hooks, Render Props, and HOC patterns

Approach A. Custom Hook

Approach B. Render Props

Approach C. Higher Order Components (HOC)

Resources

Read More

Decouple SDK Code From Core React Code

And reduce the size of your future PRs with the Open/Closed Principle

Bonus

Resources

Read More

Traditional versus Arrow functions in JavaScript Classes

Why, JavaScript, why?

Decouple Data from UI with React Hooks

And how I “program to an interface” with JavaScript functions

Read More

Async/await is awesome, but don’t abandon Promises

Bonus

Accessible UI: Stop making clickable DIVs

Missing cookie in HTTP request when using Fetch API

A bunch of users started getting 403s.