Hire the Top 3% of Freelance React.js Developers

Intro

Another wave of evolution in client-side application development is approaching. It involves ES6, the new version of JavaScript, universal applications, functional programming, server-side rendering and a webpack, which is like a task-runner with a jetpack.

Also, React is super hot right now. It is a concise and excellent framework to build performant components. Since we already have all that, how do you find the missing piece — the engineer who will embrace it and build state-of-the-art software for you?

React Plainly

First things first. In the context of React being marketed as only a views library, and as client-side applications consist of more than just views, React won’t be the only tool that your candidate will use. Still, it is a crucial one. Here are a few screening questions.

Q: What are higher-order components in React?

Broadly speaking, a higher-order component is a wrapper. It is a function which takes a component as its argument and returns a new one. It can be used to extend or modify the behaviour (including the rendered output) of the contained component. Such use of components that change behavior without modifying the underlying class in React is well characterized by the decorator pattern.

The higher-order components are a way to build components using composition. An example use case would be to abstract out pieces of code, which are common to multiple components:

Player.js

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

export default class Player extends Component {
  static propTypes = {
    black: PropTypes.bool,
    data: PropTypes.object,
    styles: PropTypes.object
  };

  static defaultProps = {
    black: false,
    data: {
      src: null,
      caption: ''
    },
    styles: {}
  };

  render() {
    const { black, data, styles } = this.props.data;
    return (
      <div className={
        'module-wrapper' +
        (styles ? ' ' + styles : '') +
        (black ? ' module-black' : '')}>
        <section className="player-wrapper video-player-wrapper">
          <video className="player" src={data.src} />
          <p className="player-caption">{data.caption}</p>
        </section>
      </div>
    );
  }
}

Consider this component, which holds a Player but also contains module markup. That markup could be reused for other components. Let’s abstract it, and also allow for passthrough of properties:

Player.js

import React, {Component, PropTypes} from 'react';
import ModuleContainer from './ModuleContainer';

export class PlayerInline extends Component {
  static propTypes = {
    data: PropTypes.object
  };

  static defaultProps = {
    data: {
      src: null,
      caption: ''
    }
  };

  render() {
    const { src, caption } = this.props.data;
    return (
      <section className="player-wrapper video-player-wrapper">
        <video className="player" src={src} />
        <p className="player-caption">{caption}</p>
      </section>
    );
  }
}

const Player = new ModuleContainer(Player);
export default Player;

ModuleContainer.js

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

export default function ModuleContainer(Module) {
  return class extends Component {
    static propTypes = {
      black: PropTypes.bool,
      styles: PropTypes.object
    };

    render() {
      const { black, styles } = this.props // eslint-disable-lint
      return (
        <div className={
          'module-wrapper' +
          (styles ? ' ' + styles : '') +
          (black ? ' module-black' : '')
        }>
          <Module {...this.props} />
        </div>
      );
    }
  };
}

Now we can still use the previous way of instantiating Player, no changes here. We can also use the inline player if we prefer. Then the module wrapper markup and props can be used with other modules:

<Player data={playerData} styles={moduleStyles} />

<PlayerInline data={playerData} />

Higher order components are the immediate answer to the design decision of moving away from mix-ins in React for ES6, which was done in early 2015. In fact, higher-order components make for a clearer structure, and they are easier to maintain because they are hierarchical, whereas mix-ins have a bigger chance of conflicting due to a flat structure.

To learn more, check out another example use case of higher order components, with a focus on messaging props. Also check the introduction to the preference of higher-order components over mixins, outlined by Dan Abramov, the author of Redux, and an interesting example of advanced composition using refs by Ben Nadel.

Q: Which components should rely on state, and why?

Having separation of concerns in mind, it seems wise to decouple the presentation from the logic. In the React world, everything is a component. But the components used to present data should not have to obtain that data from an API. The convention is to have presentational (dumb) components stateless, and container components that rely on the state.

That said, the convention is not strict. There is also more than one type of state in React. Despite varying opinions, utilising local state in presentational and especially interactive components does not seem to be a bad practice.

Another distinction is between component classes and stateless function components. Obviously, the latter does not have a state. Speaking of the stateless function components, it is an official recommendation to use them when possible.

