Architecting a User authentication service on the Rails backend is very straightforward, but it can be a bit challenging to implement this system on the React client/front-end side of the application.

In this article, I show you how to build an authentication system for a React with Rails application using HTTP Cookies and the Rails Session Data. Now, you may be wondering about JWT or JSON Web Tokens, and although that approach seems to be the most popular, I think using session data is more practical and secure. For example, If a User password is hacked, with JWT we would have to wait for the token to expire before we could 100% remove access to the User account. With session data, we can simply delete all browser cookies and all the server’s session data associated with that User and immediately block access to the account with the hacked credentials. However, there are some benefits with using JWT over Session data. You should do some research and decide which method works best for you.

Ok, let’s start building!

Pt. 1 — Rails Setup

We’ll be working with Rails 5, but these techniques should also work on Rails 6.

First, let’s create a new rails project. On your terminal, navigate to your working directory and run the rails new command:

rails new your-app-name-api --database=postgresql

Notice we are using postgresql for the database. This will make your life much easier when it comes time to deploy your app. I wrote another article on deploying a React + Rails application here: https://medium.com/how-i-get-it/rails-react-js-heroku-deployment-43d7469e122e

Also notice we didn’t use the --api flag. We don’t want to initiate an API only application. This would prevent us from using the Rails Session without installing more dependencies. Below we’ll go over how to configure the app to behave like a real API server.

Once the rails new command is finished building the file structure, we need to install two essential gems: bcryt and rack-cors. Add these to your gemfile and run bundle in your terminal to install them:

#Gemfile

gem 'bcrypt'

gem 'rack-cors'

CORS (Cross Origin Resource Sharing) will allow you to whitelist the origin of requests that can communicate with our Rails backend. Since we’ll be fetching server data originating from the front-end client, we need to configure CORS to allow the front-end to access and post data on the backend, and since we are dealing with authentication, we also want to prevent any other origins from communicating with the server.

In the config/initializers folder, create a new file called cors.rb and write the following:

Rails.application.config.middleware.insert_before 0, Rack::Cors do 
  allow do
    origins 'http://localhost:3000'
  
    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head],
      credentials: true
  end
end

By default, your React client will run on http://localhost:3000. This code allows requests originating from that address to have access to all server resources ('*') and utilize all HTTP methods: :get, :post, :put, :patch, :delete, :options, :head. This configuration is ideal while you are working on the development environment. Once your application is ready for production, you will need to change the origin to your deployed front-end client’s domain address.

We now need to configure the way our server will handle the HTTP cookies. To do so, in the same config/initializers folder, create a new file called session_store.rb. The server needs to know two things about the cookie; its key and domain. Note, the domain is only needed when the app is in production or deployed:

if Rails.env === 'production' 
  Rails.application.config.session_store :cookie_store, key: '_your-app-name', domain: 'your-frontend-domain'
else
  Rails.application.config.session_store :cookie_store, key: '_your-app-name' 
end

By convention, the key name is your application’s name and should start with an underscore.

Another thing we should change, is the default port for our Rails server. Rails 5 uses Puma to run the server, so in the config/puma.rb file, change the default port to 3001: port ENV.fetch(“PORT”) { 3001 }

This will prevent our back-end and front-end applications from attempting to run on the same port.

With this, and the two files above, we’ve now configured the Rails backend server to behave like a secure API.

Bcrypt and the User Model

Now that the server is configured, we can build a User model and migrate it to the database. In the terminal:

rails g model User username email password_digest

Note we used password_digest instead of password. By doing this we are instructing the bcrypt gem to encrypt the User’s password. bcrypt uses a process called ‘salt’ to hash and encrypt passwords. You can learn more about it here: https://auth0.com/blog/hashing-in-action-understanding-bcrypt/. For now, all you need to know is that bcrypt will secure our passwords.

We can now create and migrate our database with the User model. Make sure your postgres db client is running, otherwise you’ll run onto errors. In the terminal:

rake db:create && rake db:migrate

Check that your schema and database migrations were done correctly. If so, there is one more bcrypt configuration to do. bcrypt uses an attribute called has_secure_password We need to include this in our User model in order for bcrypt to work. While we are at it, let’s also add some validations. In app/model/user.rb :

class User < ApplicationRecord
  has_secure_password

validates :username, presence: true
validates :username, uniqueness: true
validates :username, length: { minimum: 4 }
validates :email, presence: true
validates :email, uniqueness: true

validates_format_of :email, :with => /\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/i
end

Our validations prevent Users from entering invalid or empty data, and return errors that we can present to Users. With this setup, our User model is complete. Let’s add its corresponding routes. I think we should only allow Users to create a new User, see that User and all other Users. They shouldn’t be allowed to edit or delete the user information, so we will allow the following routes in config/routes.rb

Rails.application.routes.draw do

  resources :users, only: [:create, :show, :index]

end

Let’s now connect the Users Controller. Inside app/controllers create the users_controller.rb file. Please note I’m assuming you are familiar with these methods as they are basic Rails knowledge…

class UsersController < ApplicationController

def index
    @users = User.all
    if @users
      render json: {
        users: @users
      }
    else
      render json: {
        status: 500,
        errors: ['no users found']
      }
    end

end

def show
    @user = User.find(params[:id])
   if @user
      render json: {
        user: @user
      }
    else
      render json: {
        status: 500,
        errors: ['user not found']
      }
    end
  end
  
  def create
    @user = User.new(user_params)
    if @user.save
      login!
      render json: {
        status: :created,
        user: @user
      }
    else 
      render json: {
        status: 500,
        errors: @user.errors.full_messages
      }
    end
  end

private
  
  def user_params
    params.require(:user).permit(:username, :email, :password, :password_confirmation)
  end

end

A couple of things to note here, one, I’m only rendering JSON objects because we won’t be using our Rails views. We want to treat our server as an API only app, so we pass the JSON objects to our React client for it to handle displaying them. Two, I’m handling errors in a very basic and semantic way. How you chose to handle errors is up to you. And three, I’m using a helper method login! to create a User. This method inherits from the Application Controller, where I have additional helper methods that will be useful later on. Let’s add them to application_controller.rb:

class ApplicationController < ActionController::Base

  skip_before_action :verify_authenticity_token

  helper_method :login!, :logged_in?, :current_user, :authorized_user?, :logout!

def login!
    session[:user_id] = @user.id
  end

def logged_in?
    !!session[:user_id]
  end

def current_user
    @current_user ||= User.find(session[:user_id]) if session[:user_id]
  end

def authorized_user?
     @user == current_user
   end

def logout!
     session.clear
   end

end

There are a lot of important things going on here. Let’s start from the top: the skip_before_action :verify_authenticity_token command prevents Rails from using its authenticity token. This is a security token that Rails generates from our session data and adds to the parameters sent from a Rails form to a controller action to prevent cross-site request forgery (CSRF) attacks. Since we are treating our back-end as an API, we should disable this so that we don’t receive ‘forbidden’ parameters that will prevent our controller actions from executing without errors.

