Migrating Rails 6 React to Rails 7 React

2023-06-26T00:00:00+00:00

CasePointer’s disease reporting portal is built on React and Rails 6, and it’s time for an upgrade to Rails 7. This blog post will cover the steps, benefits, and challenges of migrating from Rails 6 to Rails 7, and offer valuable insights into the world of Ruby on Rails.

With the recent release of Rails 7, there are many new features and improvements to explore. One of the biggest changes in Rails 7 is the retirement of Webpacker in favor of using the native webpack for bundling JavaScript.

For those who are not familiar, Webpacker is a Rails gem which is a wrapper around the webpack build system that provides a standard webpack configuration and reasonable defaults.

Steps for migrating Rails 6 React to Rails 7 React

To migrate a Rails 6 React application to Rails 7 React, follow these steps:

1. Update the Rails Gem in the Gemfile

In your application’s Gemfile, update the Rails gem version to Rails 7:

-gem "rails", "~> 6.1.4"
+gem "rails", "~> 7.0.0"

2. Upgrade Rails packages

Upgrade the Rails packages using Yarn:

yarn upgrade @rails/actioncable --latest
yarn upgrade @rails/activestorage --latest

3. Run the Rails update task

Run the following command to initiate the Rails update task:

bin/rails app:update

This task guides you file by file to integrate the new Rails 7 defaults. Refer to the Rails documentation for detailed information on this update task.

4. Remove Webpacker

Since Webpacker is no longer the default in Rails 7, follow these steps to remove it:

Remove the webpacker gem from your Gemfile:

-gem 'webpacker', '~> 4.0'

Remove the webpacker.yml file and any other files associated with webpacker.

Run bundle install to update the Gemfile.lock:

bundle install

5. Setting up Webpack

To set up Webpack for your Rails 7 React application, follow these steps:

Install webpack and other necessary libraries:

yarn install webpack webpack-cli @babel/core

Create a webpack.config.js file at the root of your application:

// webpack.config.js

const path = require("path");
const webpack = require("webpack");
// Add other necessary plugins and configurations

module.exports = {
  // Webpack configuration options
  output: {
    // Make sure to use the path of the rails asset pipeline
    path: path.join(__dirname, '/app/assets/builds'),
    // ...
  }
  module: {
    rules: [
      // Add CSS/SASS/SCSS rule with loaders
      {
        test: /\.(?:sa|sc|c)ss$/i,
        use: [MiniCssExtractPlugin.loader, 'css-loader', 'sass-loader'],
      },
      {
        test: /\.(png|jpe?g|gif|eot|woff2|woff|ttf|svg)$/i,
        use: 'file-loader',
      },
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader"
        }
      }
    ],
  },
  // ...
};

Add a .babelrc file for Babel configuration:

{
  "presets": ["@babel/preset-env", "@babel/preset-react"]
}

Update the scripts section in your package.json:

{
  "scripts": {
    "build": "webpack",
    "dev": "webpack --watch"
  }
}

6. Update Rails asset tags

In your application views, update the asset tags from stylesheet_pack_tag and javascript_pack_tag to stylesheet_link_tag and javascript_include_tag, respectively:

<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>

7. Start the dev server

Start the Rails development server with:

rails server

Then start the React development server with:

yarn run dev

By following these steps, we can take advantage of the new features and improvements in Rails 7 while continuing to leverage the power of React.

Integrating Laravel With a React Frontend

2021-05-07T00:00:00+00:00

Photo by Scott Webb on Unsplash

Frontend frameworks can be useful, and provide a lot of advantages over server-side rendering of views. It’s not uncommon now for websites to be purely presentational frontend applications. Thankfully Laravel provides some helpers for including a dedicated frontend, including a fantastic npm package, laravel-mix, which heavily simplifies the use of webpack.

In this article I’ll go over how to set up a new Laravel application to work with React as its frontend. While this article may focus on React, the main issues are the same regardless of framework. You’ll need to:

Add your JavaScript application to the project’s file system and set up a build process for the frontend sources
Write some additional code to bootstrap your frontend application once the page has loaded
Carefully set up URL conventions to distinguish between frontend and backend routes.