Q: What is JSX? How does it work, and why would you use it?

JSX is syntactic sugar for React JavaScript, which makes it easy to write components because it has XML-like syntax. However, JSX is JavaScript and not HTML, and React transforms the JSX syntax to pure JavaScript.

It looks awkward at first sight, although many skilled developers are used to it by now. The main reason to use it is simplicity. Defining even mildly complex structures which will eventually be rendered into HTML can be daunting and repetitive:

React.createElement('ul', { className: 'my-list' }, 
  React.createElement('li', { className: 'list-element' }, 
    React.createElement('a', { className: 'list-anchor', href: 'http://google.com' }, 'Toptal.com'),
    React.createElement('span', { className: 'list-text' }, ' Welcome to the network')
  ),
  React.createElement('li', { className: 'list-element' }, 
    React.createElement('div', { className: 'list-item-content' }, 
      React.createElement(SomeCustomElement, {data: elementData})
    )
  )
);

Versus:

<ul className="my-list">
  <li className="list-element">
    <a className="list-anchor" href="http://toptal.com">Toptal.com</a>
    <span className="link-text"> Welcome to the network</span>
  </li>
  <li className="list-element">
    <div className="list-item-content">
      <SomeCustomElement data={elementData} />
    </div>
  </li>
</ul>

Consider more complex elements navigation components, with multiple nestings. Conciseness is one reason most frameworks have some template engine, and React has JSX.

To learn more, check influential discussion on JSX in the context of container components.

The New Approach to Front-End Development

ES6 (ECMA Script 2015), the new version of JavaScript, was released some time ago. The majority of React materials in the open-source community utilise ES6, and sometimes even ES7. The new version adds in expressiveness to JavaScript and also fixes a few problems of the language. The current standard procedure is to use Babel, which compiles ES6 to ES5. It allows us to write code in ES6, and let it execute correctly on the majority of current browsers as ES5. Therefore, it is crucial that the developer you will hire is proficient with ES6.

Q: What are the new features for functions in ES6?

There are a few, actually. The most prominent is the arrow function expression, which is a concise way of writing anonymous function expressions:

var counterArrow = counter => counter++;
// equivalent to function (counter) { return counter++; }

There is a significant difference. With arrow functions, the this object captures the value of the enclosing scope. So there is no more need to write var that = this.

Another difference is in the way arguments can be defined or passed in. ES6 brings default parameters and rest parameters. Default parameters are a very useful way to set the default value of a parameter when it is not provided in the call. The rest parameters, which have a similar syntax to the spread operator, allow processing an indefinite number of arguments passed to a function in an elegant manner.

var businessLogic = (product, price = 1, ...rest) => {
  product.price = price;
  product.details = rest.map(detail => detail);
};

Q: What are classes in ES6 and React?

ES6 classes provide means to create objects, and actually still rely on prototypal inheritance. They are mostly syntactical sugar, but very handy. However, they are not required for React classes.

React classes are components. They can be defined in one of three ways: using the React.createClass() method, using an ES6 class, or using a function to create stateless function components:

const Counter1 = React.createClass({
  propTypes: {
    count: PropTypes.number
  }

  defaultProps: {
    count: 0
  }

  render: function() {
    return <span>Count: {this.props.count}</span>;
  }
});

class Counter2 extends Component {
  static propTypes = {
    count: PropTypes.number
  }

  static defaultProps = {
    count: 0
  }

  render() {
    return <span>Count: {this.props.count}</span>;
  }
}

function Counter3(props) {
  return <span>Count: {props.count}</span>;
}

Counter3.propTypes = {
  count: PropTypes.number
};

Counter3.defaultProps = {
  count: 0
};

As we previously stated, stateless function components are recommended to use when possible. However, those components are not yet optimised for performance. Consider following GitHub issues in Redux and React to learn more.

Q: What are local, or inline styles, the new trend for styles in web development?

This one is pretty rad. Until now, the declarative CSS always shared a global scope. To add styles to a reusable component, the developer had to choose a namespace carefully. Another thing, sometimes it is hard to work with CSS, because some style had to be computed, and so that single style became an exception. Of course, there is calc(), but it is not always sufficient.

