Forem: Konstantin Lebedev

10 security tips for frontend developers

Konstantin Lebedev — Thu, 09 Apr 2020 13:24:35 +0000

Web security is a topic that is often overlooked by frontend developers. When we assess the quality of the website, we often look at metrics like performance, SEO-friendliness, and accessibility, while the website's capacity to withstand malicious attacks often falls under the radar. And even though the sensitive user data is stored server-side and significant measures must be taken by backend developers to protect the servers, in the end, the responsibility for securing that data is shared between both backend and frontend. While sensitive data may be safely locked in a backend warehouse, the frontend holds the keys to its front door, and stealing them is often the easiest way to gain access.

"The responsibility for securing user's data is shared between both backend and frontend."

There are multiple attack vectors that malicious users can take to compromise our frontend applications, but fortunately, we can largely mitigate the risks of such attacks with just a few properly configured response headers and by following good development practices. In this article, we'll cover 10 easy things that you can do to improve the protection of your web applications.

Measuring the results

Before we start improving website security, it is important to have some feedback on the effectiveness of the changes that we make. And while quantifying what makes up "good development practice" may be difficult, the strength of security headers can be measured quite accurately. Much like we use Lighthouse to get performance, SEO, and accessibility scores, we can use SecurityHeaders.com to get a security score based on the present response headers. For imperfect scores, it will also give us some tips on how to improve the score and, as a result, strengthen the security:

The highest score that SecurityHeaders can give us is "A+", and we should always try to aim for it.

Note on response headers

Dealing with response headers used to be a task for the backend, but nowadays we often deploy our web applications to "serverless" cloud platforms like Zeit or Netlify, and configuring them to return proper response headers becomes frontend responsibility. Make sure to learn how your cloud hosting provider works with response headers, and configure them accordingly.

Security measures

1. Use strong content security policy

Sound content security policy (CSP) is the cornerstone of safety in frontend applications. CSP is a standard that was introduced in browsers to detect and mitigate certain types of code injection attacks, including cross-site scripting (XSS) and clickjacking.

Strong CSP can disable potentially harmful inline code execution and restrict the domains from which external resources are loaded. You can enable CSP by setting Content-Security-Policy header to a list of semicolon-delimited directives. If your website doesn't need access to any external resources, a good starting value for the header might look like this:

Content-Security-Policy: default-src 'none'; script-src 'self'; img-src 'self'; style-src 'self'; connect-src 'self';

Here we set script-src, img-src, style-src, and connect-src directives to self to indicate that all scripts, images, stylesheets, and fetch calls respectively should be limited to the same origin that the HTML document is served from. Any other CSP directive not mentioned explicitly will fallback to the value specified by default-src directive. We set it to none to indicate that the default behavior is to reject connections to any URL.

However, hardly any web application is self-contained nowadays, so you may want to adjust this header to allow for other trusted domains that you may use, like domains for Google Fonts or AWS S3 buckets for instance, but it's always better to start with the strictest policy and loosen it later if needed.

You can find a full list of CSP directives on MDN website.

2. Enable XSS protection mode

If malicious code does get injected from user input, we can instruct the browser to block the response by supplying "X-XSS-Protection": "1; mode=block" header.

Although XSS protection mode is enabled by default in most modern browsers, and we can also use content security policy to disable the use of inline JavaScript, it is still recommended to include X-XSS-Protection header to ensure better security for older browsers that don't support CSP headers.

3. Disable iframe embedding to prevent clickjacking attacks

Clickjacking is an attack where the user on website A is tricked into performing some action on website B. To achieve this, malicious user embeds website B into an invisible iframe which is then placed under the unsuspecting user's cursor on website A, so when the user clicks, or rather thinks they click on the element on website A, they actually click on something on a website B.

We can protect against such attacks by providing X-Frame-Options header that prohibits rendering of the website in a frame:

"X-Frame-Options": "DENY"

Alternatively, we can use frame-ancestors CSP directive, which provides a finer degree of control over which parents can or cannot embed the page in an iframe.