Next, we have: helper_method :login!, :logged_in?, :current_user, :authorized_user?, :logout! All this is doing is making sure the methods we define below will be passed to all other controllers in the app.

The login!, logged_in?, current_user, authorized_user?, logout! methods are pretty self explanatory; we are creating a session or deleting it, or we are authorizing a User based on the session data. These methods will be helpful when dealing with the sessions controller. Let’s write that next.

The Sessions Controller

Create a sessions_controller.rb file under app/controllers and write the following:

class SessionsController < ApplicationController

def create
    @user = User.find_by(email: session_params[:email])
  
    if @user && @user.authenticate(session_params[:password])
      login!
      render json: {
        logged_in: true,
        user: @user
      }
    else
      render json: { 
        status: 401,
        errors: ['no such user', 'verify credentials and try again or signup']
      }
    end
  end

def is_logged_in?
    if logged_in? && current_user
      render json: {
        logged_in: true,
        user: current_user
      }
    else
      render json: {
        logged_in: false,
        message: 'no such user'
      }
    end
  end

def destroy
    logout!
    render json: {
      status: 200,
      logged_out: true
    }
  end

private

def session_params
    params.require(:user).permit(:username, :email, :password)
  end

end

This controller’s purpose is to deal with the User’s Log In and Log Out functionality. Again, I only render JSON objects and handle errors in a very basic way. The .authenticate method works hand in hand with the User model’s has_secure_password method to authenticate the password.

These controller actions need their routes, so let’s write those:

Rails.application.routes.draw do

  post '/login', to: 'sessions#create'
  delete '/logout', to: 'sessions#destroy'
  get '/logged_in', to: 'sessions#is_logged_in?'
  
  resources :users, only: [:create, :show, :index]

end

The /logged_in route and corresponding action will come to play later when we design the User registration system in the React front-end. For now, just know that it will render a boolean to confirm that the User is authenticated and logged in and if so, it responds with the user object too.

Pt. 2— React Setup

A few notes before we begin the React part of this article:

• I’m assuming you are familiar with React basics like create-react-app, class vs functional components, props and state basics.
• I’m assuming you have npm or yarn installed in your system. We’ll use yarn in this article.
• We’ll use the ‘axios’ dependency for out HTTP requests to the server, and ‘react-router’ and ‘react-router-dom’ to manage our routes.
• We are going to keep the app’s style to a minimum as it’s really not relevant to this topic.
• We’ll use four components: App.js, Home.js, Login.js, Signup.js. Our App.js component will handle most of the apps logic and routing.

Let’s start by creating our React app. In your terminal:

npx-create-react-app your-app-name-client && cd your-app-name-client

I tend to clean up and remove all the unnecessary files this scaffold comes with, i.e. App.css, App.test.js, logo.svg, serviceWorker.js This is my preference, but you decide how to initiate your app. Also I’m removing the serviceWorker because we won’t need it at all here.

I then also clean the App.js file to initiate like this:

import React from 'react';

function App() {
  return (
   <div>
     
   </div>
  );
}

export default App;

And in index.js, we still pass App.js to the root element and clean the file as such:

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

ReactDOM.render(<App />, document.getElementById('root'));

You may also want to make some changes to your public folder, like changing the app’s name on index.html and manifest.json, and remove the unused logos.

Now let’s add the dependencies we need for our app. In your terminal:

yarn add axios && yarn add react-router && yarn add react-router-dom

Alright, so now that the app is setup, let’s start developing the authorization system.

Initial App Logic

We are going to establish the application’s logic in the App.js component. We will need to change to a class component to manage state, and we will need to import our dependencies axios plus {BrowserRouter, Switch, Route} from react-router-dom. The initial setup for our App.js component should now look like this:

import React, { Component } from 'react';
import axios from 'axios'
import {BrowserRouter, Switch, Route} from 'react-router-dom'

class App extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      isLoggedIn: false,
      user: {}
     };
  }

  render() {
    return (
      <div>
         <BrowserRouter>
          <Switch>
            <Route exact path='/' component={}/>
            <Route exact path='/login' component={}/>
            <Route exact path='/signup' component={}/>
          </Switch>
        </BrowserRouter>
      </div>
    );
  }
}

export default App;

Our App.js component is not going to render itself to the DOM, instead, it will serve as our router to render all other components. It will also manage the application’s state and authentication status; we use the component’s state to maintain the logged in status of a User, and to store the User data when we request it from the server. You may have noticed that the Routes aren’t rendering any components yet. We’ll build those and include them here later on.

Let’s add more functionality to the component. Let’s write two methods to interact with the app’s state:

handleLogin = (data) => {
    this.setState({
      isLoggedIn: true,
      user: data.user
    })
  }

handleLogout = () => {
    this.setState({
    isLoggedIn: false,
    user: {}
    })
  }

With these methods we now control the login status of the application and the User data. As you can see in the handleLogin() method, we are passing a data argument. This is the response data we receive from the server. So you can think of these methods as being dependent of other functions and other return values. So how do we get this server response data? Let’s add another method to our component:

loginStatus = () => {
    axios.get('http://localhost:3001/logged_in', 
   {withCredentials: true})

    .then(response => {
      if (response.data.logged_in) {
        this.handleLogin(response)
      } else {
        this.handleLogout()
      }
    })
    .catch(error => console.log('api errors:', error))
  }

This method is very important! It is the backbone of our front-end authorization system. You’ll notice it’s a very straightforward fetch ‘GET’ request using axios, but you can see that we are also passing another argument {withCredentials: true}; this is the key here! This allows our Rails server to set and read the cookie on the front-end’s browser. ALWAYS pass this argument! Also notice the http address we are requesting. Remember our Rails /logged_in route and its corresponding controller action?:

def is_logged_in?
    if logged_in? && current_user
      render json: {
        logged_in: true,
        user: current_user
      }
    else
      render json: {
        logged_in: false,
        message: 'no such user'
      }
    end
  end

Our React App.js component communicates with Rails through this route and controller action. If the User is verified in the Rails server, then a logged_in boolean is returned, along with the user object. App.js uses this response data to maintain the logged in status in the front-end. We need to ‘automate’ this request though. App.js should keep track of this status and request this information every time it’s mounted. We can use the componentDidMount() lifecycle method to call on loginStatus() and achieve this:

componentDidMount() {
    this.loginStatus()
  }

With this, our App.js component should look like this:

import React, { Component } from 'react';
import axios from 'axios'
import {BrowserRouter, Switch, Route} from 'react-router-dom'

class App extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      isLoggedIn: false,
      user: {}
     };
  }

componentDidMount() {
  this.loginStatus()
}

  loginStatus = () => {
    axios.get('http://localhost:3001/logged_in', 
    {withCredentials: true})

    .then(response => {
      if (response.data.logged_in) {
        this.handleLogin(response)
      } else {
        this.handleLogout()
      }
    })
    .catch(error => console.log('api errors:', error))
  }

handleLogin = (data) => {
    this.setState({
      isLoggedIn: true,
      user: data.user
    })
  }

