Research

With today’s abundance of tutorials, articles, videos, and websites you get exposed to a mass of information and it is important to be able to curate your sources, so you can have a reference to them later, you may never know when you might just write a piece yourself… :-)

If you do, how long it’ll take you to actually do it / finish it…

I started writing this article more than 11 months ago, I know this because that’s my baby boy’s age, around when time management became challenging…

But enough about that…

Side Note : I like to use a few tools to help me out with stuff like this. I love the OneTab chrome extension, (also mentioned by Culture Trip’s Product Director , and my friend Ariel Kedem)it just helps bookmark lists of tabs / links easily with timestamps and an option to name collections. So while writing this article I can almost time travel to the exact dates I was researching.

At first, I wanted to understand if it is all possible to get post data out of a WP site.

So as anyone does nowadays, I went to visit uncle Google… I searched for something along these keywords:

WordPress react

React on WordPress

WordPress extract post data as JSON

WordPress API

And so on…

Here are a few things I found useful:

Writing this, I can’t really remember all the stuff that I read and processed back then, so I’ll just try and TLDR; my recollection of my researches insights for You:

Extracting data from WP is possible with WP REST API

WP REST API has a CLI tool and a JavaScript client (WP-API)

People have done stuff with Angular and WP REST API

Using React to render Front End was possible

Detaching the front end from WP is possible.

So I had my starting point. I understood what was possible and I kind of knew what I want to do. Now it was time to pick the stack and get a POC going…

How I decided on the stack

I’ve worked with React before, but I’ve never implemented server-side rendering. Naturally, working at a start-up, I did what you’re supposed to do in this situation and iterated on my research process:

Search

Read

Try

I went on and dabbled with server-side rendering in React a bit, but back in v15.5.4, it wasn’t all that fun. Then I stumbled upon Next.js… I went through their great tutorial and was really impressed with the pretty simple API, it was (and is) very straightforward and added the great lifecycle hook for SSR: getInitialProps().

TLDR;

Easy setup

SSR out of the box

Routing out of the box

Great developer experience — especially if you already know React

Growing community

An established company behind the tech — Zeit

Caveats:

Understanding when lifecycle hooks get called when you start adding HOC’s and more complicated patterns

Custom routing outside of what is provided by the framework can get complex

Am I on the server or on the client? Confusing at first, even later.

Overwriting Webpack config is a bitch.

I think they say it best on their site: “The React Framework For SEO friendly React…”

It’s simple enough — Next.JS is an opinionated framework, however, not that much.

What I mean is they don’t force you to do anything in a specific way. All they did is add a directory called pages:

The Pages directory is the only thing that Next.JS add — it’s basically the routing.

The Pages directory is the only thing that Next.JS add — it’s basically the routing.

Then all you do is put all your top-level React components into “pages” folder.

And that’s it you will have routes to those pages that are SSR React:

Index.js is your entry point, e.g. => `/` route;

There are a lot of other neat features that the guys from Zeit added to Next.js out of the box like automatic code splitting, static exports, it’s fully extensible — i.e you can add a custom server; your own next and babel config files; and best of all it’s production-ready out of the box.

Zeit has also a great deployment tool called Now that works with Next.js out of the box.

getInitialProps()

IMO (and for the sake of this post) the core of Next.js is this method. Basically, it’s another React lifecycle hook that runs before componentWillMount and on the server. So any data fetching or business logic you would want to do on the server is what goes on in this method:

Sometimes there is no way around `dangerouslySetInnerHTML`

TLDR;

Simplicity in state management.

Observable reactive pattern (or change detection): when something happens to data I want to watch -> do something.

Tooling.

Declarative and readable

Caveats:

Unopinionated store structure — you will need to make decisions

Hidden “magic”

Using MobX with SSR is a challenge — when and how to hydrate stores

When some React component doesn’t re-render — annoying to debug (at least in V3.4.1)

I am not going to start ranting about state management in React now, I promise :-).

My relationship with MobX started out in a React Israel Meetup. Someone demoed it in about 20 min, I immediately fell in love with the simplicity he showed.

After the meetup, I ran home and watched a 30 min EggHead tutorial by the creator of MobX: Michel Weststrate.

Back then I was working at a startup in the fin-tech industry. We were working on a complicated platform to hedge companies F/X risks.

If you know anything about finance, and even if you don’t, you can assume there’s a lot of business logic going on there. MobX handled it beautifully.

I liked the response of our tech lead at the time:

Shout out to Alex Ilyaev, my good friend ;-)

Mostly I like the fact that MobX is easy to write, teach, it has much less boilerplate code than Redux and it just works.

I even prefer it to normal React state. (with hooks being all the rage nowadays — I might change my mind soon enough)

Simple BS generator

TLDR;

Modularize your CSS into a component

Easily extendable.

The full power of JS inside CSS

Declarative nature