4. Limit access to browser features & APIs

Part of good security practice is restricting access to anything that is not needed for the proper use of our website. We've already applied this principle using CSP to limit the number of domains the website is allowed to connect to, but it can also be applied to browser features. We can instruct the browser to deny access to certain features and APIs that our application doesn't need by using Feature-Policy header.

We set Feature-Policy to a string of rules separated by a semicolon, where each rule is the name of the feature, followed by its policy name.

"Feature-Policy": "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none';  picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';"

Smashing Magazine has a great article explaining Feature-Policy in great detail, but most of the time you'll want to set none for all features that you don't use.

5. Don't leak referrer value

When you click on a link that navigates away from your website, the destination website will receive the URL of the last location on your website in a referrer header. That URL may contain sensitive and semi-sensitive data (like session tokens and user IDs), which should never be exposed.

To prevent leaking of referrer value, we set Referrer-Policy header to no-referrer:

"Referrer-Policy": "no-referrer"

This value should be good in most cases, but if your application logic requires you to preserve referrer in some cases, check out this article by Scott Helme where he breaks down all possible header values and when to apply them.

6. Don't set innerHTML value based on the user input

Cross-site scripting attack in which malicious code gets injected into a website can happen through a number of different DOM APIs, but the most frequently used is innerHTML.

You should never set innerHTML based on unfiltered input from the user. Any value that can be directly manipulated by the user - be that text from an input field, a parameter from URL, or local storage entry - should be escaped and sanitized first. Ideally, use textContent instead of innerHTML to prevent generating HTML output altogether. If you do need to provide rich-text editing to your users, use well-established libraries that use whitelisting instead of blacklisting to specify allowed HTML tags.

Unfortunately, innerHTML is not the only weak point in DOM API, and the code susceptible to XSS injections can still be hard to detect. This is why it is important to always have a strict content security policy that disallows inline code execution.

For the future, you may want to keep an eye on a new Trusted Types specification which aims to prevent all DOM-based cross-site scripting attacks.

7. Use UI frameworks

Modern UI frameworks like React, Vue, and Angular have a good level of security built into them, and can largely eliminate the risks of XSS attacks. They automatically encode HTML output, reduce the need for using XSS-susceptible DOM APIs, and give unambiguous and cautionary names to potentially dangerous methods, like dangerouslySetInnerHTML.

8. Keep your dependencies up to date

A quick look inside node_modules folder will confirm that our web applications are lego puzzles built out of hundreds (if not thousands) dependencies. Ensuring that these dependencies don't contain any known security vulnerabilities is very important for the overall security of your website.

The best way to make sure that dependencies stay secure and up-to-date is to make vulnerability checking a part of the development process. To do that, you can integrate tools like Dependabot and Snyk, which will create pull requests for out-of-date or potentially vulnerable dependencies and help you apply fixes sooner.

9. Think twice before adding third-party services

Third-party services like Google Analytics, Intercom, Mixpanel, and a hundred others can provide a "one line of code" solution to your business needs. At the same time, they can make your website more vulnerable, because if a third-party service gets compromised, then so will be your website.

Should you decide to integrate a third-party service, make sure to set the strongest CSP policy that would still permit that service to work normally. Most of the popular services have documented what CSP directives they require, so make sure to follow their guidelines.

Especial care should be taken when using Google Tag Manager, Segment, or any other tools that allow anyone in your organization to integrate more third-party services. People with access to this tool must understand the security implication of connecting additional services and ideally discuss it with their development team.

10. Use Subresource Integrity for third-party scripts

For all third-party scripts that you use, make sure to include integrity attribute when possible. Browsers have Subresource Integrity feature that can validate the cryptographic hash of the script that you're loading and make sure that it hasn't been tampered with.

This how your script tag may look like:

<script src="https://example.com/example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
        crossorigin="anonymous"></script>

