Here's a way to get environment variable values into your [Next.js](https://github.com/zeit/next.js/) app.



## Why in the Environment?

Why might you want to put variables into the environment?  These might be values that are sensitive that you don't want to commit to source control.  They might be things that change per environment (staging vs production).  They might be things you want to be able to adjust without changing your code.

An example of a thing that we might want to change in an environment variable is the url for an API host that our Next.js site connects to for data.

## Node Environment Variables

In Node, and thus in Next.js, we access environment variables via `process.env`.  This is a map of different values available from the environment.  If I set the variable in the environment and then ran my next app:

```bash
export API_HOST=https://exampleapi.com
next 
```

Then I could access the variable in my Node code with:

```js
process.env.API_HOST
```

Instead of typing `export` every time I want to modify the environment for my app, I create a list of variables for the app process to have automatically every time I run it.  I can do this with a little tooling and setup.  

## Dotenv Module

First, create a `.env` file in your project root:

```bash
API_HOST=https://exampleapi.com
```

Put your environment variables in that file, one per line.

Then install a [dotenv](https://www.npmjs.com/package/dotenv) module for your Next.app to use to load this file:

```bash
npm install dotenv
```

In your node code, you need to invoke `dotenv` to load the `.env` file contents into the environment.  This is done with:

```js
require('dotenv').config()
```

But where should this call go in your Next.js app?

## Next.js Config Modifications

Out of the box, the Next.js config doesn't have anywhere specifically to put environment variables.  But Next.js does provide extensibility via a couple interesting hooks in the `next.config.js` file in your project root.  One hook is the `webpack` hook, where we can access and change anything in webpack.

We need to provide the environment variables to webpack so that when it builds the browser bundle of JavaScript it can make the needed string replacements for the browser environment.

Specifically, `process.env` isn't available in the browsers (only Node.js), but your Next.js code runs in both places.  So the browser bundle that is generated by webpack needs to replace, for instance, `process.env.API_HOST` with `"https://exampleapi.com"`.

To do this, edit `next.config.js` to include:

```js
const { parsed: localEnv } = require('dotenv').config()
const webpack = require('webpack')

module.exports = {
  webpack(config) {
    config.plugins.push(new webpack.EnvironmentPlugin(localEnv))

    return config
  }
}
```

Here, we call `dotenv.config()`, and we destructure out the parsed object -- usually set on `process.env`, but now given to the `webpack.EnvironmentPlugin` -- which will do the string replacement.

Now inside your Next.js code, you can use the environment variable `process.env.API_HOST`, and the final bundle will be output with `"https://exampleapi.com"`.  You're probably using this inside of `getInitialProps` or wherever you're calling your API.

What alternate methods do you use to set environment variables in your Next.js projects?

Get environment variable values into your Next.js app

Environment Variables in Next.js

Make getInitialProps available to child components in Next.js



## What is getInitialProps

[Next.js](https://github.com/zeit/next.js/) adds a great little function to top-level (page) components.  It gives access to a number of properties, such as the request and response objects and url information such as the `pathname`.  For the full list, see the [readme](https://github.com/zeit/next.js/).

This data is useful in more than just the top-level page components.

## For All Pages

To get all pages to have the `getInitialProps` data available, we could implement this function on every page.  Or we could create a shared component that implements `getInitialProps` in one place.

This component doesn't have any UI per se, so we also don't want to render any DOM.  One way to accomplish this is to write a higher-order component that wraps the top level component of each page.

Such a component, `with-server-props.js`, might look like this:

```js
export default WrappedComponent => 
  class extends React.Component {
    static async getInitialProps({ pathname }) {
      return { pathname }
    }
    render() {
      return <WrappedComponent pathname={this.props.pathname} />
    }
  }
```

This will make the `pathname` prop available to each page.

## For All Child Components

But what if we want to make `pathname` or other bits of data that `getInitialProps` can provide available to any other component?

We have a couple of options.  We could:

1) Drill props for `pathname`, etc. all the way down to where they're needed.
2) Our server component wrapper could be modified to push this data into a shared data structure, a la redux store.  
3) We could avoid drilling or another library and put `pathname`, etc into [React context](https://facebook.github.io/react/docs/context.html).

Any one of these or other options would probably work fine depending on your use case and preference.  

Let's share this data with React context. To start, we modify our page component wrapper.  The component transfers `pathname` from props to context via the `getChildContext` function:

```js
import PropTypes from 'prop-types'

export default WrappedComponent => {
  class WithServerProps extends React.Component {
    static async getInitialProps({ pathname }) {
      return { pathname }
    }
    getChildContext() {
      return { pathname: this.props.pathname }
    }
    render() {
      return <WrappedComponent />
    }
  }
  WithServerProps.childContextTypes = {
    pathname: PropTypes.string.isRequired
  }

  return WithServerProps
}
```

We would wrap a page, such as `pages/index.js`, with our component:

```js
import withServerProps from '../ui/with-server-props'
import ChildComponent from '../ui/child-component'

export default withServerProps(_ => 
  <div> 
    etc
    <ChildComponent />
  </div>
)
```

Then `ChildComponent` or any similar non-root node component can get the `pathname` from context:

```js
class ChildComponent extends React.Component {
  render() { return <div>{this.context.pathname}</div> }
}
ChildComponent.contextTypes = {
  pathname: PropTypes.string
}
export default ChildComponent
```

Now `getInitialProps` is effectively available everywhere.  Just adjust `contextTypes` in the child component to determine what you want to pull out of context.

How does this approach strike you?  Are there better options?  How do you make `getInitialProps` data available to your components in Next.js?

Make getInitialProps available to child components in Next.js

Next.js getInitialProps in All Components

How to deploy a Next.js static site to Github Pages.



[Github Pages](https://pages.github.com/) is a great place to deploy static [Next.js](/post/what-is-nextjs/) sites.

## Setup Next.js

As of `next@3`, a static export of your Next.js site is possible.

This is accomplished with:

```bash
next build && next export
```

When you export, you can specify the output directory with `-o`.  Github pages has an option of serving the `docs/` directory of your `master` branch, so we'll setup for that.  Adjust the command to be:

```bash
next build && next export -o docs
```

## Setup Custom Domain

To prep your Github Pages site to be served by a custom domain, you'll need to first buy the domain, [setup the DNS](https://help.github.com/articles/quick-start-setting-up-a-custom-domain/).

For an [example project](https://github.com/jaketrent/electron-course), my DNS setup has two entries:

```txt
CNAME electroncourse.com jaketrent.github.io
CNAME www                electroncourse.com
```

Connect your custom domain to your Github Pages site by adding a file to `docs/CNAME` with the contents of your custom domain:

```txt
electroncourse.com
```

You'll notice that this `CNAME` file is in the `docs/` directory, which is the target of the Next.js `export` command.  `export` will blow the directory away, removing your `CNAME` file.  We want to make sure we don't lose it after an export.

## NoJekyll Support

Github pages are processed by [Jekyll](https://jekyllrb.com/) by default.  In our case, the directories Next.js builds by default include a `_next` directory with all the built JavaScript assets.  In order to make those findable in our deployed site, we need to [add a special file](https://help.github.com/articles/files-that-start-with-an-underscore-are-missing/) called `.nojekyll` inside the `docs/` directory.  

We'll also need to take care not to remove this file when running a `next export` command.

## All-in-one Deploy Script

So here is an all-in-one deploy script for building, exporting, preserving the `CNAME` and `.nojekyll` files, committing, and pushing your content to the server.  If we put this in `package.json`:

```json
"scripts": {
  "deploy": "next build && next export -o docs && git checkout -- docs/CNAME && git checkout -- docs/.nojekyll && git add docs && git commit -m \"chore: regen site\" && git push origin master"
}
```

Epic!  Then we can run it with: `npm run deploy`.

## Setup Repo for Github Pages

Now go to your [repo](https://github.com/jaketrent/electron-course) on Github and go to the "Settings" tab.  Under that tab, find the section labeled "Github Pages".  Choose the "Source" option of: `master branch /docs folder`.

![github docs directory](https://i.imgur.com/6c8yWY6.jpg)

This will serve your page from that `docs/` directory.

To see if your page is working, visit your Github Pages URL, eg [`jaketrent.github.io/electron-course`](http://jaketrent.github.io/electron-course).  If the DNS is working, you'll get a redirect to your custom domain, [`electroncourse.com`](http://electroncourse.com).

You've now deployed your Next.js site to Github Pages!

What else have you done to make this process better?

How to deploy a Next.js static site to Github Pages.

Deploy Next.js to Github Pages

Styling children elements in styled-jsx doesn't have an ideal solution.  Here's one way.



## What is styled-jsx?

[styled-jsx](https://github.com/zeit/styled-jsx) is a library to support CSS-in-JS.  It was developed by [Zeit](https://zeit.co) for use in their awesome [Next.js](https://github.com/zeit/next.js/) (React) apps.

One of its great benefits is that it provides isolation of styles between UI components.

## How it works

When a Next.js app renders, React elements are rendered to the DOM with a data attribute identifying it.  For example:

```html
<div class="merry" data-jsx="1075344175"></div>
```

The selector `.merry` for that component is defined next to the compoent markup:

```js
export default props =>
  <div className="merry">
    <style>{`
      .merry { color: red; background: green; }
    `}</style>
  </div>
```

That `data-jsx` identifier is then built into the resulting CSS output so that when it is rendered on the served html page it looks like:

```css
.merry[data-jsx="1075344175"] {
  color: red; background: green;
}
```

These styles are isolated and internal to the component.  It's great... until you want to override it from a parent component.

## Allow Overriding className

One easy method for overriding a `className` is to allow passing it in on `props`.  A `parent.js` component might look like this:

```js
import Merry from './merry'

export default props =>
  <div>
    <Merry className="merry--override" />
    <style>{`
      .merry--override { color: yellow; }
    `}</style>
  </div>
```

And that might be handled simply in the `merry.js` component with:

```js
<div className={`${props.className ? props.className + ' ' : ''}merry`}>
```

## Problem with Passing styled-jsx

But now the strength of styled-jsx is a weakness that we have to work around.  Remember that each of these selectors, including the `parent.js` style, is getting namespaced with the markup's data attribute identifier.  Thus we might be setting the `class` attribute on the `merry.js` output ok:

```html
<div class="merry--override merry" data-jsx="1075344175"></div>
```

But the output CSS is something like this:

```
.merry[data-jsx="1075344175"] {
  color: red; background: green;
}
.merry--override[data-jsx="9483212348"] {
  color: yellow;
}
```

Given this output, the selector that should override to the color of `yellow` won't be applied because of the `[data-jsx="9483212348"]` isolation.  This is the weakness with coupling the CSS selector to the markup structure.  Hashing the selector itself wouldn't have this problem.

You can remove this isolation by making a selector global.  In `parent.js`, we can define the style like this:

```js
:global(.merry--override) { color: yellow; }
```

That will drop the data attribute from the output CSS:

```css
.merry[data-jsx="1075344175"] {
  color: red; background: green;
}
.merry--override {
  color: yellow;
}
```

A problem still remains, however, and that is the problem of CSS specificity rules.  Both selectors now apply to the `.merry` element, but the selector with the data attribute is a more specific selector.  Thus, the original selector wins and the color remains `red`.

## The Solution is to Make it All Global

Global variables are the best, right?  Only good things can happen here.  Eghhh...

Anyway, if you want this to work, you can make both selector definitions `:global()` -- both `.merry {}` in `merry.js` and `.merry--override {}` in `parent.js`.  This will output two CSS selectors without isolation:

```css
.merry {
  color: red; background: green;
}
.merry--override {
  color: yellow;
}
```

The override is now just as specific and will work just fine.

But now you've lost the foremost benefit of using styled-jsx: isolation!  As far as I [can](https://github.com/zeit/styled-jsx/issues/197) [tell](https://github.com/zeit/styled-jsx/issues/121), this is the current best solution so far, and it's not a great one.  This seems like a mainstream usecase, so I'm surprised this is what we're left with.

## Vacation from My Problems

Of course, there is another solution, and that's to avoid the problem.  If you have reusable components, don't attempt to override them.  Treat them as a black box.  Of course, this means that you may have to handle more styling in the outside/parent components.  

In the example above, you could define `.merry { color: inherit; }` and then *always* include `<Merry />` on the page within a wrapper that would define the color.  `wrapper.js` might look like:

```js
import Merry from './merry'

export default props =>
  <div className="wrapper">
    <Merry />
    <style>{`
      .wrapper { color: red; }
    `}</style>
  </div>
```

In this example, every wrapper would define a color as the original `red` or an overriding `yellow` or whatever.  It works in this case.  It may be more difficult, depending on your use case, to avoid this.

Have you run into this same problem when styling children using styled-jsx?  How have you found your way around it?

Styling children elements in styled-jsx is not ideal.  Here's one way.

Style Children in styled-jsx

Let's setup Next.js to be able to serve markdown content, such as blog posts.



## Next.js Custom Server

Next.js has a nice feature set out of the box.  If you have a site that's more on the site end of the spectrum (rather than the app end), you'll likely be able to use the `next` server as-is. 

If, however, you'd like to do app-ish things on the backend, you'll likely need your own custom server.  This is not hard.

Serving markdown seems to be one of the things that needs a custom server.  I tried rendering the Markdown straight from React components, and it didn't seem to work.  This after adding custom markdown loaders to the webpack config and all that.  It still didn't work.  The big hang up, for some unknown reason, was that the markdown modules could not be found in order to be imported correctly.  

My solution was to build a custom server.  

## Basic Custom Server Setup

In Next.js terms, a custom server is simply some JavaScript that starts the next app in addition to doing any of the extra app stuff you need.

First, change your `package.json` `start` script:

```
{
  "scripts": {
    "start": "node server.js"
  }
}
```

Then do the basics in your `server.js` to initialize `next`:

```js
const { createServer } = require('http')
const next = require('next')

const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()

;(async _ => {
  await app.prepare()
  createServer(async (req, res) => {
    // ...more custom stuff here later

    return handle(req, res, parsedUrl)
  })
  .listen(process.env.PORT || 3000, (err) => {
    if (err) throw err
    console.log('> Ready on http://localhost:' + (process.env.PORT || 3000))
  })
})()
```

This can be done in Express, Koa, or any other http server library.  This example uses the Node built-in `http.createServer`.  Note that all this is doing is creating a `next` app, then using that app's request handler to handle all incoming requests.  Custom additions are yet to come.

## Reading Markdown

Since we're on the server, we have full access to the Node API.  This includes the `fs` filesystem API.  To get our markdown content, let's read markdown files out of a `posts` directory.  Once the file strings are read, let's use a library called [`front-matter`](http://npm.im/front-matter) to parse metadata out of the front matter (not the markdown content yet).  First install:

```bash
npm install front-matter
```

And let's put all this in a `posts-repo.js`:

```js
const path = require('path')
const { promisify } = require('util')
const frontMatter = require('front-matter')
const fs = require('fs')

const readdir = promisify(fs.readdir)
const readFile = promisify(fs.readFile)

const deserialize = parsed => ({
  title: parsed.attributes.title,
  date: parsed.attributes.date,
  body: parsed.body
})

async function fetch() {
  const postsDir = path.join(__dirname, 'posts')
  const filenames = await readdir(postsDir)
  
  return Promise.resolve(filenames.map(async filename => {
    const markdown = await readFile(path.join(postsDir, filename), 'utf-8')
    const parsed = frontMatter(markdown)
    return deserialize(parsed)
  }))
}

exports.fetch = fetch
```

## Serving Markdown

Now we have a module that can read and load into memory all the parsed markdown files.  Now we have to serve this markdown with our custom server.  

First, we need to detect that our client is making a request for the markdown.  We'll do an overly-simple check of the request path.  If the request url matches '/api/', we'll assume we're asking for this single endpoint to fetch all the markdown posts.  We can make this more complicated later.  

In `server.js`, we'll make the adjustments.  Inside the `createServer` callback, we don't just pass everything on to the Next.js `handle` function any  more.  We now parse the URL and call our `postsRepo.fetch` instead:

```js
const { parse } = require('url')

const postsRepo = require('./posts-repo')

const serialize = data => JSON.stringify({ data })

// ...

  createServer(async (req, res) => {
    const parsedUrl = parse(req.url, true)
    const { pathname } = parsedUrl

    if (pathname.includes('/api/')) {
      const posts = await postsRepo.fetch()

      res.writeHead(200, { 'Content-Type': 'application/json'})
      return res.end(serialize(posts))
    }

    return handle(req, res, parsedUrl)
  })
```

## Requesting Markdown from Next.js Component

Now we have an endpoint that can serve the markdown-based posts.  We need to get the React components to request the data they need.  In Next.js, this is done on the server and in the client.  We'll choose an http library that can function in both places.  We'll also install a markdown parser:

```bash
npm install isomorphic-fetch react-markdown
```

We're ready to rock and roll in our React component.  The top-level component in Next.js, called a "page", has a special hook called `getInitialProps`.  Here in `pages/indexx.js` we can do our data fetching:

```
import Post from '../components/post'

export static class Index extends React.Component {
  static async getInitialProps({ query }) {
    const posts = await Post.fetch()
    return { posts }
  }
  render() {
     {this.props.posts.map(p => <Post post={p} />)}
  }
}
```

And then `components/post.js`:

```js
import 'isomorphic-fetch'
import Markdown from 'react-markdown'
import React from 'react'

const Post = props =>
  <div>
    <h1 className="title">{props.title}</h1>
    <time className="date" dateTime={props.date}>{props.date}</time>
    <Markdown source={props.body} />
  </div>

class PostContainer extends React.Component {
  static async fetch() {
    const res = await fetch('<yourHost?/api/v1/posts')
    const json = await res.json()
    return json ? json.data : {}
  }
  render() {
    return <Post {...this.props.post} />
  }
}

export default PostContainer
```

Here we have the http code to fetch the post from the server, and we're finally rendering markdown.

There are a few steps here, aren't there.  We can still get the coolness of Next.js' server-rendering of React while doing our own custom markdown fetching on top of it.

Is this how you render markdown content in Next.js?  How have you improved upon the method?

Setup Next.js to be able to serve markdown content

Serve Markdown with a Next.js Server

[Next.js](https://github.com/zeit/next.js/) is a framework that most notably allows you to write server-rendered React apps easily -- amongst other cool things.



## It's a Framework

Next.js is opinionated and provides structure for how you build your app.  Like Rails, the file-system is often the API.  You name your file something special and put it in a special directory, and it Just Works.  In this way, Next.js feels like a framework.

## The Main Event: Server-Rendering

Anyone can create an `index.html` page and call `ReactDOM.render` on it to get a client-side React app running.  Something that simple hasn't existed for the server.  Next.js attempts to be that thing.  "Put a file in this directory," it muses, "and I will create a Node.js server that renders that React component as HTML at this route".  And it really does seem that easy.

Next.js allows for things like data-fetching and app state via Redux and all that.  But you must bring that stuff to the party yourself.  And it'll work just fine.  If your game is rendering HTML via React from server and client, Next.js has that all in the box.

## CSS 

The default CSS approach in Next.js is [styled-jsx](https://github.com/zeit/styled-jsx).  You define string blocks of CSS as a child `<style />` tag in the component you want the styles to apply to, a la:

```js
const MyComponent = _ =>
  <div>
    <p>Style only applies to this paragraph</p>
    <style jsx>{`
      p { color: red; }
    `}</style>
  </div>
```

In definition, this feels a lot like the defunct [scoped css](http://caniuse.com/#feat=style-scoped).  In practice, it outputs selectors that match data- attributes that Next.js adds to the component's HTML output:

```html
<p data-jsx="123456789">Style only applies to this paragraph</p>
<style>p[data-jsx="123456789"]</style>
```

There are (so many!) other options for CSS.  Your able to customize this to your own flavor.

## Pages

The most magical directory in a Next.js project is `/pages`.  This is where your top-level React component modules will live.  These files will be used to generate routes in your app.

If you have a `./pages/about.js` component file, your app will have an `/about` route that will execute the component in that file when requested.

These top-level components have a Next.js-specific lifecycle hook, called `getInitialProps`.  It has access to route-related data like the requets (`req`), response (`res`), etc.

Pages are cool because, with a couple exceptions, they feel just like any other React component.  A valid (and boring) About page component:

```js
export default _ => <div>The About page!</div>
```

## Routing and Splitting

Next.js does automatic code splitting.  The splitting is done at page boundaries.  This means that you can be certain that any page you request from your Next.js app only includes the JavaScript that is needed to run that page.  How nice to not have to configure that.

There are other cool things that Next.js provides in order to make this even better.  It has its own router that supports lazy loading.  It allows for dynamic route creation.  There is a `<Link />` component that allows adding an attribute, `<Link prefetch />` that will fetch the route contents and scripts for quick execution down those paths.

## Escape Hatches

The power of Next.js and any framework is the mileage it gets you if its use cases match up to yours.  You can use the framework happily, and it gives you what you want.  Use cases rarely match up 100% of the time.  Next.js seems to realize this and gives you some useful escape hatches to customize what the framework provides by default:

- You can use your customized CSS-in-JS solution, eg postcss
- You can add your data fetching library, eg [`isomorphic-fetch`](https://www.npmjs.com/package/isomorphic-fetch)
- You can add your app state management, eg redux
- You can add a type system, eg Typescript
- You can override the babel config
- You can override the webpack config
- You can provide your own error handling
- You can override some of the Next configuration, eg provide your own magic directories

I haven't used Next.js on anything worthy of interesting overrides, but I am glad for the forethought here.

## Easy Deployment

With all your app wrapped up nicely inside the Next.js framework, it's not surprising that it's easy to deploy.  Ahhhh, yes.  Love me something easy to deploy.  To get a Next.js app to Heroku, add three scripts to your `package.json`:

```
{
  "scripts": {
    "build": "next build",
    "start": "next start -p $PORT",
    "heroku-postbuild": "npm run build"
  }
}
```

Procure your app on Heroku and push your code, and you're one with the Internet.

```bash
heroku create my-next-app
git push heroku master
```

Next.js seems pretty impressive.  That React server render -- so easy!

What have you used Next.js for?  What do you think its sweet spot is?

Next.js is a framework for writing server-rendered React apps.