handleLogout = () => {
    this.setState({
    isLoggedIn: false,
    user: {}
    })
  }
  
  render() {
    return (
      <div>
         <BrowserRouter>
          <Switch>
            <Route exact path='/' component={}/>
            <Route exact path='/login' component={}/>
            <Route exact path='/signup' component={}/>
          </Switch>
        </BrowserRouter>
      </div>
    );
  }
}

export default App;

We now have the main authentication logic for the app, however, all this is useless without a way for the user to Sign Up, Log In, and Log Out. For this, inside src/components, let’s make a Home.js file. Also inside, src/components, let’s create a new folder called registrations, and inside of it, let’s add Signup.js and Login.js files.

The Home Component

This will be a very basic functional component:

import React from 'react';
import {Link} from 'react-router-dom'

const Home = () => {
  return (
    <div>
      <Link to='/login'>Log In</Link>
      <br></br>
      <Link to='/signup'>Sign Up</Link>
    </div>
  );
};

export default Home;

Very simple. We just render two links using the Link component from react-router-dom. These links point to the /signup and /login routes which will render their respective components. Let’s build those components:

Registration System

The Signup.js and Login.js components will handle the User signup and login functionality through the use of controlled forms. Users are presented with a form to enter their credentials, and then these are sent to the server for validation.

A quick note here. These two components are almost identical. To keep the code ‘DRY’, we could use a Higher Order Component, or use Styled Components to pass repeating elements, but this is beyond the scope of this article and as such, we’ll just use two separate components.

Login.js:

import React, { Component } from 'react';
import axios from 'axios'
import {Link} from 'react-router-dom'

class Login extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      username: '',
      email: '',
      password: '',
      errors: ''
     };
  }

handleChange = (event) => {
    const {name, value} = event.target
    this.setState({
      [name]: value
    })
  };

handleSubmit = (event) => {
    event.preventDefault()
  };

render() {
    const {username, email, password} = this.state

return (
      <div>
        <h1>Log In</h1>

        <form onSubmit={this.handleSubmit}>
          <input
            placeholder="username"
            type="text"
            name="username"
            value={username}
            onChange={this.handleChange}
          />
          <input
            placeholder="email"
            type="text"
            name="email"
            value={email}
            onChange={this.handleChange}
          />
          <input
            placeholder="password"
            type="password"
            name="password"
            value={password}
            onChange={this.handleChange}
          />

         <button placeholder="submit" type="submit">
            Log In
          </button>

          <div>
            or <Link to='/signup'>sign up</Link>
          </div>
          
         </form>
      </div>
    );
  }
}

export default Login;

Signup.js:

import React, { Component } from 'react';
import axios from 'axios'

class Signup extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      username: '',
      email: '',
      password: '',
      password_confirmation: '',
      errors: ''
     };
  }

handleChange = (event) => {
    const {name, value} = event.target
    this.setState({
      [name]: value
    })
  };

handleSubmit = (event) => {
    event.preventDefault()
  };

render() {
    const {username, email, password, password_confirmation} = this.state

return (
      <div>
        <h1>Sign Up</h1>

        <form onSubmit={this.handleSubmit}>
          <input
            placeholder="username"
            type="text"
            name="username"
            value={username}
            onChange={this.handleChange}
          />
          <input
            placeholder="email"
            type="text"
            name="email"
            value={email}
            onChange={this.handleChange}
          />
          <input 
            placeholder="password"
            type="password"
            name="password"
            value={password}
            onChange={this.handleChange}
          />

          <input
            placeholder="password confirmation"
            type="password"
            name="password_confirmation"
            value={password_confirmation}
            onChange={this.handleChange}
          />
        
          <button placeholder="submit" type="submit">
            Sign Up
          </button>
      
        </form>
      </div>
    );
  }
}

export default Signup;

Both containers are pretty much the same. They are a basic controlled form, where Signup.js has and additional input field, password_confirmation. This is common when using bcrypt on Rails and it’s good practice in general to have Users confirm their passwords.

Other things to note about the forms; we are adding an errors attribute to state so we can handle response errors from the server. We are also destructuring the component’s state and the form’s inputs. On handleChange, we use this technique to avoid hardcoding each of the state’s properties while setting state on the input’s change. Also, we are using event.preventDefault() on handleSubmit() to prevent the browser from submitting the form in the usual way. We are going to add some additional logic to this method — and to other parts of the components, so we need to prevent the form from submitting.

Before we can add this logic to our registrations components, we must expand the App.js component and the router functionality. This component is actively checking the logged in status of the User. What we really want to do, is pass this status to components that require User authentication. The idea is to only render or display authorized data when the User is logged in, so our components will need this information, and with it, we can conditionally display information to the Users. The content you decide to render to your Users based on their logged in status is up to you. Below we expand App.js to be able to pass this status — along with our other App.js methods to our components. We also fully expand the router logic:

import React, { Component } from 'react';
import axios from 'axios'
import {BrowserRouter, Switch, Route} from 'react-router-dom'
import Home from './components/Home'
import Login from './components/registrations/Login'
import Signup from './components/registrations/Signup'

class App extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      isLoggedIn: false,
      user: {}
     };
  }

componentDidMount() {
    this.loginStatus()
  }

  loginStatus = () => {
    axios.get('http://localhost:3001/logged_in', {withCredentials: true})
    .then(response => {
      if (response.data.logged_in) {
        this.handleLogin(response)
      } else {
        this.handleLogout()
      }
    })
    .catch(error => console.log('api errors:', error))
  }

handleLogin = (data) => {
    this.setState({
      isLoggedIn: true,
      user: data.user
    })
  }

handleLogout = () => {
    this.setState({
    isLoggedIn: false,
    user: {}
    })
  }

render() {
    return (
      <div>
        <BrowserRouter>
          <Switch>
            <Route 
              exact path='/' 
              render={props => (
              <Home {...props} loggedInStatus={this.state.isLoggedIn}/>
              )}
            />
            <Route 
              exact path='/login' 
              render={props => (
              <Login {...props} handleLogin={this.handleLogin} loggedInStatus={this.state.isLoggedIn}/>
              )}
            />
            <Route 
              exact path='/signup' 
              render={props => (
              <Signup {...props} handleLogin={this.handleLogin} loggedInStatus={this.state.isLoggedIn}/>
              )}
            />
          </Switch>
        </BrowserRouter>
      </div>
    );
  }
}

export default App;

We imported our Home.js, Login.js andSignup.js components. We are also now rendering these components using render=props. This allows us to pass props to the components to be rendered, and in that way, we can pass isLoggedIn state status, handleLogin(), and handleLogout(), to our components as props!

Note: you can also pass the User object from state down to the necessary components. Which of your components will need that data is up to you, I’m not passing user at this time.

Back to the Registration System

Now that we have access to App.js's state and methods, we can expand the functionality of Login.js and Signup.js:

Login.js:

import React, { Component } from 'react';
import axios from 'axios'
import {Link} from 'react-router-dom'

class Login extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      username: '',
      email: '',
      password: '',
      errors: ''
     };
  }

handleChange = (event) => {
    const {name, value} = event.target
    this.setState({
      [name]: value
    })
  };