It's worth clarifying that this technique is useful for third-party libraries, but to a lesser degree for third-party services. Most of the time, when you add a script for a third-party service, that script is only used to load another dependant script. It's not possible to check the integrity of the dependant script because it can be modified at any time, so in this case, we have to fall back on a strict content security policy.

Conclusion

Save browsing experience is an important part of any modern web application, and the users want to be sure that their personal data remains secure and private. And while this data is stored on the backend, the responsibility for securing it extends to client-side applications as well.

There are many variations of UI-first attacks that malicious users can take advantage of, but you can greatly increase your chances of defending against them if you follow the recommendations given in this article.

Animating between units with react-spring

Konstantin Lebedev — Thu, 21 Nov 2019 14:44:50 +0000

It's no secret, that on the web we have to deal with different units - from rems and pixels to percentages and viewport-based values. In this tutorial, we'll explore the problem of animating between different units, and see how we can overcome it.

The problem

Let's start by creating this simple animation where a div with pixel-based size expands to fill the entire viewport width and height when we click on it:

To create this animation, we'll use useSpring hook from react-spring package, and set the width and the height of the box to 200px when it's not expanded, and to 100vh and 100vw when it is. We'll also remove 10px border-radius when the box is expanded:

The result will look like this:

As we can see, the border-radius animation is working, but the box gets smaller instead. Why is that?

To understand the problem, we need to look at how react-spring (and most of React animation libraries for that matter) handles animation between units. When we pass width and height values as strings, react-spring will parse the numeric values from the "from" and "to" values, take the unit from the "from" value, and completely ignore the unit of the "to" value:

In our example, the initial state of the box is collapsed and the height of the box is pixel-based, so when react-spring starts animating it, it'll use "pixels" as a unit. If instead the initial state was expanded and the height was viewport-based, then the animation would use "vh" as a unit and run from 100vh to 200vh instead.

The border-radius animation works fine because if uses pixels for both expanded and collapsed states.

Side note: the only library that I found that handles animation between units correctly out-of-the-box is framer-motion. I have an intro level article about framer-motion, and you can also sign up for my upcoming framer-motion course.

The solution

To fix this problem, we need to make sure that both the initial and the target value use the same unit. We can easily convert viewport-based values into pixels with these simple calculations:

Now instead of using viewport-based values, we'll use our helper functions to set the width and the height of the box:

This solves the problem only partially because if we resize the browser window after the animation has run, we'll discover a different issue - the box doesn't adjust to the viewport size anymore since now it has pixel-based size:

We can fix this issue by setting the box size back to viewport-based values once the animation finishes. First of all, we'll use useRef hook to hold a reference to the actual DOM node of our box. Secondly, react-spring provides a handy onRest callback that fires at the end of each animation, so we can use it to check if we animated to the expanded state, and if so, we'll set the box width and height directly.

With this setup, animation works fine - it uses pixel values while animating, and sets the box dimensions to viewport-based size upon completion, so the box remains responsive even if we resize the browser afterward.

You can find working CodeSandbox demo here.

Conclusion

Animation libraries such as react-spring give us a greater degree of control over our animations compared to CSS animations, but they have shortcomings as well. Animating values between units is one of them, and it requires us to do extra work to make sure that our animation runs smoothly and remains responsive.

Building a Cool Horizontal Scroll Interaction in React

Konstantin Lebedev — Sat, 02 Nov 2019 10:41:26 +0000

In this tutorial, we'll create a fun scroll animation in which items "flip" in the direction of the scroll. We're going to use react-spring for animating and react-use-gesture to tie animation to the scroll events. The native onScroll event handler won't do in this case, because we'll need additional information about scrolling that native onScroll handler doesn't provide - scroll delta in pixels, and whether the scrolling is in progress or not.

This is what we're going to build:

Basic setup

We'll start with the basic React component you can see below. The component renders a list of images from public folder, and sets them as background for div elements:

Next, we'll apply some styling. We need to make sure that the container takes up 100% of the width and it allows its children to overflow:

With the basic styling, our component will look like this:

Adding animation

Let's start by adding a rotation animation. First, we'll replace div element with animated.div. animated is a decorator that
extends native elements to receive animated values. Every HTML and SVG element has an animated counterpart that we have to use if we intend to animate that element.

Next, we'll use useSpring hook from react-spring package to create a basic animation that will run when the component is mounted. Eventually, we'll bind our animation to the scroll event, but for the time being, it will be easier to see the result of the changes that we make if animation simply runs on mount.

useSpring hook takes an object with CSS properties that should be animated. These properties should be set to end values of the animation, so if we want to rotate divs from 0 to 25 degrees, we set the transform value to rotateY(25deg). To set the initial values, we use from property which itself takes an object with CSS properties.

useSpring hook returns a style object that we need to set on the target component. We can see the updated code and the result below:

This animation looks flat because by default the rotation is 2-dimensional, it's rendered as if there were no distance between the user observing the animation and the rotation plane. perspective transformation allows us to move the observation point away from the rotation plane, and thus makes 2-dimensional animation look 3-dimensional:

Finally, we need to add vertical padding to the container div to make sure that children elements don't get cut off:

Binding animation to scroll

Before we start working with scroll events, we need to make a small change to how we use useSpring hook. There are two things to keep in mind:

we need to be able to trigger animation manually
we no longer need to run animation on mount

To address both of these issues, we'll use a different useSpring signature - instead of passing an object with CSS properties, we'll pass a function that returns an object with CSS properties. Previously, useSpring hook returned us a style object
. With the new signature, it will return a tuple, where the first argument is a style object, and the second argument is a set function that we can call anytime to trigger the animation.

We can also drop from property since this value will be determined based on the current rotation of the divs:

Now we can import useScroll hook from react-use-gesture package and bind it to the container div. The logic for handling scroll events is very simple - if the user is scrolling (event.scrolling === true), we want to rotate cards by the number of degrees equal to scroll delta on Y-axis (event.delta[0]); if scrolling stops, we want to reset the rotation angle to 0:

Animation works, but there is an undesired side-effect - if we scroll sharply, the Y delta will be quite big, which may cause cards to flip more than 90 degrees. I've tested different values and discovered that the animation looks best if the cards flip no more than 30 degrees. We can write a helper function to clamp the delta value so it never gets more than 30 and less than -30:

Now we can use this helper function to clamp Y delta inside useScroll hook and get the final result:

You can find a complete working demo of this interaction here.

PS: I also made the same interaction using framer-motion. working demo is available here.

If you want to get more tutorials like this one, make sure to subscribe to my newsletter.

Final thoughts

I would like to mention two decisions that stayed behind the curtain of this tutorial but had been made before making this particular animation.

The first decision concerns performance. To make the flip animation, we animated only transform property, which is one of the only two properties that are accelerated by GPU and that don't take time off the main thread (the other property is opacity). There's quite a lot we can achieve by animating only transform and opacity, and whenever possible, we should avoid animating any other CSS properties.

Secondly, we need to consider responsiveness. Horizontal scroll that we implemented works well on phones and tablets, but for larger desktop screens we might want to use a more common grid layout. With small CSS changes and a media query we can switch from flex to grid layout, and we don't have to change the animation at all - it will continue working on small screens that use flex layout, and it will be ignored on large screens since with grid layout we won't have horizontal scroll.

Animate React with Framer Motion

Konstantin Lebedev — Thu, 25 Jul 2019 13:24:03 +0000

Framer-motion is a library that powers animations in Framer, and it's now available as an independent package that we can use in React applications. It has a very simple declarative API that makes it easy to create and orchestrate complex animations with a minimal amount of code. In this article, we'll start with very basic animations and gradually move to the more advanced ones.

Note: animation examples in the article may not look smooth because of a low frame rate of GIF images. Rest assured, real animation are butter-smooth. You can play with them in the sandbox here.

Setup