Scaffolding The Frontend

In a standard Laravel 8 application (created using composer create-project laravel/laravel <NAME>), the frontend JS application is stored in the /resources/js folder. Laravel provides a helper package called laravel/ui, which can be used to scaffold the frontend with many popular frameworks, including React. To scaffold an empty React application, you can run the following:

composer require laravel/ui
php artisan ui react

This will add a new folder resources/js/components/ with a single file called Example.js in it, which contains a basic stateless functional component called Example. It’ll also add a new line to resources/js/app.js that requires the Example component. Finally, webpack.mix.js will be updated to include adding React in the build. I’ll go over what this file does in the next section.

Compiling Assets With Laravel Mix

Laravel Mix is an npm package that comes bundled with every Laravel application. It’s not Laravel specific though; you can add it to any application where you want a simple build process. It defines helpers for popular frameworks, React included. The mix.react() helper automatically handles adding in Babel to support using JSX syntax. For Laravel, the frontend build process is configured in webpack.mix.js. By default, it includes some scaffolding code that gives you a general idea of how it can be used:

const mix = require("laravel-mix");
mix
  .js("resources/js/app.js", "public/js")
  .react()
  .sass("resources/sass/app.scss", "public/css");

To run this build process, use the npm run dev command. This will use laravel-mix to compile everything specified in webpack.mix.js. The output directory for the build is also specified there. You can also start a basic development server by running php artisan serve.

This works just fine out of the box, but one thing worth noting is that by default, it’ll package all the code, including your dependencies, in the same file: public/js/app.js. This will cause the entire dependency tree to be reloaded if you make even a single line change to your code. You can use the mix.extract() helper to put the modules into a separate file, public/js/vendor.js. This allows the browser to cache your dependencies, which won’t change too much, separately from your application, which will change much more often. Here’s how this looks in webpack.mix.js:

mix
  .js("resources/js/app.js", "public/js")
  .react()
  .extract(["react"])
  .sass("resources/sass/app.scss", "public/css");

Then, to actually include your built JavaScript sources, go to views/welcome.blade.php and add them in the header, in this order:

<head>
  . . .
  <!-- Include Frontend Application (webpack mix) -->
  <script defer src="/js/manifest.js"></script>
  <script defer src="/js/vendor.js"></script>
  <script defer src="/js/app.js"></script>
</head>

The order is important because each successive script depends on the content of the previous one being defined.

Notice that all the script tags have the defer attribute added to them. This forces the browser to wait until the DOM has fully loaded in order to execute the scripts. If you don’t add the defer attribute, you’ll end up with a blank screen when you try to load the application. This happens because the browser will, by default, run your scripts as soon as they’re loaded. And, when they’re in the head section, they get loaded before the body. So, if the script loads before the body, the root element of the React application won’t be in the DOM yet, which in turn causes the application to fail to load.

Handling Frontend Routing

The next roadblock to tackle for setting up the frontend is routing. If you’re planning to have the frontend do its own routing, you’ll need to make sure that the backend routes don’t clash with the frontend ones. You’ll also need to make sure that, for all routes that the backend doesn’t recognize, it falls back to rendering the layout page that bootstraps the frontend, and not a 404 page. If you fail to do the latter, nested frontend routes won’t work if you navigate to them directly, or refresh the page after navigating from the root URL.

One way to ensure the routes don’t clash is to add a prefix like /app/ for web routes. API routes already have the /api/ prefix set up by default, and shouldn’t pose any issues. Then, since all frontend routes won’t be recognized by Laravel, we’ll want to add a fallback route. The fallback route ensures that welcome.blade.php, which contains our root React component Example, gets rendered instead of a 404 error page for all frontend routes. We can do this by using Laravel’s Route::fallback() function in /routes/web.php:

Route::fallback(function() {
    return view(welcome);
});

Make sure you add this at the very bottom of /routes/web.php, so that it’s the last route registered by your application. This is recommended by the Laravel docs and is also good practice since this route should be the last possible route to match any given URL.