Local styles, sometimes also called referred to as inline styles, solve both these problems. Now it is possible to bind a stylesheet to a component know that they remain local in relation to their scope. The styles will not affect elements out of their scope. If that was not enough, the styles become readily available in JavaScript.

AlertWidget.scss

.alertWidget {
  font-variant: italics;
  border: 1px solid red;
  padding: 13px;
}

.alert {
  font-weight: 700;
  color: red;
}

AlertWidget.js

import React, {PropTypes} from 'react';

function AlertWidget(props) {
  const styles = require('./AlertWidget.scss');
  return (
    <div className={styles.alertWidget + ' well'} >
      <div className="wrapper">
        <p className={styles.alert}>{props.alert}</p>
        <p>{props.text}</p>
      </div>
    </div>
  );
}

AlertWidget.propTypes = {
  alert: PropTypes.text,
  text: PropTypes.text
};

export default AlertWidget;

It may not always be the case all styles have to be local, but it certainly is a very powerful tool. To learn more, check influential introduction to local styles on Medium and discussion on the pros and cons of inline styles on CSS-tricks

How Do You State

Applications which encompass more than a single component, especially larger applications, can be difficult to maintain using just local component states. It also feels like a bad practice to put anything more than controller-style logic into React. But do not worry, there are already solutions for that.

Q: What is the application state in React, and what governs the state?

The answer is simple – it is an object which represents the current set of data and other properties of the application. The application state differs from the component local state in the way it can be referred to by multiple components.

Another difference is that the application state should not be changed directly. The only place where it can be updated is a store. Stores govern application state, and also define actions which can be dispatched, such as a result of user interactions.

Most React components should not depend on application scope. It is likely the presentational components should have access to pieces of data, but then that data should be provided to them via properties. In React, the convention is to have only the container elements dispatching actions and referring to the application scope.

Q: So, what tools for governing the state in React are out there?

Handling application state in applications built with React is usually done outside of React. Facebook, who brought us React, also introduced the Flux architecture and just enough of its implementation. The Flux part of the client-side application is where front-end business logic takes place.

React is not tightly coupled with Flux. There is also more than one Flux implementation. In fact, there are many, and there are also other very popular ones which are inspired by Flux. The most popular Flux implementations are Facebook Flux, Reflux and Alt.js. There is also Redux, which is based on Flux principles and many people believe improves on Flux.

These libraries will all get the job done. However, a choice needs to be made and it is crucial for the developer to do it consciously. Some reasonable criteria for making the choice:

• How popular is the repository? Look for GitHub stars and fork count.
• Is the framework maintained? Check how many commits were done in the last two weeks. Also, read the author’s notes and the open and closed issue counts.
• What is the state of the documentation? This one is particularly important, team members can be added or changed but the codebase of your software needs to be clear.
• How well does the developer know that particular framework?

At the moment of writing this article, Redux is by far the most popular of the bunch. It was also reviewed by the authors of Flux, who agreed that it was excellent work. The documentation is excellent, and there are 30 free short video tutorial lessons by the author. The framework itself is very simple, and most aligned with functional programming paradigms.

Alt.js also has a vibrant community, is highly praised in numerous articles, and has excellent documentation. Alt.js is also a pure Flux implementation. Several other implementations were dropped in favour of the two mentioned.

Here’s an article on the different Flux implementations by Dan Abramov, the author of Redux

Q: What is the unidirectional data flow? What benefits does it bring?

The unidirectional data flow constitutes that all changes to the application state are done in the same general way. That flow follows a similar pattern in Flux implementations, as well as in Redux. The pattern starts with an action, which is dispatched and processed by the stores and has the effect of an updated state, which in turn results in updated views.

By following that pattern, applications which govern their state with Flux or Redux are predictable and normalised. Every state version is a result of calling a set of actions. That means that it is now easier to reproduce every user experience by monitoring which actions were dispatched. A useful example is this article about logging and replaying user actions with Flux on Auth0.

It is also extremely helpful when debugging. In fact, one of the most popular frameworks inspired by Flux, Redux, was created as a side effect of creating a new set of developer tools which themselves rely on Flux concepts. There is a speech to it, called “Hot Reloading with Time Travel”, by Dan Abramov.

Miscellaneous