We can start with framer-motion by simply installing it with yarn add framer-motion command.

To animate elements, we'll need to ditch primitive HTML elements (div, span, path, etc.) in favor of their "motion-infused" counterparts - motion.div, motion.span, motion.path, etc. These elements expose the properties that we'll need to add our animations.

Get things moving

To create the simplest animation, we can specify animate property that accepts an object with CSS properties that we want to animate. This is how we can animate opacity and background color of the div:

Demo 1: Animate on mount

The properties that we pass to animate represent the final state of the animation. Framer-motion will infer the initial state based on the specified CSS properties, or their defaults. For example, default opacity for CSS elements is 1 (even if we don't set it explicitly), so framer-motion knows how to animate it down to 0.5.

We can also set the initial values of animatable CSS properties using initial prop. It also accepts an object with CSS properties that will tell framer-motion what initial values should be like. In the example below, we fade in the rectangle by animating y and opacity properties:

Demo 2: Animate using initial state

It's worth mentioning that property y is special - it's not a real CSS property, but framer-motion understands it. There are a bunch of CSS transform-related properties that have shortcuts in framer-motion, so when we change y property, we actually apply animation to transform: translateY() property. Similarly, there are scale, rotate, scaleX, scaleY and some other properties, you can find the complete list here.

Animating state changes

The animations that we've done so far only run when components mount. Now let's see how we can animate elements when some internal state changes.

We can set animation property to different values based on the internal state, and framer-motion will animate between those values when the state changes:

Demo 3: Animate div on click

Note that the component re-renders only when state changes, and not on every animation frame, which makes animations very efficient.

Variants

The real power of framer-motion comes from using variants. Let's start by exploring how we can rewrite the previous example to use variants.

We'll begin by extracting inline definition of animatable properties from animate prop into a separate object. This object will contain key-value pairs, where keys are some meaningful names that we give to our animatable properties, and values are the properties themselves. Then we can pass this variants object to variants prop, and inside animation we can toggle animations based on the string names we gave to them:

Demo 4: Animate div on click (again, but using variants)

This example works, but it's not very useful. The power of variants is in orchestrating complex animations throughout a component tree, and to see that, we'll need a slightly bigger example.

In the component below, we have a container div that has three child divs inside of it. Container div uses the same onClick animation that we've seen before:

Demo 5: Animate div

Now we can animate children elements simultaneously with the parent by setting their own variants object. When descriptive names of child animations match those of the parent, child animations will be triggered at the same time as parent animation.

Notice how both container and box variants have the same keys active and disabled:

Demo 6: Animate div with child elements

Configuring variants

Variants also allow us to orchestrate the child animations. We can do that by providing transition property inside the animation object.

For example, we can set staggerChildren children property, which specifies the delay in seconds between child animations:

Demo 7: Stagger child elements

Note how transition is applied only when we transition into a given variant. Since we defined transition property inside active variant, the stagger animation is only applied when we transition from disabled into active, but not when we transition from active to disabled.

By default, variants start animating parent element and its children at the same time. We can control that behavior using when property. We can set it to beforeChildren to make parent element animate first, or to afterChildren, to make parent element animate after its children:

Demo 8: Animate parent before children

With this configuration, the parent div changes background color first, and then child elements rotate with a staggered delay.

There are a lot more properties of variants that we can control - animation delays, stagger direction, etc. You can find more information on them in framer-motion documentation.

Wrapping up

In this article, we've seen how easy it is to animate React components using declarative API that framer-motion provides. However, we just scratched the surface, since there's a lot more that framer-motion is capable of - gestures, dragging, working with SVG paths and much more. If you're interested in learning more - check out my new course that covers all the great features that framer-motion has to offer:

Rematch with Hooks

Konstantin Lebedev — Mon, 24 Jun 2019 15:20:51 +0000

If you've been using Rematch for managing state in your application, the latest release of react-redux that adds support for hooks should get you really excited.

Rematch has always tried to keep compatibility with existing react-redux API, and that stays true for the newly released version that supports hooks!

In addition to having more readable and reusable code, hooks allow us to do less work when adding type safety with TypeScript.

Let's look at an example of doing things "the old way". Here's a component that stores a list of users in Redux store, and loads them when the component is mounted:

This code looks and works fine, but there are a couple of issues that we couldn't address in pre-hook era. One of them is related to typing connect component. Higher order components are notoriously difficult to type properly due to the difficulty of inferring types of the properties being passed down to the component inside. To get around this problem, we have to define types for props being passed to the component separately (type UsersProps), and then manually set them for the component (FC<UsersProps>).

With hooks, we can replace mapState function with useSelector hook, mapDispatch with useDispatch, and we can drop our difficult-to-type connect HOC altogether, leaving us with concise and fully typed code:

If we need to work with multiple actions, we can create a custom useRematchDispatch hook that allows us to have the familiar syntax that we used for writing mapDispatch functions:

useRematchDispatch hook can also come in handy if we want to refactor existing Rematch application, because it allows us to copy mapDispatch functions with minimum changes.

If you want to learn more about Rematch, check out my free course on YouTube.

Type aliases vs. interfaces in TypeScript-based React apps

Konstantin Lebedev — Fri, 31 May 2019 08:35:08 +0000

Type aliases and interfaces are TypeScript language features that often confuse people who try TypeScript for the first time. What’s the difference between them? When should we use one over the other?

Type aliases and interfaces used to be quite different in their capabilities. However, it’s no longer true in the latest versions of TypeScript. Over time they have grown together to the point when they are almost identical. They still have some subtle differences — interfaces are more “extendable” due to the support of declaration merging, and types are more “composable” due to support of union types. We’ll talk about these differences in more details a bit later.

Owing to the nature of differences between type aliases and interfaces, the decision to use one over another usually depends on your preferred programming style. If you write object-oriented code — use interfaces, if you write functional code — use type aliases.

Now let’s talk about React.

React is more functional by nature. Functional components are generally preferred over class-based components. Hot and shiny React Hooks are just functions used inside functional components. HOCs, Redux, pure functions, and a handful of other concepts widely used in React come from a functional world. So for these reasons,

In React applications, just use type aliases.

Now let’s see why.

1. Power of interfaces isn’t useful in React applications

One of the main things that differentiate interfaces from type aliases is the ability to merge declarations. With interfaces, we can re-open previously declared interfaces and add additional properties to it:

The code above doesn’t have any errors, because the resulting IUser interface will contain all 3 properties — firstName, lastName, and age.

This is a very powerful feature that allows us to write type declarations for 3rd party libraries and gives us an option to extend them. However, In regular React application, this feature doesn’t bring any value. On the contrary, it can introduce unnecessary complexity and add bugs if somebody will try to monkey-patch props or state interfaces.

2. Type aliases are more composable

One thing that type aliases can do that interfaces can’t is create an intersection with a type alias that uses union operator within its definition:

This can be useful when we want to combine component’s own props with some HOC’s props that might use union operator.

3. Type aliases require less typing (as in typing on the keyboard)

It’s simply faster to type type Props than interface IProps.

4. Consistency

First of all, we don’t want to mix interfaces and types. It’s a common convention to prefix interface names with I, so we’ll have a mix of IProps interfaces and Props type aliases in our code. Not only will it create unnecessary clutter, but also increase required mental effort every time we need to think: “Do we have IProps interface or Props type aliases here?”

Second, we won’t be able to just use interfaces either. As we mentioned earlier, type composition is a very useful feature for React applications, and because interfaces cannot be combined with union-based types, at some point we may need to change our interfaces to type aliases. That means that we’ll also have to rename IProps to Props to avoid further confusion. And if the type is exported, we have to rename all the occurrences in the code as well. This extra work can be avoided by simply using type aliases everywhere.

Conclusion

Hopefully, this article helped you to see the difference between interfaces and type aliases in TypeScript and also convinced you that type aliases are preferable for React applications.

If you disagree with any of the points or feel that something is missing, please let me know in the comments. In the meantime, go ahead and disable interface-over-type-literal setting in TS Lint and start using type aliases in your React applications!

Shameless plug: if you want to learn how to use Redux without writing a ton of boilerplate, check my "State management with Rematch" course on Youtube.

Typing components in Next.JS applications

Konstantin Lebedev — Wed, 29 May 2019 14:39:02 +0000

Note: This post covers typing Next.JS applications that use versions prior to v9. Starting with version 9, Next.JS comes with its own types by default, and their names may differ from those used in DefinitelyTyped package. If you use Next.JS version 9 and older, please refer to the official documentation. For earlier versions, continue reading :)

