Speed up development with Gulp Templates

No matter what language you’re programming in or what kind of app you’re creating, sooner or later you’ll notice that specific patterns of your code are repeating. For example, each time you create a new presentational component or a utility class, you may follow a specific code structure and write sections of code with little or no alteration. This is called boilerplate code and while it may be necessary in some cases, it can be very tiresome to write over and over.

This article will demonstrate how such a tedious process can be automated with a very cool JavaScript toolkit called Gulp. Although the examples will be shown in React Native, the principles used here can be applied to any programming language.

First of all, let’s take a look inside a React Native project and examine its code in order to find out why automation is needed and useful.
Here’s a basic directory structure:

Nothing surprising here, this is a basic React Native + Redux code structure. Let’s take a closer look inside the state/ subfolders:

Now it’s getting interesting since these files give out real déjà vu vibes. The project is using Redux for managing state, so one of the first decisions a developer must make relates to structuring action creators, action types and reducers.

This particular React Native project uses modular file structure and each feature (such as login, profile, search etc.) has its own folder which contains three files:

• actions.js
• reducers.js
• types.js

Of course, this is, by no means, the only or the “best” way to structure Redux projects, but that is a completely different discussion and beyond the scope of this article.

What we are interested in, however, is how to automate and speed up the process of creating new features. In order to do that, we must search for patterns in these files. For example, let’s see how each of these files looks inside the signup/ folder.

export const SIGNUP_REQUEST = 'signup_request';
export const SIGNUP_SUCCESS = 'signup_success';
export const SIGNUP_FAILURE = 'signup_failure';

import axios from 'axios';

import * as types from './types';

function signupRequest() {
  return {
    type: types.SIGNUP_REQUEST,
  };
}

function signupSuccess(response) {
  return {
    type: types.SIGNUP_SUCCESS,
    payload: response,
  };
}

function signupFailure(error) {
  return {
    type: types.SIGNUP_FAILURE,
    payload: error,
  };
}

export function signup(email, password, username, firstName, lastName) {
  return async (dispatch) => {
    dispatch(signupRequest());
    const url = 'https://my-react-native-server.com/api/signup';
    try {
      const response = await axios.post(url, {
        email,
        password,
        username,
        firstName,
        lastName,
      });
      dispatch(signupSuccess(response));
    } catch (error) {
      dispatch(signupFailure(error.message));
    }
  };
}

import * as types from './types';

const INITIAL_STATE = {
  loading: false,
  finished: false,
};

export default function (state = INITIAL_STATE, action) {
  switch (action.type) {
    case types.SIGNUP_REQUEST:
      return { ...state, loading: true, finished: false };
    case types.SIGNUP_FAILURE:
      return { ...state, loading: false, finished: false };
    case types.SIGNUP_SUCCESS:
      return { ...state, loading: false, finished: true };
    default:
      return state;
  }
}

Now let’s see how these three files look inside the login/ folder.

export const LOGIN_REQUEST = 'login_request';
export const LOGIN_SUCCESS = 'login_success';
export const LOGIN_FAILURE = 'login_failure';

import axios from 'axios';

import * as types from './types';

function loginRequest() {
  return {
    type: types.LOGIN_REQUEST,
  };
}

function loginSuccess(response) {
  return {
    type: types.LOGIN_SUCCESS,
    payload: response,
  };
}

function loginFailure(error) {
  return {
    type: types.LOGIN_FAILURE,
    payload: error,
  };
}

export function login(username, password) {
  return async (dispatch) => {
    dispatch(loginRequest());
    const url = 'https://my-react-native-server.com/api/login';
    try {
      const response = await axios.post(url, {
        username,
        password,
      });
      dispatch(loginSuccess(response));
    } catch (error) {
      dispatch(loginFailure(error.message));
    }
  };
}

import * as types from './types';

const INITIAL_STATE = {
  loading: false,
  finished: false,
};

export default function (state = INITIAL_STATE, action) {
  switch (action.type) {
    case types.LOGIN_REQUEST:
      return { ...state, loading: true, finished: false };
    case types.LOGIN_FAILURE:
      return { ...state, loading: false, finished: false };
    case types.LOGIN_SUCCESS:
      return { ...state, loading: false, finished: true };
    default:
      return state;
  }
}

Whoa, that’s a lot of repetition! Let’s summarize everything we’ve learned so far from examining these files:

• Each state folder is named after the feature (login, signup etc.) and has exactly three files: types.js, actions.js and reducers.js.
• Every feature has three basic action types: REQUEST, SUCCESS and FAILURE.
  The string constants are named after the folder, so login/ folder has LOGIN_REQUEST, LOGIN_SUCCESS and LOGIN_FAILURE types, and signup/ folder has SIGNUP_REQUEST, SIGNUP_SUCCESS and SIGNUP_FAILURE types.
• Every actions.js file has three boilerplate functions which are also conveniently named. According to this, login/actions.js file has private loginRequest(), loginSuccess() and loginFailure() functions, along with the exposed login() function that uses them.
  On the other hand, signup/actions.js file has private signupRequest(), signupSuccess() and signupFailure() functions, and the exposed signup() function that uses them.
  The bodies of the private functions are exactly the same for both login/ and signup/ folders, while the exposed functions login() and signup() are quite similar but not the same — which is expected, because login and signup actions have different parameters, as well as different endpoints and custom logic.
• login/reducers.js and signup/reducers.js are also exactly the same, the only differences being the names of action types.
  Of course, this is a very simple example where we only need to know whether the signup or login operation has finished successfully. More complex use cases would require more custom code in reducers, but the basic skeleton would still remain the same. Every reducer needs to define an initial state, preferably keep track of whether the request is still loading or not (to display some kind of progress indicator UI to the user), and keep track of whether the request has successfully finished.

