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

Just wanted to write a quick post about small project I'm working on. I'm writing my first bash script and its purpose is to completely take care of setting  up a new machine (Mac or linux). 

Here it is: [install.sh](https://github.com/jonleopard/dotfiles/blob/master/install.sh)

**Description**
Since I use both Mac and Linux, I wanted my dotfiles to be as portable as possible. I chose to use [stow](https://www.gnu.org/software/stow/) since its platform agnostic, and very easy to use/setup.

Script will look inside your home directory first and backup any existing dotfiles (just to be safe). Then it will look at your kernel and decide what to do next. [Homebrew](https://brew.sh/) will install all the packages I have defined in the brew.sh file. This only applies to MacOS systems. If I'm on linux, then I just need to install a few dependencies (some of which will be defined in vim-install.sh). 


You might be thinking, "Uh, why not just git pull your dotfile repo and stow whatever dotfiles you want to use??". Well, you could totally do that if you don't mind manually setting up the rest of your dependencies and plugin managers. I just wanted to make something completely automated. It might be silly, but hey, its a learning experience!



**Goals**
If people like this approach of managing dotfiles, zsh & vim plugins, then it might be cool to just set up a bare-bones branch but strips away my customisations, therefore allowing the user to build their own dotfile repo.

The bare-bones edition would most likely just be:

* GNU stow
* vim OR neovim
* bash OR zsh
* if zsh then install zplug



From there, you'd just go in and install your vim/zsh plugins and start git inside ./dotfiles.



**Todo**

* Finish mac testing
* Finish vim-install.sh
* Implement a chsh command for switching shells (if * installing/using zsh)
* Finish linux commands and test in Ubuntu env
* Once finished, cleanup README.md and write installation instructions.


Take a look at the file and let me know what you think! If you like what's been made so far, then feel free to contribute :)