CSRF Tokens

One other thing that’s important to mention is that by default Laravel has built-in features for generating and verifying CSRF tokens. This is set up in the VerifyCsrfToken middleware class that comes bundled with a fresh application. It provides nice and easy helpers for Blade pages like @csrf to ease adding this to your forms as a hidden input. However, if you’re making forms outside of Blade in React, you might receive an error page that says 419 Page Expired when you try to submit a form or send a request:

This error happens for both vanilla HTML forms, and when sending a POST request via JavaScript, depending on the library being used. For example, I’ve encountered this issue when using jQuery, but not axios.

You can handle this in a few different ways. The easiest way is to simply add an exception for this route in your VerifyCsrfToken class:

class VerifyCsrfToken extends Middleware
{
    /**
     * The URIs that should be excluded from CSRF verification.
     *
     * @var array
     */
    protected $except = [
        "/my-route"
    ];
}

However, this removes CSRF protection entirely and in most cases, you’ll want the CSRF protection in your forms. This can be done by setting either X-XSRF-TOKEN or X-CSRF-TOKEN request headers, and also by adding a _token property to the request parameters containing the CSRF token. It’s important to note that these similarly named values are not the same thing. The XSRF token is just an encrypted version of the actual CSRF token. Laravel 8 always sets the XSRF-TOKEN cookie in the response headers by default:

This means that XSRF-TOKEN is defined in document.cookie when the page loads. By default, axios (which is included with your new Laravel application) automatically looks for this value in the cookie, and adds it to the request headers.

Conclusion

And that’s it! I’ve found Laravel works pretty well with a dedicated frontend once you get the initial setup out of the way. Have any questions? Feel free to leave a comment!

React: Style Tips

2019-09-28T00:00:00+00:00

Photo by Harpal Singh on Unsplash

I’ve worked on a couple of large React projects over the last few years. In my experience, one of the trickiest parts of getting a React project up and running is figuring out how you want to visually style your application in the browser, so I’ll share in this post some of the ways I’ve styled my projects.

CSS Modules

Libraries like Material-UI (which I’ll discuss next) do a lot of the work of styling for you. However, sometimes you’ll still need to define styles unique to your project, and the most common way is with CSS.

For projects created with create-react-app, any CSS you include in a React project isn’t scoped. This means that if you define a class tall in one component that has a height of 40 pixels and a class tall in another component with a height of 80 pixels, one of your rules will overwrite the other—whichever makes it into the compiled CSS file last. However, webpack allows you to use CSS modules, which restrict your CSS rules to components that explicitly import them. It took me a long time to figure out how to use them due to lack of relevant documentation, but eventually I discovered a very easy way to do it.

If your file structure looks like this:

- app/
  |-App.js
  |-App.css

It’s as simple as renaming your CSS file like this:

- app/
  |-App.js
  |-App.module.css

Using the suffix .module.css tells create-react-app that the rules within should be scoped only for where they’re imported. They can be used like other styles by importing and passing the classes like this:

import styles from './App.module.css';

export default function Component(props) {
  return <div className={styles.myClass} />;
}

Material-UI and similar libraries

There are many different design philosophies for web, but probably the most popular is Google’s Material Design. Material Design lays out some rules that help keep a user interface uncluttered, intuitive, and pleasant to use. However, jumping into the guidelines on Google’s website can be very intimidating. In addition, manually defining CSS for your web application is a lot of work. There are several different libraries that offer solutions to this, my favorite being Material-UI. Material-UI provides a set of components that you can reuse to put your application together.

Here’s a simple example showing different styles of text fields:

import TextField from '@material-ui/core/TextField';

export default function TextFieldDemo(props) {
  render() {
    return (
      <form>
        <TextField
          label="Name"
          value={values.name}
          onChange={handleChange('name')}
        />
        <TextField
          label="Name"
          value={values.name}
          onChange={handleChange('name')}
          variant="outlined"
        />
        <TextField
          label="Name"
          value={values.name}
          onChange={handleChange('name')}
          variant="filled"
        />
      </form>
    );
  }
}

