Knowing how to profile a React application to improve real-world performance is a good tool in any front-end developer’s toolkit. The Profiler API allows us to do just that with insights on why and how long our components are rendering for.

We can use the profiling data to find unnecessary and expensive renders that may be impacting performance negatively. Thankfully, it’s not that complicated. Let’s take a look at the Profiler API that comes bundled with every React install.

You can interact with the React Profiler API in two ways:

- The React Devtools extension
- The Profiler Component

Both allow you to interact with the same data, but in different ways. Whichever one you choose depends on your use case. By the end of this article, we will have covered how to use the Profiler API to measure and improve the performance of a React app.

## The React Devtools extension

The Devtools profiler offers a simple, visual way of profiling a React app. We can visually see components that re-render and even pinpoint the cause of the render. Using such valuable information, we can make decisions to reduce unnecessary renders and optimize performance.

![We can navigate the component tree and gain valuable insight](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615284491738_Screenshot+2021-03-09+at+10.55.19+AM.png)

Let’s take a look at the interface of the profiler so that we’re able to understand the profiling data. I’ve numbered each section (in red) so that we can break it down bit by bit.

__1. Component chart__
This is a chart of all the components being profiled in a commit. To understand what a commit is, we have to understand how React renders a component. It does this in two phases —

- The render phase where it determines what changes need to be made to e.g. the DOM. During this phase, React calls `render` and then compares the result to the previous render.
- The commit phase is when React applies any changes. (In the case of React DOM, this is when React inserts, updates, and removes DOM nodes)

So a commit is basically all the changes applied from the render phase. A render may not always lead to a commit (i.e there are no new changes) but a commit is always from a render so you can think of a commit as a render even though they don’t exactly mean the same thing.

The component chart can display different types of information depending on the currently selected view. It can display either —

- A tree of all components being rendered in the commit
- A sorted view of all the components in order of slowest to fastest

In this view, we can also hover over the component bars to see information like if and why the component rendered, the duration of the render (or commit), and based on colour of the bar, whether it’s a relatively slow or fast render.

__2. Tabs__

- __Flamegraph tab__ — shows the component tree for the current commit. It Includes render information about each component in the tree. The length and colour of the bars indicates how long the render took.
![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615277833592_Screenshot+2021-03-09+at+9.14.02+AM.png)

    - The longer a bar is relative to the other bars, the more time it took to render
    - The yellower a bar is, the more time it took to render
    - The bluer a bar is, the less time it took to render
    - If the bar is grey, it didn’t render

You can also hover or click on a component bar to get information on why the component rendered (you have to enable this in the profiler settings using the gear icon before profiling)

- __Ranked tab__ — Similar to Flamegraph but sorts the components based on which took the longest time to render. The slowest components will be at the top and the fastest will be at the bottom. This makes it easy to identify which components are affecting performance the most.
![It seems the Input component is taking the most time to render](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615278303810_Screenshot+2021-03-09+at+9.20.17+AM.png)

- __Interactions tab__ — Shows information on how long certain UI actions take using the [experimental tracing API.](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html#interactions) It can track actions like whether a specific button was clicked or whether a form was submitted. Because it is still experimental and the API is prone to change at any time, we will not be focusing on it.

__3. Commits overview__
This shows an overview of all the commits (renders that led to actual DOM updates) being made as the app renders. The slower a commit is (i.e the slower the render), the longer the bar will be. We can navigate back and forth between commits to get more information about a particular commit.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615381592986_commit+overview.png)

This is useful in instantly identifying when an app is making more commits than expected. For instance, if you type a single word in an input and there are 20 commits being made for just that action, then there’s a good chance some of those commits are unnecessary.

__4. Commit information__
This shows information about a specific commit. You can gain useful insight like when the commit was made (Commited at), how long the commit took (Render duration), and if enabled, the interactions that triggered the commit (Interactions).

When a component is clicked from the component chart, the commit information section also shows extra details like why a component rendered and a list of all the commits recorded during profiling.

![We can see that the Input component rendered because the inputValue prop changed](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615279289337_Screenshot+2021-03-09+at+9.38.35+AM.png)

This can help us identify props, state variables, and hooks that may be causing unnecessary renders i.e a function prop being redefined in the parent component.

## The Profiler Component

This is a lower-level way of interacting with the same profiling data as with the extension. Instead of a visual representation of performance using colours and bar lengths, the Profiler component provides a more textual way of profiling a React app.

It is in fact what the extension uses under the hood to display the performance data in a visual way. This means that it is more flexible to use as you can choose to do whatever you want with the data. For example, you could render it as a graph or store it in a database so you could track performance changes over the lifetime of your app.

__How to use the Profiler component__
In the simplest of terms, it wraps over a React component and measures how often the component renders and how long the renders take. To use it, you wrap the component you want to measure in the Profiler component —

    <Profiler id="definition" onRender={callbackToProcessRenderInfo}>
      <Definition />
    </Profiler>

It takes in two props —

1. `id` — A unique identifier for the component you’re profiling. This is useful for differentiating between different components if you’re profiling more than one at the same time or just for identification purposes.

2. `onRender` — A callback function that receives the profiling data as arguments. You can do whatever you like with this data such as logging it, graphing it, etc. It receives the following arguments —
  - `id` → An id string prop passed to the Profiler component
  - `phase` → Can be either “mount” or “update” and tells you if the component is mounting for the first time or whether it’s updating due to a props, state, or hooks change (i.e re-rendering)
  - `actualDuration` → The time spent in milliseconds rendering the Profiler component (The Profiler adds a tiny performance overhead) and all its descendants
  - `baseDuration` → The estimated time in milliseconds that would be spent rendering the descendants without any memoisations. The delta between this and `actualDuration` should tell you how useful your `React.memo` and `useMemo` callls are (for more information about these calls, you can read [this article on memoisation in React](https://ovie.dev/blog/memoisation-in-react-memo-use-memo).
  - `startTime` → A timestamp of when React began rendering the current update
  - `commitTime` → A timestamp of when React committed the current update
  - `interactions` → A [Set](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set) of interactions (if any) that were being traced when the update was scheduled

A simple `onRender` callback would look something like this —

    function callbackToProcessRenderInfo(id, phase, actualDuration, baseDuration, startTime, commitTime) {
      // we can log it to a database or render it out as a chart 
      logToDatabase({ id, phase, actualDuration, baseDuration, startTime, commitTime })
    }

In this case, the callback function is simply logging the performance data to a database where we could do more things like rendering it in a chart similar to what the devtools extension does.

## Profiling a React app

Let’s profile a simple dictionary app using the Devtools extension to see how to improve the performance.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615295777239_Screenshot+2021-03-09+at+2.12.44+PM.png)

This is a very simple app consisting of three components —

1. SearchWord - This is the main wrapper component. It has the following state variables —
    - `formInput` → This is the word we want definitions for. Also used in the `Input` component
    - `entries` → Used to store the definitions for `formInput`. Also used in the `Defintions` component

2. Input  - Used for capturing user input. It receives its value (`formInput`) and `onChange` handler from the parent `SearchWord` component.

3. Definitions - Used to display the definition entries and the current selected entry. Receives the definition entries (`entries`) from it’s parent `SearchWord` component.

When a user types into the input field, we set the value into `formInput`. We have a `useEffect` that runs when `formInput` changes to fetch the definitions for its current value which we store in `entries` and pass on to the Definitions component as a prop.

![Link to source code of code snippet](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615296341294_Screenshot+2021-03-09+at+2.25.33+PM.png)

This is very barebones without any error handling but it’s good enough for the purposes of showing how the devtools profiler works. To get started — 

__Profiling and optimizations__

- We’ll install the [React devtools Chrome extension](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi/related?hl=en)
- Start a profiling session
- Search for the word “flame” by typing into the input field
- End the profiling session and view the data
![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615296790456_start+profiling+session.gif)

This is the result of the first render and the results are certainly interesting.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615301333233_Screenshot+2021-03-09+at+3.29.08+PM.png)

- We have a total of 14 commits, and it seems they’re pretty slow too. We can tell from the commit bar height and colour.

- The root SearchWord component is taking 73.5ms to render on mount. This isn’t bad enough to cause noticeable problems but it is taking up valuable CPU resources that could be shared by other programs on the computer.

- The Input component contributes around 13% to the render duration at around 10ms of render time. This sounds about right and doesn’t seem like it would benefit from some performance optimisations.

- The Definitions component on the other hand is a bit alarming. It renders for around 60ms which contributes over 80% of render time. Looking at other commits using the commit overview, we can see it is also the main cause for the slow commit times on re-renders.
![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615302156683_Screenshot+2021-03-09+at+3.58.47+PM.png)

We can pick a commit in the middle of the history where the app is updating and we seee that the rendering times are similar to the mount render times.

Compiling the results along with data from the “Networks” tab in the Chrome inspector tools, we get the following results for a search of the word “Flame” —

- 14 commits
- All commits updated Definitions (It’s re-rendering too much)
- 5 network calls (But we only want definitions for one word)
- 1127ms total SearchWords render time
- 1029s total Definitions render time

How would we improve the performance in this case?

A first step would be to take a look at why the Definitions component is re-rendering on every commit. The answer lies in the logic of the app. We’re making a new search every time the user types a letter. This is making a network request and updating the definition entries on each keystroke triggering re-renders.

Ideally, we want the search to kick off only when the user stops typing and only then updating the definition entries. 

![Link to source code of code snippet](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615302136631_Screenshot+2021-03-09+at+4.01.49+PM.png)

The fix is to make the Input control it’s own state and only make a request when the user is finished typing. This would make the Definitions component render far fewer times as it would only update when we make the request at the end of the typing session.

The SearchWord component would also re-render fewer times as it will no longer re-render on the input change event.

Finally, instead of 5 network calls for the word “flame”, we’d only make 1. Let’s see if this improves the rendering times. I’ll commit the change, refresh the app, start another profiling session, and search for the word “flame”.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615302675890_Screenshot+2021-03-09+at+4.06.57+PM.png)

Immediately, we can see improvements in our rendering times. The rendering times for the first mount didn’t change much. The commits overview, however, is where we see the improvements.

Previously, the Definitions component rendered every time the Input component rendered. Because it is a slow component, it used up a lot of time and resources on every keystroke. Now, however, we’ve reduced the number of times it has to re-render and the app becomes more efficient.