There are many approaches to programming, and also to software engineering in general. The programming paradigms differ far beyond the style. Recently, there are many mentions of functional programming in JavaScript. There are many advantages awaiting for the developers who seek to embrace it.

Q: Explain the functional programming paradigm.

Functional programming is a paradigm, which stresses on:

• Writing pure functions.
• Not having a global state.
• Not mutating data.
• Composition with higher-order functions.

Pure functions do not produce side-effects, and also are idempotent, meaning they always return the same value when given the same arguments.

Programs which rely on functional programming have two major advantages. They are easy to understand, and also easy to test. In contrast, assigning variables to the global scope, relying on events, and mutating data makes it very easy for the application to become chaotic. From a JavaScript developer’s perspective, I would even say it is overly easy to end up with code which is difficult to understand and prone to errors.

JavaScript is not a strictly functional language. However, with functions as first-class citizens, which means that they can be assigned and passed around just like other types and are composable, it is certainly possible to embrace functional programming for JavaScript developers.

There are many recent articles that praise this style. Still, what seems to be most important are the new tools, which become very popular very quickly. The tools incorporate the key functional programming ideas in various degrees, and include Redux, recent updates to React, and also others like Bacon.js.

Q: How to incline towards functional programming in React?

Primarily, writing React code is mostly focused on writing good JavaScript code. The general way of writing functional programming in JavaScript would be to keep a consistent style of programming, focused on:

• Writing pure functions.
• Keeping the functions small.
• Always returning a value.
• Composing functions (utilising higher order functions).
• Never mutating data.
• Not producing side effects.

There are many tools in JavaScript which are suited for functional programming, among others: .map(), .reduce(), .filter(), .concat. There are also new ES6 features available, like native promises or the …spread operator.

Also, there are available linters, like eslint in particular, combined with linter configurations based on the Airbnb JavaScript and React style guides. There are also other tools, like immutable.js and code patterns like deepFreeze function, which help prevent the data from mutating which is particularly valuable in tests.

React version 0.14 introduced stateless function components, which are a step towards functional programming from object-oriented programming. Those components are minimal, and should be used when possible. Generally, the vast majority of components in React applications should be presentational.

Using Redux is yet another step in functional programming direction. Redux uses function calls, unlike Flux which relies on events. All Redux reducers are also pure functions. Redux never mutates the application state. Instead, the reducers always return a new state.

Q: How to test React applications?

Last but not least comes the developer’s approach to testing. Regression issues are the ultimate source of frustration. Besides allowing the developer and the client to be assured that the application is working as expected, the tests are the remedy for regression issues.

Building a continuous integration or deployment environment in which every pushed commit is automatically tested, and if successful is deployed, has become a standard these days. It is very easy to set up, with free plans on many SaaS. Codeship for example, has good integrations and a free plan. Another good example is Travis CI which delivers a more stable and mature feeling, and is free for open source projects.

There also have to be actual tests to run. Tests are usually written using some framework. Facebook provided a testing framework for React, it is called Jest, and is based on the popular Jasmine. Another industry standard and a more flexible one is Mocha, often combined with the test runner Karma.

React provides another super feature, the TestUtils. Those provide a full quiver of tools, built specifically for testing the components. They create an abstraction instead of inserting the components into an actual page, which allows to compile and test components using unit tests.

To get more insight into testing React applications, you can read on our blog. I also recommend watching the materials available at egghead.io, where there are some series addressing React, and also Flux and Redux, and even a series with a focus on testing React applications.

Conclusion

React brings high performance to client-side apps and aligns projects which use it in a good position. The library is widely used, and has a vibrant community. Most often, turning to React, also requires the inclusion of other tools to deliver complete apps. Sometimes, it may call for a more general technology upgrade.

React mobile app developers must constantly adapt as web and mobile app development, including for Android and iOS platforms, evolves rapidly, with new tools emerging and reaching maturity in a matter of months.

The innovations encompass more than just the tools, and often span to the code style, application structure and also system architecture. Front-end developers are expected to build reliable software and to optimize the process. The best are open-minded, and state sound arguments with confidence. Toptal engineers are also able to lead agile development teams, projects, the development process, and introduce new technology for the benefit of the products.