The perfect universal front-end stack

Nowadays React is the established way to go in the front-end Javascript world and combined with the power of ES6, Node JS and Webpack it’s bound to make a guaranteed success of your project. But what’s a good or even the most perfect setup at this moment? Let me help you with that by giving you some insights in our current setup.

Webpack 2 & Universal webpack
With the arrival of Webpack 2 it’s definitely time to hop on and use this version. Please upgrade when you’re still using Webpack 1, they have made an excellent migration guide available. The new version has made configuration a little bit easier and it gives you some advantages like Tree Shaking (excluding unused exports from bundles). And as we want to render React both on the server (for SEO purposes) and on the client side we choose to implement it together with universal-webpack.

Hot Module Replacement
One of the better features of Webpack which makes the development experience much better is Hot Module Replacement. With HRM enabled you can develop and without reloading the page your application will automatically update. This will save you a lot of time pressing on the F5 button. You can also combine the power of HMR with React! Keep in mind though that HMR is for development only, don’t use this in your production environment.

SASS and CSS Modules
To really make our React components modular we use CSS modules. It gives you an easy way of integrating CSS into the component files and makes dependencies throughout the project explicit. Just create a SASS file next to your component file and import the styles. In the following example i’m adding a border style to the div element.

import React from 'react';
import PropTypes from 'prop-types';
import styles from './Component.scss';
const Component = ({ message }) => (
<div className={styles.border}>
{ message }
</div>
);
Component.propTypes = {
message: PropTypes.string.isRequired
};
export default Component;

Unit testing with Jest
For some (or maybe most) unit testing the code isn’t core business and can consume a lot of you’re time. But hey there is an easier way! Jest is just like React provided by Facebook and is gives you an efficient way to quickly unit test your code. With Jest you don’t have to test all of your component props for example, but you can just easily make a snapshot. This will cost you just a couple lines of code instead of manually checking your whole component.

import React from 'react';
import { shallow } from 'enzyme';
import { shallowToJson } from 'enzyme-to-json';

import Component from './Component';

describe('Component', () => {
it('should render hello world message correctly', () => {
const props = { message: 'hello world!' };
const wrapper = shallow(<Component {...props} />);
expect(shallowToJson(wrapper)).toMatchSnapshot();
});
});

But with great power for the developers comes a great responsibility for the reviewers as they should look very extensively at the snapshot files to see wether they are correct. You should always provide your tests with a correct description so the reviewer can easily understand where he’s looking at. Also look at the classname in the example below, with CSS modules this becomes Component_border.

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`Component should render hello world message correctly 1`] = `
<div
className="Component_border"
>
hello world!
</div>
`;

Another big advantage of Jest is that imported files or packages can be easily mocked. This way you can easily stub out functionality with mock data like for REST calls. It will makes your tests faster and will always gives you the correct outcome and don’t forget to snapshot the outcome.

Get better coverage insights with Codecov
After you’ve created all of your code and unit tests, you should always look if you really covered all of you lines. Luckily Jest has code coverage implemented which is very easy to run and gives you detailed information on your localhost. But what if you could make it easier for your reviewer to see if all of your (newly) code is covered? Then use Codecov in your project, it provides you with an easy way of showing you the coverage of your project and branches. It even has Github plugins and browser extensions which can give you messages, graphics and even show the lines of code which are covered and which aren’t in your pull request.

Using Cypress for your integration testing
Integration testing can be hard, especially when you’re still using Selenium based testing tools like Protractor. Until last year this was actually the only best way to go, but fortunately for us Cypress was launched! Cypress makes integration testing so much easier. It takes all the pain and headaches away and makes you love testing again! Look at this simple example below.

describe('Website integration test', () => {
beforeEach(() => {
setUp('macbook-13'); // could also be iphone-6 or ipad-2
cy.visit('/');
});

it('should render hello world', () => {
cy.get('.classname').should('contain', 'hello world!');
});
});

While Cypress will be fully available in 2017, you can ask for early access at their website or at their channel on Gitter.

Check your bundle!
The final step before shipping your application, should always be checking your bundle. You can easily add this functionality to your project by adding the webpack-bundle-analyzer. It gives you the power to really understand which files and packages are bundled and shipped to the user. Try to make your bundle as small and optimized as possible.