- /pages/index.js // Import React import React from ‘react’ // Export an anonymous arrow function // which returns the template export default () => (
This is just so easy!
- import React from ‘react’ import Head from ‘next/head’ import axios from ‘axios’; export default class extends React.
- Our index page does not implement this performance related feature in details page.
- /pages/details.js import React from ‘react’ // Import Link from next import Link from ‘next/link’ export default () => (
Coming soon. . .!
The term “universal” is a community-coined term for building web apps that render happily on a server. You might be familiar with “isomorphic” as…
@ReactiveConf: React Universal with Next.js: Server-side #ReactJS
The term “universal” is a community-coined term for building web apps that render happily on a server. You might be familiar with “isomorphic” as well but the goal of this article is not to debate names; we are going to learn how to build server-rendered React apps with Next.js.
We’ve talked about building React server-side before. Today we’ll discuss the topic more since it’s an important one.
React apps implement the virtual DOM ideology which is an abstraction of the real/original DOM. This abstraction is very useful to app performance because we can take a portion of the DOM, bind whatever data we need to bind, and insert back to the original DOM tree. This is in no way standardized and is just a concept that front-end frameworks utilize to make better user experience a true story.
Just as every great thing comes with a price, Virtual DOM poses a problem. The original DOM which was received based on some information provided by the server has been lost. You might be wondering why that matters — it does and we will see how.
Search Engines do not care about how your app is architected or whatever ideology was used so as to adjust and fetch the right content. Their bots are not as smart as using your apps like a real user would. All they care about is that once they send their spiders to crawl and index your site, whatever the server provides on the first request is what gets indexed. That is bad news because at that time your app lacks the actual content on the server. This is what the spider takes home from your website:
) that is.
How do we tackle these problems?
Universal apps are architected in such manner that your app renders both on the client and the server. In React’s case, the virtual DOM is eventually dropped on the server as well as using some mechanisms that might give you headache if you don’t choose the right tool.
I have worked with few solutions but Next.js it is very promising. Next is inspired by the 7 Principles of Rich Applications. The idea is to have a good experience while using web app as well as building it. The experience should feel natural.
Next offers more out of the box:
Let’s do something fun with Next.js together. We will use the Football Data API to build a simple small app that shows the Barclays Premier League ranking table. If that sounds like fun to you, then let’s get started.
package and all you need do is install locally and start building your app:
Now run the following command to see your app running at localhost:3000:
I bet this was easier than you even expected. You have a running app in about 5 minutes that is server-rendered. We are making history!
section in the page so as to define global styles and set meta details:
keyword to handle operations that are deferred. See the following example:
, we can actual handle the async request without having to use callbacks or chain promises.
property on the data and printing each of the standings. The class names are as a result of the Pure CSS style included in the head which is a very simple CSS library to get you started.
directory. Let’s create another route to show more details about a team:
component from Next:
will be used to then filter the team’s information:
value to filter the data array from a given team based on their position on the table.
because the data will not persist once the current window exits.
Let’s now render to the browser:
page. We can update the component accordingly:
template should also be updated to include links that point to each team’s details page:
page to handle 4 and 5 errors. Next already displays errors so if that is fine with you, then no need to create the new error page.
This is what a 404 looks like with the default error page:
…but with the custom error page, you get:
command for our app:
Now run the build and start command to prepare for deploying: