Introduction

My number one goal as CEO of ShakaCode is that my clients are satisfied to the point they are referenceable. Since the majority of our projects are billed per hour, clear and regular communications regarding time spent on various tasks are critical to having good client relationships. Every week, I send my team and clients 3 reports that show various breakdowns that detail how time was spent. With these reports, our clients can assess the overall level of effort for various tasks and efficiency of ShakaCode development efforts. Beyond just tracking time to a task, we try to break the work up behind a task into more detailed “time entries” that can provide color to what was done.

For our clients that use an agile project management tool, like Clubhouse or Jira, it’s useful to know how much time was spent on various stories and epics. Why?

1. Such data can help for future estimations of story points and required resources.
2. Such data shows where time was spent and how it correlates to delivered work.
3. Such data can help with the evaluation of developer effectiveness.

ShakaCode’s consulting clients appreciate the transparency of having weekly and monthly reports which show a breakdown by:

1. Project — Task — Breaks down time spent on epics and stories.
2. User — Task — Shows how each time each user spent on each story.
3. User — Time Entry — Shows how much time each User spent on each part of every story, such as writing a test for a story, can show details for why a story took extra long.
4. Weekly Report Grid — Shows the day of the week across columns and the users on rows, with breakdowns by project, which provides high-level details on what a developer did for each of the past 7 days.

You can see samples of these reports further down in this document

Thanks

If you are looking for expertise in projects involving React and Ruby on Rails, possibly with server-side-rendering, ShakaCode is taking on new projects. All of our clients are technical experts that have found us mainly via our open-source efforts, especially https://github.com/shakacode/react_on_rails. We help some clients that have a CTO and don’t want to hire additional staff. In other cases, we work side-by-side with an existing team to accelerate projects without adding full-time staff or rushing hiring.

Special thanks to the team at Jilt.com. From our work with Jilt, we got to know of Clubhouse and developed the techniques presented here. If you’re thinking of trying Clubhouse, check out some details on their referral program and consider using me as your referral with this link.

I welcome your feedback. Feel free to email me at justin@shakacode.com.

Toggl Background

ShakaCode uses the Toggl time tracking system mainly for ease of use and good reporting. Toggl tracks time spent based on 3 levels:

1. Time Entry: Freeform editing field. This article describes what should be placed here, based on the task chosen.
2. Task: Tasks roughly map to a Clubhouse story, Github Issue, etc. Tasks require setup in the Toggl web UI. When a task is completed, it is marked as done and then it does not show in the autocomplete for time entries.
3. Project: Each task belongs to a single Project, which is a collection of tasks. Thus, picking a task also picks the project.

Toggl provides summarizing reports that group on 2 levels, such as by Project-Task by User-Task, and by User-Time Entry. The reporting does not allow grouping by Task-Time Entry. Thus, we try to enter the freeform Time Entries so that they make sense without the task name for the summary reports.

Task Definitions Come from Stories/Cards/Issues

Different project management systems use different terminology.

• Clubhouse stories: CH123
• Trello cards have an id, so we can use T123. Many chrome plugins show the ids.
• Github issues have an id: GH123
• Jira stories have an id: XYZ-123

We’ll use “story” for the rest of this article, as well as using an example of Clubhouse with stories and ids like CH123.

In all cases, the project management stories (cards, issues, etc.) map to:

• Toggl Tasks
• Usually, pull requests or some other work output

This allows us to map time back to the intention, which is the story, as well as the result, which is usually the PR.

Stories Map to Toggl tasks

We map stories to toggl tasks. More specifically, we create two Toggl tasks per story, a base tasks and a tasks for reviews of the story.

Why track the Toggl tasks to stories?

1. Provides a detailed placeholder for where time is spent
2. Allows us to revisit the Clubhouse stories to see if the point estimation of difficulty is reflected in the task description.

Why track time spent in review separate from development?

• We want to make sure that a sufficient amount of time is spent on big, tough PRs. Not doing enough code review is bad!
• An excessive amount of time spent during reviews might indicate:
• Problems with the initial story definition
• Problems with the initial code quality
• A tough task

We considered tracking time spent writing tests…

• Pro: Visibility in the effort to create the tests
• Con: If doing TDD, one is bouncing back and forth between implementation, tests, refactoring, etc.

Recommendation: Provide some visibility in the Time Entry (not the task title)

Time Entries to Better Explain Time Spent on Tasks

The time entry in Toggl is a freeform text entry associated with the time tracking to a task. Often, a developer will copy the task definition into the time entry, as the time entries are never shown on the same summary reports with the tasks. Thus, a time entry like “Debugging” should never be used as it’s confusing as to what task it had mapped to.

For larger “tasks,” we recommend prefixing the time entry with the story ID, like “CH123 — “ so that the time entry might look something like this. This provides the ShakaCode client with additional details on where time was spent in completing a longer task. Such time entries for a larger task should typically be less than 3 hours, so as to provide sufficient explanation of time spent.