Themeing

SSR support

Auto Prefixing

Preprocessor like functionality; support nesting, etc.

VScode / WS plugins

Caveats:

Putting too much logic into styling

How to structure Styled Components? One element with only its style or a React component with declarations in the length of an old school CSS file?

Sometimes shit breaks just because you forgot a semicolon and there is no error or way of knowing even with the tooling.

Formatting template strings is a bitch — also copy/pasting them inside certain IDE’s is annoying.

or a React component with declarations in the length of an old school CSS file

This is another love story of mine.

A lot has been said lately about CSS in JS lately, but I’m not going through that rabbit hole.

I think Styled Components is awesome! Kudos to Max Stoiber, Evan Jacobs and everyone else involved in this incredible project!

In my view, the best way to look at Styled Components is as a CSS lego block. It encapsulates the style into a React component and has the benefit of accepting variables.

You can do a lot of cool shit with it.

Again, I like to KISS (Keep It Simple Stupid) and I believe in progressive enhancement.

Here are some Styled Components:

The beauty is the declarative way of naming your style “blocks”

And we add it to the former example:

The best thing about the actual Styled Components is that they are React Components, e.g they accept props.

You can then do a lot of nifty things like this:

const fontSizeMap = {

S: `10px`,

M: `20px`,

}; const Header = styled.h1`

font-weight: bold;

font-family: Helvetica;



// pass in a "size" prop to the component: font-size: ${ {(size) => size && fontSizeMap[size] } };

`; // Then we can use it in some component: const DemoStyledComponent = () => (

// pass in the size prop to our component

<Header size={ 'M' }>

Use Styled Componets - They're Awesome!

</Header>

);

WordPress

TLDR;

WordPress is the defacto majorly used CMS.

Easy to set up and extend

PHP based templating system (prior to project Gutenberg)

Has user roles, permission and authentication built-in.

Plugin system — you can find a plugin for almost anything.

Caveats

Clumsy — IMO the whole hook, filter and function system is a bit overly complex and leads to clumsy code.

WP Engineers — people who only use WP tend to be too confined to the WP ecosystem, and sometimes are missing basic web development knowledge.

Extending themes may cause a very big overhead.

A lot of WP wizardry.

I guess I can’t sum up this post without saying a few words about WordPress…

WordPress and I have had a love/hate relationship for about 18 years now… I recall using version 3 point something.

Bottom line, WordPress is a great tool and a great CMS. If all you have are dozens of people — it’s a great choice. At Culture Trip, we have over 300 freelance creators working on the WP Admin side. So, at scale, it gets a bit messy. The code is hard to maintain and it is hard to push massive product changes.

That’s why we chose this approach to decoupling WordPress from out front-end.

Bringing it all together

Let’s recap… We have our stack: Next.js, React, MobX, Styled-Component, WordPress, back end REST API. We know what we want to achieve and we know where to start — The article page.

As I’ve demonstrated in the Next.js section, you can see how we would fetch data from WP and render it.

So, it works like this:

A client enters an article page. Our Next.js (node) server calls our BE API with the URL address the client entered (something like sitePath/articles/some-slug ). Back end REST server returns a response with the post content and metadata to Next. Next.js uses the response to SSR the HTML needed for the client. The client browser renders the HTML and bootstraps the JS.

After the clients’ browser loaded all of our JS — All user interactions on the client side are now handled with React & MobX.

This is a simplification of what is actually going on today, but I hope it helps illustrate my point enough. Because, I have not touched a lot of our challenges, like handling 3rd party scripts, hydrating stores, caching, a/b tests, etc. I think I have enough for a whole series of posts.

Conclusion

What did we cover in this post?

My journey, research, and workflow. Why I chose to use React for CT’s front-end. Basics of Next.js , MobX and Styled-Component . Connecting WordPress to our modern front-end stack.

This post is a culmination of almost 2 years of work. It’s funny when I look back at old code snippets, how they started out and how they morphed along this timeframe is staggering. When I searched for old code, I felt like Indiana Jones — doing archeological code digging.

What can you take with you? what is in it for you?

I hope I was able to be clear enough on why you would care about switching a WP site to have a React front-end and why we had to make the change at Culture Trip.

For us, as a company, this decision was what enabled us to move more quickly, hire more talent and build new awesome features, which could not have been achievable with our old stack.

I hope this post will give you enough information to do the same if you want to.

Thoughts about the future.

With Wordpress coming out with Gutenberg soon and rewriting wordpress.com to work with Node.js (project Calypso), there might not be a reason to go down the route we did.

However, this post could just serve a guide to the murky waters which used to run in this river before.

I hope I was able to cover enough grounds in this post, it is definitely a long one. Being this is one of my first posts, I hope I was able to convey my thoughts well enough. If I wasn’t able to, or you have some constructive criticism, I’ll be happy to know in the comments.