handleSubmit = (event) => {
    event.preventDefault()
    const {username, email, password} = this.state

let user = {
      username: username,
      email: email,
      password: password
    }
    
axios.post('http://localhost:3001/login', {user}, {withCredentials: true})
    .then(response => {
      if (response.data.logged_in) {
        this.props.handleLogin(response.data)
        this.redirect()
      } else {
        this.setState({
          errors: response.data.errors
        })
      }
    })
    .catch(error => console.log('api errors:', error))
  };

redirect = () => {
    this.props.history.push('/')
  }

handleErrors = () => {
    return (
      <div>
        <ul>
        {this.state.errors.map(error => {
        return <li key={error}>{error}</li>
          })}
        </ul>
      </div>
    )
  }

render() {
    const {username, email, password} = this.state

return (
      <div>
        <h1>Log In</h1>
        <form onSubmit={this.handleSubmit}>
          <input
            placeholder="username"
            type="text"
            name="username"
            value={username}
            onChange={this.handleChange}
          />
          <input
            placeholder="email"
            type="text"
            name="email"
            value={email}
            onChange={this.handleChange}
          />
          <input
            placeholder="password"
            type="password"
            name="password"
            value={password}
            onChange={this.handleChange}
          />

          <button placeholder="submit" type="submit">
            Log In
          </button>

          <div>
           or <Link to='/signup'>sign up</Link>
          </div>
          
        </form>
        <div>
          {
            this.state.errors ? this.handleErrors() : null
          }
        </div>
      </div>
    );
  }
}

export default Login;

Signup.js:

import React, { Component } from 'react';
import axios from 'axios'

class Signup extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      username: '',
      email: '',
      password: '',
      password_confirmation: '',
      errors: ''
     };
  }

handleChange = (event) => {
    const {name, value} = event.target
    this.setState({
      [name]: value
    })
  };

handleSubmit = (event) => {
    event.preventDefault()
    const {username, email, password, password_confirmation} = this.state
    let user = {
      username: username,
      email: email,
      password: password,
      password_confirmation: password_confirmation
    }

axios.post('http://localhost:3001/users', {user}, {withCredentials: true})
    .then(response => {
      if (response.data.status === 'created') {
        this.props.handleLogin(response.data)
        this.redirect()
      } else {
        this.setState({
          errors: response.data.errors
        })
      }
    })
    .catch(error => console.log('api errors:', error))
  };

redirect = () => {
    this.props.history.push('/')
  }

handleErrors = () => {
    return (
      <div>
        <ul>{this.state.errors.map((error) => {
          return key={error}>{error}</li>
        })}
        </ul> 
      </div>
    )
  }

render() {
    const {username, email, password, password_confirmation} = this.state

return (
      <div>
        <h1>Sign Up</h1>

       <form onSubmit={this.handleSubmit}>
          <input
            placeholder="username"
            type="text"
            name="username"
            value={username}
            onChange={this.handleChange}
          />
          <input
            placeholder="email"
            type="text"
            name="email"
            value={email}
            onChange={this.handleChange}
          />
          <input 
            placeholder="password"
            type="password"
            name="password"
            value={password}
            onChange={this.handleChange}
          />

          <input
            placeholder="password confirmation"
            type="password"
            name="password_confirmation"
            value={password_confirmation}
            onChange={this.handleChange}
          />
        
          <button placeholder="submit" type="submit">
            Sign Up
          </button>
      
        </form>
        <div>
          {
            this.state.errors ? this.handleErrors() : null
          }
        </div>
      </div>
    );
  }
}

export default Signup;

We expanded the same functionality to both Login.js and Signup.js. Let’s break down what we added:

On handleSubmit(), we are creating a user object based on the component’s state. This is the data argument that axios will POST to the Rails server for authentication. Again, note we are also passing {withCredentials: true}. ALWAYS pass this in the header as it’s what allows Rails to set the cookie! We then check the server response and if it’s valid, we can call App.js's handleLogin() method, which will change the app’s isLogged_in status. Else, the server responds with errors and we set the state’s errors attribute. Since this attribute evaluates to true, the handleErrors() method is called in the component’s render() method and displays these errors to the user:

handleErrors = () => {
    return (
      <div>
        <ul>
        {this.state.errors.map(error => {
        return <li key={error}>{error}</li>
          })
        }
        </ul>
      </div>
    )
  }

.
.
.

render()
...

<div>
   {
     this.state.errors ? this.handleErrors() : null
   }
</div>

We are also utilizing redirect():

redirect = () => {
    this.props.history.push('/')
  }

We built this method so we can redirect the User if the server responds with a valid authentication. We have access to the history props passed to us from react-router-dom when we use render=props on App.js.

We now have a working authorization system on our React front-end. But how do we really implement it? This is really up to you. Now that we have access to App.js's isLoggedIn state, we can render or prevent rendering of content. For example, if a User is already logged in, allowing navigation to the /login route, wouldn’t make sense. Let’s prevent that:

componentWillMount() {
    return this.props.loggedInStatus ? this.redirect() : null
  }

With this, we prevent a logged in User from navigating to /login. You can see how the logged in status can be used in several ways; allowing or preventing displaying the User page, rendering items on a NavBar, loading User preferences, or rendering a Log Out link for example. Let’s create the Log Out functionality:

We are going to add a ‘Log Out’ link to the home page in Home.js. Normally though, I would add this link on a NavBar so that is available to Users at anytime.

import React from 'react';
import {Link} from 'react-router-dom'

const Home = (props) => {

const handleClick = () => {
   // we'll do handle the logout functionality here
  }

return (
   
    <div>
      <Link to='/login'>Log In</Link>
      <br></br>
      <Link to='/signup'>Sign Up</Link>
      <br></br>
      { 
        props.loggedInStatus ? 
        <Link to='/logout' onClick={handleClick}>Log Out</Link> : 
        null
      }
    </div>
  );
};

export default Home;

Here, we are displaying the link only if the User is logged in, and we are adding an onClick event that triggers the handleClick function which will handle the logout functionality. This will have to do two things, 1) update the isLoggedIn state in our front-end to false and remove the User data, 2) logout the User on the back-end server.

App.js already has a handleLogout() method that we can use to update the isLoggedIn state and remove the User. We need to pass this method as a prop to Home.js. To do so, we update the route in App.js:

<Route 
    exact path='/' 
    ender={props => (
    <Home {...props} handleLogout={this.handleLogout} //pass prop loggedInStatus={this.state.isLoggedIn}/>)}
     />

And now to logout the User on the back-end, we make a request to the server's /logout route, which triggers the sessions_controller destroy action. We also keep the User on the home page by redirecting to the root route. As ALWAYS, remember to pass {withCredentials: true}:

axios.delete('http://localhost:3001/logout', {withCredentials: true})
    .then(response => {
      props.handleLogout()
      props.history.push('/')
    })
    .catch(error => console.log(error))

We put it all together and our Home.js component should now look like this:

import React from 'react';
import axios from 'axios'
import {Link} from 'react-router-dom'

const Home = (props) => {

const handleClick = () => {
    axios.delete('http://localhost:3001/logout', {withCredentials: true})
    .then(response => {
      props.handleLogout()
      props.history.push('/')
    })
    .catch(error => console.log(error))
  }

return (
   
    <div>
      <Link to='/login'>Log In</Link>
      <br></br>
      <Link to='/signup'>Sign Up</Link>
      <br></br>
      { 
        props.loggedInStatus ? 
        <Link to='/logout' onClick={handleClick}>Log Out</Link> : 
        null
      }
    </div>
  );
};

export default Home;

And the other components should look like this:

App.js:

import React, { Component } from 'react';
import axios from 'axios'
import {BrowserRouter, Switch, Route} from 'react-router-dom'
import Home from './components/Home'
import Login from './components/registrations/Login'
import Signup from './components/registrations/Signup'

class App extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      isLoggedIn: false,
      user: {}
     };
  }

componentDidMount() {
    this.loginStatus()
  }

loginStatus = () => {
    axios.get('http://localhost:3001/logged_in', {withCredentials: true})
    .then(response => {
      if (response.data.logged_in) {
        this.handleLogin(response)
      } else {
        this.handleLogout()
      }
    })
    .catch(error => console.log('api errors:', error))
  }

handleLogin = (data) => {
    this.setState({
      isLoggedIn: true,
      user: data.user
    })
  }

handleLogout = () => {
    this.setState({
    isLoggedIn: false,
    user: {}
    })
  }

render() {
    return (
      <div>
        <BrowserRouter>
          <Switch>
            <Route 
              exact path='/' 
              render={props => (
              <Home {...props} handleLogout={this.handleLogout} loggedInStatus={this.state.isLoggedIn}/>
              )}
            />
            <Route 
              exact path='/login' 
              render={props => (
              <Login {...props} handleLogin={this.handleLogin} loggedInStatus={this.state.isLoggedIn}/>
              )}
            />
            <Route 
              exact path='/signup' 
              render={props => (
              <Signup {...props} handleLogin={this.handleLogin} loggedInStatus={this.state.isLoggedIn}/>
              )}
            />
          </Switch>
        </BrowserRouter>
      </div>
    );
  }
}

export default App;

Login.js:

import React, { Component } from 'react';
import axios from 'axios'
import {Link} from 'react-router-dom'

class Login extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      username: '',
      email: '',
      password: '',
      errors: ''
     };
  }
  componentWillMount() {
    return this.props.loggedInStatus ? this.redirect() : null
  }

handleChange = (event) => {
    const {name, value} = event.target
    this.setState({
      [name]: value
    })
  };

handleSubmit = (event) => {
    event.preventDefault()
    const {username, email, password} = this.state

let user = {
      username: username,
      email: email,
      password: password
    }
    
    axios.post('http://localhost:3001/login', {user}, {withCredentials: true})
    .then(response => {
      if (response.data.logged_in) {
        this.props.handleLogin(response.data)
        this.redirect()
      } else {
        this.setState({
          errors: response.data.errors
        })
      }
    })
    .catch(error => console.log('api errors:', error))
  };

redirect = () => {
    this.props.history.push('/')
  }

handleErrors = () => {
    return (
      <div>
        <ul>
        {this.state.errors.map(error => {
        return <li key={error}>{error}</li>
          })
        }
        </ul>
      </div>
    )
  }

render() {
    const {username, email, password} = this.state

return (
      <div>
        <h1>Log In</h1>
        <form onSubmit={this.handleSubmit}>
          <input
            placeholder="username"
            type="text"
            name="username"
            value={username}
            onChange={this.handleChange}
          />
          <input
            placeholder="email"
            type="text"
            name="email"
            value={email}
            onChange={this.handleChange}
          />
          <input
            placeholder="password"
            type="password"
            name="password"
            value={password}
            onChange={this.handleChange}
          />

          <button placeholder="submit" type="submit">
            Log In
          </button>

          <div>
            or <Link to='/signup'>sign up</Link>
          </div>
          
          </form>
          <div>
          {
            this.state.errors ? this.handleErrors() : null
          }
        </div>
      </div>
    );
  }
}

export default Login;

Signup.js

import React, { Component } from 'react';
import axios from 'axios'

class Signup extends Component {
  constructor(props) {
    super(props);
    this.state = { 
      username: '',
      email: '',
      password: '',
      password_confirmation: '',
      errors: ''
     };
  }

handleChange = (event) => {
    const {name, value} = event.target
    this.setState({
      [name]: value
    })
  };

handleSubmit = (event) => {
    event.preventDefault()
    const {username, email, password, password_confirmation} = this.state
    let user = {
      username: username,
      email: email,
      password: password,
      password_confirmation: password_confirmation
    }

axios.post('http://localhost:3001/users', {user}, {withCredentials: true})
    .then(response => {
      if (response.data.status === 'created') {
        this.props.handleLogin(response.data)
        this.redirect()
      } else {
        this.setState({
          errors: response.data.errors
        })
      }
    })
    .catch(error => console.log('api errors:', error))
  };

redirect = () => {
    this.props.history.push('/')
  }

handleErrors = () => {
    return (
      <div>
        <ul>{this.state.errors.map((error) => {
          return <li key={error}>{error}</li>
        })}</ul> 
      </div>
    )
  }

render() {
    const {username, email, password, password_confirmation} = this.state

return (
      <div>
        <h1>Sign Up</h1>

        <form onSubmit={this.handleSubmit}>
          <input
            placeholder="username"
            type="text"
            name="username"
            value={username}
            onChange={this.handleChange}
          />
          <input
            placeholder="email"
            type="text"
            name="email"
            value={email}
            onChange={this.handleChange}
          />
          <input 
            placeholder="password"
            type="password"
            name="password"
            value={password}
            onChange={this.handleChange}
          />

          <input
            placeholder="password confirmation"
            type="password"
            name="password_confirmation"
            value={password_confirmation}
            onChange={this.handleChange}
          />
        
          <button placeholder="submit" type="submit">
            Sign Up
          </button>
      
        </form>
        <div>
          {
            this.state.errors ? this.handleErrors() : null
          }
        </div>
      </div>
    );
  }
}

export default Signup;

And that’s it! You now have a working React and Rails User authorization system. I know it’s a long one, but this is a good guide to keep.

Sources:

Jordan Hudgens CTO at devCamp

React with Rails User Authentication was originally published in How I Get It… on Medium, where people are continuing the conversation by highlighting and responding to this story.

Deploying a Rails + React.js App to Heroku

So you have a finished application that runs on your localhost machine. It’s time now to make your application public and available to users on the web; in essence, to move out of development and into production stage. This isn’t a straight forward task and usually requires some careful tweaking to make sure everything runs smoothly on the web.

For this article, in an attempt to save you some headaches and countless trial and error commits and erroneous deploys, I will go in-depth on deploying a Rails with React.js application using Heroku.

Before starting, I’m assuming you’ve done a few things:

1. You have a working Rails application with React.js as the client on the same stack that can run on your local environment
2. You used the rails new –api command to build the app in API mode (best practice in this case)
3. You used create-react-app to build the React client
4. Your Ruby version is 2.4.0 or above
5. Your Rails version is 5.x
6. You know what Heroku is and have set up an account and have their CLI installed
7. You have Yarn or NPM installed (we’ll use Yarn in this article)

Before you can even attempt deploying the app, you must first make some changes to the default configurations in Rails and the overall project in general.

I suggest you create a separate git branch for these coming changes in case you want to keep your original development version. Once your deployment/production version is complete, you can merge to your master branch.

Ok, let’s get to it!

Changing the Rails Database

By default, Rails uses SQLite3 for its database, however, SQLite is not intended as a production-grade database. Heroku works with PostgreSQL, a more robust database. If you’re not familiar with PostgreSQL, I encourage you to research it; it’s really powerful and used by many applications.

To move from sqlite3to postgres, open your Gemfile and remove or comment out the sqlite3gem and add the postgres gem:

# gem ‘sqlite3’

gem ‘pg’

Alternatively, you can group your gems on their respective environments if you want to preserve your current database on the development environment:

group :development do
    gem ‘sqlite3’
end

group :production do
    gem ‘pg’
end

At this point, if you don’t have one, I suggest you create a seed file based on your current database. This will allow you to move or recreate your current data into the new PostgreSQL database. If you plan on having a blank production database, then this won’t be necessary.

Once your gemfile has been updated, re-install the dependencies by running bundle install in your terminal.

By adding the postgres gem, we’ve told Rails to start using PostgreSQL as the database. For this to work, you need to change the database adapter from sqlite3 to postgresql in the database configuration file config/database.yml:

development:
  adapter: postgresql
  database: my_database_development
  pool: 5
  timeout: 5000
test:
  adapter: postgresql
  database: my_database_test
  pool: 5
  timeout: 5000

production:
  adapter: postgresql
  database: my_database_production
  pool: 5
  timeout: 5000

Note: This setup makes all environments use PostgreSQL. If you want to keep using SQLite on development, leave the development adapter pointing to sqlite3. Also, make sure you substitute “my_database” to your app’s root directory name.

At this point, you should commit your changes to your production branch.

ActiveStorage Changes

Rails’ ActiveStorage allows you to attach files to ActiveRecord models. If you are using ActiveStorage to attach pictures, audio, or other files, you need to make some configuration changes before deployment. This is because Heroku uses an “ephemeral” disk that allows you to write files to it, however, those files won’t persist after the Heroku app is restarted.

Instead of storing uploaded files directly on Heroku, it is recommended to use a cloud file storage service such as AWS or Google Cloud. In this article, we’ll use Google Cloud Storage as it’s very straight forward and it’s free to use for the first year.

Go to https://cloud.google.com and sign in with your Google account or create one. You’ll be taken to the Google Cloud Platform where you will create a new project. Name the project as your application’s name:

Next, open the Google Cloud Platform menu on the left side. Under “Storage”, hover over “Storage” and click on “Browser”. Click on the “Create Bucket” button to create a new “bucket” for your project:

A bucket is where your data is held on the Google Cloud. The name must be globally unique across Cloud Storage. For the settings, select Regional storage class, choose your location, and create:

Your bucket is now created. Now you have to give it access to your Rails backend. To do so you need to get an authorization key. On the main menu, under API’s & Services”, click on “Credentials”. This will open up a new page to create new credentials; create a new Service account key:

Pick a name for your service account, select Project Owner as the Role, and make sure the Key Type is in JSON format:

After clicking “Create”, a public/private key pair is generated and downloaded to your computer. Make sure to keep this in a safe place as it is the only copy of it you will have.

You now have a working Google Cloud project to upload and host your application’s files. Now let’s set up the Rails backend to work with it:

You need to let your app know about the authorization keys you just saved. First create a secrets folder inside your app’s config folder.

