## Introduction

The past few months have not been easy for anyone. I hope everyone and their families stay healthy.

To support the company’s new initiative, drive down our user acquisition costs, our engineering team was asked to come up with a solution to improve SEO (organic search result).

Ideally, we want to find a solution that supports Server-Side rendering and provides decent web performance. Out existing apps are created as a Single Page App that handles all the page rendering on the client-side and First Contentful Paint takes too long to happen due to the amount of JavaScript shipped to browsers. We decide to give Next.js a try given that it provides Server-Side Rendering out of the box and SSR should improve the page loading speed by reducing the workload in the browser. However, the path is not so straightforward. I want to share a few issues and obstacles I encounter while building our Next.js app.

## There Is No Window

As developers who work with Javascript and Browsers every day, there are certain things we usually take for granted. It is in our subconscious that `window` object is always there when we need them. It is not the case for Next.js. `window` object is part of Browsers' web API instead of part of core JavaScript. For SSR, Next.js makes the initial render on the server-side in Node.js, where `window` object is not available. 

*__Takeaway__*

For our source code that uses `window` or anything that comes from Web API, we will check if the object exists before calling it.

```javascript
if (typeof window !== 'undefined') {
  window.addEventListener('NAV_LOADED', () => handleInitNavData());
  window.addEventListener('resize', refreshNavHeight);
}
``` 