![](https://paper-attachments.dropbox.com/s_5BDA6475985560E6AAE7066757107C6A7BE872E3D5E939A2F0CE6778BFB724B8_1615383708054_optimisation+results.png)

Subsequent updates where only the Input component re-renders are fast and complete in around 10ms. Since the definition entries are not updated until the user stops typing, the Definitions component does not re-render.

Also, because the Input component now manages it’s own state, typing in the input field doesn’t re-render the parent SearchWord component. Only the Input component re-renders on the onChange event.

The profiling data for the session now looks like this

- 14 commits
- Only first and last 3 commits updated Definitions (We’ve reduced the number of renders)
- 1 network call (We only make a call for the exact word we want)
- 296.4ms total SearchWords render time
- 273.3ms total Definitions render time

This is some amazing improvements in just one change. We can take it further if we want like optimizing the Definitions component to reduce rendering time. However, you could argue that it is pointless chasing after milliseconds of improvement at this point. I say it’s fun and can be useful 🙂

Next steps

Once you know how to identify bottlenecks in your React application using the Profiler API, you can explore other ways, especially if performance is important to your business. 

Additional ways to measure performance in JavaScript apps —

- [User Timing API](https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API)
- [Lighthouse](https://developers.google.com/web/tools/lighthouse)
- [Chrome Devtools performance panel](https://developer.chrome.com/docs/devtools/evaluate-performance/)
- [Custom Metrics](https://web.dev/custom-metrics/)

After profiling and analyzing bottlenecks in your app, you can then look into ways of improving performance using techniques like memoisation and lazy loading.

[Here’s an article on implementing memoisation in React using React.memo and useMemo and one on lazy loading in React apps.](https://ovie.dev/blog/memoisation-in-react-memo-use-memo)

If you’re interested in general improvement tips for the web, [here’s an article on 10 of some of the weirdest web performance tips.](https://blog.asayer.io/10-of-the-weirdest-web-performance-tips)

[Link to source code](https://github.com/ovieokeh/dictionary-profiler-api) for the application profiled in this tutorial.

Learn how to use the React Profiler to measure and improve the performance of your app.

react-logo

Practical guide to profiling a React app

As a React developer, you’ve most likely come across situations where optimizing the performance of a component is necessary. There are certain cases where rendering a component might be so expensive that it uses up a lot of CPU resources and/or memory (i.e rendering a graph with thousands of data points).

When this happens, there are some React APIs that we can reach for to improve performance and today, we’ll focus on two of the most misunderstood ones — React.memo and useMemo.

Before we do this, however, it’s important to get a clear understanding of the concept of memoization and how it relates to these two APIs.

What is memoization?

Memoization is a fancy computer science buzzword that just means a way to avoid doing unnecessary work. Wikipedia describes memoization as —

> “In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.”

Let’s think about it this way. Say you were taking a Mathematics quiz and you were asked the products of 99 and 22. The first time you hear the question, it might take you some seconds to perform the calculations and you arrive at the answer 2,178.

However, if at a later stage you were asked the same question of 99 * 22, you already know the result  from the last time you answered it and you can answer the question immediately without having to do the calculations all over again.

In essence, you memoized (memorized) the result of 99 * 22 the first time you calculated it and every time someone asks you what the answer is, you no longer have to calculate it again. You already know the answer.

This is exactly how memoization works in programming as well. If I had an unoptimized function that calculated the digits of PI, it would consume a lot of CPU resources every time I called this function.

    function digitsOfPI(numOfDigits) { ...some logic }    
    // First call, we use up a lot of resources to calculate the answer
    digitsOfPI(100)

But if the result from this function was memoized, then it would only use up CPU resources the first time it was called. If you called it a second time and asked for the same number of digits as before, the function can just return the memoized result without having to calculate anything again.

    // Second call, we've calculated 100 digits of PI before
    // so the function already knows the answer and doesn't use
    // up any resources calculating it.
    digitsOfPI(100)

It is important to note, however, that memoization is not free and in some cases can actually lead to worse performance. We’ll explore this in more detail below.

## React.memo
How does this relate to React? It becomes useful when you consider how React updates the DOM. When updating the DOM, React renders a component and compares the current and previous render. If they are different, it updates the DOM with the new render, and if they aren’t, it just discards the current render.

But notice that for React to decide whether to update the DOM, it first has to render the component. And if doing so is expensive, you want to minimize the number of times it happens. You can do this by bypassing unnecessary renders using `React.memo`.

If you wrap a component in `React.memo`, React will still render the component normally the first time but it also remembers the props. Before the next render, React will compare the new props and the old ones. If they are the same, it just returns the previous result instead of rendering it again.

### Example use case of React.memo
Take this component which renders a bar graph based on data it receives from props.

    const BarGraph = ({ data }) => {
      ...some expensive calculations
      ...render method
    }

This component will always render the same graph given the same dataset while performing some expensive calculations (expensive here might mean it takes 400ms to process the data). So we only want it to render when the `data` prop changes.

However, the data prop is most likely an array or object so React will always see it as a changed prop between renders even when it hasn’t really changed. This is because of how object equality works in JavaScript. An object is only equal to another object if they point to the same location in memory regardless of the actual contents. (Learn more about object equality on MDN).

This means React will waste some time rendering it and comparing the result before seeing that the result is the same and discarding the render. This is not ideal because it’s an unnecessary cycle and more importantly, an expensive one too.

We can fix this by telling React not to render the component unless the actual value of the `data` prop changes using React.memo like so —

    export const memoisedBarGraph = React.memo(BarGraph)

Ideally, this should fix the issue but in this case, it does not. React.memo uses a shallow comparison of the component props and because of how JavaScript works, comparing objects shallowly will always return false even if they have the same values.

This is why React.memo also takes in a second argument. This argument is a custom equality check function that you, the developer, uses to decide if the component should render (Think shouldComponentUpdate).

The solution then, for our initial problem would look something like this —

    const barGraphPropsAreEqual = (prevProps, newProps) => {
      ...some custom logic to determine if the props are equal
    }

    // we update our React.memo usage
    export const memoisedBarGraph = React.memo(BarGraph, barGraphPropsAreEqual)

Now, when a render is triggered (i.e the parent component rerenders), React.memo can use our custom equality check function to determine if the props for the BarGraph component have changed and if it should rerender.

If our function returns true, React bails out of the render and doesn’t update the DOM. If it returns false, React renders the component again and updates the DOM.

When to use React.memo
You can use React.memo if your component —

- Will always render the same thing given the same props (i.e, if you have to make a network call to fetch some data and there’s a chance the data might not be the same, do not use it)
- Renders expensively (i.e, it takes at least 100ms to render)
- Renders often

If your component does not meet the above requirements, then you might not need to memoize it as using React.memo can, in some cases, make performance worse as it’s more code for the client to parse.

When in doubt, profile your component to see if it would be beneficial to memoize it.

Potential performance pitfalls
There’s a reason why React.memo utilizes shallow comparison by default for determining when to rerender. This is because there is an additional overhead in checking if a value has been memoized every time we need to access it and the more complex the data structure of the value, the worse the overhead is.

For strings, numbers, and dates, comparing the values is trivial but for objects, it can get very resource-intensive based on how complex the object is.

So if a component renders often but the custom equality check function is more expensive, then the performance gets worse instead of it getting better. This is why it is important to benchmark a component before and after using React.memo to ensure that it is actually worth memoizing.

Callback functions
Before springing for React.memo, it is important to check if the component accepts any callback functions. This is because a function in JavaScript is only equal to its instance. What does this mean?

If I pass in a prop to a component like this —

    <BarGraph
      data={data}
      onRenderFinish={() => showNotification(subscribedListeners)}
    />

`onRenderFinish` will have a different instance on each render and if you don’t provide a custom equality check function, then React.memo will re-render everytime the function instance changes even if it is basically the same function. This can lead to worse performance as React will have more work to do when rendering the component — first doing a props comparison, and then rendering anyway because the callback prop has a different instance every time.

There are multiple ways to fix this issue but the officially recommended way is to wrap the callback prop in a useCallback hook like so —

    const onBarGraphRenderFinish = useCallback(
      () => showNotification(subscribedListeners),
      [subscribedListeners]
    );

    <BarGraph
      data={data}
      onRenderFinish={onBarGraphRenderFinish}
    />

Learn more about the useCallback hook.

Another way to fix this is through the custom comparison function passed to React.memo. You can convert the function prop to a string and compare the string values but this comes with some caveats.

    const barGraphPropsAreEqual = (prevProps, newProps) => {
      ...some custom logic to determine if the props are equal

      if (typeof prevProps[propKey] === 'function') {
        const isEqual = prevProps[propKey].toString() === newProps[propKey]
    }

This could also be an expensive operation depending on the size of the function but in most cases, should work fine.

You could also decide not to compare the callback function in the custom equality check function since you can decide which props trigger a re-render. But there are cases where it is actually important to compare a callback function prop.

In our case, if `subscribedListeners` changes and you ignore the `onRenderFinish` prop in the equality check function, you’ll effectively be showing notifications to an outdated list of subscribers.

However, If you do not have any values in the callback that could change over the course of time, then ignoring it in the equality check function would be fine.

useMemo

useMemo is one of the built-in hooks in React and it performs a fundamentally similar but different job to React.memo. Similar in the sense that it also memoizes values but different because `useMemo` is a hook and as a result is limited in how it can be used.

Where we used React.memo to optimize a graph component, we can’t use `useMemo` for the same purpose. Instead, it should be used in cases where a derived value is expensive to calculate on every render. What does this mean?

Example use case of useMemo
Say we have a component that takes in some data and encrypts it using a string key from props like so —

    const Encrypter = ({ dataToEncrypt, encryptKey }) => {
      const encryptedData = encrypt(dataToEncrypt, secretKey);
      ...render method
    }

Whenever this component renders, it has to encrypt the data passed to it every time regardless of if the props change. If the `encrypt` function takes a long time to do this, we might want to reduce the number of times we have to run it.

This is where `useMemo` shines. If we have a variable inside a component that is expensive to compute, we can use `useMemo` to reduce the number of times this has to happen by memoizing the computed variable.

In our example case above, this would look something like —

    const Encrypter = ({ dataToEncrypt, encryptKey }) => {
      const encryptedData = useMemo(
        () => encrypt(dataToEncrypt, secretKey),
        [dataToEncrypt, encryptKey]
      );
      ...render method
    }

Now, every time the `Encrypter` component renders, before running the expensive `encrypt` function, `useMemo` checks to see if the `dataToEncrypt` and `encryptKey` values have changed between renders.

If not, it simply returns the result of the previous render without calling the  `encrypt` function. If it changed, then we calculate the result again.

Instead of a custom equality check function as in React.memo, `useMemo` takes in a dependency array (i.e the values that need to change for the result to be calculated again) to determine when to “forget” the previous result and recalculate it (I’m not a 100% sure if React only memoizes the previous render or if there’s an internal cache of previously memoized renders).

If the values in the dependency array are objects or functions, `useMemo` checks for referential equality to determine whether to recalculate the result. This means that for an object or function value, React only considers the value changed if the reference in memory has changed regardless of the actual contents.

In many cases, the object and function instances (except arrow functions because they’re always recreated on each render) don’t change between renders but in cases where deep comparison is necessary, you can use a custom hook like useMemoCompare.

When to use useMemo
Before deciding to use `useMemo`, make sure that —

- You have profiled the component and determined if it’s calculating an expensive value in every render
- There are no side effects (e.g async calls) in your `useMemo` hook because it runs during rendering and all side effects belongs in the useEffect hook.
- You do not break the rules of React Hooks
Which one should I pick?

Now that we have a solid understanding of both `React.memo` and `useMemo`, deciding which one to use should be simple.

- If you’re memoizing a whole component, use `React.memo`
- If you’re memoizing a value inside a functional component, use `useMemo`

It’s noteworthy to mention again that before you spring for either of these solutions, ensure that your use case warrants it as if used carelessly, they could harm performance instead of improving it.


Memoisation sounds fancy but it is really just saving a value and using it later.

If you're searching for new ways to boost your React app performance then this article might be for you.

memoisation-in-react-feature-image

Improving React application performance: React.memo vs useMemo

Over the years, there’s been a gradual shift in the way we build and ship web apps. We’ve gone from monolithic apps running on a server to flexible units running on ephemeral instances.

You only need to look at the [trends data for the term “aws serverless”](https://trends.google.com/trends/explore?date=all&q=aws%20serverless) to see how popular serverless has gotten over the years. So why the trend? What does the term serverless mean? How can there be no server?

All serverless means is that you can ship code to your users without having to worry about the underlying architecture required to run it. There is still a server running your code somewhere, but you don’t have to worry about setting it up or managing it.

"Let someone else be your DevOps team" - Serverless in a nutshell

Before we go any further, I'll come right out and say that I'm an advocate for serverless. [If the use case is right,](https://cloud.google.com/functions/docs/concepts/overview#use_cases) it can carry massive reductions in hosting costs, among a whole host of other benefits.

There's a caveat, though — notice that I used the phrase "if the use case is right." That's because not every app should be built on a serverless architecture. You might end up paying more for hosting and still end up delivering a subpar experience to your users.

This is why you have to weigh the pros and cons of going serverless on a case-by-case basis. In this article, we'll look at how to determine if serverless is a good fit for your project.

Firstly, let's see what servers are before we move on to serverless.

"Learn the rules like a pro, so you can break them like an artist"
          - Pablo Picasso

## Servers and why you need one

[A server, in the context of web apps,](https://www.lifewire.com/servers-in-computer-networking-817380) is hardware or software dedicated to running and serving your code to your users. You need a server to run your HTML, CSS, and JavaScript as well as your backend environment like Node.js. Even your database runs on a server.

All requests made by your browser are eventually handled by a server somewhere, so you can see how important a server is in software development.

OK, so what's wrong with the way we use them right now? Well, a traditional server is like a 24/7 restaurant. It's always open and ready to serve requests. This is how it has always been since [Tim Berners Lee invented the web in 1989](https://home.cern/science/computing/birth-web/).

But the problem with being on all the time is that when there's nothing to do, you'll start wasting resources. If your restaurant is open for ten hours but is filled for only three, you've wasted time and power for seven hours. Do this long enough and the costs begin to accumulate. It eats into your revenue and causes [adverse effects on the environment.](https://www.computerworld.com/article/3431148/why-data-centres-are-the-new-frontier-in-the-fight-against-climate-change.html)

Let's look at a fictional case study to show how inefficient it is to run a traditional web server in a specific case.

## The gross inefficiency of a traditional server

Trakkr is a young startup trying to make package tracking and delivery easy and convenient.

They have an API endpoint that enables you to track the location of your package through a unique tracking number. You put in the tracking number and it tells you the location of your package.

Let's imagine that they host this API on a traditional server, and it takes approximately 200ms to process a single tracking request. We’ll assume that they process an average of 10,000 requests every day.

    10,000 requests per day * 200 milliseconds per request
    =
    2.000.000 miliseconds of work done by the server in a day
    or
    33 minutes of work done by the server in a day

From multiplying the number of requests by the time it takes to process each request, we can see that they need the server to be on for only 33 minutes per day.

The average cost to run a server for a whole day is approximately $3. Running that same server for 33 minutes is approximately $0.07.

Scale that up to a month and Trakkr is shelling out **$****90** for a server that is idle for 97 percent of the time instead of paying only **$****2** for the 33 minutes they need.

This brings us to the major selling point of serverless architectures: [You only pay for what you use.](https://aws.amazon.com/lambda/pricing/)

## Benefits of a serverless architecture

Unlike a traditional architecture, where your server is always on regardless of whether it is being utilized, a serverless “server” is only on whenever there’s something to do. This means that you only pay for the time and resources used within a given period. How does this work?

If you decide to build on a serverless architecture, you’ll have to make some major changes to the way you structure your code. Instead of a single server that handles all requests, your app will be composed of smaller functions that are spun up each time when called.

Let’s look at our previous example with the Trakkr API. In a traditional approach, the API would be hosted on a single, always-on server (this is simplified, as you could implement [load balancing](https://www.znetlive.com/blog/what-is-load-balancing-in-cloud-computing-and-its-advantages/)), and the server would stay on, waiting for tracking requests to process.

In a serverless architecture, the API would be modularized. All the endpoints would be split up into smaller functions that live on the cloud. These functions can access a file system, a database, talk to each other, or use third-party services.

![Serverless favors modularity.](https://paper-attachments.dropbox.com/s_51CEFF421197FF68277EDC7A3C9981B7AC0CA0E76ACCE95BE3D751FD6DAAA120_1586130341650_serverless+vs+traditional.png)

So the Trakkr API, in this case, would consist of these functions hosted on a service like [AWS Lambda](https://aws.amazon.com/lambda/) or [Google Cloud Functions.](https://cloud.google.com/functions) Each request can then be routed to the corresponding function through an API gateway. So what happens when a user makes a request to track a package?

When a tracking request is made, [an API gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) intercepts the request and calls the appropriate function to handle the request. An ephemeral instance of the function is then spun up in an isolated container. The function does its job, passes the response back to the user like a normal REST endpoint would, and then the instance is destroyed.

So, to recap:

- A serverless architecture requires you to modularize your public endpoints into functions
- Each function lives on the cloud, and new instances are created every time a function is called *
- Each function instance has access to a file system, database, and resources
- A function instance can only run for a short time before getting destroyed **

> \* In some cases, instances are reused for faster load-up times
> \** Up to 15 minutes for AWS Lambda, and 9 minutes for Google Cloud Functions

The major strength of a serverless architecture is that you’re only charged for the resources you use in a period. If the function runs for 10 minutes in one day and uses 128MB of memory, you will be charged for only those 10 minutes and 128MB of memory.

**Trakkr on** **s****erverless**
What if Trakkr switched to a serverless platform like AWS?

Well, we already know that their tracking service handles approximately **10,000 requests** per day and that each request takes **200ms** to be processed.

We also know that Trakkr is paying $90 to host the server that powers the service. How much would they pay if they switched to AWS?

AWS charges by the number of requests and the duration of each request, and their free tier offers you **1 million requests** and **400,000s** of compute time. With these freebies, Trakkr’s monthly hosting costs would effectively drop to $0.

What if they decided not to opt for the free tier for some reason? Well, [AWS charges $0.2](https://aws.amazon.com/lambda/pricing/)[0](https://aws.amazon.com/lambda/pricing/) [per 1 million requests](https://aws.amazon.com/lambda/pricing/)[,](https://aws.amazon.com/lambda/pricing/) [and $0.0000002083 per 100ms of compute time.](https://aws.amazon.com/lambda/pricing/) Let’s revisit the calculations we made before.

Since Trakkr requires just **2,000,000ms of compute time** in a day, they’d be spending;

2,000,000ms x ****$0.0000002083 / 100ms **=** **$0.004166 per day****,** or **$0.125 per month**

That’s a reduction of more than 860 percent in server costs for the same service. You can begin to see how, in some cases, switching to a serverless architecture can help you cut down on infrastructure costs massively. This is just one example with one serverless provider, but most offer similar savings.

Apart from the financial gains you could enjoy by switching to a serverless architecture, there are other advantages of building your app this way:

- Scaling is handled automatically in response to load
- Multi-language development
- Code optimization directly impacts operational costs
- Scale different parts of your app independently
## Trade-offs of going serverless

You may have noticed some issues with the way serverless functions are run. Most times, they have to be spun up from scratch when called — [a cold start](https://cloud.google.com/functions/docs/concepts/exec#cold_starts). This includes some overhead like setting up a file system, allocating memory, pulling in dependencies, etc.

This extra work that has to be done before a function is ready can lead to slow startup times, which, in turn can lead to a bad user experience. This is why providers like AWS and Google Cloud Platform will sometimes reuse an instance of a function to reduce latency (warm starts).

Apart from slow startup times, a serverless function is also constrained in other ways.

Because each function is ephemeral (i.e., short-lived), a new function can’t depend on the data from a previous function — that is, unless the data is stored in a separate, persistent layer, like a Postgres database somewhere. But this isn’t ideal, as you’ll incur more latency in communicating with a separate server to retrieve this data.

There are many other drawbacks to using a serverless architecture. [Martin Fowler has gone much more in-depth about these drawbacks in his blog](https://martinfowler.com/articles/serverless.html#drawbacks).

If you’re interested in seeing whether serverless would be the right option for you, read along.

## Should you switch to a Serverless architecture?

The decision to adopt an architecture should not be based on a single article. However, the aim of this section is to provide you some of the questions you should be asking if you’re considering adopting a serverless architecture.

These questions can guide [your research](https://serverless.com/blog/when-why-not-use-serverless/) to enable you to make informed decisions that will lead to the best outcome for your particular use case.

- Do you already utilize most of your server hardware?
- Does your app require a lot of in-memory caching?
- How will frequent cold starts affect your UX?
- Do you require long-lived processes most of the time?
- Does your traffic profile play to the strengths of a serverless architecture?

Maybe have a chat with your CTO or your team lead to answer the questions above (this is by no means an exhaustive list). You should have a much better idea if serverless would be right for a project at the other end of the conversation.

I’ll leave you with a quote from Martin Fowler that bests summarizes the decision to switch to a serverless architecture:

“While there are riches — of scaling and saved deployment effort — to be plundered, there also be dragons — of debugging and monitoring — lurking right around the next corner.”


If the use case is right, serverless architectures can offer massive reductions in hosting costs and incredible modularity. But you need to be aware of the caveats.

Cloud computing

Benefits and tradeoffs of going Serverless

React has made building interactive applications a lot more manageable. We’re able to break up our app into components, each with their own encapsulated logic and styling. It’s great — it means we’re able to work on lots of smaller problems instead of one really large one.

This method of building applications works really well because of abstractions. A component in an application is just an abstraction of logic, data, and, in some cases, styling.

    const Button = () => (...)

The `Button` component above is an abstraction of the logic and styles required to make a button show up on a page. Now, every time we want a button, we simply use this abstraction — no need to reinvent the wheel.

When we build apps this way, a new challenge arises: sometimes we want to share logic or data between components. We also want to do this in a way that is clean and composable. Just as we’re able to abstract logic and data into components, we also want to be able to compose these components to form larger building blocks.

Four paragraphs in and we still haven’t gotten to [render props](https://reactjs.org/docs/render-props.html) yet.

**Put simply, a render prop is simply a function prop that is called in a render method**. But to truly understand what this means, we need to know why such a pattern exists in the first place.

## Why do we need render props?

Let’s take a legitimate problem we might face in the real world. Say we wanted to have a UI element that we could dismiss with an animation.

![Delete from table by Alex Lauderdale](https://static.dribbble.com/users/46425/screenshots/4823330/table_ux.gif)

What we want here is a component that can render anything, but we want to keep this dismissal animation. We could simply use the `children` prop and pass whatever we wanted to render as a child.

    const Dismiss = ({ children }) => {
      return (
        <Fragment>
          {children}
        </Fragment>
      )
    }

That would work, but it’s limited.

- How would we fire the dismiss event from within the component being rendered? If we decide to fire it from the `Dismiss` component, that means we’ll have to hardcode some HTML.
- What if we wanted to set up different actions to fire on the dismiss event?
- Is there any way to pass data as props to the children being rendered?

In situations like this, we need something a bit more flexible than the children prop method. What we really want is to encapsulate the dismissal functionality so that we can share it between components.

With render props, we could render anything we wanted, just like the children prop method. But we will also be able to pass props to whatever is being rendered.

**This is the main purpose of render props — being able to communicate with any rendered component without having to couple implementation details.** This is possible because the render function now comes in as a prop, and you can pass data to it as arguments when you call it.

This will become clearer when we take a look at a practical use case for render props (based on [Wave Free’s modal component](https://wave.free-now.com/components/Modal)). We’ll look at a possible solution to the problem we raised initially using the children prop method. Then, we’ll look at a more flexible solution with render props.

## Implementing render props
    const Dismiss = ({ children }) => {
      const dismiss = () => {
        ...code to implement dismissal animations etc
      }

      return (
        <div>
          {children}
          <button onClick={dismiss}>dismiss</button>
        </div>
      )
    }

    const DismissableContent = () => {
      return (
        <Dismiss>
          ...code
        </Dismiss>
      )
    }

Above, we have a `Dismiss` component that renders whatever is passed as the children prop but also contains code to implement the dismiss animation. Below it is how we’d use such a component. Notice that with this implementation:

- You can only fire the dismiss event from within the `Dismiss` component
- You can’t pass data to the `children` being rendered
- You have to account for the extra div in your layouts

You can see some of the limitations in sharing functionality this way. Now let’s look at the same solution, but with render props:

    const Dismiss = (props) => {
      const dismiss = () => {
        ...code to implement dismissal animations etc
      }

      return props.render(dismiss)
    }

    const DismissableContent = () => {
      return (
        <Dismiss render={
          dismiss => <Content dismiss={dismiss} />
        } />
      )
    }

Apart from the code being smaller, there are some more important advantages to this method.

We have moved the content of the render function from being hardcoded in the `Dismiss` component to accepting it from the props. By simply calling `props.render()`, the component is able to render whatever is returned from the render prop. This comes with some implications:

- Since the render prop is a function, we can pass data to it as arguments. This means that  `Dismiss` can communicate with the component being rendered and vice versa
- You don’t have to account for any extra divs from `Dismiss` because it can be pure and not return its own HTML (most times, though, you’d return some accompanying HTML and styling)

We can now see how this solves the issues we had using the children prop method. This is much cleaner and more flexible by every metric.

## Implementing other props

Another advantage of render props is that the prop doesn’t have to be called `render`. You could call it whatever you want as long as the prop is invoked in the render method. This leads to interesting implementations, like this:

    const Dismiss = ({ children }) => {
      const dismiss = () => {
        ...code to implement dismissal animations etc
      }

      return children(dismiss)
    }

    const DismissableContent = () => {
      return (
        <Dismiss>
          {(dismiss) => (
            <Content dismiss={dismiss} />
          )}
        </Dismiss>
      )
    }
## Implementing higher-order components (HOCs)

You may have noticed by now that render props also allow us to implement HOCs with minimal effort. Below, you can see a `withDismiss` HOC that takes in a component and enhances a component with the dismiss functionality.

    const withDismiss = (Component) =>
      (props) => (
        <Dismiss>
          {(dismiss) => (
            <Component dismiss={dismiss} {...props} />
          )}
        </Dismiss>
      )

This is so easy because of the compositional nature of components in React. Because we’ve been able to encapsulate the dismiss logic into a component with render props functionality, composing new components with the same functionality becomes effortless.

## Caveats

There’s an important edge case to keep in mind when using the render props pattern if you use `React.PureComponent`. For a quick refresher, `PureComponent` can provide small performance gains because it implements `shouldComponentUpdate` internally through a shallow props and state comparison.

The important thing to note here is the shallow props comparison. Most of the time, when you use render props, you’ll be passing an anonymous function to the render prop.

    class Dismiss extends React.PureComponent {
      dismiss = () => {
        ...code to implement dismissal animations etc
      }

      render() {
        return this.props.render(dismiss)
      }
    }

    const DismissableContent = () => {
      return (
        <Dismiss render={
          dismiss => <Content dismiss={dismiss} /> // will be different every render
        } />
      )
    }

In this example, every time `DismissableContent` renders, it generates a new value for the render prop, and this fails the shallow comparison done by `React.PureComponent`.

If it is important to you that this doesn’t happen — e.g., maybe `Dismiss` contains some intensive code — you could fix it by moving the render prop value into a named function, like this:

    class Dismiss extends React.PureComponent {
      ...same implementation as above
    }

    const DismissableContent = () => {
      const content = (dismiss) => <Content dismiss={dismiss} />

      return (
        <Dismiss render={content} />
      )
    }

This will ensure that the `content` value becomes an instance of the `DismissableContent` component and is not regenerated on every render.

## Conclusion

I hope by the end of this article you should have a solid understanding of the render props pattern in React. It is a very powerful and flexible pattern for solving some code sharing issues you might come across in your codebase.

If you want a playground to practice with render props, you can [fork this CodeSandbox](https://codesandbox.io/s/render-props-bd52r) and try to get a practical feel for working with the pattern.

Happy coding ❤️.

My all-in-one reference guide on render props in React, including how to implement render props, how to implement HOCs, and more.

react-logo-wide

All you need to know about React Render Props

So you want to publish a React component as a package to npm? This guide has all the information you need.

npm logo on red background

Publishing a React package to NPM

I’m writing this blog post on testing because it’s a topic I’m very comfortable with and I recently had a Eureka! moment and I want to document my growth in this area.

This is a question that has bugged me from the first time I wrote an integration test using Cypress. I had a vague understanding that integration and end to end tests interact with the app as a user would. But to what extent, I didn't know.

Cypress itself didn't really help matters with it being branded as an end to end testing tool but then using an `/integration` folder name in example tests. Is it an e2e or an integration test?

I think I can finally attempt to answer that question now 😄

## Integration tests

Integration tests are similar to end-to-end tests in one major way; they both test the app as a user would use it. Apart from that, they are pretty different from each other in what they assert and their overall scope with respect to the application.

Integration tests, in my opinion, should interact with the application from the perspective of a user but should not interact with the network layer, i.e, make a network request to fetch data.

Imagine a slider component built with React. Testing such a component using unit tests would probably result in very unreliable tests that don't say much about how it fits in with the app holistically.

Instead, you'd write a simple integration test that would interact with the slider just like a user would.

    Pause slider
    Click to next slide
    Swipe to next slide
    ...

You want to ensure that a user can perform the above actions in your applications and that they would see the correct thing every time and you probably don't need to make a network request to fetch content for the slider but you want to be able to assert that those actions are possible.

This is where a tool like Cypress then comes in. Because it has access to all layers of your application, it can stub out network requests and provide the data required for the slider component to function.

You can then interact with the slider component using mocked data. This allows the integration test to remain fast and lightweight while ensuring that your slider component works correctly in the context of your application.

To iterate, integration tests

- test small sections of the app at a time
- can bypass the network layer without losing integrity
- are usually faster

## End to end tests

Now imagine another scenario. You want to add search functionality to your blog.

When a user types in the search input box and hits enter they should see a list of results that match their query

Instead of testing an isolated section of your app, you're now testing for user flows and stories which may involve populating many smaller components with data and seeing if they can work together to complete the desired action.

Since your search functionality is probably a custom code, you also want to ensure that it meets business requirements. You should not stub this request because you really want to test your backend search API as well as your frontend rendering code. End. To. End.

Notice how we're involving multiple stacks and asserting that they can work together to satisfy the user story. Stubbing out the network layer would make it impossible to test a significant portion of the feature (the backend code that actually does the searching).

To iterate, end to end tests

- test user flows and whole features from end to end
- good e2e tests require the network layer to be useful
- are slower and expensive to run compared to integration tests

Can you now begin to see how integration and end to end tests operate at different scales? They are similar in a way but are concerned with proving different things.

## Conclusion

Both integration and e2e testing are essential in any significant application. Having one or the other may be sufficient in some cases but you can’t beat the robustness of having both in a project.

Having both classes of tests will enable you iterate much faster with little worry of breaking existing features and UX flows.


Learn how to differentiate between an integration test vs an end-to-end test. Inspired by real life eureka moments!

E2E vs Integration

Integration vs e2e testing

I love React Hooks even though they're not perfect thanks to some weird rules that sometimes make them feel like magic. Rules such as not being able to use them inside conditionals, and requiring them to be called at the top of the components.

Even with these restrictions, I still enjoy using them when building my React apps and they have helped me write cleaner, intuitive code many times.

However, there was a case recently where I discovered a quirk of how the `useEffect` hook works and how it caused me wasted hours of debugging.

## Beware of stale state
I had a keydown listener being attached to the DOM inside a `useEffect` call that had no dependencies (supposed to run only once per render).

Inside the callback to the listener, I was reading a state variable (`useState`) and updating it depending on what the value was whenever a user clicked on their arrow keys.

Now here’s the problem. The callback was always working with the INITIAL state captured during the first render. Even though I was updating the state inside the callback, I kept reading a stale state.

I was stumped as to why this was happening.

After eliminating wrong logic as the cause of the problem, I started suspecting the useEffect call. So I went to Dan Abramov’s ["A Complete Guide to useEffect" post](https://overreacted.io/a-complete-guide-to-useeffect/ "Link to Dan Abramov's post on useEffect") to see if there was something I was missing.

It was then I discovered something which explained why I was getting this problem.

> useEffect calls close over any variables within them per render

So during the first render, the useEffect call would effectively freeze over the initial state and since there were no dependencies to update the useEffect call, I was always going to be stuck with stale data.

The fix was simply to add in the state variables I was making use of to the useEffect's dependency array. That enabled the useEffect call to “refresh” in response to the state updates being made inside the listener callback.

It's a simple fix that is obvious in hindsight and is even documented on the [`useEffect` entry in the Hooks documentation.](https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects "Link to the useEffect docs entry").

[The problematic piece of code.](https://github.com/ovieokeh/robot-sim/blob/master/src/components/useKeydownListener.ts)

An eye-opener on the inner workings of the React useEffect hook.

mystery-feature

A Curious Case of Stale State

Learn how to use Suspense to orchestrate optimised and predictable loading states in your app.

React Suspense for data fetching

Learn how to build a PWA on a Serverless architecture capable of working offline using React and Firebase.

feature

Creating a "Lists" PWA with React and Firebase

The Hooks API has brought with it a whole new way of writing and thinking about React apps. One of my favorite Hooks so far is `useReducer`, which allows you to handle complex state updates, and that’s what we’ll be looking at in this article.

Managing shared state in larger React apps usually involved pulling in third-party libraries like [Redux](https://blog.logrocket.com/why-use-redux-reasons-with-clear-examples-d21bffd5835/) and MobX. These third-party libraries made it easier to update your application’s state in a more predictable and fine-grained way, but they usually came with extra overhead and learning curves.

The good news is that you can now reap the same benefits without the extra packages and learning curve — OK, maybe a tiny curve — thanks to `useReducer`. By the end of this article, you should be able to manage your application’s state in a predictable manner without any third-party package.

*__Note: This is not an article bashing Redux, MobX, or any other state management package. They all have cases where they shine. This article simply aims to familiarize you with `useReducer` and how you can use it as an alternative to manage an application’s state.__*

## What is `useReducer`?
Before we get into how to use `useReducer` to manage shared state, we’ll have to deconstruct it so we can understand it better.

It’s one of the new custom Hooks that now [ship with React since v16.8](https://reactjs.org/docs/hooks-intro.html). It allows you to update parts of your component’s state when certain actions are dispatched, and it is very similar to how Redux works.

It takes in a reducer function and an initial state as arguments and then provides you with a state variable and a dispatch function to enable you to update the state. If you’re familiar with how Redux updates the store through reducers and actions, then you already know how `useReducer` works.

## How does `useReducer` work?
A `useReducer` requires two things to work: an initial state and a reducer function. We’ll see how they look below and then explain in detail what each of them is used for.

Consider the following snippet of code:

```
// we have to define the initial state of the component's state
const initialState = { count: 0 }

// this function will determine how the state is updated
function reducer(state, action) {
  switch(action.type) {
    case 'INCREMENT':
      return { count: state.count + 1 }
    case 'DECREMENT':
      return { count: state.count - 1 }
    case 'REPLACE':
      return { count: action.newCount }
    case 'RESET':
      return { count: 0 }
    default:
      return state
  }
}

// inside your component, initialize your state like so
const [state, dispatch] = useReducer(reducer, initialState);
```
In the code snippet above, we have defined an initial state for our component — a reducer function that updates that state depending on the action dispatched — and we initialized the state for our component on line 21.

For those of you who have never worked with Redux, let’s break down everything.

### The initialState variable
This is the default value of our component’s state when it gets mounted for the first time.

### The reducer function
We want to update our component’s state when certain actions occur. This function takes care of specifying what the state should contain depending on an action. It returns an object, which is then used to replace the state.

It takes in two arguments: state and action.

`state` is your application’s current state, and `action` is an object that contains details of the action currently happening. It usually contains a `type:` that denotes what the action is. action can also contain more data, which is usually the new value to be updated in the state.

An action may look like this:

```
const replaceAction = {
  type: 'REPLACE',
  newCount: 42,
}
```
Looking back at our reducer function, we can see a switch statement checking the value of `action.type`. If we had passed `replaceAction` as the current action to our reducer, the reducer would return an object `{ count: 42 }`, which would then be used to replace the component’s state.

### Dispatching an action
We know what a reducer is now and how it determines the next state for your component through actions being dispatched. How, though, do we dispatch such an action?

Go back to the code snippet and check line 21. You’ll notice that `useReducer` returns two values in an array. The first one is the state object, and the second one is a function called `dispatch`. This is what we use to dispatch an action.

For instance, if we wanted to dispatch `replaceAction` defined above, we’d do this:

```
dispatch(replaceAction)

// or

dispatch({
  type: 'REPLACE',
  newCount: 42,
})
```
Dispatch is nothing more than a function, and since functions in JavaScript are first-class citizens, we can pass them around to other components through props. This simple fact is the reason why you can use `useReducer` to replace Redux in your application.

## Replacing Redux with useReducer
Now for the reason you’re actually reading this article. How do you use all these to get rid of Redux?

Well, we know how to dispatch an action to update a component’s state, and now we’re going to look at a scenario where the root component’s state will act as the replacement for the Redux store.

Let’s define the initial state of our store:

```
const initialState = {
  user: null,
  permissions: [],
  isAuthenticating: false,
  authError: null,
}
```
Now our reducer function:

```
function reducer(state, action) {
  switch(action.type) {
    case 'AUTH_BEGIN':
      return {
        ...state,
        isAuthenticating: true,
      }

    case 'AUTH_SUCCESS':
      return {
        isAuthenticating: false,
        user: action.user,
        permissions: action.permissions
        authError: null,
      }

    case 'AUTH_FAILURE':
      return {
        isAuthenticating: false,
        user: null,
        permissions: []
        authError: action.error,
      }

    default:
      return state
  }
}
```
And, finally, our root component. This is going to hold the store and pass the required data and the dispatch function down to the components that need them. This will allow the children components to read from and update the store as required.

Let’s see how it looks in code:

```
function App() {
  const [store, dispatch] = useReducer(initialState)

  return (
    <React.Fragment>
      <Navbar user={store.user} />
      <LoginPage store={store} dispatch={dispatch} />
      <Dashboard user={store.user} />
      <SettingsPage permissions={store.permissions} />
    </React.Fragment>
  )
}
```
We have `App` set up to handle the store, and this is where we pass the store values down to the children components. If we were using Redux, we’d have had to use `Provider` to wrap all the components, create a separate store, and then for each component that needs to connect to the store, wrap them in a HOC with `connect`.

With this approach, however, we can bypass using all that boilerplate and just pass in the store values directly to the components as props. We could have as many stores, reducers, initialStates, etc. as is required without having to bring in Redux.

OK, let’s write a login function, call it from the `<LoginPage />` component, and watch how the store gets updated.

```
async function loginRequest(userDetails, dispatch) {
  try {
    dispatch({ type: 'AUTH_BEGIN' })
    const { data: { user, permissions } } = await axios.post(url, userDetails)
    dispatch({ type: 'AUTH_SUCCESS', user, permissions }) 
  } catch(error) {
    dispatch({ type: 'AUTH_FAILURE', error: error.response.data.message })
  }
}
```
And we’d use it like this in the LoginPage component:

```
function LoginPage(props) {
  // ...omitted for brevity
  const handleFormSubmit = async (event) => {
    event.preventDefault()

    await loginRequest(userDetails, props.dispatch)
    const { authError } = props.store
    authError
      ? handleErrors(authError)
      : handleSuccess()
  }
  // ...omitted for brevity
}
```
We’ve now been able to update a store variable that is being read from several other components. These components get the new value of user and permissions as soon as the the reducer returns the new state determined by the action.

This is a very modular way to share dynamic data between different components while still keeping the code relatively simple and free from boilerplate. You could improve on this further by using the useContext Hook to make the store and dispatch function available to all components without having to manually pass it down by hand.

## Caveats
There are some rather important limitations to `useReducer` that we need to talk about if we’re being objective. These limitations are what may hinder you from managing all your application’s state with `useReducer`.

### Store limitations
Your store is not truly global. Redux’s implementation of a global store means that the store itself isn’t tied to any component; it’s separate from your app.

The state you get from `useReducer` is component-dependent, along with its dispatch function. This makes it impossible to use the dispatch from one `useReducer` call on a different reducer. For instance, take these two separate stores and their dispatch functions:
```
const [notificationStore, dispatch1] = useReducer(initialState, notificationReducer)
const [authStore, dispatch2] = useReducer(initialState, authReducer)
```
Because of the dependence of the dispatch function on the `useReducer` call that returned it, you can’t use `dispatch1` to trigger state updates in `authStore`, nor can you use `dispatch2` to trigger state updates in `notificationStore`.

This limitation means you have to manually keep track of which dispatch function belongs to which reducer, and it may ultimately result in more bloat. As of the time of writing this article, there is no known way to combine dispatch functions or reducers.

### Extensibility
One of my favorite features of Redux is how extensible it is. For instance, you can add a logger middleware that logs all the actions dispatched, and you can use the Chrome extension to view your store and even diff changes between dispatches.

These are all things that you’d give up if you decide to replace Redux with `useReducer`. Or you could implement these yourself, but you’d be reintroducing the boilerplate that Redux brings with it.

## Conclusion
The `useReducer` hook is a pretty nice addition to the React library.

It allows for a more predictable and organized way to update your component’s state and, to an extent (when coupled with `useContext`), makes sharing data between components a bit easier.

It has its shortcomings, too, some of which we discussed above.

Check out the [React documentation to learn more about this and the other Hooks available right now](https://reactjs.org/docs/hooks-reference.html#usereducer). Goodbye and happy coding ❤️

Learn how to manage state using only React Hooks for small to mid-sized applications. Useful for when you don't want to use any third-party libraries.

react-hooks-feature

State management using only React Hooks

Testing has become an essential aspect of software engineering, and for good reason, too. Writing software of any complexity can often be a messy task, and this only gets worse when teams get larger and more people start to work on the same codebase.

This problem is worsened in frontend development, where there are so many moving parts that writing unit and functional tests might not be enough to verify the application’s correctness. For example, you can’t really verify that a particular user flow doesn’t cause issues through a unit test.

[End-to-end testing](https://blog.logrocket.com/end-to-end-testing-react-apps-with-puppeteer-and-jest-ce2f414b4fd7/) allows you to replicate user behaviour on your application and verify that everything works as it should. If you’re writing production-grade web apps, writing e2e tests is a no-brainer.

In this article, we’ll take a look at how to write useful e2e tests on the frontend using [Cypress.js](https://www.cypress.io/).

While there are other e2e testing tools like [Selenium](https://www.seleniumhq.org/) and [Nightwatch.js](https://nightwatchjs.org/), we’ll focus on Cypress because of its suite of features, which include time travelling through your tests, recording your tests for later playback, etc.

*__Note: To follow along with this tutorial, you’ll need to have Node.js installed. If you don’t have it, you can download the latest stable version [here](https://nodejs.org/en/).__*

## Setting up Cypress
Let’s create a new project and set up Cypress so we can get started.

Initialize a new project by running the following:

```
mkdir cypress-tutorial
cd cypress-tutorial
npm init -y
```
Install Cypress as a dev-dependency:

```
npm install --save-dev cypress
```
Update the project’s scripts by opening package.json and updating your scripts to the following:

```
"scripts": {
  "test": "$(npm bin)/cypress run",
  "cypress:open": "$(npm bin)/cypress open"
},
```
Create a file called `cypress.json` in the root folder. This is how you customize Cypress’ behaviour for this specific project. Add the following in it and save.

```
{ "chromeWebSecurity": false }
```
Why we do this will be explained further down, so keep reading.

## Writing our tests
User stories (for those of us who practice Agile) usually follow a format that might look similar to this: “*When a user takes a specific action, then the user should see this.*”

Following this pattern, you can determine how to go about writing an e2e test for that specific story. All you need to do is simulate taking the action the user is expected to take through the test and then assert that the application state matches what you expect.

For frontend testing, those steps can usually be broken down into these:

- Visit a page on your app
- Query an element on that page, e.g., buttons, dropdowns, etc.
- Interact with the element, e.g., clicking on buttons, dragging divs, etc.
- Confirm that the new state after the interaction is correct

We’re going to write three tests to assert that we can perform certain actions on [Wikipedia](https://wikipedia.org/) by mimicking a user’s actions. For each test, we’ll write a user story before writing the actual test.

Before we get started with writing the tests, you will have to create a special folder to hold your Cypress tests. In the root of your project, run the following commands:

```
mkdir cypress && cd cypress
mkdir integration && cd integration
```
All our Cypress tests will go inside this `/integration` folder. Don’t worry about the name of the folder, as you can store any type of test in here.

*__Note: Don’t use Cypress on a website/application that you do not own. Cypress is solely meant for testing your own apps and not as a tool for automating your personal life.__*

### Test 1: A user can perform a search from the homepage
__User story__
When a user visits the homepage, types in the search box, and click on the search icon, then the user should see a new page populated with the results from their search term.

The user story is pretty straightforward: it is just asserting the correct behaviour for a search action on the homepage by a hypothetical user. Let’s write a test for it.

Inside the `/integration` folder, create a new file called `homepage_search_spec.js` and open it in your favourite text editor (I use Visual Studio Code).

```
describe('Testing Wikipedia', () => {
  it('I can search for content', () => {
    cy.visit('https://www.wikipedia.org');
    cy.get("input[type='search']").type('Leo Panthera');
    cy.get("button[type='submit']").click();
    cy.contains('Search results');
    cy.contains('Panthera leo leo');
  });
});
```
Let’s go through the test and see how it matches the steps we defined earlier.

- Line 3: Visit a page on your app
- Line 4: Query an element on that page and interact with it
- Line 5: Query an element on that page and interact with it
- Line 6: Confirm that the new state after the interaction is correct
- Line 7: Confirm that the new state after the interaction is correct

A majority of your e2e tests will follow the above format, and you can begin to see the benefits of testing your applications this way. You don’t need to care about how the app is handling these actions in the background; all you care about is that your app should perform a certain way for a certain action.

How about the syntax? One thing I like about Cypress is how intuitive the syntax is. It uses natural language that makes it easy for even non-programmers to read and understand your tests.

Let’s run the test. In your terminal, run `npm test` and Cypress will look inside the `cypress/integration` folder and run all the tests there.

But this is not the only way to run your tests. You can run them in a GUI, where you get a real-time view of your app as Cypress manipulates it according to your test spec.

In your terminal, run `npm run cypress:open` and a window should pop up that looks like this:
![tests-window](//images.ctfassets.net/6qz05ishztgm/1wlrP9kKJtW6yFhfmKV9MN/9f4035c6d2f6f888bf78fcdf77803a9a/tests-window.png)

Simply click on `homepage_search_spec.js` to run your tests and you should see another window pop up.

![test-results](//images.ctfassets.net/6qz05ishztgm/5Glb46jfmJhw6IvliFEewC/d5b17974f5c8eed018ac387a32315629/test-results.png)

At the top left of the window, you can get a quick view of how many passing and failing tests you have in your test suite. On the right side of the window is what a user would see if they interacted with your application the way you specified in the test.

The left side is where most of the magic happens. Here you can see which test is currently running, the actions being taken, and the results of those actions.

With this simple test, we’ve been able to assert that whoever worked on the search functionality for Wikipedia has been able to satisfy the hypothetical user story requirements.

### Test 2: A user can switch languages from the homepage
__User story__
When a user visits the homepage, clicks on the language switcher, and selects a new language, then the user should be redirected to the appropriate domain for the selected language.

Inside the `/integration` folder, create a new file called `homepage_switch_language_spec.js` and open it.

```
1. describe('Testing Wikipedia', () => {
2.   it('A user can switch languages', () => {
3.     cy.visit('https://wikipedia.org');
4.     cy.contains('Read Wikipedia in your language');
5.     cy.get('#js-lang-list-button').click();
6.     cy.contains('Yorùbá').click();
7.     cy.url().should(
      'equal', 'https://yo.wikipedia.org/wiki/Oj%C3%BAew%C3%A9_%C3%80k%E1%BB%8D%CC%81k%E1%BB%8D%CC%81',
    );
8.     cy.contains('Ẹ kú àbọ̀');
9.   });
10. });
```
Now let’s talk about some Cypress-specific syntax.

On line 3, we’re simply visiting Wikipedia’s homepage. On line 4, we assert that we’re on the page we want to be on by confirming that the page contains the text “*Read Wikipedia in your language.*”

On line 5, we query the language switcher button by its id and we simulate a click on it. I know the id because I inspected it in Chrome’s dev tools. This brings me to an important concept in writing Cypress tests: there are multiple ways to select a DOM element on Cypress. You can do it by targeting its id, its class, or even its tag type.

In this particular test, we’re targeting the button’s id, but in our previous test, we targeted the tag name and attribute. You can read about the different ways of selecting a DOM element [here](https://docs.cypress.io/api/commands/get.html#Syntax).

On line 6, we encounter another common Cypress command, which you’ll notice shows up a lot in tests. We assert that there’s an element with the text “Yorùbá” on the DOM, and then we simulate a click on it.

This action will cause Wikipedia to redirect you to the appropriate domain for the language you selected. In our case, we selected the Yorùbá language from West Africa, and we can confirm that we were redirected to the correct page by looking at the current page’s URL.

On line 7, we do exactly that. By calling `cy.url()` we get the URL of the current page as text and then we assert that it should equal the appropriate domain for the Yorùbá language.

On line 8, we have an extra optional check to see if there is any content on the page in the Yorùbá language.

*Bonus fact: Ẹ kú àbọ̀ means “Welcome” in the Yorùbá language and is pronounced: Eh — Koo — AhBuh.*

Run the test the same way we ran the previous one, and it should pass.

### Test 3 — A user can check the definition of a word on Wiktionary
__User story__
When a user visits the homepage and clicks on the link to Wiktionary, then the user should be redirected to wiktionary.org.

When a user on wiktionary.org searches for a definition by typing in the search bar and hits enter, then the user should be redirected to a page with the definition of that search term.

Another straightforward user story. We want to check for the definition of the word “Svelte” on Wiktionary, but we’ll start off on Wikipedia’s homepage and navigate to Wiktionary before searching for the word.

Inside the `/integration` folder, create a new file named `homepage_search_definition.js` and open it.

```
1. describe('Testing Wikipedia', () => {
2.   it('A user can search for a word', () => {
3.     cy.visit('https://wikipedia.org');
4.     cy.get('.other-project-link')
5.       .eq(2)
6.       .click();
7.     cy.url().should('equal', 'https://www.wiktionary.org/');
8.     cy.get('#searchInput').type('Svelte{enter}');
9.     cy.contains('Etymology');
10.    cy.contains('svelte');
11.   });
12. });
```
Let’s walk through this test the same way we did the previous one.

On line 3, we visit Wikipedia’s homepage as usual. On line 4, we target a class name, pick the third element with the class (don’t forget that indices start at 0), and simulate a click on the element.

Before we move further, a little caveat: if your code relies on autogenerated CSS classes, targeting elements by class names might result in inconsistent test results. In those cases, targeting by id or tag type and attribute would be the way to go.

On line 7, we assert that we’re on the correct domain by checking the URL using `cy.url()`.

Another caveat: If you’re testing your own app, the need to navigate to another domain may be rare, and it’s for this reason this test would fail if we didn’t add `"chromeWebSecurity": false` in our `cypress.json` config.

On line 8, we target the search input by its id, and then we simulate a change event by typing in “Svelte” and hitting the enter button (hitting the enter button is handled by "{enter}"). This action takes us to a new page with the result of our query.

We then confirm on lines 9 and 10 that we’re on the correct page by asserting that the words “Etymology” and “svelte” can be found on the page.

Run the test the same way we ran the previous one and marvel at your newfound skill!

## Conclusion
You’ve seen how easy it is to verify the correctness of your web app by writing simple e2e tests using Cypress. We’ve barely scratched the surface of what Cypress can do and some of the features it provides.

For example, you can see screenshots of your tests and even watch recorded videos by looking under `cypress/videos`. You can even define custom commands to avoid code repetition, mock API response data using fixtures, etc.

Having well-written end-to-end tests can save you hours of development time and can help you catch bugs and unexpected behaviours before you merge into production. Get started by going through the [Cypress docs](https://docs.cypress.io/guides/overview/why-cypress.html) and playing around until you get comfortable enough to start writing live tests.

Get started writing your first frontend end to end test so that you can catch bugs early and ship error-free features.

cypress-feature-image

End to end testing using Cypress.js

This is going to be the first in a series of articles covering the various concepts in data structures and their implementation in TypeScript.

Data Structures are an integral part of software development. Having a solid foundation in data structures will allow you to pick the right tool for the job as some structures are better suited for some use cases than others.

The Node is one of the most fundamental data structures in the sense that it is the building block for many other ones and that is why we’ll be looking at it first.

## What is a Node in Data Structures?
A Node put simply, is a data structure that contains some kind of data, and a pointer (or link) to another Node. Think of it as a small box with two compartments. One compartment holds the content and the next compartment holds a reference to another box just like it.

![node-representation](//images.ctfassets.net/6qz05ishztgm/2Prb6oKIFsC4BXI82Q9MF7/2ffa086b7983c3f74810525482c0eae7/node-representation.png)
*A visual representation of a Node*

When a Node is being used in another data structure, the other box being linked to is usually (but not always) the very next Node in the structure.

There are some cases where a Node can hold two links to other Nodes, i.e, the previous Node that came before it, and the next Node after it. To keep it simple though, we’re going to limit it to just one link (the next Node) for now.

How would you store the following todo list using only Nodes?

- Watch Netflix
- Hit the gym
- Cook dinner

Since the list is in a sequence, we could create three Nodes, and store each of the items in the Nodes as the data.

And then to link them together, we’d start with the first Node which contains the first item (Watch Netflix) and set its link to point to Node 2 (Hit the gym), and then set Node 2’s link to point to Node 3.

It would look something like this:
![node-list](//images.ctfassets.net/6qz05ishztgm/4dt9v42CnbGOe3JbCj1sOo/dd3a460f578dd7b747e713ebd8df842d/node-list.png)
*A visual representation of a Node list*

## How to Implement a Node in TypeScript
We have the theory down so it’s time to implement it. We’ll create a Node class using TypeScript following these constraints:

- A Node can hold a data
- A Node can point to another Node
- A Node’s data can be accessed and updated
- A Node’s pointer can be accessed and updated

First, we’ll create a simple class with a constructor that takes in the data to hold. By default, this Node’s pointer will be set to null.

```
class Node {
  constructor(data: any) {
    this._data = data
    this._pointer = null
  }
}
```
We’ll then add some methods to this class to enable us to access the data and update it.

```
class Node {
  constructor(data: any) {
    this._data = data
    this._pointer = null
  }

  getData() {
    return this._data
  }

  setData(newData: any) {
    this._data = newData
  }
}
```
Time for the pointer. We want to be able to set the pointer to another Node and also to retrieve the Node from the pointer.

```
class Node {
  constructor(data: any) {
    this._data = data
    this._pointer = null
  }

  getData() {
    return this._data
  }

  setData(newData: any) {
    this._data = newData
  }

  setPointer(node: Node) {
    this._pointer = node
  }

  getNodeAtPointer(): Node {
    return this._pointer
  }
}
```
And that’s basically it. As I said, Nodes are really simple but they provide the foundation for more complex data structures like Queues, Linked Lists, etc.

Next, we’ll be looking at how to implement a Linked List using this Node class we created.

Goodbye and Happy Coding 🙂

Learn how to implement a simple Node data structure using TypeScript. The first in a series of post about implementing data structures using TypeScript.

nodes-feature-image

Nodes in Data Structures – TypeScript

TypeScript: love it or hate it, you can’t deny the fact that it’s spreading like wildfire. In fact, according to the Stack Overflow 2019 developer survey, it was listed as the [third most-loved programming language](https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-languages "Survey of the most loved programming languages by StackOverflow") and the fourth most-wanted.

Now whether the survey accurately represents real-world sentiments is up for debate, but the fact remains that TypeScript is here, and it has come to stay. It’s so pervasive now that it has replaced vanilla JavaScript as the language of choice for many packages in the JS ecosystem, with some like [Yarn even going as far as rewriting their entire codebase in TypeScript](https://github.com/yarnpkg/yarn/issues/6953 "Link to Yarn's Github Issues page").

I feel one of the reasons for this meteoric rise to success has to be the fact that TypeScript, in essence, is just JavaScript. This makes the entry bar a lot lower for existing JavaScript developers, and the fact that it’s typed may also attract other devs who prefer the features typed languages provide.

This cuts both ways, too, because the ease of picking up TypeScript has led to some cases where the language is not being utilized as effectively as it could be. Many developers still write TypeScript like they’re writing JavaScript, and this brings with it some disadvantages.

We’ll be looking at some real-world code written in TypeScript that could be improved to make better use of the language’s strengths. This is by no means an exhaustive list, and I welcome you to list some you might have noticed in the comments section below.

Some of these examples involve React because I’ve noticed some instances where React code could be improved by simply making use of some TypeScript features, but the principles are by no means limited to React. Let’s dive in.

__*NOTE: Many code snippets in this article have been taken from real-world projects and anonymized to protect their owners.*__

## Interface neglect
Let’s start with one of the most useful features of TypeScript: interfaces.

[In TypeScript, an interface](https://www.typescriptlang.org/docs/handbook/interfaces.html "Link to TypeScript docs") simply specifies the expected shape of a variable. It’s as simple as that. Let’s look at a simple interface to drive the point home.

```
interface FunctionProps {
  foo: string;
  bar: number;
}
```
Now if any variable is defined to implement `FunctionProps`, it will have to be an object with the keys `foo` and `bar`. Any other key addition will make TypeScript fail to compile. Let’s look at what I mean.

```
const fProps: FunctionProps = {
  foo: 'hello',
  bar: 42,
}
```
Now we have an object `fProps` that implements the `FunctionProps` interface correctly. If I deviate from the shape specified in the interface by, say, writing `fProps.foo = 100` or deleting `fProps.bar`, TypeScript will complain. `fProps`'s shape has to match `FunctionProps` exactly or there will be hell to pay.

```
fProps.foo = true ❌ // foo must be a string
``` 
Now that we’ve gotten that out of the way, let’s look at an example. Take this React functional component method:

```
const renderInputBox = (props, attribute, index) => {
  return (
    <div key={index} className="form-group">
      {renderLabel(attribute)}
      <InputBox
        name={attribute.key}
        value={!!isAssetPropAvailable(props, attribute) && props.inputValue}
        onChange={props.handleInputChange}
        placeholder={`Enter ${attribute.label}`}
      />
    </div>
  );
};
```
While this is completely fine if you were writing JavaScript, it doesn’t take advantage of interfaces. Why is this bad? For one, you don’t get any IntelliSense features that you otherwise would if the method’s arguments were typed.

Also, you could easily pass in a prop of a different expected shape to this method and you would be none the wiser because TypeScript would not complain about it.

This is just vanilla JS, and you might as well eliminate TypeScript from the project altogether if everything was written like this.

How could we improve this? Well, take a look at the arguments themselves, how they’re being used, and what shape is expected of them.

Let’s start with `props`. Take a look at line 7 and you can see that it’s supposed to be an object with a key called `inputValue`. On line 8, we see another key being accessed from it called `handleInputChange`, which, from the context, has to be an event handler for inputs.

We now know what shape props is supposed to have, and we can create an interface for it.

```
interface PropsShape {
  inputValue: string;
  handleInputChange: (event: React.FormEvent): void;
}
```
Moving on to `attribute`, we can use the same method to create an interface for it. Look at line 6. We’re accessing a key called `key` from it (hint: it’s an object). On line 9, we’re accessing another key from it called `label`, and with this information, we can go ahead and create an interface for it.

```
interface AttributeShape {
  key: string;
  label: string;
}
```
We can now rewrite the method to look like this instead:

```
const renderInputBox = (props:PropsShape, attribute:AttributeShape, index:number) => {
  return (
    <div key={index} className="form-group">
      {renderLabel(attribute)}
      <InputBox
        name={attribute.key}
        value={!!isAssetPropAvailable(props, attribute) && props.inputValue}
        onChange={props.handleInputChange}
        placeholder={`Enter ${attribute.label}`}
      />
    </div>
  );
};
```
Is it more code to write? Yes. But consider the benefits of doing this:

- You get IntelliSense wherever you use this method, and you can instantly see what its arguments are supposed to look like without having to look at it.
- You can never misuse this method because TypeScript will not allow you to pass in arguments with wrong shapes.
- Any change to the method definition — maybe index is now a string — and TypeScript will prevent your code from compiling until you fix all the instances where the method was used.

Why use TypeScript in the first place if you don’t care about these benefits?

## Any abuse

The type `any` is a fantastic way for you to migrate an existing JavaScript project gradually to TypeScript.

Why is this? Well, if you type a variable as `any`, you’re telling TypeScript to skip type-checking it. You can now assign and reassign different types to this variable, and this allows you to opt-in and out of type checking when necessary.

While there may be other use-cases for using `any`, such as when you’re working with a third-party API and you don’t know what will be coming back, it is definitely possible to overuse it and, in effect, negate the advantages of TypeScript in the process.

Let’s take a look at a case where it was definitely abused.

```
export interface BudgetRequiredProps {
  categoryDetails?: any[];
  state?: any;
  onInputChange?: (event) => void;
  toggleSubCategory?: (type: any) => any;
  displaySubCategory?: () => any[];
}
```
This interface breaks my heart. There are legitimate use cases for `any`, but this is not one of them.

For instance, take a look at line 2, where we’re basically specifying an array that can hold content of any type. This is a bomb waiting to explode wherever we’re mapping over categoryDetails, and we don’t account for the fact that it may contain items of different types.

NOTE: If you need to work with an array that contains elements of different types, consider using a [Tuple.](https://www.typescriptlang.org/docs/handbook/basic-types.html#tuple)

Line 3 is even worse. There is no reason why `state`'s shape should be unknown. This whole interface is basically doing the same thing as vanilla JS with regards to type checking, i.e, absolutely nothing. This is a terrific example of interface misuse.

If you have ever written an interface like this in production code, I forgive you, but please do not let it happen again. Now, I went through the codebase where this example was plucked from to look at the expected shapes of the variables, and this is how it should look:

```
export interface BudgetRequiredProps {
  categoryDetails?: CategoryShape[];
  state?: string | null;
  onInputChange?: (event: React.FormEvent) => void;
  toggleSubCategory?: (type: string) => boolean;
  displaySubCategory?: () => CategoryShape[];
}
```
Much better. You get all the advantages of using TypeScript without changing the interface too much. Now let’s take a look at where using any actually makes sense.
```
export interface WeatherPageProps {
  getCurrentWeatherStatus: (city: string): Promise<any>;
  handleUserUpdate: (userContent: any): Promise>any>;
}
```
Why is this a valid use case for `any`?

Well, for one, we’re working with an external API. On line 2, we’re specifying a function that makes a fetch request to a weather API, and we don’t know what the response should look like; maybe it’s an endpoint that returns dynamic data based on certain condition.

In that case, specifying the return type as a promise that resolves to any is acceptable.

*__NOTE: This is not the only approach to working with dynamic data. You could specify all the possible values coming from the endpoint in the interface and then mark the dynamic fields as optional.__*

On line 3, we’re also working with a function that takes in a prop that is dynamic in content. For instance, say `userContent` comes from the user, and we don’t know what the user may type. In this case, typing `userContent` as any is completely acceptable.

Yes, there are valid use-cases for the `any` type, but please, for the love of TypeScript, avoid it as much as you possibly can without ruining the developer experience.

## Index signature misuse

Now, this is a very subtle mistake I see quite a lot in React code where you may need to map over an object and access its properties dynamically. Consider this example:

```
const obj = {
  gasoline: 'flammable',
  sauce: 'hot',
  isTypeScriptCool: true,
}

Object.keys(obj).forEach(key => console.log(obj[key])) // 'flammable', 'hot', true
```
The above example will not cause an issue with vanilla JavaScript, but the same is not true in TypeScript.

```
interface ObjectShape {
  gasoline: string;
  sauce: string;
  isTypeScriptCool: boolean;
}

const obj: ObjectShape = {
  gasoline: 'flammable',
  sauce: 'hot',
  isTypeScriptCool: true,
}

Object.keys(obj).forEach(key => console.log(obj[key])) // ❌ you can't just do this
```
The reason you can’t just do that is because of type indexing.

In TypeScript, you need to specify how an interface should be indexed into by giving it an index signature, i.e, a signature that describes the types we can use to index into the interface, along with the corresponding return types.

*__A quick refresher: indexing into an object looks like `obj['sauce']` or `obj.gasoline`__*

We didn’t tell TypeScript what index signature `ObjectShape` should have, so it doesn’t know what to do when you index into an object that implements it as we do on line 13. But how does this concern React?

Well, there are cases where you might need to iterate over a component’s state to grab certain values, like so:

```
interface ComponentState {
  nameError: string;
  ageError: string;
  numOfFields: number;
}

this.state: ComponentState = {
  nameError: 'your name is too awesome',
  ageError: 'you seem immortal',
  numOfFields: 2,
}

Object.keys(this.state).forEach(err => this.handleError(this.state[err]));
```

This is a very common operation in React, but you can see how we may run into a problem on line 13. We’re indexing into `this.state`, but the interface it implements doesn’t have an index signature. Oops.

But that is not even the mistake I’m talking about, and I’ll get to it in a moment. To fix the warning TypeScript throws, you might update the state’s interface like so:

```
interface ComponentState {
  nameError: string;
  ageError: string;
  numOfFields: number;
  [x: string]: any;  // index signature added
}
```

Before we continue, it’s worth noting that, by default, adding an index signature to an interface also means you will be able to add new values that do not exist in the interface to any variable that implements it.

This will successfully get rid of the error, but now you’ve introduced a new side effect.

This is the equivalent of telling TypeScript that when `ComponentState` is indexed with a string, it should return a value of type `any` (basically all possible types). This could cause issues if `this.handleError` was not expecting anything apart from a string or a number.

But more importantly, you can now add a new property with ANY type to whichever variable implements the interface, which, in our case, is `this.state`. So this becomes valid:

```
this.state['shouldNotBeHere'] = { bugs: 1, dev: 0 }
```
Now that is the mistake I am talking about. How do we fix it, though? Well, there are actually two things we need to look out for:

- We want to specify all possible index return types in the object, but no more (no any)
- We don’t want to be able to add new values to an object because of indexing

So, in most cases, the proper way to fix our initial issue (indexing into an object without TypeScript complaining) would be to do this:

```
interface ComponentState {
  nameError: string;
  ageError: string;
  numOfFields: number;
  readonly [x: string]: string | number;
}
```
OK, so here’s what this piece of code is saying:

Hey, TypeScript, I would like to be able to index into this interface with a string, and I should get either a string or a number back. Oh, and please don’t let me add any other thing to any object that implements this interface that I didn’t explicitly specify.

By simply specifying the index signature return values, we’re able to solve our first issue, and by marking it as `readonly`, we’re able to solve the second issue. Please watch out for this subtle issue when writing TypeScript code.

## Conclusion

TypeScript is a wonderful way to write type-safe JavaScript, but you have to do it right. It’s possible to write TypeScript in a way that just causes headaches with no real benefit, but thankfully, that can be easily solved by taking the time to learn the gotchas of the language.

I hope you were able to learn one or two things from this article, and if you have some examples you’d like to share, please add them in the comment section below so that others can benefit.

Goodbye and happy coding ❤️.


Discover common pitfalls in the way we use TypeScript and learn to maximize your productivity by using the language's features properly. 

how-to-write-better-typescript-feature-img

How to write better TypeScript

That title is a bit dramatic, but then again, so is Svelte and the idea behind it. If you don't know what Svelte is yet, then strap in — you're about to witness a revolution, and it's going to be quite the ride (no pressure on the Svelte team 😅).

Note that this is not a tutorial on how to get started with Svelte. There is already a great step-by-step interactive tutorial by the Svelte team that eases you into the world of reactive programming.

__Disclaimers are in order:__ If I say something that sounds stupid in this article, please let me know.

Alright, let's get into it!

## But first, React
Before I get into why I think Svelte is so disruptive, let's take a look at this tweet from the man, [Dan](https://twitter.com/dan_abramov "Link to Dan Abramov's Twitter profile"), from a while back and dissect what it actually means:

https://twitter.com/dan_abramov/status/1025801430668664833

__Yet another disclaimer:__ This article is not meant to bash React in any way. I simply decided to use React as a case study because most people who read this article will have used it at one point or another. It’s just the best example to contrast Svelte against.

What did Dan mean, and what effect does this have on the way we currently write code? To answer this question, let me give you a simplififed view of how React works behind the scenes.

When you render a React app, React keeps a representation of the DOM in something called the [Virtual DOM.](https://reactjs.org/docs/faq-internals.html "Link to React's Virtual DOM explanation in the React Documentation") The Virtual DOM acts as a middleman of sorts between your React code and what your browser paints on the screen.

Then, when your data changes (maybe you called `this.setState`), React does a bit of work to determine how to repaint your UI on the screen.

It compares the Virtual DOM against the real DOM to determine what changed due to this data update. It then repaints only the parts of the DOM that do not match the new copy in the Virtual DOM, eliminating the need to repaint the whole DOM every time there's a data update.

While the Virtual DOM is very fast compared to other alternatives, it's still an extra layer of complexity that the browser has to deal with along with the actual DOM updates.

Another thing you might have noticed is that if you don't notify React that your data has changed (i.e, by calling `this.setState`), your Virtual DOM will not change, and React will not react (ba dum tss! 🤓).

This is what Dan meant when he said React isn't fully reactive. React is relying on you to track your app's data and to tell it when there are updates. This is more work for you to do and yes, there's a better way.

## OK, now Svelte
Svelte is a whole new way of building UI in a blazingly fast, efficient, and truly reactive manner, all without using a virtual DOM in fewer lines of code that you'd write with any other framework/library.

That sounds all nice and good, but how is it different from the myriad of other JavaScript frameworks/libraries out there, you ask? I'll tell you.

### 1. True Reactivity
Svelte is not a library. Svelte is not a framework. Rather, Svelte is a compiler that takes in your code and spits out native JavaScript that interacts with your DOM directly with no need for an intermediary.

Wait, what? A compiler? Yes — a compiler. It’s such a good idea that I don’t know why it wasn’t so obvious until now, and I’ll tell you why I think it’s so cool.

Here's a quote from [Rich Harris' talk at the YGLF 2019 conference:](https://www.youtube.com/watch?v=AdNJ3fydeao "Link to Rich Harris' talk at the YGLF 2019 conference on YouTube")

> Svelte 3.0 moves reactivity out of the component API and into the language.

What does that mean? Well, we've seen how React (and most other frontend frameworks) requires you to use an API to tell it that data changed (`this.setState`) before it knows to rerender.

This need to call `this.setState` means that the reactivity of your app is tied to a specific API, without which, it would be completely unaware of data changes.

Svelte takes another approach to solving this problem.

It has taken inspiration from [Observable](https://observablehq.com/ "Link to Observable HQ's homepage") in the way it runs your code. Instead of running your code top to bottom, it runs it in topological order.

Look at the snippet of code below, and we'll go through what it means to run code in topological order.

```
(() => {
  const square = num => num * num
  
  const secondNumber = square(firstNumber)
  const firstNumber = 42
  
  console.log(secondNumber)
})()
```
If this code was parsed top to bottom, `const secondNumber = square(firstNumber)` would throw an error because at this point, `firstNumber` has not been defined yet.

However, running the code in topological order would not result in any errors. How is this? Well, the compiler wouldn't run this code from top to bottom. Rather, it would take a look at all the variables first and generate a dependency graph (i.e who needs who first).

In this case, here's an extremely simplified look at how a compiler would compile this code topologically.

```
1 - Does this new variable 'square' depend on any other variable?
  - it doesn't so I'll parse it
  
2 - Does this new variable 'secondNumber' depend on any other variable?
  - it depends on 'square' and 'firstNumber'. I already initialised
    sqaure but I haven't initialised 'firstNumber' which I will do now
    
3 - Ok, I've initialised 'firstNumber'.
    Now I can initialise 'secondNumber' using 'square' and 'firstNumber
  - Do I have all the variables required to run this console.log  statement?
  - Yes, so I'll run it.
```
At first glance, it seems that the code is being parsed top to bottom, but take a closer look and you'll discover that it actually does some jumping around.

When it gets to line 4, the compiler discovers that it doesn't have `firstNumber` so it pauses the execution there and looks ahead in your code to see if you defined it anywhere. Well, we did exactly that on line 5, so it runs line 5 first before going back to line 4 to execute it.

> TL;DR If statement A depends on statement B, then statement B will run first regardless of the order of declaration.

So how does this apply to the way Svelte implements reactivity?

You can label a statement with an identifier in JavaScript, and that operation looks like this:

`$: foo = bar`.

All that does is add an identifier called `$` to the `foo = bar` statement (note that this would fail in strict mode if `foo` wasn't defined earlier).

So in Svelte's case, whenever it sees a statement prefixed with `$:`, it knows that the variable on the left derives it value from the variable on the right. We now have a way of binding one variable's value to another's.

This means that we're now using a core part of JavaScript's API to achieve true reactivity instead of relying on third-party APIs like `this.setState`.

This is how it looks like in practice:
```
// vanilla js
let foo = 10
let bar = foo + 10 // bar is 20
foo = 15 // bar is still 20 (no reactivity)

// svelte js
let foo = 10
$: bar = foo + 10 // bar is 20
foo = 15 // bar is now 25 because its value is derived from foo's value
```
Notice how in the code above, we didn't need to reassign bar to the new value of `foo` — either by doing it directly like `bar = foo + 10` or by calling an API like `this.setState({ bar: foo + 10 })`. It is handled automatically for us.

This means that when you change `bar` to equal 15, `foo` is updated to be 25 automatically, and you don't need to call an API to update it for you. Svelte already has your back.

The compiled version of the Svelte code above looks like this:
```
... omitted for brevity ...
function instance($$self, $$props, $$invalidate) {
  let foo = 10; // bar is now 20
  $$invalidate('foo', foo = 15) // bar is now 25 because it is bound to the value of foo
  let bar;

  $$self.$$.update = ($$dirty = { foo: 1 }) => {
    if ($$dirty.foo) { $$invalidate('bar', bar = foo + 19); }
  };

  return { bar };
}
... omitted for brevity ...
```
Take your time to really study this piece of code above. Really take your time.

Do you see how the update on `foo` happened before `bar` was even defined? That’s because the compiler is parsing the Svelte code in topological order instead of a strictly top-down order.

Svelte is reacting on its own to data changes. It doesn’t want you to worry about tracking what changed and when; it knows automatically.

__Note:__ On line 4, `bar`'s value is not updated until after the next [Event Loop](https://www.youtube.com/watch?v=8aGhZQkoFbQ "A link to a YouTube video on the Event Loop") so that performance is not negatively affected.

This allows you to stop worrying about manually updating your state whenever your data changes. You can focus on your logic all day while Svelte helps you to reconcile your UI with your latest state.

### 2. Brevity
Remember how I said Svelte allows you to do so much with fewer lines of code written? I meant it. I’ll show you a simple component in React and its equivalent in Svelte, and you judge for yourself:

![svelte vs react](//images.ctfassets.net/6qz05ishztgm/42iAL6aUmJX1zKMX0nnpPA/2e72b2909f2f0eeba11d78d49e81b4f8/svelte_vs_react.png)

These two apps are completely identical in functionality but you can see how much more code we had to write in React — and don’t even get me started on Angular 😂.

![react vs svelte result](//images.ctfassets.net/6qz05ishztgm/6etNwlk1UhiwOKWsfJdxQl/859703be45d000b6f5caa46482ee29a6/react_vs_svelte_result.png)

Apart from the Svelte code being more pleasing to the eye, it is also much easier to reason about as there are less moving parts than in the React code. We didn’t need an event handler to update the value of the input element — simply binding the value was enough.

Imagine you were just starting out learning web development. Which code would have confused you more? The one on the left, or the one on the right?

While this might seem like a trivial point to make, it quickly becomes clear how useful it is to write fewer lines of code when you start to build bigger and more complex apps. I’ve personally found myself spending hours trying to understand how a large React component my teammate wrote works.

I honestly believe that Svelte’s simplified API will allow us to read and understand code much faster, improving our overall productivity.

### 3. Performance
So we've seen how reactive Svelte is and how it allows you to do more with less. What about performance? What is the user experience like with apps written entirely in Svelte?

One of the reasons React is so powerful is because of how it uses the virtual DOM to minimize how much it updates the real DOM.

A downside to this approach, though, is that if a component's data changes, React will re-render that component and all its children whether they need to re-render or not. This is why React provides APIs like `shouldComponentUpdate`, `useMemo` etc.

This problem is not specific to React. Any framework/library that utilises some sort of a virtual DOM will suffer from this issue.

Svelte, on the other hand, doesn't use a virtual DOM. So how does it tackle the issue of matching your app's UI to it's state? Let me quote Rich Harris again from his wonderful YGLF talk:

> Frameworks are not tools for organising your code. They are tools for organising your mind.

The quote above is what led Rich to the idea that a framework could be something that runs in a build step, eliminating the need for your code to have an intermediary at runtime. This idea is why Svelte is a compiler and not a framework.

That simple idea is why Svelte is really fast. Svelte compiles your code down to an efficient, low-level code that interacts with the DOM directly. This is all well and good, but how does Svelte solve the issue of repainting the whole DOM when data changes?

The difference lies in the way a framework like React knows what changed versus how Svelte does the same thing. We’ve seen how React relies on you to call an API method to tell it when your data changes, but with Svelte, simply using the assignment operator `=` is enough for it.

If a state variable — let’s say `foo` — is updated using the `=` operator, Svelte will only update the other variables that depend on foo, like we saw earlier. This allows Svelte to only repaint the parts of the DOM that derive their value in one way or another from `foo`.

I’m going to leave out the actual implementation of how this works because this article is already long enough. You can [watch Rich Harris himself explain that.](https://www.youtube.com/watch?v=AdNJ3fydeao "Link to Rich Harris' YGLF talk on YouTube")

## Final Thoughts
Svelte 3.0 is one of the best things to happen to software development in a while. Some may say that that is an exaggeration, but I disagree. The concept behind Svelte and its execution will enable us to do more while shipping less boilerplate JS to the browser.

This, in turn, will allow for apps that are more performant, more lightweight, and produce code that is easier to read. Now, will Svelte be replacing React, Angular, or any of the other established frontend frameworks anytime soon?

For now, I can say the answer is no. Svelte is relatively new compared to those, so it needs time to grow, mature, and sort out some kinks we might not even know exist yet.

Just like React changed software development when it came out, Svelte, too, has the potential to change how we think about frameworks and what is possible when we create new boxes to think in.

Happy coding!

Learn how Svelte moves reactivity from an API into the JavaScript language itself.

❖ My articles on JavaScript and React