Add config/secrets/* to the app’s .gitignorefile. This will prevent the contents of the secrets folder to be included in git version control, and uploaded and shared to git remotes.

Now rename the downloaded .json file to: your-app-name.json and move it into the config/secretes folder.

You now need to configure Rails to use the Google Cloud Service. First, add the Google Storage gem to your gemfile:

gem "google-cloud-storage", "~> 1.8", require: false

And run bundle install in the terminal.

Next, change the app’s storage configuration file config/storage.yml. Make the following changes:

google:
     service: GCS
     project: your-app-name
     credentials: <%= ENV['GOOGLE_APPLICATION_CREDENTIALS'] %>
     bucket: your-app-name

Note: Make sure you add your corresponding project and bucket names instead of “your-app-name”.

Now, tell Rails to use :google for the production environment. In config/environments/production.rb, make the following change:

config.active_storage.service = :google

Note: Your development environment will continue to use ActiveStorage. If you want to use Google Cloud for development environment as well, you need to configure Rails to do so:

google_dev:
     service: GCS
     project: your-app-name
     credentials: <%= Rails.root.join("config/secrets/ your-app-name.json ") %>
     bucket: your-app-name

config/environments/development.rb :

config.active_storage.service = :google_dev

At this point, if this was a single Rails application, you could create the database and do your migrations, and then deploy it to Heroku. But since we have a React.js client, we need to change a few more things on the backend. This would be a good time to commit your changes.

Building the Production Client and Setting Up Rails for Deployment

Just as with a single React.js application, the client needs to be built to create a build directory that will hold the app’s production static files. Included in these files will be index.html, which will be served to visitors of the site. These files will be contained on the public folder of the Rails backend, which is what we want to deploy to Heroku. We can use Yarn (or NPM) to create the build and deploy scripts that will prepare our app for production.

Heroku works very good with Node.js applications and will recognize such apps if it sees a package.json file in the root of the application. Let’s create that file:

In your terminal and in the project’s root directory, execute yarn init and follow instructions.

This will add the package.json file to the Rails backend that Heroku will then use to build and deploy the app. It will look something like this:

{
  "name": "my-awesome-package",
  "version": "1.0.0",
  "description": "The best package you will ever find.",
  "main": "index.js",
  "repository": {
    "url": "https://github.com/yarnpkg/example-yarn-package",
    "type": "git"
  },
  "author": "Yarn Contributor",
  "license": "MIT"
}

We now need to add the scripts that will be executed for such actions:

"scripts": {
    "build": "cd client && yarn install && yarn build && cd ..",
    "deploy": "cp -a client/build/. public/",
    "postinstall": "yarn build && yarn deploy && echo 'Client built!'"
  },

When we push our repo to Heroku, Heroku will run npm install while deploying the app to make sure all necessary dependencies are installed. With the scripts above, we are telling Heroku to run the postinstall script after it initially runs npm install. The postinstall script runs the build script which will run yarn install in the client directory to install any dependencies the client may have, and then run yarn build to create the build folder that will hold the static files. Then the deploy script will run and will copy all the build files into the public folder for deployment.

Heroku also needs to know your version of Yarn, NPM, and Node. To find them use these commands in the terminal:

yarn -v && npm -v && node -v

Then add an engines object to the Rails’ package.json:

. . .

"scripts": {
    "build": "cd client && yarn install && yarn build && cd ..",
    "deploy": "cp -a client/build/. public/",
    "postinstall": "yarn build && yarn deploy && echo 'Client built!'"
  },
  "engines": {
    "yarn": "1.21.1",
    "npm": "6.11.3",
    "node": "12.11.1"
  },

With the above instructions, Heroku now knows how to build and deploy the app. We now need to tell it how to run the Rails server once the app is hosted on Heroku. To do this, we need to give it instructions via a Procfile:

In the app’s root directory, create a file called Procfile (it must be named exactly this way). In the file, write the following line:

web: bundle exec puma -t 5:5 -p ${PORT:-3001} -e ${RACK_ENV:-development}

This tells Heroku to run the Rails server on port 3001.

Note: You can set this port to whatever you want. Just make sure it is not the same port your client is using to connect, and that is the same port your fetch/ajax request are using to fetch data from the backend. More on this in the section below.

Connecting the React Client to the Rails API

By default, the Rails server runs on port 3000. So does the client development build when ruining in your local server, i.e. when running yarn start or npm start.

You might have been running two local servers by executing rails s –p 3001 in your terminal and on your app’s root directory, and yarn start on the client’s root directory. This will allow your client to run on the http://localhost:3000/ and the Rails backend/server on http://localhost:3001/.

This manual setup is ok while on development, but for production, we need to make sure that the client makes the server calls to the right port, every time. To do so, we must add a proxy to the client’s package.json file:

{
  "name": "client",
  "version": "0.1.0",
  "private": true,
  "proxy": "http://localhost:3001",
  "dependencies": { 
	
	. . .
	
	}

Next, we need to make changes to the client’s fetch requests.

You may have a component that makes calls to the Rails API/server. Something similar to this:

const apiURL = 'http://localhost:3001'

export const fetchWorkouts = () => {
  let data = {
    method: 'GET',
    headers: {
      'Accept': 'application/json',
      'Content-type': 'application/json'
    }
  }

  return dispatch => {
    fetch(`${apiURL}/resources`, data)
      .then(response => response.json())
      .then(resources => dispatch({
          type: 'FETCH_RESOURCES',
          resources
      }))
      .catch(errors => errors)
  }
}

A few things to note here. First, this is a React/Redux “API call action”. It uses ‘Redux-Thunk’ to handle the fetch request, but the same principles apply to use other tools like ‘Axios’ or vanilla fetch requests.

Second, note that here we have an apiURL variable that points to the Rails server. The variable is then interpolated into the fetch request address where it’s used to call on the “resources” endpoint. Although this is the correct way to handle these calls on your development environment, this wouldn’t work for a production build when deployed to Heroku. This is because we are “hard-coding” the path to our server, and Heroku –after deployment and once the app has been built on their server, uses its own HTTP routing stack with unique paths to the app’s Heroku server.

To fix this, you simply remove the apiUrl variable from the fetch request path and leave your resource endpoint. Something along:

//const apiURL = 'http://localhost:3001'

export const fetchWorkouts = () => {
  let data = {
    method: 'GET',
    headers: {
      'Accept': 'application/json',
      'Content-type': 'application/json'
    }
  }

  return dispatch => {
    fetch(`/resources`, data) //removed hard-coded path
      .then(response => response.json())
      .then(resources => dispatch({
          type: 'FETCH_RESOURCES',
          resources
      }))
      .catch(errors => errors)
  }
}

One last thing to consider, is the use of ‘React-Router’.

If your React client uses ‘react-router’ for its routing, you would need to make some changes to the Rails backend. Specifically, you will need to create a ‘fallback route’ for all routes or paths that don’t match or are not included in your client’s routes. In other words, you will tell your app to serve the client’s index.html for any path that is not included in your client’s routes.

To do so, in the Rails app/application_controller.rb file, add the following:

class ApplicationController < ActionController::API

  def fallback_index_html
    render :file => 'public/index.html'
  end
  
end

And in the Rails config/routes.rb file, add the following:

get '*path', to: "application#fallback_index_html", constraints: ->(request) do
    !request.xhr? && request.format.html?
  end

All right, that was a lot to do! But now our application is ready to be deployed. Next, we’ll create the Heroku app and deploy our Rails with React app to it.

This will be a good time to commit your work.

Deploying to Heroku

As a reminder, I’m assuming you have a Heroku account and have the Heroku CLI installed. If you haven’t, please go to https://www.heroku.com/, create an account and follow instructions on how to set up the CLI.

The first thing to do is to log in to your Heroku account. In your terminal, execute heroku login and fill in your credentials.

Now, create a new Heroku app:

In your terminal, and in your app’s root directory, execute the following: heroku create your-app-name

You can confirm the new Heroku app is connected to your Rails + React app by executing git remote –v. This will list all your remote depositories associated with your app directory. You should see Heroku listed there because Heroku uses your git repo to build your app on their server.

Next, you will tell Heroku how to build the app. Since the app uses Node.js and Ruby on the stack, Heroku needs to execute the correct buildpacks when building the app. To do so, execute the following in your terminal:

heroku buildpacks:add heroku/nodejs --index 1

heroku buildpacks:add heroku/ruby --index 2

You are all set!!

Commit all your changes and push them to Heroku:

git add .

git commit -m "first Heroku deploy "

git push heroku master

Note: the git push command takes in two arguments, a remote name and the local branch name to be pushed, i.e git push <remotename> <branchname>. You should push the branch name where all these changes took place. If you followed my suggestion to create a new deployment branch before making these changes, you will need to deploy that branch instead of master above.

When you push your app to Heroku, Heroku will run the scripts we set in the Rails package.json file to build the app. This process will take a minute or two. You can see the build and deploy scripts running in the background while this process takes place.

You probably have some .env variables in your development. Since these variables are usually protected and not committed to git, Heroku won’t know about them when we push the project to its master branch. To add these variable to your Heroku project, we can run the following command in the terminal AFTER the application has been created and uploaded to Heroku:

heroku config:set VARIABLE=VALUE

And finally!… since this is a brand new app hosted in Heroku, there won’t be a database set yet. You must create it, migrate it, and seed it (if you have a seed file). In your terminal:

heroku rake db:create

heroku rake db:migrate

heroku rake db:seed

And that’s it! You should now have a working production app hosted in Heroku.

You can open and test the app by running heroku open on the root directory.

One final note: if you find that your app’s images or styling aren’t loading properly, it may be because their corresponding static assets aren’t being processed while deploying. Check the Heroku logs to see which assets aren’t loading.

The quick fix is to pre-compile your assets before deployment. Note, however, that doing the following will slow down the app’s loading time. It’s recommended instead that you host the static assets on a CDN service.

To pre-compile assets, change the following lines in the Rails config/environments/production.rb file:

config.assets.complie = true

config.serve_static_assests = true

If you are new to deployment, I hope this guide has saved you a few hours of research and has allowed you to successfully deploy your app. If you are experienced, hopefully, you can use this guide as a refresher and maybe keep it as a comprehensive reference for the future. I sure will.

References:

https://devcenter.heroku.com/articles/getting-started-with-rails5

https://medium.com/@bruno_boehm/reactjs-ruby-on-rails-api-heroku-app-2645c93f0814

https://www.youtube.com/watch?v=Z0sFlwz0YvU

https://medium.com/@pjbelo/setting-up-rails-5-2-active-storage-using-google-cloud-storage-and-heroku-23df91e830f8

Rails + React.js Heroku Deployment was originally published in How I Get It… on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Given the following code, please write the order in which the logs will appear in the console:”

const a = () => {
	b()
	console.log("a")
	
};

const b = () => {
	console.log("b")
	c()
};

const c = () => {
	console.log("c")
};

c()
console.log("d")
a()

Can you answer the question?

There is a fundamental principle in JavaScript that makes answering this question very easily; The Execution Context (and Execution Stack).

JavaScript is a a single threaded language and therefore, only one task can run at a time. The environment where this task or code is evaluated and executed is referred to as the execution context. In other words, wherever — or whenever a line of code runs in JavaScript, it runs in its execution context.

To understand how the execution context is created, we must first understand how the JavaScript engines run code in general: Every time JavaScript code runs, the engine does several things. One of them is to read the code line by line and use the syntax parser. In this phase, the engine parses the code and compiles it to instruct the computer on what to do. It also checks for errors in syntax and if there are none, it stores variable and function declarations to memory and creates the execution contexts.

The two main types of execution contexts in JavaScript are the:

• Global Execution Context: this is the base execution context and is where EVERYTHING in JavaScript is available. All of the codebase is wrapped inside the global execution environment; variable declarations, variable assignments, function calls, and function declarations for example, all run in the global execution context. In JavaScript “global” means not inside a function and there can only be one global execution context in a particular program.
• Functional Execution Context: this is the context that exists inside a particular function. Whenever a function is invoked or called, the JavaScript engine creates another execution context that belongs to that function’s environment only. This functional execution cotntext is then stacked on top of the global execution context. All following function calls will generate their own execution context and will be stacked on top of the previous execution context.

Let’s take a look at the question and the code again to see the execution contexts in our code:

///////////////GLOBAL ENVIRONMENT//////////////

const a = () => {
  //function a execution context
  b()              
  console.log("a") 
  };
  
  const b = () => {
   //function b execution context
   console.log("b")
   c()         
  };
  
  const c = () => {
   //function c execution context
   console.log("c")  
  };
  
  //global execution context
  c() 
  console.log("d") 
  a()
  
  //////////////GLOBAL ENVIRONMENT///////////////

OK, so we’ve determined our execution contexts, but how do we determine the order of our console.logs and answer the question? To do so we need to understand the execution stack.

When the JavaScript engine parses our code in its first pass, it reads code from top to bottom in the global environment, creates the global execution context and stores it at the bottom of what is known as the execution stack:

—EXECUTION STACK—
///////////////////////
///////////////////////
///////////////////////
///////////////////////
///////////////////////
///GLOBAL EXECUTION///

If there is a function call, the engine creates an execution context for that function and stacks it on top of the execution stack. If it finds another function, it creates another execution context for that function and stacks it on top of the execution stack:

—EXECUTION STACK—
///////////////////////
///////////////////////
///////////////////////
///FUNC 2 EXECUTION///
///FUNC 1 EXECUTION///
///GLOBAL EXECUTION///

This process is repeated until no other function calls are found. The order of the stack is determined by the order in which the engine finds the function calls, and the order of code execution is determined by the order of the execution stack. In the example above, function 2, will be executed first, then function 1, and finally, whatever code is left in the global environment/global execution context will be executed.

Let’s take a look again at our code in question and stack our execution contexts:

///////////////GLOBAL ENVIRONMENT//////////////

const a = () => {
  //function a execution context
  b()              
  console.log("a") 
  };
  
  const b = () => {
   //function b execution context
   console.log("b")
   c()         
  };
  
  const c = () => {
   //function c execution context
   console.log("c")  
  };
  
  //global execution context
  c() 
  console.log("d") 
  a()
  
  //////////////GLOBAL ENVIRONMENT///////////////

Our initial stack looks like this:

—EXECUTION STACK—
///////////////////////
///////////////////////
///////////////////////
///FUNC C EXECUTION///
///GLOBAL EXECUTION///

The engine finds a call to function c, stacks it on top of the stack and executes function c because there are no other functions to call, we only console log “c”. Once the function is called and executed, it gets removed from the stack, and so we are back in the global execution context:

—EXECUTION STACK—
///////////////////////
///////////////////////
///////////////////////
///////////////////////
///////////////////////
///GLOBAL EXECUTION///

The engine now finds console.log(“d”) in the global environment/context. At this point there is nothing to stack because we are still in the global execution context, so no new execution context is created. After the engine logs “d”, it finds a call to function a. At this point an execution context is created for function a and it’s put on top of the stack. Our stack now looks like this:

—EXECUTION STACK—
///////////////////////
///////////////////////
///////////////////////
///////////////////////
///FUNC A EXECUTION///
///GLOBAL EXECUTION///

Now the engine attempts to execute function a but it finds a call to function b inside that context, so it won’t execute function a and instead creates a new execution context for function b and stacks it on top of the execution stack like so:

—EXECUTION STACK—
///////////////////////
///////////////////////
///////////////////////
///FUNC B EXECUTION///
///FUNC A EXECUTION///
///GLOBAL EXECUTION///

Now inside function b’s execution context, the engine logs “b” and it encounters a call to function c which needs to stack at the top of the execution stack. Because this is the last line of code in function b, function b is fully executed and removed from the stack by then. So our execution stack now looks like this:

—EXECUTION STACK—
///////////////////////
///////////////////////
///////////////////////
///FUNC C EXECUTION///
///FUNC A EXECUTION///
///GLOBAL EXECUTION///

Notice that function a is still in the execution stack because it hasn’t been executed yet. Remember the engine first found a call to function b inside function a and that call needed to be executed first. As of now function a is not executed and remains in the execution stack.

So at this point the next execution in the stack is for function c. The engine logs “c” and function c gets fully executed and removed from the stack, leaving function a at the top of the stack and next in line to be executed:

—EXECUTION STACK—
///////////////////////
///////////////////////
///////////////////////
///////////////////////
///FUNC A EXECUTION///
///GLOBAL EXECUTION///

What remains to be executed in function a is the console.log(“a”). So the engine logs “a” and function a is fully executed. It gets removed from the stack and the engine is left with the global execution only. Since there is nothing else to execute in the global environment, the global execution context gets removed from the stack and all our code is fully executed and complete.

Our answer then should be:

c d b c a

I think this is a very important concept to grasp in JavaScript. It helped me understand the basics of how JavaScript code runs and works. It helped me understand Scope, variable assignment and declaration on ES6, and other important concepts. Hopefully it’s given you a similar understanding that you can use to become a better JavaScript developer.

JavaScript Execution Context was originally published in How I Get It… on Medium, where people are continuing the conversation by highlighting and responding to this story.