When first learning React, you are introduced to the concept of components. I first learned React though the official docs, and therefore started crafting my functional components the way it taught. After spending some time in other OSS projects, as well was watching quite a few online courses and guides on React, I noticed other ways of writing these functional components.


So a couple months ago, I asked [how do you write your functional components?](https://spectrum.chat/users/jonlprd?thread=91f98b74-a6b0-44ea-807f-372695da6926) over at [spectrum.chat](https://spectrum.chat/). The question also gained some traction over on [twitter](https://twitter.com/mxstbr/status/996653187481460736). People have a lot to say when it comes to how they write their functional components!


This was very educational and exposed me to a couple different ways to write React components. This also inspired me to write a short post on what the differences are between them. This is hardly an exhaustive blog post on the subject! I am writing this to help engrain the concepts into my head. 


With that said, how you choose to write your React components is simply a matter of taste and/or whatever convention(s) your team has decided on. We'll keep it simple and only discuss functional, or (dumb) components today.

---


## Normal Functions

As the [React documentation](https://reactjs.org/docs/components-and-props.html#functional-and-class-components) states:
> "The simplest way to define a component is to write a JavaScript function."


```jsx

function Welcome(props) {
 return <h1>Hello, {props.name}</h1>;
}

```

> "This function is a valid React component because it accepts a single “props” (which stands for properties) object argument with data and returns a React element. We call such components “functional” because they are literally JavaScript functions."


Whats really great about React is that it makes you a better Javascript developer. Components are simply Javascript functions, there is no abstraction going on here. Lets create a simple component that we'll transform throughout this blog post:


```jsx
export default function NormalFunction(props) {
 return (
 
 Greetings, {props.name}. I am {props.age} years old.
 
 );
}
```

If you are writing your component in a separate file, then you'll need to export it so that you can import it wherever you intend to use it. If you are writing a normal function declaration, you can either do this directly inline, like in the example above, or you can export at the bottom of your file like so:

```jsx
function NormalFunction(props) {
 return (
 
 Greetings, {props.name}. I am {props.age} years old.
 
 );
}

export default NormalFunction;
```

When reading the React documentation, I was curious why no components were written with arrow functions (I see so many out in the wild!). Dan Abramov helped clear my curiosity:

> In the docs we tend to prefer function declarations because people are more familiar with them. Hoisting is also helpful when you have many components in one file and want to define them in top-to-bottom order.

Curious what hoisting is? Here's an excerpt from the [MDN docs](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting):

> Conceptually, for example, a strict definition of hoisting suggests that variable and function declarations are physically moved to the top of your code, but this is not in fact what happens. Instead, the variable and function declarations are put into memory during the compile phase, but stay exactly where you typed them in your code.


Again, another great example of how React helps you become a better Javascript developer.

---

## Arrow Functions
We can also write React components by using [ES6 Arrow Functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions). For this example, we'll just do the same as the function above and write `props` as our single parameter. I'll explain prop destructuring in more detail in the next section.


```javascript
const ArrowFunction = ( props ) => {
 return (
 
 Greetings, {props.name}. I am {props.age} years old.
 
 );
};

export default ArrowFunction;
```

We could also omit the curly braces, and remove the return statement (unique to arrow functions):
```jsx
const ArrowFunction = props => (
 
 Greetings, {props.name}. I am {props.age} years old.
 
);

export default ArrowFunction;
```


Unlike our normal function, we cannot `export default` directly inline, so we'll have to do so at the bottom. It's also important to note that arrow function definitions are not hoisted like normal function declarations. 

Another topic we should explore is [function name inference](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/name). In section [7.1](https://github.com/airbnb/javascript#functions--declarations) of AirBNB's style guide, they suggest to use named function expressions instead of function declarations.
>Why? Function declarations are hoisted, which means that it’s easy - too easy - to reference the function before it is defined in the file. This harms readability and maintainability. If you find that a function’s definition is large or complex enough that it is interfering with understanding the rest of the file, then perhaps it’s time to extract it to its own module! Don’t forget to explicitly name the expression, regardless of whether or not the name is inferred from the containing variable (which is often the case in modern browsers or when using compilers such as Babel). This eliminates any assumptions made about the Error's call stack.


If you are using [@babel/preset-env](https://github.com/babel/babel/tree/master/packages/babel-preset-env) to transpile your code, then `const foo = () => {}` will be transpiled to `var foo = function foo () {}`. So if thats the case, you don't have to worry much about this. However, its still good to be aware of. You can read about this in more detail [here](https://github.com/airbnb/javascript/issues/794).

---

## Prop Destructuring

In the above examples, we just simply wrote `props` as our function parameter which allowed us to go pass in props like `props.name`. [Destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) is an ES6 feature and pairs nicely with stateless functional components. So, rather than declare props as our function parameter, lets destructure some props!

```jsx
export default function NormalFunction({ name, age }) {
 return (
 
 Greetings, {name}. I am {age} years old.
 
 );
}
```

Of course, we can do the same with arrow functions:

```jsx
const DestructuredArrow = ({ name, age }) => (
 
 Greetings, {name}. I am {age} years old
 
);

export default ArrowFunction;
```

This is great as it self documents the component and makes it clear as to what the component is expecting. The only caveat to this is that it can become ugly if you have a lot of props.

---

## Proptypes and Flow

A way to improve your components is by adding proptypes. With React, we can add types to our components to reduce errors and make sure our props are receiving the correct type of data.

Since React v15.5, [prop-types](https://github.com/facebook/prop-types) comes as a separate package that you'll need to install via yarn or npm. Implementing it is very simple, but make sure to check out the [documentation](https://reactjs.org/docs/typechecking-with-proptypes.html). 

[Flow](https://flow.org/en/) is another great tool which builds upon prop-types and adds additional power by informing you if you are misusing a component without actually running your code! 

+1 for Flow!


### prop-types
Here's how prop-types would look with our basic component:
```jsx
import PropTypes from 'prop-types';

export default function PropTypesExample({ name, age }) {
 return (
 
 Greetings, {name}. I am {age} years old.
 
 );
}

PropTypesExample.propTypes = {
 // You can chain `isRequired` to make sure a warning
 // is shown if the prop isn't provided.
 name: PropTypes.string.isRequired,
 age: PropTypes.string,
}
```


### Flow
Here's what Flow would look like, you can see its pretty similar to prop-types. The only downside to Flow is that it requires some additional set up to get running. Be sure to check out the [documentation](https://flow.org/en/docs/react/components/)!


```jsx
type Props = {
 name: string,
 age: string,
};


export default function FlowExample({ name, age }) {
 return (
 
 Greetings, {name}. I am {age} years old.
 
 );
}

```

---

### fin
So that about wraps up what I've discovered thus far with crafting stateless functional components. I'll be implementing a [codesandbox ](https://codesandbox.io) so that readers can play around with the examples I provided, so stay tuned for that. I am still learning quite a bit. If I made any errors, please mention them below in the comments! 

Thanks for reading!

Composing Stateless Functional Components

It's been awhile since my last post so I thought I would give little update on my progress.

[Colt Steele's](https://www.udemy.com/the-web-developer-bootcamp/) course was great. I highly recommend it if you are interested in building web apps with javascript. Aside from teaching vanilla javascript, the course also introduced you to some great frameworks and libraries (Express, Pug, MomentJS, EJS, etc...). 

I completed Wes Bos's [Node Course](https://learnnode.com/?utm_source=wesboscom&utm_medium=blog&utm_campaign=launchpost) and that has probably been my favourite javascript course so far. He can be a bit fast at times, so I found myself rewinding quite a bit. The course helped reinforced my MongoDB experience and also introduced me to another templating engine [Pug](https://pugjs.org/api/getting-started.html). [EJS](http://ejs.co/) templating syntax is pretty much the same as HTML, so if you prefer writing HTML then you'll wanna choose EJS as your JS templating engine. Pug felt faster and more fluid. Writing JS logic inside your templates is a great feature as well. 

I'm now working my way through [Brian Holt's](https://twitter.com/holtbt) Complete Intro to React course over at [FrontEndMasters](https://frontendmasters.com/courses/react/). React has been sort of difficult for me to digest. Redux....don't even get me started on that.

I recently went to my first Javascript [Meetup](https://www.meetup.com/FranceJS/events/243389082/) here in Paris and it was a blast. I met some great developers and look forward to meeting up with them again.

I'm starting to tackle my own little projects that I can add to my Github profile (I'll save those for another post). I am also trying to recreate my website using [GatsbyJS](https://www.gatsbyjs.org/) since its using all the technologies I am interested in. I'm using the [gatsby-advanced-starter](https://github.com/Vagr9K/gatsby-advanced-starter) skeleton since it already has SEO, Tags, Disqus comments, and other useful things out of the box. I am trying to style the entire website with [Rebass](http://jxnblk.com/rebass/) and [Styled Components](https://styled-components.com). So far, so good. Since I'm still new to React, it's been a bit challenging. [Dan Abramov](https://twitter.com/dan_abramov) wrote a great [article](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) thats helping me figure out "Presentation" and "Container" components.


**So to sum up what I've learned so far and practicing:**

* Javascript Fundamentals
* jQuery
* Git Version Control
* Databases (MongoDB & SQL)
* Templating (Pug & EJS)
* RESTful routing
* HTTP
* CSS & Sass
* Server Side Javascript (Node & Express)
* Other js libraries like [Passport](http://passportjs.org/) and [Moment.js](https://momentjs.com/)


**On the horizon:**

* ES6
* React / Redux
* NodeJS
* GraphQL
* Styled Components
* CSS Modules
* Webpack
* Code Splitting
* Server Side Rendering


That's all for now folks :)