For components we only want to render on the client-side, we can use [Dynamic Import](https://nextjs.org/docs/advanced-features/dynamic-import). `ssr: false` make sure the component is not server-side rendered.

```javascript
import dynamic from 'next/dynamic';
...

const Footer = dynamic(import('../../components/ui/Footer/Footer'), {
  ssr: false,
});
```

Packages from `node_module` cannot be handled this way. Unfortunately, we either have to change the way we use the library, or we have to replace it with a new one. One example of the first situation is `react-media`, we had to depend on user agent from the request to provides a semi-reliable default value so it knows the default screen size.

## Where Is The Environment Variable

Isn't it just `process.env.MY_THING`? Yes, but that's not all. Next.js provides 3 different types of environmental variables. 

```javascript
const globalConfig = {
  env: {
    ASSET_PATH: isDevelopment ? '' : 'https://cdn.cloudfront.net/',
  },
  publicRuntimeConfig: {
    SEGMENT_ID,
  },
  serverRuntimeConfig: {
    CACHE,
  },
};
```

__[env](https://nextjs.org/docs/api-reference/next.config.js/environment-variables)__: It replaces the value at __build time__. `process.env.ASSET_PATH`  will be replaced by `https://cdn.cloudfront.net/` when we try to make a production build

__[publicRuntimeConfig & serverRuntimeConfig](https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration)__: There are runtime variables, Next.js provides an good example of them.

```javascript
import getConfig from 'next/config'

// Only holds serverRuntimeConfig and publicRuntimeConfig
const { serverRuntimeConfig, publicRuntimeConfig } = getConfig()
// Will only be available on the server-side
console.log(serverRuntimeConfig.mySecret)
// Will be available on both server-side and client-side
console.log(publicRuntimeConfig.staticFolder)

function MyImage() {
  return (
    <div>
      <img src={`${publicRuntimeConfig.staticFolder}/logo.png`} alt="logo" />
    </div>
  )
}

export default MyImage
```

*__Takeaway__*

Be mindful of how we use those variables and assign them to the correct places. Build time variables will not be available during runtime. Don't expose more than you need in the public runtime config. After knowing the differences between those three, common sense works best here.

## No Free Cookies

I had a problem when I started working data fetching in the Next.js app. I have this code that making `GET` a request to get user information. However, the request failed to authenticate the user  in `getServerSideProps`.  

```javascript
// Fetch user context
async function fetchUser(req: IncomingMessage): Promise<UserContext | null> {
  let userContext: UserContext | null = null;
  try {
    // our custom API helper uses fetch internally
    userContext = await ApiService.get(
      `${process.env.WEB_HOST}/web-api/user/get`,
      {}, // params
    );
  } catch (error) {
    console.error('Unable to load user context', error);
  }
  return userContext;
}

export const getServerSideProps: GetServerSideProps = async ({ req }) {
  const userCtx = await fetchUser(req);
  return {
    props: {
      userCtx,
    },
  };
}
```

*__Takeaway__*

We have to manually pass cookies to the request that is sent to our endpoints.

__For Next.js Server__:

```javascript
await ApiService.get(
  `${process.env.WEB_HOST}/web-api/user/get`,
  {}, // params
  {
    // adding cookie to the new request
    cookie: req.headers.cookie,
  }
);
```

## Other Things

- Global stylesheet can only be added to `_app.js`. Next.js automatically use scoped CSS (CSS Module) for components. [Next.js - Built-In CSS Support](https://nextjs.org/docs/basic-features/built-in-css-support#adding-a-global-stylesheet)
- `assetPrefix` only applied on generated assets (JS, CSS, JSON...), It has no no effect whatsoever on the assets (images, fonts...) in `public` folder. [Next.js - CDN support](https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix) 
- To organize our code better, we are able to move all our source code under `src/...`. [Next.js - Src directory](https://nextjs.org/docs/advanced-features/src-directory)


## Final Thoughts

We like Next.js a lot. It does most things right out of the box. We have already started migrating SEO focus pages into this new Next.js app, and it has been great. On the other hand, we still haven't found solutions to integrate certain Next.js features, such as [Incremental Static Regeneration](https://nextjs.org/blog/next-9-5#stable-incremental-static-regeneration), into our infrastructure.  If you have recently started looking into Next.js like me, I hope this post saves you some time and Googling. 

Next.js: Not So Straightforward Path To Production

## Introduction
The complexity of our web applications has grown drastically. Fixing bugs is part of the daily life of a developer. Luckily, there is a set of tools that can help us avoid some of the most common bugs and improve the overall developer experience.

This article will introduce a list of tools that I have used at work.

* [ESlint](https://eslint.org/)
* [Prettier](https://prettier.io/)
* [TypeScript](https://www.typescriptlang.org/)
* [husky](https://github.com/typicode/husky)
* [lint-staged](https://github.com/okonet/lint-staged)

***This article is inspired by the awesome [Kent C. Dodds 🧢](https://twitter.com/kentcdodds)**


## ESlint
ESlint is a well-known tool that statically analyzes the code and finds problems. It can fix many of those problems automatically so we as developers don’t have to spend precious time fixing those problems in the future. ESlint is also highly customizable, developers have the ability to customized the rules to support different coding styles. 

To get started, we can create a new file `.eslintrc` with something like this.
```json
{
  "parserOptions": {
    "ecmaVersion": 2019,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "extends": ["eslint:recommended"],
  "rules": {
    "strict": ["error", "never"]
  },
  "env": {
    "browser": true
  }
}

```

`parserOptions`: By default, ESlint expects ES5 syntax. Since most of the modern application is written in newer ECMAScript version and compile into ES5 using Babel TypeScript Compiler, we need to override the parser options to support our source code. In the example config, we want ESlint to use ES10 syntax and enable the support for ES Modules and JSX.
`extends`: Instead of defining all the rules, we use `eslint:recommended` rule set as our starting point. 
`rules`: We can add any additional rule as needed and it will override the same rules defined in `extends`.
`env`: We also want ESLint to be aware that our code is meant to execute in the browser environment. So ESlint will not throw any error for any browser-specific code/syntax such as `console.log`.

## Prettier
A well-formatted code base with consist code format is much easier to understand but developers don’t want to waste their precious time to formatting code. There is where Prettier comes into play.

Once we installed the Prettier package, we can simply play around with the config we want on [Prettier Playground](https://prettier.io/playground/) and copy the config JSON to `.prettierrc`. We can simply use Prettier as npm script. `--write` write will format the source files that match the string pattern. `--list-different` will tell if any files will be formatted. We can think of it as Prettier’s dry-run option.

```json
"scripts": {
  "prettier": "prettier \"**/*.+(js|json)\"",
  "format": "npm run prettier -- --write",
  "check-format": "npm run prettier -- --list-different",
}
```

Since Prettier will format the source, we can turn off some of ESlint rules that will not occur, we can install `eslint-config-prettier` and put it at the end of `extends` config. `”extends”: [“eslint:recommended”, “eslint-config-prettier”]`

Prettier has decent IDE/Editor integration which allows auto code format on-save. Here are the most common ones.

[VSCode Integration · Prettier](https://prettier.io/docs/en/editors.html#visual-studio-code)

[WebStorm/IntelliJ Setup · Prettier](https://prettier.io/docs/en/webstorm.html)

## TypeScript
TypeScript is a topic for another day. We will focus on enabling ESLint support for TypeScript files here. Once we install the TypeScript package, we need to create a `tsconfig.json` for the ESlint’s TypeScript parser. It can be something as simple as the following if we already use Babel to transform TypeScript file. We are telling the compiler not to compile (`"noEmit": true`) the TypeScript files into JavaScript for all files in the `src` directory.

```json
{
  "compilerOptions": {
    "noEmit": true,
    "baseUrl": "./src"
  }
}
```

ESlint does not understand TypeScript files by default. So we need to install `@typescript-eslint/eslint-plugin`  and `@typescript-eslint/parser` to help us deal with those files. We will override default ESlint setting for all TS and TSX files in `.eslintrc`

```json
"overrides": [
  {
    "files": "**/*.+(ts|tsx)",
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
      "project": "./tsconfig.json"
    },
    "plugins": ["@typescript-eslint/eslint-plugin"],
    "extends": [
      "plugin:@typescript-eslint/eslint-recommended",
      "plugin:@typescript-eslint/recommended",
      "eslint-config-prettier/@typescript-eslint"
    ]
  }
]
```


## Husky
Git hooks can be useful for preventing bad code being committed to the code base but configuring it is not as straightforward. Husky is a package that helps us config git hooks by handling the boilerplate stuff behind the scenes. Once the package is installed, we can create `.huskyrc` with the git hook we need. In the following example, we want to make sure linting and type checking are passed befor any code is committed.

```json
{
  "hooks": {
    "pre-commit": "npm run check-type && npm run check-format && npm run lint"
  }
}
```


## lint-staged
Husky and git hooks are great but it will starting run slower as our project grows. Most of the time, we only want to validate the file that will be committed. lint-stage will pass the files that match glob pattern as arguments to specific commands. We can create `.lintstagedrc` with something similar to this:

```json
{
  "*.+(js|ts|tsx)": [
    "eslint"
  ],
  "*.+(|ts|tsx)": [
    "tsc"
  ],
  "*/*.+(js|json|ts|tsx)": [
    "prettier --write",
    "git add"
  ]
}
```

In the above example, we will 

* Lint all Javascript and TypeScript files
* Check type for TypeScript files
* Format all JavaScript, TypeScript and JSON files with Prettier before stage those files

We can simplify the pre-commit hook with `“pre-commit”: “lint-staged”`


## Conclusion
I hope this article gives a decent overview of some of the tools we can leverage to improve our code quality and developer experience. Each of the tool we have mentioned is highly customizable. I highly recommend everyone to explore them further. 

You can find the source code at [GitHub - xian0831/static-testing-starter: This project demonstrate a simple setup of some static code quality tool](https://github.com/xian0831/static-testing-starter)

Tools of Front End Developers — Static Code Analysis

## Introduction 
Every e-commerce site knows that the slower the page it loads the more likely your customers will turn around and leave your site. 
According to [the research from Google](https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/),
 53% of mobile site visits leave a page that takes longer than three seconds to load. 

However, startups like [Zola](www.zola.com) are moving fast to deliver features to meet the needs of our customers.
Once in a while, we have some downtime between projects. I was able to use one of those opportunities to take a step 
back to optimize one of the internal React component packages, `component-public-registry`. 

### What are the issues?
1. component-public-registry was using webpack 2 and all the JavaScript files were concatenated without any optimization. 
It builds a bundle that is 3.5 MB! 
2. Included the unnecessary part of node package, such as `moment/locale`.
3. When the share components were pulled out from the main app, they carried all the dependency with them cause lots of 
duplicated packages being included when the library is built.


### Step 1: Upgrade to webpack 4
webpack 2 is pretty outdated at this point. We want to start the optimization with better long term support down the 
road. Our existing webpack config was minimum. It is effortless to upgrade it.

Since webpack 4 minify the JavaScript by default, we can shrink down the size to 865KB without making any webpack 
config changes.

### Step 2: Optimize Less import
Some of the Less files contain incorrect import statements that cause the same CSS file from our internal library to be 
appended to component CSS files multiple time.  By doing this, we reduce the package to 862 KB. 
Since the CSS file being duplicated is relative small, the size reduction is not dramatic.

**_Do this:_**

It will only copy the part being used.
```js
@import (reference) “~@zola/zola-ui/common/_variables.less”;
```

**_Don’t do that:_**

This will copy the entire file which is unnecessary most of the time.
```js
@import “~@zola/zola-ui/common/_variables.less”;
```


### Step 3: Optimize NPM Packages (mostly moment and lodash) 
For Lodash: 

When we initially created the component-public-registry, we didn't pay attention to how we are importing functions from 
Lodash. It causes webpack to bundle entire Lodash packages.

**_Do this:_**

Only the specific function is imported.
```js
import find from 'lodash/find';
```

**_Don’t do that:_**

Entire Lodash library will be bundled.

```js
import { find } from 'lodash';
```

---

**_For Moment:_**

Unfortunately, we can’t pick out certain functions like how we did it with Lodash. But that does not mean there is no 
opportunity for optimization. Since we don’t use locale files from Moment, we can ask webpack not to include that 
part when making the bundle. 

**_Do this:_** webpack will ignore the locale section.
```js
plugins: [
  // Ignore all locale files of moment.js
  new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/),
],
```

At this point, the file size has been reduced to 582 KB

### Step 4: Remove Duplicate Package In Bundle

component-public-registry started in our registry app and our team decided we can use reuse the same code elsewhere. 
With limited resources, as mentioned earlier, we only set up a bare minimum webpack config. 
As a side-effect, lots 3rd party packages (such as React and Moment) were being bundled without any optimization.  
We decide to make those packages  `peerDependencies`  and exclude them from the bundle. 
This makes further reduce the package size down to 192 KB.

**_Do this:_**

webpack will avoid bundle those packages to reduce the final bundle size.

webpack.config.js

```js
// webpack config
module.exports = {
  externals: {
    react: {
      commonjs2: 'react',
    },
    'react-dom': {
      commonjs2: 'react-dom',
    },
    'core-js': {
      commonjs2: 'core-js',
    },
    moment: {
      commonjs2: 'moment',
    },
    '@zola/zola-ui': {
      commonjs2: '@zola/zola-ui',
    },
    'logrocket': {
      commonjs2: 'logrocket',
    },
  },
}
```

Package.json

```json
"peerDependencies": {
  "react": ">= 16.8.x < 17.x",
  "react-dom": ">= 16.8.x < 17.x",
  "core-js": ">= 2.x",
  "moment": ">= 2.22.0",
  "@zola/zola-ui": ">= 2.*",
  "logrocket": "^1.0.3"
},
```

### Step 5: Remove Duplicate Package In Web App
Modern NPM is smart to handle duplicated packages by flattening the dependencies when you do `npm install`. 
When we inspected the package structure, we still noticed some duplicated packages were being added. 

After a bit of a Googling, we found `npm dedupe`.  According to NPM documentation, the command 
**searches the local package tree and attempts to simplify the overall structure by moving dependencies 
further up the tree, where they can be more effectively shared by multiple dependent packages.**

## Conclusion
After these iterations, our web app bundle reduced almost 2/3 of its original size. With a much smaller footprint, 
we also double our Lighthouse performance score for mobile. While this is great news for us, there are many other ways 
to improve the performance of the website.

I'm glad we have a good start. 

Making Our Site Loads Faster

## Introduction
Since I wrote my last blog [post](https://medium.com/@xiangzheng/practical-use-cases-of-react-context-and-hooks-a9f62815e38d) 
about using React Context and Hook APIs, I have been using the combination for a few weeks now, they have made my project much simpler. However, as the complexity of the application increases, `useState` becomes less ideal for managing complicated local state.

### Initial Approach

This was the original implementation of `OrderInfoContext` and we used it to host data for a list of Orders. 

```javascript
import React, { useState, useEffect, useContext, createContext } from 'react';
import FetchService from './util/FetchService';

const OrderInfoContext = createContext();

// This is a helper component that generate the Provider wrapper
function OrderInfoProvider(props) {
  // We will persist API payload in the state so we can assign it to the Context
  const [orders, setOrders] = useState([]);

  // We use useEffect to make API calls.
  useEffect(() => {
    async function fetchData() {
      // This is just a helper to fetch data from endpoints. It can be done using axios or similar libraries
      const orders = await FetchService
        .get('/v1/registry/orders');
      setOrders(orders);
    }
    fetchData();
  });
  //we create a global object that is avaibvale to every child components 
  return <OrderInfoContext.Provider value={[orders, setOrders]} {...props} />;
}

// Helper function to get Context
function useOrderInfo() {
  const context = useContext(OrderInfoContext);
  if (!context) {
    throw new Error('useOrderInfo must be used within a OrderInfoProvider');
  }
  return context;
}

export { OrderInfoProvider, useOrderInfo };
```

This approach works fine until I needed to perform some actions such as adding additional order information. While I can still use `setOrder` to update the state, I faced the following challenges:

1. multiple child components need to fetch or add a new order
2. order mutation logic are all over child components

With those challenges in mind. I went with [`useReducer hook](https://reactjs.org/docs/hooks-reference.html#usereducer) 
for help 

### Solution: useReducer as a replacement

I rewrote the `useState` with [useReducer](https://reactjs.org/docs/hooks-reference.html#usereducer). 
`useReducer` allows developers to manage state like Redux. According to the official React Doc, `useReducer is usually 
preferable to useState when you have complex state logic that involves multiple sub-values.` 

```javascript
// This is the first attempt to use useReducer hook. 
// reducer returns the next state based on the action passed in
const reducer = (state, action) => {
  switch (action.type) {
    case INITIAL:
      return [];
    case FETCH_ORDER:
      return action.payload;
    case ADD_ORDER:
      return [...state, action.payload];
    default:
      throw new Error();
  }
};

// This is a helper component that generate the Provider wrapper
function OrderInfoProvider(props) {
  // We will persist API payload in the state so we can assign it to the Context
  const [orders, dispatch] = useReducer(reducer, []);
  const addOrderInfo = (data) => { addOrders(dispatch, data); };

  async function fetchOrders() {
    const data = await ApiService
      .get('/v1/registry/orders');
    dispatch({
      type: FETCH_ORDER,
      payload: data
    });
  }

  useEffect(() => {
    fetchOrders();
  }, []);

  // we create a global object that is available to every child components
  return <OrderInfoContext.Provider value={[orders, dispatch]} {...props} />;
}
```

Since the context exposes `dispatch` as part of the value, any child component can get the dispatch function from the context and update the order data in the context. This solution is slightly better than the original version since we can have different ways to change the local state.

```javascript
// any child component can dispatch functions
import { useOrderInfo } from './context/OrderInfoContext';
...
const [, dispatch] = useOrderInfo();

dispatch({
  type: 'ADD_ORDER',
  payload: {
    order_id: 'xyz',
    status: 'SENT'
  }
});
```

However, It is still not ideal to give child components the burden to re-implement all those dispatch functions over and over again. 

### Make it even better
To make dispatching functions easier and the code cleaner, I extracted actions, action creator and reducer 
from `OrderInfoContext`.

```javascript
// OrderInfoReducer.js
// actions
import ApiService from './util/apiService';

const INITIAL = 'INITIAL';
const FETCH_ORDER = 'FETCH_ORDER';
const ADD_ORDER = 'ADD_ORDER';

// action creators
export const fetchOrder = data => ({ type: FETCH_ORDER, payload: data });
export const fetchInitial = data => ({ type: INITIAL, payload: data });
export const addOrder = data => ({ type: ADD_ORDER, payload: data });

// reducer
export const reducer = (state, action) => {
  switch (action.type) {
    case INITIAL:
      return [];
    case FETCH_ORDER:
      return action.payload;
    case ADD_ORDER:
      return [...state, action.payload];
    default:
      throw new Error();
  }
};

export async function fetchOrders(dispatch) {
  const data = await ApiService
    .get('/web-registry-api/v1/thankYouNote/orders');
  dispatch(fetchOrder(data.data));
}

export async function addOrders(dispatch, data) {
  dispatch(addOrder(data));
}
``` 

After the complex logic is extracted, `OrderInfoProvider` component becomes much cleaner again. 
We also create closures from the original `fetchOrders ` and `addOrders ` to provide some restrictions and 
a better experience for users of those helper functions from `OrderInfoContext`. 

```javascript
// OrderInfoContext.js
import { reducer, fetchOrders, addOrders } from './OrderInfoReducer';
function OrderInfoProvider(props) {
  const [orders, dispatch] = useReducer(reducer, []);
  const fetchOrderInfo = () => { fetchOrders(dispatch); };
  const addOrderInfo = (data) => { addOrders(dispatch, data); };

  useEffect(() => {
    fetchOrderInfo();
  }, []);

  return <OrderInfoContext.Provider value={{ orders, dispatch, fetchOrderInfo, addOrderInfo }} {...props} />;
}
```

We can simply call the function from the Context to fetch the order data or add a new order.

```javascript
import { useOrderInfo } from '../../context/OrderInfoContext';

......

const { fetchOrderInfo } = useOrderInfo();
fetchOrderInfo();

```

### Conclusion
`useReducer` provides more precise control of local state mutation. It is fairly familiar to developers who already
are comfortable with Redux. For any new developers who hasn't used React Hook and Redux, it might not be as 
straightforward. I also started thinking about the pros & cons of using Context + useReducer as opposed to Redux. 
But that is the discussion for another day 😀.  
   


Use useReducer As useState Replacement To Handle Complicated Local State

Recently, our teams have moved to React 16.8 across all our web applications. React Hooks and Context becomes the most 
talked-about features at the moment. I am one of those people. 

The goal of this article is to show a couple of use cases where we are attempting to use hooks and contexts to make the 
source code a bit cleaner and more efficient. If you are not familiar with Hooks yet, you can take a look at the official 
introduction from [Facebook](https://reactjs.org/docs/hooks-intro.html).

---

## Introduction 
In one of the projects I’m currently working on, we need to build an editor component for displaying a list of orders 
and providing the ability to edit the detail of the order.

When users land on the page, they will see the first view (Overview Mode)as default. After clicking one of the orders 
from the side panel, they will see the second view (Detail Mode) which will allow them to edit some details. The general 
structure of components can be represented in the following.

```
Container & ContextProvider Wrapper
| — — SidePanel
| — — — OrderView
| - - - - - - OrderList
| - - - - - - OrderItem
| — — — OrderDetailView
| — — EditorPanel
| — — — -SomeOtherComponents
``` 

### View 1: Show list of orders
![list-view](//images.ctfassets.net/ywybshois4yv/1mcGWcYx7fpSG9ejfiGowL/9010e8b9902fef4720e1cc9193347908/list-view.png)

### View 2: Show detail of an order
![detail-view](//images.ctfassets.net/ywybshois4yv/3HC5Vtcv4ayl19tkmlobRw/c625df6dcb4a69728e0ffd5dbde8a1cc/detail-view.png)


## Case 1: Using Context to Manage Local State

Traditionally, we have been using Redux to handle all the application. Sometimes we simply just fetch and the data which 
is only being used for a small subset of our application and we will never call any action to update them. With Context 
API available with React 16.8, I am attempting to use Context to manage the local state instead of Redux for the above 
reason.

***OrderInfoContext.jsx***
```javascript
import React, { useState, useEffect, useContext, createContext } from 'react';
import FetchService from './util/FetchService';

const OrderInfoContext = createContext();

// This is a helper component that generate the Provider wrapper
function OrderInfoProvider(props) {
  // We will persist API payload in the state so we can assign it to the Context
  const [orders, setOrders] = useState([]);

  // We use useEffect to make API calls.
  useEffect(() => {
    async function fetchData() {
      // This is just a helper to fetch data from endpoints. It can be done using axios or similar libraries
      const orders = await FetchService
        .get('/v1/registry/orders');
      setOrders(orders);
    }
    fetchData();
  });
  //we create a global object that is avaibvale to every child components 
  return <OrderInfoContext.Provider value={[orders, setOrders]} {...props} />;
}

// Helper function to get Context
function useOrderInfo() {
  const context = useContext(OrderInfoContext);
  if (!context) {
    throw new Error('useOrderInfo must be used within a OrderInfoProvider');
  }
  return context;
}

export { OrderInfoProvider, useOrderInfo };

```

Inspired By [Kent C. Dodds’s article](https://kentcdodds.com/blog/application-state-management-with-react) about 
application state, I created a functional component to help me fetch the order data and set up the `OrderInfoContact`. 
Because we need to fetch the data, we have to use `useEffect` to deal with the async operation here. If you are not 
familiar, you can think about this like how we fetch data in `componentDidMount` a class component.
Using the Context Provider helper we created, we can wrap every component related to the order context. At this point, 
we can get the order information from `OrderList` and `OrderView`.

Using the Context Provider helper we created, we can wrap every component related to the order context. At this point, 
we can get the order information from `OrderList` and `OrderView`.

***Container.jsx***
```javascript
class OrderContainer extends Component {
  render() {
    return (
      <OrderInfoProvider>
        {/* This is another context provide information about the mode editor is in at the momenmt */}
        <EditorModeProvider> 
          <div className="row">
            <div className="col-md-3">
              <SidePanel />
            </div>
            <div className="col-md-9">
              Right Panel
            </div>
          </div>
        </EditorModeProvider>
      </OrderInfoProvider>
    );
  }
}

export default OrderContainer;
```

## Case 2: Use Hooks to Create Cleaner Code
Now we can access the order data in OverView, we would like to split them into multiple lists by their status. 
Traditionally, we will pass down the order data component by component ([prop-drilling](https://kentcdodds.com/blog/prop-drilling)). 
We will likely end up writing a class component that use `getDerivedStateFromProps` to help users update those lists in 
the state. Luckily, we are not able to use hooks to make this code a bit cleaner. First, we define those lists as an 
empty array. Once the data comes back and the order in the Context is updated, the effect will be triggered 
which will update those lists. It does feel nice when you don’t need to write those life cycle methods 😀

***OrderView.jsx***
```javascript
import _includes from 'lodash/includes';
import { useOrderInfo } from '../../OrderInfoContext';
import OrderList from './OrderList/OrderList';

const OrderView = () => {
  // Get order data from context provider
  const [orders] = useOrderInfo();
  // Splite orders by their status and store them in the compoent state.
  const [remainingOrder, setRemainingOrder] = useState([]);
  const [readyOrder, setReadyOrder] = useState([]);
  const [doneOrder, setDoneOrder] = useState([]);
  
  // We need update those lists whenever the order data in context is updated
  useEffect(
    () => {
      setRemainingOrder(orders.filter(({ status }) => status === 'NOT_SENT'));
      setReadyOrder(orders.filter(({ status }) => status === 'DRAFTED'));
      setDoneOrder(orders.filter(({ status }) => status === 'SENT'));
    },
    [orders] // run when orders changes
  );

  return (
    <div className="container_order-view">
      <div className="container-list-container">
        <OrderList orderList={remainingOrder} title="Remaining" />
        <OrderList orderList={readyOrder} title="Ready to Order" />
        <OrderList orderList={doneOrder} title="Done" />
      </div>
    </div>
  );
};
```


## Summary

I want to keep this article short so I skip the EditorModeConext, which has the state for change editor views but it 
works similarly. This is my first attempt to use Context and Hooks for my project. It is by no means the best approach. 
I do not think Context should be used all the time if I intend to reuse certain UI components across multiple applications. 
By injecting context to a component technically makes a component less reusable. I also don’t think Context can replace 
Redux as many people claimed if the local state is being manipulated over and over again. I will leverage Redux’s time 
travel ability and its excellent DevTool.

In terms of hooks, I will start using them wherever I can. They do make the code much cleaner and concise.

Blog.

A place for me to record some random thought about tech and life.

Next.js: Not So Straightforward Path To Production

More Stories

Tools of Front End Developers — Static Code Analysis

Making Our Site Loads Faster

Use useReducer As useState Replacement To Handle Complicated Local State

Practical Use Cases of React Context and Hooks