React Code Examples in a WordPress Blog

Coby HausrathUncategorized

For an upcoming blog series on learning React, I wanted to have a way to share the code I was writing, including syntax highlighting.

Note: I’m using the “Text” editing view for posts on a self-hosted WordPress instance.

The Naive Solution:

WordPress has built-in <code> tags, but they’re a pain to use with an HTML snippet since reserved characters need to be escaped manually. Meaning: every < and > needs to be entered in the post editor as &lt; and &gt; instead. You must make this change to prevent what’s written inside the <code> tags from being evaluated! It’s quite cumbersome to make these changes manually when editing the post text by hand, and updating existing code is near-impossible without using a separate encoder-decoder. Not a very useful implementation of <code> tags, IMO.

Another Built-in WordPress Option

WordPress also has “shortcodes” that add functionality through plugins. These shortcodes are similar to html tags but use square brackets ([]) instead of angle brackets (<>). The shortcode suggested for code is the [x_code] tag, which makes something like <div id="component">Hello!</div> look like

<div id="component">Hello!</div>

It’s not as compact as the built-in (inline) <code> tags, but it’s better for multiple lines of code that need to be separated from the rest of the text. Better yet, [x_code] tags allow reserved characters to be left alone (and not converted to &gt; or &lt;). But there’s still no syntax highlighting.

With the two above code tags already built in, I can include short bits of inline and multiline code. Unfortunately these options both let me down in the end, since for inline code I must escape all special characters, and for both there’s no syntax highlighting. I really want something that lets me copy code from source files and then paste it into the post without escaping “special” characters or monkey-ing with it much at all.

A Sidenote about Self-Hosting:

The following solutions mentioned on How to Insert Code Into WordPress @ StackOverflow did not work out of the box:

    [code] tags
    [sourcecode] tags

This is because our WP site is self-hosted and not run by

SyntaxHighlighter Evolved Plugin for WordPress

Enable [code] tags with this plugin, then get syntax highlighting by specifying the language with a language="html" attribute or by using an alias like [html] instead of [code]. With this plugin, there is no need for manual encoding of reserved characters – and it includes nice features like line numbering and highlighting. For example:

<div id="component">

The above was made using [html highlight="2"] and [/html] tags.

I’ve found this plugin to work well with code snippets that have been separated into one language per snippet. Multiple languages should be supported in one snippet with the htmlscript="true" attribute, but it only works with HTML/PHP. For React, I’ll be using writing JSX (via Babel) – which looks like HTML within JavaScript. Babel/JSX isn’t supported as its own “language”, so a choice must be made between HTML orJS: this plugin can’t highlight both inside the same snippet.

Finding a Solution for ReactJS

The overall operation and look of a React app comes from (at least) HTML, JS, and CSS – each of which usually live in separate files. The above options can be great for showing a single code snippet in one language, but there’s no built-in WordPress way to link snippets of different languages together with a “live preview” or “results” showing how they work together.

Here are three services that tie together HTML, JS, and CSS code snippets with a preview:

For each of these services, once the code snippet has been added on the site, it can then be embedded into a WordPress blog post by pasting in one or two HTML tags. Here are examples of each service’s embed result:


JSfiddle embed code:

<script async src="//,css,js,result/"></script>

JS Bin on
(it’s okay if you don’t see anything above)
JSbin embed code:

<a class="jsbin-embed" href=",css,js,output&height=150px">JS Bin on</a><script src=""></script>

See the Pen rmmgMe by Coby Hausrath (@cobyhausrath) on CodePen.

CodePen embed code:

<p data-height="173" data-theme-id="light" data-slug-hash="rmmgMe" data-default-tab="html,result" data-user="cobyhausrath" data-embed-version="2" data-pen-title="rmmgMe" class="codepen">See the Pen <a href="">rmmgMe</a> by Coby Hausrath (<a href="">@cobyhausrath</a>) on <a href="">CodePen</a>.</p>
<script async src=""></script>

Comparing the Options

JSfiddle, JSbin, and CodePen each highlight syntax and combine HTML, CSS, and JS with the resulting output. Unfortunately JSbin requires a Pro account to embed a snippet on an HTTPS site – and since this site is an HTTPS site, loading the snippet via HTTP is blocked by the browser. For the two examples that *do* load above, they are fairly compact and it’s easy to see that all three inputs (JS, CSS, and HTML) help make up the result.

Taking JSbin out of the running, that leaves JSfiddle and CodePen. Of the two, I like that CodePen has the results always displayed at the right of the code. I also like that CodePen lets you “embed” scripts within the configuration of the JS code – so there’s no need to add <script> tags at the top of the HTML. This works great to keep examples short and to the point when scripts like React and React-DOM may be used in every snippet.

Decisions, Decisions…

Even though JSfiddle is completely free (well, ad-supported), I’m leaning towards selecting CodePen as the embedded-source-code-and-example tool for future blog posts because its free version has more features than does JSfiddle. We might go with a paid plan, but I don’t see any immediate reason to do so: the good news is if we did upgrade, there wouldn’t be any loss of functionality down the road if we let the pro-level subscription lapse. Whereas if we paid JSbin to enable HTTPS embeds, dropping that subscription later on would force us to redo those snips with another provider only for the sake of keeping the snips we’ve already embedded working.

Most of all, I don’t want anyone to ever have to use the Wayback Machine to see the full content of the blog.

What have you used for code snippets on WordPress?

How MicroConf Kick-Started Our Business

Chris AchardBusiness, React0 Comments

MicroConf is two day conference focused on self-funded startups. They have speakers that will inspire you and help you start, grow, or sell your startup. It turned out to be one of the best things we could have done for our new business.



My co-founder and I went into MicroConf thinking about starting a B2B SaaS app. We had a few ideas and had started the process of customer validation to determine the real problems our target markets were facing. I went in feeling pretty good about the process we had used so far, and the software that we were getting ready to build.

Imagine my surprise then, when one of the first piece of advice the speakers gave was don’t build a SaaS product first! It was repeated at least three times over the course of two days. The speakers encouraged us to start with something we can do quickly. A SaaS startup normally takes a long time to get going if you’re starting from where we are, and then – if you are successful – you’re rewarded with ongoing customer support. So – what should we do instead?

Start Small

The most common advice given was to start with an info product. An info product can be anything you can sell digitally – an ebook, infographic, video course – or anything else you can produce with a computer and sell online. The benefits over a SaaS product are numerous:

  1. You can get up and running quickly
  2. No support calls at 2am
  3. Learn how to sell online

An info product will teach you how to sell things online. The whole idea is to get the first experience of selling something you’ve created to a stranger on the internet. The first time you do that (make your first $1 online) is a magical moment. That will give you momentum – and will help you get started on your journey.

Just Ship It

Once we had decided not to start with a B2B SaaS app – we were faced with a question: “What should we build first?” The answer for us was so obvious that it’s embarrassing that I didn’t think about it first.

A year ago, I actually started down this path already – and I have an almost completed ebook about React… just ready to get finished! I wrote it because I had several beginners ask me about React (I use it for my day to day consulting) – and I started to teach them how to build web applications with it. After doing that for a while, I thought: “Hey! I should write this down…”

MicroConf reminded me: don’t wait for it to be perfect – or you’ll never get across the finish line. So after the first day, we decided to start with the React e-book, and skip the B2B SaaS startup.

In order to ship as soon as possible, we worked hard to get a landing page up, and we started to tell people about it.

Learn React!

Learn react 3

Get a FREE sample chapter!

Be the first to know when our beginners guide to React is available!

Powered by ConvertKit

Charge More

We haven’t started selling the e-book yet, but the most common advice in all of MicroConf is to charge more. We constantly undervalue our contributions and output – and almost every speaker had some variation of this message in their talk.

We probably would have sold our e-book for $29 max before hearing that advice again and again, but after hearing the speakers and talking to the other conference goers, I think a $49 price point is totally reasonable for a 250 page book. I still can’t shake the urge to charge less though, so the plan right now is for a sale price of $29 for launch. We’ll write all about the launch – so check back to see if that was a good idea or not 🙂

Moving Forward

MicoConf is a fantastic conference to get you excited about your business. I had been following Rob and Mike and watching the old MicroConf videos for many years – but this conference still exceeded my expectations. The talks were inspiring, and the “hallway track” (talking to other conference attendees between talks) gave me more new ideas for our startup.

I left MicroConf with a huge to-do list, and the momentum has pushed us in better directions. Next year I hope to have grown the company from zero to a solid business for me and my co-founder – and feel confident to attend the Growth Edition instead of Starter!

How we built a React Native app in 24 hours (and won a hackathon!)

Chris AchardReact0 Comments

This past weekend was the Indianapolis AT&T IoT Civic Hackathon – 24 hours of building, making, and playing with IoT hardware and software. The theme of the event was for projects to be related to the economy of Indiana – specifically in the areas of manufacturing, agriculture, and logistics/transportation.

I was invited to join an existing team by a friend from college. They had a group of four hardware guys already, and needed someone who knew software to build the app portion. We held one group meeting before the event to come up with ideas.  We generated a lot of good ones, but most of what we came up with would have been far too much work to complete for a 24-hour hackathon.

Being Realistic

It didn’t matter how neat our ideas were – if we couldn’t execute on them in 24 hours, then the project would be doomed before it started. At the end of the meeting, we had developed one single (but fuzzy) idea that we thought we could execute in a day. One of the team members had some old lockers in his office – and our group’s idea was to make an app to control access to them. For an interesting hardware angle, we thought we could integrate Bluetooth Low Energy (BLE) in some way. And given the three broad hackathon categories, we thought we could probably make it fit in one of them. All we had was a vague idea – but it was good enough to get started.

How can you build anything useful in 24 hours?

Now at the hackathon itself, the first thing we realized when we started working together was that we had a lot of ideas about what we wanted to build – too many ideas in fact.  If we tried to build all of them into the final product we would never get done in 24 hours.  We had some great ideas about authorization and access, Alexa integration, social features… and on and on – but we knew that even if we could build them in a day (which we couldn’t), then we would still have to fit all of that into a three minute presentation.

To be successful, we had to focus our efforts on two things.  Particularly, we focused on what we could possibly

  1. build (in the next 24 hours)
  2. present (in the three minutes we would have onstage to make our impact on the judges)

With too much to do and not enough time, we got started.  Not by building, hacking, creating…but the opposite: cutting features.

Working backwards, we started with the presentation – what could we present in our three minutes onstage?  With the focus on what would matter for the final presentation, we decided on the core functionality of our app that we would demonstrate:

  • Use a mobile app to unlock a box
  • “Check Out” a piece of equipment
  • Return that equipment to a different box

We also decided to focus the app on one vertical in the theme of the event: manufacturing.  We chose this specifically because of the amount of tools and equipment that could need to be secured in the manufacturing vertical.

With those constraints, we felt that we had a plan for what we needed to build in the next 24 hours – so we got to work.

Know Your Strengths, Then Focus

I was the only “software person” on our team, as the other members were the hardware experts. So when I started designing the React Native app, I knew I had to keep it simple. My design process started like this:

I decided to use the React Navigation library, since I had used that before, and skip the fancy animation I had planned. I skipped logging in (since that’s not interesting in a three minute demo), and made the text large and readable. The whole app was designed and built with the presentation in mind. I knew that if the presentation was rushed, or the audience couldn’t read the app – it didn’t matter how cool it looked up close to me!

Leverage React Native

During the hackathon, I had to make a conscious decision to not waste time fighting the technology to get every last visual detail to be perfect, but instead to leverage the strength of React Native to get a functional UI in the minimum time. When you have 24 hours, it’s not important if you get the app to look exactly how you want it to look – what’s important is that you get it to look good enough…and then move on. You can always go back later to fix design flaws if it’s absolutely necessary.

When designing a native app, it’s easy to get caught up in tiny design decisions that take a long time to work through. To make a native app quickly, you have to learn how to let go of those battles, and do whatever is easiest. I used Tab Navigators and Stack Navigators – because that’s what’s easy to use for me. I had grand designs for a unique card list interface – but that would have fought against React Navigation’s natural navigation flow, so I dropped that too. In the end – it was more important that it worked.

When it came to integrating with the BLE beacon, I wanted to keep that as simple as possible too. I found an existing library (react-native-beacons-manager), and as soon as I got the phone to read RSSI from our beacon with it – I moved on to the next feature. Choosing a library for a hackathon is different than picking one for a real product. I didn’t care about future support or how robust the library was – all I optimized for was getting it to work as fast as possible. It’s not often that I get to develop that way; I’m usually worried about features, support, and community – so it was fun just to see how fast I could get something working with the tools I had.

Have Fun

A hackathon isn’t just about building something cool in 24 hours. I met interesting people, learned new things, and had a lot of fun creating something new. Plus now I can say that it’s possible to build a complete React Native app in 24 hours!

If you’re interested to read what kind of code is possible in 24 hours, we’ve open-sourced everything! Check here for the source of the React Native app. Here’s the video of our presentation:

Besides our own, I was impressed by how much was accomplished by all the teams collectively over the course of this short event.  In the end, 25 other teams presented a bunch of great projects as well.

Thanks AT&T, thanks Launch Fishers, and thanks team!