And here’s what that looks like:

Vanilla CSS with Material-UI

It’s also important to note that Material-UI’s preferred way of defining additional styles is using CSSinJS rather than plain CSS. Given the following CSS:

.button {
  margin: --theme-spacing
}

.input {
  display: none
}

You would instead use the following JSS object:

{
  button: {
    margin: theme.spacing(1),
  },
  input: {
    display: 'none',
  },
}

Using the styles in your project is mostly the same after that, but I won’t go into detail about that here. CSSinJS has some advantages (which you can read about in the Material-UI documentation as well as on the CSSinJS website), but I prefer vanilla CSS. It’s not immediately obvious from their site, but you can still use vanilla CSS as well as CSS modules with Material-UI, and setting it up is pretty simple.

First, you need to make sure that your CSS is injected before styles included with Material-UI. There are two steps to making this work: first, you define an injection point for your CSS by adding an element to your index.html at the injection point:

<head>
  <noscript id="jss-insertion-point" />
</head>

Then, you wrap the entire application in the StylesProvider component with a prop named injectFirst:

import { StylesProvider } from '@material-ui/styles';

class App extends Component {
  render() {
    return (
      <StylesProvider injectFirst>...</StylesProvider>
    );
  }
}

Now, your imported CSS will take predence over the styles provided by Material-UI, so you can still use vanilla CSS if you like!

Conclusion

These methods have worked great for me, but they’re certainly not the only way to do things. Leave a comment if you’ve found a library you like, or have an approach you recommend!

Campendium: A Responsive, Fancy Detail Page

2019-09-09T00:00:00+00:00

This week, I was very excited to deploy a project for Campendium, one of our long-time clients. As noted in my recent post on Campendium updates for the year, Campendium has thousands of listings of places to camp and provides a great infrastructure for the development of a rich community of travelers around North America.

For the past few months, I’ve been working on a significant update to Campendium’s campground detail page, the page template where in-depth information is provided for each of Campendium’s locations. This is equivalent to a product detail page on an ecommerce site.

The “guts” of the update included a new detail page design with expanded responsiveness, the introduction of 360° videos, and expanded user driven content in the form of Question & Answer (Q&A or QnA), reviews, notes, nightly rates, etc. Read on to find out more and see video examples of several of the features!

User Interface & Responsiveness Updates

One of the things the Campendium team and I are most proud of here is the responsiveness of the new design. In the case of traveling and camping, responsiveness is important since a large amount of traffic comes from mobile devices, relative to what you might see in other industries.

User images are shown as “hero images” and the user interface updates depending on the browser device and width, as shown in the following videos for Gilbert Ray Campground and Cayuga Lake State Park.

A preview of responsive behavior on the campground detail page with user submitted photos.

A second preview of responsive behavior on the campground detail page with embedded maps.

Another updated design usability tweak was a sticky navigation bar to navigation throughout the page, which can get especially long with user submitted content. See how the “Overview”, “Video”, etc. links become sticky as you scroll down on the page, and the current region coming into view of the page is underlined:

Navigation becomes fixed to the top of the browser as a user scrolls through the content.

Campendium uses Ruby on Rails as a backend, a bit of Bootstrap, and Sass and best practice responsive design is used throughout this updated user interface.

360° Videos

The Campendium team has been hard at work creating 360 degree videos of the various locations to provide significant value to their users. These videos are now embedded into the campground detail page. Video hosting is provided by YouTube and dropped into the Campendium campground HTML template.

A video in a video—a 360 degree video example.

I personally think these 360° videos are awesome, especially to those visual learners out there! You can learn so much from a video that can be hard to capture in user reviews.

Community Q&A

Another new feature with this deploy is the introduction of community driven Question & Answer. Users can submit questions about a campground, and users who have contributed to this campground are invited to respond (or they can opt-out site-wide to responding to questions). In addition to Q&A itself, user content can be “upvoted” (marked as Helpful) or flagged for an improved user content browsing experience.

All Q&A functionality is driven by JavaScript coupled with the Ruby on Rails backend.

