Next.js meets Firebase and mobx | I

January 31, 2017 0 Comments mobx, firebase, npm, server

Next.js meets Firebase and mobx | I

 

 


Episode 1 | next.js SSR fundamentals


Just recently I wrote about not using meteor any more as a "one size fits all" solution - not because meteor is bad - but because there's other cool stuff which will no doubt convince you by giving it a chance. In this short tutorial series we are going to use the next.js shiny thing in combination with firebase as the database layer and mobx as state manager. This is not a next.js, firebase promo tour :) I will certainly find things which are super annoying and I'll also report them (until now next.js css handling is irritating to use, but they are working on it).

Vision

Over the next few articles we'll recreate https://tagbag.today. The app consists of an individual input field which allows you to enter one single word or sentence per day. Originally, this was a hackathon project from a few months ago using create-react-app, mobx and firebase.

Topic

This article will cover the basics of ssr with mobx and next.js and not touch firebase at all - if this is boring stuff for you, you may enjoy the followup firebase-auth article.

Preparation

Let's first initiate a new project and add all the dependencies we need.

npm init
npm install --save next@2.0.0-beta.18 mobx mobx-react firebase
npm install --save-dev babel-plugin-transform-decorators-legacy babel-root-import

Using beta.18 here as in beta.19/20 is a with mobx. I'll update this post as soon as the issues are resolved.

Babel


DecoratorsRoot-import: I tend to be confused by relative madness - babel-root-import basically allows you to write instead (where ~/is the root of your source code). : I like the decorators pattern - if you don't, just use the wrapper functions instead. The mobx documentation

  1. serve a useful initial DOM, so that e.g. twitter and facebook can display rich snippets of your website.
  2. performance - there are edge cases in which ssr can also slow you down, but we won't go into that

is pretty awesome so you'll figure out how to refactor the @ decorators :)

The babel plugins are optional, but I included them as they make things more readable.

Next.js automatically parses your .babelrc so let's add the file containing the plugins.

  1. The server initially generates the DOM and sends it down to the client.
  2. The client renders the DOM.
  3. The client waits until resources are loaded and javascript is evaluated.

Next

Last thing left is to add the next.js scripts in package.json so that we can easily start/build from command line.

"scripts": {
"dev": "next",
"build": "next build",
"start": "next start"
},

Getting started With SSR

Why

Server-side rendering is an important part of almost every js based web-application. There are two main goals we want to archive:

I won't go into it too deeply as there are already good articles on why and where to use SSR: just to name one

How

SSR basically works like this:

Just after that, the client generates the initial DOM itself and compares its hash to the servers one. To avoid unnecessary re-renders the server should generate the same DOM as the client. This means that the first render must be deterministic!


Tag cloud