ReactJS: Functional Stateless Components

maxresdefault

Smart programmers are naturally lazy! Why, cause they write code in such a way that, the next time they need a certain chunk of code, they can refer to it, with just a single line of code. Reusability, Reusability, Reusability! ReactJS provides such capability through the use of components.

Prior to React 0.14, components were defined as ES6 classes, as seen below:

class Price extends React.Component {
    render(){
        return <span>$, {props.price}</span>
    }
}

Since the release of React 0.14, components can be defined as Javascript functions which accept inputs called props and return React UI elements. That is why we call them functional, stateless components (FSCs). Here is a simple component defined as a Javascript function:

function Price(props){
    return <span>$, {props.price}</span>
}

To render the component in the view, we add this code, which basically calls Reacts to render function passing the custom component and the DOM element in which it will be inserted:

ReactDOM.render(
   <Price price="3500" />,
   document.getElementById('root')
);

We can also use ES2015 arrow functions to define the components, it provides a shorter syntax:

const Price = ({ price }) => <span>$, {price}</p>;

FSCs provides a simpler, cleaner way of defining and rendering components compared to class components, which basically fulfills the need to only pass data in via props and render a UI component. With class components, you would have to scan through several lines of code to see if it has any state management, or lifecycle hooks.

FSCs are sometimes called presentational components, and as a good practise, it is recommended that your React application should have more stateless components, than stateful components. They can easily be tested using a series of functional tests, leading to fewer or no bugs.

Another great benefit of FSCs is that they are highly portable and can be used in other Javascript frameworks apart from React since they are merely functions.

Also, you can define propTypes and defaultProps in FSCs, as seen:

Price.propTypes = {
   price: React.PropTypes.number.isRequired
};

Price.defaultProps = {
   price: '3500',
};

Event handlers can also be defined with FSCs, but the only drawback is each time the FSC is instantiated, the event handler will be re-initialized, which can hurt performance. So to avoid this, your best bet is to pull out the event handler from the FSC. Here’s an FSC with an event handler defined within:

const Price = props => {
    const onClick = e => (...)

    return <button onClick={onClick}>Calculate Price</button>
}

And here’s an FSC with an event handler defined outside (recommended):

const onClick = e => (...)

const Price = props => {
    return <button onClick={onClick}>Calculate Price</button>
}
Wrapping Up

I would recommend developers to adopt the usage of FSCs in the applications they develop, as they are cleaner and possess potential performance benefits when infused into React apps.

Author: daltonwhyte

A technocrat who believes in a smart future, that will be proliferated with systems that allow us to focus on the bigger picture.