I set myself a task last week.
I was checking out some “Get Started” Universal React Redux Boilerplates and found that a lot of them are really complex. They include heaps of dependencies, and have functionality that can take weeks to unpick.
In general, boilerplates serve two functions for me:
Get started quicker, since the app is already scaffolded
Learn about how to scaffold an app
I am much more interested in the second item. As a developer, I like to understand how things fit together, how things work under the hood.
Therefore I set myself the task:
Create the simplest possible Async Universal React Redux boilerplate.
Sounds great, but what does it all mean?
Just want to see the code? Check out this GitHub Repo.
Let’s unpick each word, one by one.
Essentially, Universal describes an app that is both server-side rendered, and has dynamic client-side routing.
Why is this important? Server-side rendering is important for SEO and for rich links and metadata — like when you post a weblink in Twitter or Slack.
Client-side routing offers your users a fluid experience on your website, because the browser doesn’t have to reload when the user navigates between pages.
Async means that we want to fetch data from external APIs before we render the page. We want to render the page server-side with data that is an asynchronous request away.
Why is this important? This is really important for apps where data or content is stored separately from the website code. Let’s say we have data in a database, or we are requesting data from the Twitter API. We want to get our hands on this data before we render the page.
React is the functional rendering library that has been developed by the team at Facebook to work on both the server-side and the client-side. React gives us the functionality we need to render a page server-side, but still initialize the app client-side.
Redux is a state management package that has been developed to be easy to use on both server-side and client-side. Redux give us the functionality we need to pass state between the server and the client.
Defined by the Cambridge Dictionary as:
Text that can be copied and used … in computer programs, with only very small changes.
A lot of websites just render on the client-side. Google Search can now index pages that render on the client-side, so why do we need to go through the pain of creating Universal apps?
The main reason is for rich links and metadata. When you post a page into Twitter or LinkedIn, they scrape the raw HTML of the page returned from the server to find metadata.
This can be a huge issue. Imagine the difference between just your weblink being rendered as text and your weblink being rendered with rich images and metadata. Here’s an example:
Slack post of Pilcro without metadata
Slack post of Pilcro with metadata — spot the difference
Note: Check out howdoesitlookonsocial.com to see how your metadata is rendered on social sites.
Creating universal apps is really complex. There isn’t a standardized way of approaching it yet. A lot of the existing boilerplates are hideously complex.
That’s why I tried to make the simplest boilerplate possible that works on both Mac and Windows.
There is nothing superfluous in the source code. The webpage couldn’t be simpler. It looks like this:
I want developers to be able to unpick all the different functions and packages used in it, hack around with it, test different parts, and ultimately build great universal apps on top of it.
So here is the GitHub repo link.
Check it out — clone it, install it, run it. See what you think. I would love any feedback. And if you like it, make sure you star it and share it!