You can imagine that writing all this boilerplate each time we need to implement a new feature is not a very thrilling task indeed. So, let’s figure out how to automate this process.

Ideally, we’d want to only provide a name of our new feature, and everything else would be generated for us: The state folder, along with the types, actions and reducers. All functions would be named after the feature we are creating, and all code that can be repeated would be automatically generated for us. Is this even possible?

Well, with Gulp, it is! So let’s dive right in and prepare all the tools we need for our big automation adventure. We can install everything with one command:

npm install --save-dev yargs gulp gulp-template

Before we start writing our automation code, we need to define templates which will be used for generating our code. So, let’s create templates/ a directory in our project root, and create three files inside, called types.js, actions.js and reducers.js.

The gulp-template library composes templates using the following syntax:

function <%= functionName %>() {
    // function code
}

In this case, functionName is a parameter which will be provided by the user.

Based on the code similarities and naming rules we discussed above, our template files will have a single parameter — name, and the files will look like this:

export const <%= name.toUpperCase() %>_REQUEST = '<%= name %>_request';
export const <%= name.toUpperCase() %>_SUCCESS = '<%= name %>_success';
export const <%= name.toUpperCase() %>_FAILURE = '<%= name %>_failure';

import * as types from './types';

function <%= name %>Request() {
  return {
    type: types.<%= name.toUpperCase() %>_REQUEST,
  };
}

function <%= name %>Success(response) {
  return {
    type: types.<%= name.toUpperCase() %>_SUCCESS,
    payload: response,
  };
}

function <%= name %>Failure(error) {
  return {
    type: types.<%= name.toUpperCase() %>_FAILURE,
    payload: error,
  };
}

export function <%= name %>() {
  return async (dispatch) => {
    dispatch(<%= name %>Request());
    try {
      const response = 'Success';
      dispatch(<%= name %>Success(response));
    } catch (error) {
      dispatch(<%= name %>Failure(error.message));
    }
  };
}

import * as types from './types';

const INITIAL_STATE = {
  loading: false,
  finished: false,
};

export default function (state = INITIAL_STATE, action) {
  switch (action.type) {
    case types.<%= name.toUpperCase() %>_REQUEST:
      return { ...state, loading: true, finished: false };
    case types.<%= name.toUpperCase() %>_FAILURE:
      return { ...state, loading: false, finished: false };
    case types.<%= name.toUpperCase() %>_SUCCESS:
      return { ...state, loading: false, finished: true };
    default:
      return state;
  }

These template files can be used to generate corresponding types.js, actions.js and reducers.js files for any feature based on its name only. Of course, those files will eventually probably need some fine-tuning — especially the last (exported) function in actions.js file (because that function differs for each feature), but everything else can be used as it is.

Finally, in order to connect everything together we need to create a gulpfile.js in our project root, because that’s what we’ll be using for our Gulp tasks. Based on our current project structure, our gulpfile.js will look like this:

const { argv } = require('yargs');
const gulp = require('gulp');
const template = require('gulp-template');

gulp.task('createFeature', () => {
  const { name } = argv;

  if (name && name.length > 0) {
    const destinationPath = `src/state/${name}`;

    gulp.src('templates/actions.js')
      .pipe(template({ name }))
      .pipe(gulp.dest(destinationPath));

    gulp.src('templates/reducers.js')
      .pipe(template({ name }))
      .pipe(gulp.dest(destinationPath));

    gulp.src('templates/types.js')
      .pipe(template({ name }))
      .pipe(gulp.dest(destinationPath));

    return;
  }

  console.log('******************************************');
  console.log('* ERROR: You must provide a feature name *');
  console.log('* HINT:  gulp createFeature --name login *');
  console.log('******************************************');
});

This script uses yargs to parse the single console argument name, and then generates all the files by using gulp-template library and the template files provided inside the templates/ folder. We can easily run this script inside the console.

For example, if we want to generate boilerplate code for a feature named search, we just need to type in console:

gulp createFeature --name search

This will generate a folder src/state/search/ and the following files inside it:

export const SEARCH_REQUEST = 'search_request';
export const SEARCH_SUCCESS = 'search_success';
export const SEARCH_FAILURE = 'search_failure';

import * as types from './types';

function searchRequest() {
  return {
    type: types.SEARCH_REQUEST,
  };
}

function searchSuccess(response) {
  return {
    type: types.SEARCH_SUCCESS,
    payload: response,
  };
}

function searchFailure(error) {
  return {
    type: types.SEARCH_FAILURE,
    payload: error,
  };
}

export function search() {
  return async (dispatch) => {
    dispatch(searchRequest());
    try {
      const response = 'Success';
      dispatch(searchSuccess(response));
    } catch (error) {
      dispatch(searchFailure(error.message));
    }
  };
}

import * as types from './types';

const INITIAL_STATE = {
  loading: false,
  finished: false,
};

export default function (state = INITIAL_STATE, action) {
  switch (action.type) {
    case types.SEARCH_REQUEST:
      return { ...state, loading: true, finished: false };
    case types.SEARCH_FAILURE:
      return { ...state, loading: false, finished: false };
    case types.SEARCH_SUCCESS:
      return { ...state, loading: false, finished: true };
    default:
      return state;
  }
}

Not bad, eh? We created a whole lot of code with a single command! This is only a small fraction of what Gulp can do but it should give you a basic idea of automating processes in order to speed up development and concentrate on the logic instead of wasting time on writing boilerplate code.

Happy coding! ☺️