Expansion of User Contributed Content and Features

Finally, this update includes expansion of user contributed content in addition to Q&A. This includes the ability for users to contribute notes, cell signal reports, and nightly rates. Reviews can now be filtered by user profile information and sorted by date or specific ranking. Reviews can also be searched by keywords and those keywords highlighted in the results. The following video demonstrates sorting and searching of reviews with highlighted keyword match:

Review searchability with highlighting and filterability.

All search functionality driven by JavaScript on the frontend, and a Ruby on Rails backend coupled with Sunspot and Solr.

Who Doesn’t Love Stats?

Just for the sake of sharing stats, from GitHub, this update included:

215 changed files
6,284 additions
3,924 deletions (removal / cleanup of unneeded JavaScript files)

Campendium v2019: A Summary of Recent Updates

2019-08-05T00:00:00+00:00

This year has brought a handful of exciting changes for Campendium, one of End Point’s long-time clients, by yours truly. Created by campers for campers, Campendium has thousands of listings of places to camp, from swanky RV parks to free remote destinations, vetted by a team of full-time travelers and reviewed by over 200,000 members. I thought I would take some time to summarize these recent updates.

Maps and Clustering

Campendium uses Mapbox for map rendering to display campgrounds and locations throughout North America. One of the new features added this year was clustering of campground locations, where campgrounds are grouped together and presented in a “cluster” with a size relative to how many campgrounds are in the cluster.

If a user is searching for campgrounds in a broad location, they can see where campgrounds might be more densely grouped by location. Once a user zooms in zoom in a couple of clicks, the campgrounds are no longer clustered and individual campgrounds locations can be seen. While working on this update, we spent a good amount of our time tweaking and troubleshooting the optimal clustering behavior to provide the most benefit to those searching for a campground. Mapbox GL JS works in parallel with ReactJS, and runs with a Ruby on Rails back-end.

Advanced Filtering

Another exciting was the introduction of advanced filtering in the search interface, presented in combination with map display. Users can filter campgrounds by category (e.g. Public Land, RV Parking, Parking, Dump Station), filter by price (with a slider), hookups, campground policy (e.g. age or pet restrictions), discounts, recreation, and facilities. All of this search filtering is driven by Sunspot, a Ruby on Rails gem for working with the popular Solr search engine. Results can be sorted by user provided reviews, price or distance from a specific GPS location. Here, much care was given to provide the best user interface for presenting this valuable functionality.

“Supporters Only” Features

Another recent update to Campendium includes functionality to offer user subscriptions. Registered users can sign up to support Campendium on a monthly or annual basis, and subscriptions are set to auto-renew at the end of their subscription period. This paid support hides advertisements throughout the site (advertisements are controlled by a third party), and advanced filtering on cell reception. There are plans to expand supporter features in the future. Ruby on Rails combined with StripeJS is used to manage subscription payments, and Ruby on Rails also serves as a backend for In-App Purchases of subscriptions from the App store.

Always Responsive and Latency-Aware

Because a large portion of the Campendium visitors are on the road, it’s important to have both a responsive design and to build for bandwidth limitations for users. Throughout the development of these new features, responsive and mobile friendly designs were implemented leveraging Sass, sometimes requiring help from the rest of the knowledgeable End Point team!

Many of the pages throughout the site are fully cached including the homepage, search result pages, and campground detail page, and cookies are used to indicate user status. In some cases, user submitted campground images are lazy-loaded to mitigate bandwidth limitations.

What’s Next?

While I didn’t go into much technical depth on these updates, I am happy that the updates represent a broad spectrum of full-stack development skills featuring nginx, Ruby on Rails, 3rd party integration including StripeJS, MapboxGL and IAP (Apple), a JavaScript framework with ReactJS, and working with Ruby gems to leverage other tools, for example, Solr (Sunspot) and Sass.

In the future, Campendium plans to continue using these tools to see a more interactive, social campground detail page, and has plans to expand outside of North America. You can visit Campendium here, or find them on Instagram here to follow their exciting announcements!