Epics May Map to Toggl Projects

Toggl allows us to group tasks into “projects.” Larger epics in Clubhouse can roughly map to projects. Since all stories map to epics, it’s not necessary to have the epic name and Epic ID in the task name.

Task Setup in Toggl

Clubhouse Tasks, Dev and Review

The task names are of this format, mirroring the Clubhouse story:

• CH123 — Story Title
• Development including writing tests.
• CH123 Review — Story Title
• Time spent by the reviewers

Why have a review task?

Having a separate review task allows tracking the amount of time spent in review.

It is important to set up both (with and without “Review”)** **Toggl tasks at the beginning of working on the story. It’s a bit awkward to have to add the review task later.

Generic Tasks

For every project, we set up the following generic tasks that are used when the work does not correspond to a story specific task.

• Ask
• Probably needs a task, but one is not yet created
• Bug Investigation
• Other Development Tasks
• For time entries that don’t justify a big enough grouping to be a “Task”. This is a judgment call.
• Other Code Reviews
• Non-categorized code review. Prefer categorized ones.
• Other Design
• Non-categorized design. Prefer categorized ones.
• Other Meetings
• Non-categorized meeting. Prefer categorized ones.
• Performance Investigation
• Ideally, create a story first for the performance work
• Project management

We prefer non-misc, specific tasks where possible. In other words, tracking time to an anonymous task “Misc” is an antipattern.

Reporting

The goal of the setup is to provide useful reporting.

Reporting by Project and Tasks

Reporting by User and Tasks

Reporting by User and Time Entry

When a developer starts work on a task, the developer can copy the task name into the Time Entry and change the information as needed to provide any additional color on how the time was used, such as debugging something difficult, writing tests, etc.

Reporting by the Days of the Week

Clubhouse (Jira/Trello/Github) Toggl Time and Task Tracking was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

TLDR:

• Don’t use an @import url for google fonts!
• Use the gatsby-plugin-prefetch-google-fonts plugin
• Go through this tutorial: on Preload critical assets to improve loading speed.

Backstory

We recently built our new ShakaCode.com website using Gatsby.

I noticed that the fonts jumped around a lot. And I hated that!

While doing some work to update React on Rails for Loadable-Components, I was going through this excellent tutorial on Preload critical assets to improve loading speed. Part of the tutorial included some experimentation with fonts and preloading.

Aha! There had to be a problem with the HTML generated for the ShakaCode home page. I bet it doesn’t preload! Sure enough, it wasn’t! I verified that by searching the page source for the font “Montserrat,” which was buried inside a mass of inlined CSS. Yep, no preload!

I searched the codebase for this font, and I found it inside of a styled-components CSS-in-JS file.

Don’t use @import url for google fonts!

I searched the codebase and found that Montserrat was loaded using the CSS @import rule.

import { createGlobalStyle } from "styled-components"

const GlobalStyle = createGlobalStyle`
  @import url('https://fonts.googleapis.com/css?family=Montserrat:600,800,900|Open+Sans:400,400i,600&display=swap');

Using @import to load Google fonts was exactly what should not have been done. Many search results on this topic pointed to exactly what I observed in the Chrome Dev Tools profiler: "@import" will defer the loading of the resource and slow down the page.

I looked at the performance of loading the fonts on the current live site. In the web.dev tutorial I just mentioned, I got a better understanding of how to use the Chrome Dev Tools Network tab a bit better. To get some better clarity around a slow network, I throttled the network speed just a bit to Fast 3G.

OMG! Of course, the page jumps! The Montserrat font was not even queued until 4.1s!

Gatsby plugin gatsby-plugin-prefetch-google-fonts to the rescue!

Next, I googled around for the topic of how best to apply Google fonts to a Gatsby site.

Ahh, of course, there was a Gatsby plugin for this issue: gatsby-plugin-prefetch-google-fonts. I just had to add the plugin and remove the old font code. Note, the display=swap is automatically set by the plugin. While not documented, I did a quick search for swap on the github repo.

The resulting page source shows the preloads.

Now, all the Google fonts load right at the beginning of the page load.

Here’s the diff of my pull request to the ShakaCode.com source.

I hope you found this useful!

Optimizing Google Fonts on Gatsby Sites was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

In case you haven’t hard, you want to be on Webpack v4! Why? For the official story, see the official release article. To summarize:

1. Much faster build times, so you can see your changes more quickly!
2. Easier configuration, although if you’re using rails/webpacker, you might not see that so much, since you only are customizing beyond the defaults set by rails/webpacker.
3. Better support for code-splitting. If you’re using react-router , you can get a solid performance gain by code-splitting your routes.

While Webpack v4 has been out since February 2018, rails/webpacker has not yet been officially updated.

As of October 14, 2018, I just tested out the pre-release version of rails/webpacker, and it works fine with React on Rails. See the details at the bottom here.

Additionally, I just published React on Rails version 11.1.7, which fixes an issue with server-side-rendering when using the webpack-dev-server, which optionally provides Hot Module Reloading.

In case you want to see how easy it is to set up a live web application leveraging Rails plus React, you really should give React on Rails a try. The React on Rails generator leverages rails/webpacker to enable a zero-config setup of your client-side assets.

Why Use rails/webpacker for Webpack setup?

React on Rails has utilized rails/webpacker since September 2017 for the view helpers and, optionally, for the Webpack configuration. The generator and tutorial utilize the automatic Webpack configuration because it’s awesome for a quick demo. However, many React on Rails applications needing server rendering should consider a custom Webpack setup, as explained below.

Why Have a Custom Webpack Setup?

The main issues I’ve seen with using rails/webpacker for the Webpack configuration are:

1. Do you want the extra layer of abstraction on top of the simplified setup of Webpack v4? Webpack v4 introduced the concept of “modes”. The magic can have its downsides. Not only must you consult the well-written Webpack docs, but you might need to dig into the source code of rails/webpacker to see what it’s doing.
2. rails/webpacker does not support different configurations for server and client rendering. This is recommended (and probably necessary) if you are using server rendering and you need to have different configurations for client and server rendering, such as different entry points. For example, the code for react-router on the client must be different than for server rendering.

My company, ShakaCode, has helped many companies with their Webpack and overall React server-side rendering setup for efficient development and optimized deployments.

Creating a new React on Rails App to Use webpacker v4

I just updated the React on Rails tutorial instructions to include the details of how to use the pre-release version of rails/webpacker. You can find the details here. You can see the basic steps followed here in this GitHub repo.

Upgrading an Existing React on Rails App to Use rails/webpacker v4

The following steps can be followed to update a Webpacker v3.5 app to v4 based on Github’s rails/webpacker master branch. Here is an example commit of these changes. Here is a list of the steps.

1. Update the Gemfile’s webpacker to gem ‘webpacker’, github: “rails/webpacker"
2. Update the package.json’s @rails/webpacker to @rails/webpacker”: “rails/webpacker”. Note, this is how you reference the github version.
3. Merge changes from the new the new rails/webpacker default .babelrc to your /.babelrc. If you are using React, you need to add "@babel/preset-react", to the list of presets.
4. Copy the file .browserslistrc to /.
5. Merge any differences between the new rails/webpacker config/webpacker.yml and your /config/webpacker.yml.

Easy React Server Rendering with rails/webpacker v4 and React on Rails was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

HVMN Testimonial, Written by Paul Benigeri, October 12, 2018

Since HVMN installed React on Rails Pro, they’ve seen a roughly 90% improvement in server-response times. The gain came from a combination of intelligent caching along with a much more efficient Node React Server Rendering Engine.

“I looked at the Scout data on the performance changes after the deployments of both the fragment caching and the change from switching to a standalone Node React rendering engine, and I can confirm that the performance improvements were both significant beyond any doubt.” Derek Haynes, co-founder Scout.

Background

HVMN’s site is a Ruby on Rails app. The customer-facing side uses a single Rails view with a single React component. Routes are handled using react-router along with a Rails wildcard route. Because the site, like most e-commerce sites, depends heavily on SEO, the site server renders React on all pages. React on Rails handles integration of Rails with React. The Rails pages/index.html.hamlview contains one helper call to the React on Rails view helper react_component.

HVMN has been using React on Rails since late 2015. I got to know HVMN’s head of e-commerce, Paul Benigeri, after he got involved in the ShakaCode slack workspace and the React on Rails open source.

Paul reached out to me in late May 2018 to learn about how React on Rails Pro could improve the performance of HVMN’s e-commerce site, especially in regards to server rendering of React with Ruby on Rails.

3 Performance Enhancements

The addition of React on Rails Pro to the HVMN site resulted in reducing the server response times almost 90%. Scout reporting started with a median response time of around 1100 ms and dropped down to a median of about 120ms, an 89% improvement. New Relic showed a similar improvement of the average going from 953ms to 127ms, an 87% improvement.

React on Rails Pro offers 3 types of performance enhancements over the open source React on Rails. These performance enhancements were added sequentially to identify the impact of each.

1. Pre-Render Caching

This cache intercepts the server rendering request such that two requests with the same parameters will not result in JavaScript execution a second time. Of course, many factors come into play with the cache, including any changes in the JavaScript source files.

Pre-render caching provided a slight impact of from 2–5%, per New Relic and Scout data. However, the improvement was too small to be conclusive.

2. Fragment Caching of React Server Rendering

This type of caching is analogous to the Rails fragment cache view helper. The difference is that the React on Rails caching API is specific to rendering a react component. The programmer needs to consider cache keys in exactly the same manner as other fragment caches for Rails. However, in the case of React components, the cache key needs to be optimized based only on the props for rendering. The React on Rails Pro library handles all the other nuances of the cache key, including a determination if any serializers for the props have changed. The API is structured such that the calculation of props is placed in a block so that creating the props is not done if the cache key exists. the site Creating the props typically involves database queries and many string manipulations to convert the data into a JSON string.

Fragment Caching made the biggest difference in overall response times. Measuring the 3 days before and after fragment caching was added, Scout reported a 59% improvement in the median response time for the site’s main controller action (PagesController#index), from 943ms to 382ms. Similarly, New Relic reported the average execution time going from 953ms to 392ms, a 59% improvement.

3. Node React Server Rendering rather than Ruby Embedded JavaScript

I had suspected performance issues from using an embedded JavaScript VM inside of the Ruby VM. One thing that is for sure is that if there are any memory leaks in the JavaScript code from repeatedly running server rendering code. The React on Rails Pro Node Renderer utilizes a standalone Node server using a recent version of Node.js. A big advantage of standalone Node is that we can use proper Node tooling analyze performance and track down memory leaks.

React on Rails Pro Node React Server Rendering provided a healthy boost in performance. Measuring the 3 days before and after the rendering engine change, Scout reported a 69% drop in the median response time, going from 387ms to 120ms. New Relic reported a similar gain of 68% drop in the average response time.

Implementation

You might be wondering if it was difficult to achieve these gains. Installation of React on Rails Pro included installing the gem, turning on the pre-render cache and configuring the Node React Server Renderer. These steps required only configuration, rather than programming.

The enablement of React fragment caching required the same level of detail of any Rails fragment caching. The main steps were to identify efficient cache keys and to ensure that all props were fetched in the block passed to the React on Rails Pro view helper cached_react_component.

Contact Information

For additional details and confirmation of these results, feel free to email:

• Paul Benigeri, HVMN’s E-Commerce Lead, paul@hvmn.com. Paul wrote this: HVMN Testimonial, Written by Paul Benigeri, October 12, 2018
• Derek Haynes, Scout co-founder, support@scoutapp.com
• Justin Gordon, ShakaCode CEO, justin@shakacode.com

If you’re interested in trying out React on Rails Pro, please email Justin. You can find the documentation of React on Rails Pro here.

Comparing Scout vs. New Relic

The below screen grabs support the data above. I dug heavily into the available tools from New Relic and Scout. One thing I really liked about Scout was the ability to have a graph compare 2 periods. I show that in the graphs below. I couldn’t find any such feature from New Relic. One thing I did like about New Relic was that I could get data older than 30 days. Scout is currently limited to 30 days of historical data.

Scout Data

New Relic Data

HVMN’s 90% Reduction in Server Response Time from React on Rails Pro was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

However, it almost happened to me today! I’m sharing what happened so that others can avoid this issue.

I got this message in my company’s help desk (Intercom) on hawaiichee.com.

We have a very active Facebook media effort for our page: facebook.com/HawaiiChee. We’re partnering with many content creators for content, so the message was very plausible.

What made the phishing attempt realistic?

1. The URL provided in the main call-to-action link went to the official Facebook site. That was probably the only part of the email that I read super-carefully. Normally, a slightly misspelled URL is a tip-off to a scam site.
2. There were no other typos in the email. So, the first part of the phishing attempt worked. It got me to click on the URL. Normally, that’s a pretty bad mistake already, but I knew I was going to the official Facebook site, so how bad can that be?

I skimmed very quickly the content on the left side of the Facebook page. HTTPS to Facebook. Must be legit, right?

Nothing jumped out at me, but, to be honest, my skimming was quick enough that I started to fill out the form.

I stopped just short of putting in my Facebook password. Why would Facebook be asking for my password again? This did not make sense. Wait, and what about this grammar error “We made abble this form for”?

WAIT!

WHAT!

Heart racing, I double checked again. It’s the real FB site. What is going on?

Hey, there are more typos on this form. There weren’t, however, any on the email. I guess the hackers only spell and grammar check emails!

BINGO! This is a SCAM!

I noticed the “From” did have a typo in the domain name: “noreply@facbooksupport.com.” Notice, there’s no “e” in the “facebook”!

HOLY !*#!

I was on the verge of putting in my FB password!

I went back and double checked the email. Yes, all real Facebook links. The ONLY surefire clue on the email was the misspelled “From” domain name. I bet that is why Google threw this in my spam folder originally.

I forwarded the email to phish@fb.com. However, I didn’t get any reply. I hope they track the scammers down!

And today, I got the same hack attempt again! But no stress today.

Tips for You to Avoid Getting Hacked

I hope this article might help you avoid getting hacked. The most essential bits of advice I can give you are:

1. Two Factor Authentication (2FA) for sites that offer it, like Google, Facebook, Github, etc.
2. Use a password manager like LastPass.com, 1Password.com
3. Double and triple check from email address domains and links, and don’t click on links unless you’re sure they are legit.
4. Scammers for some reason don’t spell and grammar check, so look out for that!

If this article helped you, please consider how you can help me:

• Check out hawaiichee.com if you’re considering looking for a vacation rental in Hawaii.
• Check out my company ShakaCode if you’d like my help with your web application development, be it a new project or help for your team, especially if you’re using Ruby on Rails plus React. I’m the creator of https://github.com/shakacode/react_on_rails.

How I Almost Fell for Phishing! was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s the common pattern of shaping a state in JS apps:

type State = {|
  loading: boolean,
  data: Data | null,
  error: Error | null,
|};

What’s wrong with this? Let’s see how it can be handled in UI:

render = () =>
  <div>
    {this.state.loading && <Spinner />}
    {!this.state.loading &&
      !this.state.error &&
      <div>{this.state.data.foo}</div>
    }
    {this.state.error && <div>{this.state.error.message}</div>}
  </div>

It can be improved a bit by re-shaping this state:

type State = {|
  status: "loading" | "ready" | "error",
  data: Data | null,
  error: Error | null,
|};

render = () => {
  switch (this.state.status) {
  case "loading":
    return <Spinner />;
  case "ready":
    return <div>{this.state.data.foo}</div>;
  case "error":
    return <div>{this.state.error.message}</div>;
  default:
    throw new Error("¯\_(ツ)_/¯");
  }
}

But the main issue is still there: conditional dependencies between state properties. When loading === false (or status === "ready") it implicitly assumes that data is not null. No guarantees tho. Opened doors into an illegal state.

When you use Flow or TypeScript, these tools warn you that data might be null and you have to add all these annoying checks to calm type system down:

case "ready":
  if (!this.state.data) {
    throw new Error("Uh oh no data");
  }
  return <div>{this.state.data.foo}</div>;

I look at the code above and I’m just sad.

The light

First of all, let me introduce you to the thing called variant.

type status =
| Loading
| Ready
| Error;

This is type similar to enum in TS except its parts are not strings (nor any other data type you familiar with from JS). These things called tags (or constructors).

Now the magic moment: every tag can hold its own payload!

type status =
| Loading
| Ready('data)
| Error('error);

If you’re not there yet, here’s the code (mixing Reason & JS just for clarity’s sake!):

type Status =
| Loading
| Ready('data)
| Error('error);

type State = {status: Status};

class Foo extends React.Component {
  state = {status: Loading};

  componentDidMount = () => {
    api.getData()
      .then(data => this.setState({status: Ready(data)}))
      .catch(error => this.setState({status: Error(error)}));
  };

  render = ({state}) => (
    <Layout>
      {
        switch (state.status) {
        | Loading => <Spinner />
        | Ready(data) => <div>{data.foo}</div>
        | Error(error) => <div>{error.message}</div>
        };
      }
    </Layout>
  );
}

How beautiful is that! There’s no way to get into an illegal state in this component. Everything is type safe. Combine it with “everything is an expression” in Reason and you can use pattern matching at any point of your JSX render tree (spot switch as a child of <Layout />).

You know what to do.

ReasonML: Eliminating illegal state was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a part of “Selling ReasonML to my colleagues” campaign (and to anyone, really), I’m going to spam your feeds from time to time with ReasonML related write-ups (hopefully, plural!). I’m too lazy these days to do epic monolithic posts so it’s going to be almost twitter-like shout-outs about the features I’m excited about the most.

Ok, first one is definitely about modules. It seems this is the number one thing that confuses the most of newcomers from JS world (I was there!) so let’s start with it.

Fact #1: Each .re file is a module

Let’s say you created new file Math.re. Boom, you have a new module in your app called Math.

By convention, all filenames are capitalized to match module name. You can
name file math.re but module name is still capitalized: Math.

Fact #2: All content of the module is exported by default

If you create a type or a function or whatever inside your module it’s automatically available for module’s consumers using dot notation.

/* Math.re */
let sum = (a, b) => a + b; 

/* Now you can use `Math.sum` in another module */

Fact #3: All modules are available globally

Let’s say you created file App.re and want to use sum function from Math. How can you import it? The answer is “You don’t need to!”. All your root modules are available everywhere in your app. You can use any of them once you need it without messing with imports.

/* App.re */

let onePlusTwo = Math.sum(1, 2);

Imagine when you implement some UI where you need Button, Input, Link etc etc: every time you need a new component in JS you have to go up, import it, go back to where you were. With Reason, you can just use whatever you want right here right now without interrupting your flow. So good! Once you’ll start using it, you’ll get how brilliant this is.

Fact #4: No folders (for the compiler), all filenames must be unique

Of course, you can use folders to group your files as you usually do (requires a bit of configuration) but for the compiler, all your files within a project is a flat list of modules. So all your files, no matter where they are located, must have unique names (remember, all modules are available globally). Compiler backs you up in case you accidentally created a file with a non-unique name.

At the very beginning, it might seem inconvenient constraint but in reality, it makes the naming of your modules accurate and explicit across the entire app.

E.g. in JS you can easily get into this state:

// LoginButton.js
export default AuthButton extends React.Component {}

// LoginForm.js
import Button from "./LoginButton";

What a mess! If you ever decide to rename your component you have to change all these places to keep your naming accurate. Meh. In Reason world, you have only one source of truth: file name. So it’s always guaranteed accurate across the entire app.

Read more about modules in the official documentation: https://reasonml.github.io/docs/en/module.html

ReasonML: Modules was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

The integration of Webpacker solves two problems for React on Rails users:

1. Webpacker provides standard view helpers to enable direct publishing from Webpack output to a Rails view. Previously, React on Rails apps would typically put the Webpack output into the asset pipeline. Webpack evolved to fully and better handle many of the Asset Pipeline’s responsibilities, including minification and fingerprinting.
2. Webpacker provides a great starter Webpack configuration. While the prior versions of the React on Rails installation generator had provided a very simple starter Webpack configuration, this was not an area of focus of React on Rails. New installations of React on Rails via the generator default to using the Webpack configuration from Webpacker.

Before Webpacker v3, React on Rails could not utilize the official rails/webpacker with React on Rails. That led to the creation of shakacode/webpacker_lite and React on Rails v8. I documented the details of in the article Webpacker Lite: Why Fork Webpacker? The major benefit of this fork of Webpacker was that it allowed us to figure out the gaps in Webpacker to support a project like React on Rails. The fork led to detailed discussions resulting in a merge of webpacker_lite into webpacker. You can find the details in Webpacker issue 464 and PR 601. The details are only relevant so far as to demonstrate the level of work involved in making this as simple as it is now with React on Rails V9 and Webpacker V3.

Why use React on Rails in addition to Webpacker?

Given that Webpacker already provides React integration, why would you add React on Rails? Additional features of React on Rails include:

1. Server rendering, often for SEO optimization.
2. Direct passing of props from your Rails view to your React components rather than having your Rails view load and then make a separate request to your API.
3. Redux and React-Router integration
4. Localization support
5. RSpec test helpers to ensure your Webpack bundles are ready for tests

Additionally, we have a vibrant community of production projects using React on Rails.

Here’s a quick video walkthrough of creating a new Rails app with Webpacker and adding React on Rails.

With the Webpacker integration and the default Webpack setup, there’s not much complexity with adding React on Rails to a Rails app for server rendering with React + Redux + React Router.

My next article will document migration details of moving from v7 or earlier to v9.

Please reach out to me if my team at ShakaCode can you help you with your React or React-Native apps, with or without Rails on the backend. The use of React on Rails should be ideal for legacy jQuery or Angular apps that wish to convert to using React with Rails.

Introducing React on Rails v9 with Webpacker Support was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

Saturday, June 24th, GORUCO in NYC

Front-End Sadness to Happiness: The React on Rails Story

Abstract: Standard Rails development made me happy like no other programming paradigm in my career. Simple front-end development with standard Rails and a sprinkling of jQuery was ‘OK’ Then, in 2014, I had to build a front-end that dynamically updated like a desktop app. I knew there had to be something better, and I went down the rabbit hole of integrating React with Rails using Webpack. Come find out how my obsessive pursuit of “developer happiness” for the Rails front-end eventually drove me to start the React on Rails gem, the most popular integration of Rails with React using Webpack.

GORUCO 2017: Front-End Sadness to Happiness: The React on Rails Story

Click for more photos from GORUCO 2017

Thursday, June 8th: LA Ruby

Click for more photos from the LA Ruby meetup.

Tuesday, June 13th: Pivotal Labs, Santa Monica, CA.

Tuesday, June 20th: Pivotal Labs, San Francisco, CA.

Thursday, June 22nd, 7 pm: NYC.rb Meetup

Click for more photos from the NYC.rb meetup

Tuesday, June 27th at 6:30 pm: Austin on Rails

Click for more photos from my Austin visit

I’m happy to provide a free, 30 minute video chat consultation to discuss your web or mobile application development needs. Please get in touch at justin@shakacode.com. You can follow me @railsonmaui.

Front-End Sadness to Happiness: The React on Rails Story at GORUCO 2017 was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.

ReactOnRails + Jest + CodeCov + CircleCi Parallelization

At ShakaCode, our internal app, FriendsAndGuests, tends to be our guinea pig for the bleeding-edge use cases of ReactOnRails. Just getting CI to work was no exception. There are a lot of workarounds and “gotchas,” but this should hopefully save you the pain I went through. We chose to use CircleCI as our CI provider and CodeCov as our code coverage provider. This guide assumes you’ve read through the basic documentation for both.

Parallelization

When your app starts to scale, your test suite is inevitably going to get slower. Your first line of defense should always be to stay judicious with what and how you test (see Martin Fowler’s Test Pyramid). Still, this slowdown is inevitable with growth. CircleCI has a great feature called parallelization that allows you to easily configure your tests to run across multiple containers. Parallelizing your build can greatly increase your speed.

If your testing frameworks can be configured to use JUnit reporters (as RSpec, Jest, and ESlint can), CircleCI will read those reports, figure out the median time to test each file, and then properly distribute those tests across the containers. Distributing the files in this way ensures that one container doesn’t end up with only fast unit tests and the other with only slow feature specs. You want the containers to finish their suites around the same time—you’re only as fast as your slowest container.

As a bonus, if any tests fail, they show up in an easy-to-read format right at the top of the page. That means no more searching through endless lines of noise to find your failing test.

If your tool does not have a JUnit reporter but still allows for passing files via the command line in a space-separated format (by the way, scss-lint, slim-lint, and rubocop all let you do this), then you can still use parallelization! The only difference here is that CircleCI won’t be able to tell how long each file takes to be run through the tool, so it falls back to using file size and you may not get as well-calibrated division of the files across the containers.

Here’s a list of tools we currently use where we can’t use parallelization:

• brakeman
• flow
• bundle-audit

CodeCov Flags

One of the cool new features coming out of CodeCov is the use of flags. They allow you to easily split up the coverage of different test suites.

I’ve got guys on my team who only do backend and likewise guys who only do frontend, and they don’t care about each others’ code coverage, so why combine the two? Flags allow you to do that.

circle.yml

There’s a lot going on here, make sure you’re up to speed with the basics of how CircleCI works and what different options mean. Also, watch out for those pwd: client lines, that means we’re running all of the commands in the “present working directory” of the client folder.

machine:
  environment:
    RAILS_ENV: test
    RACK_ENV: test
    YARN_VERSION: 0.24.6
    PATH: "${PATH}:${HOME}/.yarn/bin"
  node:
    version: 7.7.3

dependencies:
  pre:
    # Install Yarn
    - |
      if [[ ! -e ~/.yarn/bin/yarn || $(yarn --version) != "${YARN_VERSION}" ]]; then
        echo "Download and install Yarn."
        curl -o- -L https://yarnpkg.com/install.sh | bash -s -- --version $YARN_VERSION
      else
        echo "The correct version of Yarn is already installed."
      fi
  cache_directories:
    - "~/.yarn"
    - "~/.cache/yarn"
  override:
    - yarn install --no-progress --no-emoji
    - bundle check --path=vendor/bundle || bundle install --path=vendor/bundle --jobs=4 --retry=3
  post:  
    - yarn run build:all:rspec:
        pwd: client
    - mkdir -p $CIRCLE_TEST_REPORTS/jest
    # HACK: junit-reporter fails if file doesn't already exist
    - touch $CIRCLE_TEST_REPORTS/jest/test-results.xml

test:
  override:
    - bundle exec rspec -r rspec_junit_formatter --format progress --format RspecJunitFormatter -o $CIRCLE_TEST_REPORTS/rspec/junit.xml:
        parallel: true
        environment:
          CODECOV_FLAG: backend # tags all Ruby tests
        files:
          - spec/**/*_spec.rb
  post:
    # HACK: for why maxWorkers is needed, see https://github.com/facebook/jest/issues/535#issuecomment-171445481
    - $(yarn bin)/jest --testResultsProcessor jest-junit-reporter --coverage --maxWorkers 3:
        pwd: client
        environment:
          NODE_ENV: test
          TEST_REPORT_PATH: $CIRCLE_TEST_REPORTS/jest # used by jest-junit-reporter
        files:
          - 'app/**/*.spec.js'
          - 'app/**/*.spec.jsx'
    - $(yarn bin)/codecov -p .. --F frontend:
        pwd: client
        parallel: true
    # Other stuff such as rubocop, eslint, flow, scss-lint, brakeman, bundle-audit

general:
  artifacts:
    - tmp/capybara # great for debugging feature test screenshots
    - log/test.log # sometimes needed for hard-to-track bugs
    - tmp/brakeman-report.html # if you're using brakeman

yarn

Since we’re using yarn instead of npm, we need to use override during the dependencies step to avoid installing via npm. That means we now need to manually run bundle check and bundle install as well.

We deviate a bit from the docs regarding yarn because sometimes we want to install newer versions of yarn than what comes with the CircleCI container. We use a simple shell script and cache technique that CircleCI itself used to recommend before they added built-in yarn support. In the post step, we build our webpack bundles ahead of time.

RSpec

Although CircleCI can automatically detect we are using Ruby and configure itself correctly, we have to override this and run RSpec ourselves because we want to specify the custom environment variable CODECOV_FLAG so that CodeCov will know that these are backend tests.

Jest

Next, we run Jest. We’re not using our normal test script from the package.json because we need to do some special things for CI. Jest has a weird issue on CircleCI where it can go over memory if you don’t limit the number of workers. To get around this, we can specify that the maxWorkers is 3. While we certainly could run Jest in parallel, there seems to be some type of strange issue with how the code coverage results get merged together across containers, so opt not to do it here.

Jest JUnit Reporter

In order to get JUnit output (again, this allows for those nice little errors at the top of the page), we need to specify using jest-junit-reporter via the --testResultsProcesser flag. The test results file must be put in a place where CircleCI can find it, however, so we need to use the special TEST_REPORT_PATH that the jest-junit-reporter package will pick up (docs). Unfortunately, there seems to be a bug where if the file does not already exist, the process fails, so we need to put create a blank file at that location first using the touch command.

Jest Coverage

Then, we tell Jest to collect coverage with the --coverage flag. After the tests run, we can use the codecov package to upload the results. We must take care to tell it that the root of the project is actually a folder level up using -p .., otherwise CodeCov will get confused and think that your Rails app folder is the same folder as the client/app folder! While we’re at it, we pass the -F frontend flag to tag our coverage as frontend.

Note: Don’t use --root or --flags as the CLI help recommends; these don’t actually work. Use the short versions I listed above. Also, see comment in the “Jest” section about parallelization needing to be turned off due to coverage report merge problems.

codecov.yml

coverage:
  status:
    project: off
    patch:
      frontend:
        flags: frontend
      backend:
        flags: backend

flags:
  backend:
    paths:
      - app
      - lib
      - db
  frontend:
    paths:
      - client

Here’s how we set CodeCov to give us separate frontend and backend coverage status (I prefer to only see the patch status so I turned project off). Note that the partial line coverage feature seems to cause “file not found in report” errors in CodeCov when trying to view your files, so I don’t enable it here.

client/package.json

// ...
"devDependencies": {
  // ...
  "codecov": xxx,
  "identity-obj-proxy": xxx,
  "jest": xxx,
  "jest-junit-reporter": xxx,
},
"jest": {
    "collectCoverageFrom": [
      "app/**/*.{js,jsx}",
      "!**/types/**"
    ],
    "coverageReporters": [
      "lcov"
    ],
    "moduleNameMapper": {
      "\\.(css|scss)$": "identity-obj-proxy"
    },
    "resetModules": true,
    "resetMocks": true,
    "roots": [
      "<rootDir>/app/"
    ]
  }
}

Most of this is self-explanatory if you’ve read the documentation. We are using the identity-obj-proxy package to fake our css and Sass files during Jest testing since Webpack usually handles that. You may need to make a file mock for other types of imports. Babel support is automatically included in Jest’s core, so no need to configure anything there.

Note: You may also need to set up any aliases you’ve made with Webpack, but my colleague Alex Fedoseev set us up with babel-plugin-module-resolver and has eliminated our need to do that!

Additionally, the Jest coverage output can get kind of spammy because it spits the entire coverage file to STDOUT, so we override that with coverageReporters so that it uses lcov only (this is the type that’s needed by CodeCov). No more spammy output!

spec/rails_helper.rb

if ENV["CI"]
  require "simplecov"
  require "codecov"

SimpleCov.formatter = SimpleCov::Formatter::Codecov
  SimpleCov.start("rails")
end

unless ENV["CI"]
  ReactOnRails::TestHelper.configure_rspec_to_compile_assets(config)
end

Here we startup SimpleCov with CodeCov as the formatter. In addition, we use ReactOnRails’s test helper in development to make sure we don’t forget to run our tests against stale Webpack bundles. However, we already made sure to build the bundles in our circle.yml config, so we can skip this step when in CI.

Gemfile

# ...

group :test do
  gem "codecov", require: false
  gem "rspec_junit_formatter"
end

Self-explanatory, and that’s it!

bonus: flow

If you use Flow, it can take a while to initialize the server. You can tell CircleCI to start up the server in the background at the beginning of your test suite. Assuming you’ve got enough jobs going on (so that you avoid a race condition)your server finishes starting up, then when you start your Flow check, it should be pretty much instantaneous.

test:
  pre:
    - $(yarn bin)/flow start: # start up flow server in background so it's ready to go
        pwd: client
        background: true

Optimized, Parallelized CircleCI Configuration for ReactOnRails was originally published in ShakaCode on Medium, where people are continuing the conversation by highlighting and responding to this story.