In this article, we'll talk about typing Next.JS components. We'll be using this Next.JS application that connects to Reddit API and displays a list of top posts in a given subreddit. Right now, the main component Posts.tsx doesn't have any type-safety, so we're going to fix that.

The project already contains TypeScript configured, so if you don't know how to do that, please read the official guide here, it's as easy as installing a few dependencies and dropping in some configuration files.

Now let's clone the project from GitHub and get started.

FunctionComponent

First, let's take a look at how we type React components in general.

If we write our components as functions, we can use FunctionComponent type from React library. This type takes a generic type argument that describes the shape of the props. Our Posts component takes a subreddit name and a list of posts, so props object is going to look like this:

Now when we destructure props into posts and subreddit, we get full type safety. Pretty neat, right?

Now let’s look at Next.JS components.

NextFunctionComponent

One thing that makes Next.JS components different is a static getInitialProps function. If we try to assign it to our regular React component, we’ll get a type error:

To fix this problem, we need to use a special component type from Next.JS package called NextFunctionComponent. This type extends standard React’s FunctionComponent type with Next.JS-specific static lifecycle methods (well, only one method, really). So now our code will look like this:

To make our types more robust, we can infer the shape of props returned from getInitialProps function instead of defining them manually. To do that, first, we want to extract getInitialProps function into a separate variable. This step is required to avoid circular type reference when we start inferring the shape of our props:

