The Single Page App and Client-Side Routing

OK, so we want to make elaborate web apps which are interesting enough to even have security implications. At this stage in your leveling up you're building apps with multiple screens. But some of those screens will have millions of versions (for every unimagined topic a user creates, for instance). So how do we make a meaningful webpage at /topics/jacksonville-jaguars and /topics/ninja_notes immediately after our user has created a topic with those names?

There really are only three options:

Create each new page as it's own document on the server (rarely do this: only for SEO driven blogs)
Use server-side routing to parse the request and render a template on the server (express does this well enough)
Use client-side routing (today's topic)

Client-side routing is part of the overall paradigm of a Single-Page App (SPA) which is what most of the MV* JS frameworks output.

The Plan

So a single page app is a modern web design pattern. The idea is to give a fluid interesting multi-page web experience while never reloading the page (or all of the expensive resources, images, libraries, etc). Your reddit-clone will have several pages, the default way to do that is to make multiple *.html files and have them link to each other. Each page visit would trigger a complete reload of your assets (photos, js libraries, source code, etc.).

When the MVC frameworks (Angular, Backbone, React, Vue, etc.) started to come out the main benefit wasn't MVC it was faster load times because of implementing the "single page app" pattern.

Here are the 3 ideas we will walk through to get to client-side routing as a thing:

Change on-screen content/pages purely from javascript
Given a URL to a specific page in your app decide what to render
Create a record in your browsers history to enable back buttons

Remember, our goal is to synthesize the experience of navigating from HTML page to HTML page without ever leaving a single-page.

Concept 1: modular page rendering

Instead of a separate file per page we use a function to draw our new page.

All animation engines will wipe the screen and redraw it at least 20 times per second. We can use the same notion, clear the body or hide a div, now draw an appropriate page.

These simple exercises are intended to awaken the idea of a page as a user's experience and not a concrete file or chunk of text somewhere.

Smoke and Mirrors Micro-Task: Show page 1, navigate to page 2, navigate back to page 1

Rendering Pages: Create a webpage which begins by displaying the number 1. Then every 3 seconds re-renders to show the next largest number. (Check out setTimeout if you haven't already. ) Each of these renderings is a "separate page" if you want to see them that way. (What if the number was just inside of a span inside a long paragraph? See, it's a philosophical distinction.)

Modular Programmatic Page: Now create a page which has an input box of type text and a button. When the button is clicked you should receive the value of the input box and if that value has length more than 0 call a function called greetingPage(name) where name is the input box's value. That function should wipe the screen, and add a paragraph which has a greeting for name.

Generate Back Action: Now adapt your greetingPage function to also generate a button which says change name. But an event listener on that button which returns the state of the screen to the original HTML. (Note you might have to go back and store the document.body.innerHTML depending on how you structured your first page.)

Simple Templating / storing HTML for re-use

Here are some tricks for having unrendered HTML that you can keep up your sleeve for later.

Trick 1: multiple pages, all but one hidden.

See the Pen dGKyjZ by Andy Novocin (@AndyNovo) on CodePen.

Simple Pages: Add a fourth page template. Add a button on your page that when clicked alerts "hi".

Trick 2: multiple pages, all hidden, one display area.

See the Pen xZzxyq by Andy Novocin (@AndyNovo) on CodePen.

Simple Pages: Add a fourth to this example. What are the differences with the first trick. Any pros and cons that you can see?

Trick 3: script tags with bad types don't render.

See the Pen MKXWLa by Andy Novocin (@AndyNovo) on CodePen.

Simple Pages: Add a fourth. What are the differences? What are the pros and cons?

Trick 4: inline-template literals.

See the Pen version3 by Andy Novocin (@AndyNovo) on CodePen.

Simple Pages: Add a fourth to this example. What are the differences with the first trick. Any pros and cons that you can see?

For what it's worth, the 3rd trick is the one I see most often in simple page examples. Another trick is to keep separate HTML template files and use a library to help you load them.

Concept 2: Given a URL show the right thing

I've seen 2 ways to do this in the last 5 years, one is pure client side (using hashtags) the other leans a little on the settings of the server hosting your page (but has prettier URLs). Today I'll walk you through the prettier results but I'll give you extra notes on the hashtag-y version for your own exploration.

Head to Glitch.com and make a new "express" app. Change the one line in server.js which said app.get("/", function(request, response) { and add the wildcard character: app.get("/*", function(request, response) {. Visit your URL, then your URL/farts, then your URL/hello/world.

Use that index.html and client.js and visit your URL then also the URL /farts and /kthxbye

This is a simple proof of concept for the simplest client-side routing I can imagine.

Now swap in client2.js from my gist which just adds links. Click around. This has the right behavior (even back buttons) but is NOT a single-page app. Why not?

Now swap in client3.js and navigate around. This is SPA but is missing history/back-buttons and all of that.

Intellectual HW/To-Do: Engineer better routing, include URL parameter reading, data-driven templating, etc.

Concept 3: History and popState/pushState

I don't anticipate that we'll have enough time for this. So I'll give you my hand-crafted sample code and some insights for your own perusal:

See the Pen Small pushState Example by Andy Novocin (@AndyNovo) on CodePen.

The magic parts of that are history.pushState and the popstate event. The upshot is that with pushState we can change the URL and store a JSON of data for the new page. Then whenever the user navigates forward and backward the popstate event is fired and we get the JSON object back.

Note that this example lets you have a back button inside of codepen. We never left the page, but we're making records in the history of the clients.

Implement this in our farts example. So when we "change the page" we add an entry to our history and change the URL.

Last of the Dev half:

HTTPS via Let's Encrypt