Next, we can use ReturnType helper type to get the type of the value returned from getInitialProps function:

Since getInitialProps function is asynchronous, the return type is going to be a promise, so we also need to extract its value. We can define a global helper type that will use conditional type magic to unwrap our promise:

Now we can put everything together:

NextContext

Let’s make this example more interesting by taking the name of a subreddit from a query string.

To achieve that, we can use a context argument that gets passed to getInitialProps function that we haven’t used so far. We will use NextContext<T> type to type this argument. The type T allows us to specify the parameters we know we will have in a query string (subreddit in our case):

We got type-safety inside getInitialProps function, but now we run into another type error talking about incompatible types of Context.

The reason is that by default getInitialProps expects a context to be of a generic type NextContext, but we specified a stricter, more specific type — NextContext<{ subreddit: string }. To resolve this issue, we need to pass a few more type arguments to NextFunctionComponent type. Its full signature looks like this:

As you can see, NextFunctionComponent can take up to 3 types — Props, InitialProps, and Context. InitialProps should only contain props returned from getInitialProps function. Props should contain all the props that component has access to, which include own component props, props passed through higher order components (such as connect from Redux), plus the initial props. And finally, Context specifies the shape of the context used by our component.

When we put everything together, we’ll get a fully typed Next.JS component

You can find the source code for the fully typed component in "final" branch.

Conclusion

In this article, we've explored how to type Next.JS components. The approach is different from typing regular React functional components because of the special getInitialProps function that Next.JS uses to prepare props data server-side. For that reason, we need to use special NextFunctionComponent and NextContext types that come with Next.JS typing package.

PS: If you’re curious why we used type aliases everywhere instead of interfaces, make sure to check this article.

Shameless plug: if you want to learn how to use Redux without writing a ton of boilerplate, check my "State management with Rematch" course on Youtube.