
Greetings earthlings! And welcome to another install of A to Z in FP. In today's article, we'll be targeting a concept that, like the Alphabet, also begins with the letter "A" **Abstraction!**

![Letter A Image](/static/Letter-A.jpg)

### Understanding Abstraction

- When writing code in declarative manner [¹](#1), it's important to place a great deal of emphasis on creating abstractions within our code base. To successfully build resilient, pure applications, we should aim to abstract functionality (code) away from the values that it's meant to operate on, as opposed to hard-coding computations within the body of a function.
- This process is referred to as "generalization" and we should be doing it wherever possible. Once we have our generalized functions, we can use them to create specialized versions that are tailored to our needs.

### Show me the contrived examples!

- It can be easy to get caught up in programming lingo so let's take a more practical approach and look at some examples. Below, we have two extremely (im)practical functions: `contrivedCalcNumeroUno` & `contrivedCalcNumeroDos`.

```jsx
const contrivedCalcNumeroUno = x => {
  const fiftyPercent = x / 2
  const addTenToFiftyPercent = fiftyPercent + 10
  return addTenToFiftyPercent
}

const contrivedCalcNumeroDos = x => {
  const twentyFivePercent = x / 4
  const addTwentyToFiftyPercent = twentyFivePercent + 20
  return addTwentyToFiftyPercent
}

contrivedCalcNumeroUno(100) //? 60
contrivedCalcNumeroDos(100) //? 45
```

- Our goal is to create abstractions for these functions. The first step we should take is to recognize any code that can be pulled out of the function body and transformed into it's own function. Additionally, we're going to want to pay attention to any behavior we see that our functions are sharing.
- In this case we should note that both functions perform the following computations:
  1. Dividing the function's input by some number.
  2. Adding some number to the result of the freshly divided input.

### Real eyes realize how to generalize then specialize [functions].

- Now that our detective work is done, we can begin abstracting away these implementation details by creating some generalized functions. First, let's create a function for handling division.

```jsx
const divide = x => y => y / x
```

- Rather than taking the arguments at once, we will define `divide` to be a curried function.
- I'll go into detail about function currying in a separate post. For now, however, we just want to acknowledge the fact that by doing this, we'll be able to leverage `divide` to create new, specialized functions.
- Any guesses as to what these functions are going to look like?
  - Here's a hint: there names are `calculateOneHalf` and `calculateOneQuarter`.
- Before we take a look at those though, we need to create one more generalized function for performing addition.

```jsx
const divide = x => y => y / x
const add = x => y => y + x
```

- With exception of its addition operational symbol, the `add` function is doppelganger of `divide`doppelganger.
- Even though we have't flipped the arguments like we did inside `divide`, we could have if we really wanted to due to addition's communitive property.
- In other words, order doesn't matter in addition therefore the code block above will work in the exact same way as the code block below.

```jsx
const divide = x => y => y / x
const add = x => y => y + x
```

- Alright! We are looking good! Like, super good. Derek Zoolander good.... seriously 😎.

### Generalized ⇒ Specialized

- We're finally ready to recreate our contrived examples using our new `add` and `divide` functions.
- Throughout this ar
- If you took a shot at defining these functions on your own, let's see how you did.

`calculateOneHalf`

[article.md](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/9b87aedd-d92c-4f5d-acee-27f13f200da6/article.md)

- **Creating abstractions is a crucial part of the functional programming paradigm._> AB~C~A -> Always Be Abstractin'!_`js`**

### Footnotes

**¹.** Declarative code describes code that adheres to the functional programming paradigm. It's inverse would be imperative code.


Abstractions in JS


Functional programming is littered with terminology that sounds really confusing. If you're new to FP or even programming in general, then it's important to keep in mind that these are just words used to describe concepts that you're likely already familiar with. As you continue on learning, you'll begin to understand that these terms simply allow for us to base our programming practices in various mathematical theorems, thus ultimately create pure, deterministic programs.

The goal for this article, and every article in this series, is essentially the same: **to help mitigate any confusion that can arise when learning about common FP terminology, while simoultaneously helping you become more comfortable with these concepts**. Today, our goal is to bring you closer to **functors**.

## Meet functor.

At the core of functional programming as a data type called functor. The essence of this data type is that it is `mappable`. This simply means that it provides an interface that we can `map` over in order to read or transform values.

Hmmm.... A container that we can map through. 🤔 Sounds kinda familiar, right? 😏

#### Why functors

```js
const myFunctor = [25]
```

Above we see the `myFunctor` variable being set to an array. This array acts as a container inside of which we can store values. In this instance, we're storing numbers, however this could be names, objects, etc. The shape of the data is irrelevant. Rather, it's the shape of the data type that is important, and as we can see by checking out our `myFunctor` variable, basic arrays can be classified as a valid interface for functors.

Do you know what this means? It means that you've been interacting with functors all along, and you likely didn not even realize! I sincerely hope that this fact is as mind-blowing to you as it was to me. Before we get too ahead of ourselves,let's be good functional programmers and prove this to be true.

### Prove it

In order for an interface to be considered a functor, it must passed the functor laws of **Identity** and **Composition**.

1. **Identity**:
   - id function must always `map` a functor back to the **same value**,
   - `const id = x => x;`
   - `[1,2,3].map(id); // returns [1,2,3]`
2. **Composition**:
   - Functors of the same type can be computed in any order and it will not effect their value.
   - _Given `g: x => y, f: y => z` where `x,y,z` are collection objects..._ **there must be a composition that directly `X → Z`**.

> This composition law was the same that I was forced to learn in algebra class. It' **associative** meaning that the order in which it is computed does not matter. Realizing this was a big "a-ha" moment when studying functional programming.

> **Ex.:** (f ◦ g) ◦ h = f ◦ g ◦ h = f ◦ (g ◦ h)

Now that we know the functor laws lets apply test them out against our array example.

#### What we know

1. `f` takes an `x` and divides by `.5`
2. `g` takes an `x` and multiplies by `10`
3. `functor` is a functor containing 1 value.

```js
const f = x => x / 0.5
const g = x => x * 10
const functor = [25]

// identity law
console.log(functor.toString() === functor.map(x => x).toString()) // 25 === 25

// composition law
console.log(
  functor
    .map(g)
    .map(f)
    .toString() === functor.map(x => f(g(x))).toString()
)
```

##### Who f\*ckin cares dude

> Why the FUCK do I care about these stupid fucking functor laws man.... Shit is sooo FUCKING stupid.
>
> - Majority of people reading this posts

Maybe you're not impressed with our `data` array and the one value that it includes. functor's satisfy the `Identity` and `composition` law. Well, that's too bad but don't give up just yet.

We've seen functors in action and we've learned the rules that they must abide by. Now let's create one for ourselves.

The `Box` functor (often referred to as the `Identity` functor) will take a value as it's input. From there, it will return an object `{}` with a `map` method inside of it. When this `map` executes, it will apply it's input `fn` to the value inside and return it's result wrapped inside of. What's that you said? This `map` implementation sure sounds awfully familiar to JavaScript's``Array.prototype.map`. Well, friend, _that's because it is_ !

Taking a look at the code snippet below we see how our `Box` function's `map` method is implemented. Cool, right?

```javascript
const Box = value => ({
  map: fn => Identity(fn(value)),
})

const OurFirstFunctor = Box(20)
```

![boring]('../../../imgs/boring.gif)

Alright, I get it. Let's extend this a little bit by adding some more methods, `fold` and `inspectValue`.

```javascript
const Box = value => ({
  map: f => Box(f(value)),
  fold: (f, g) => f(value),
  inspectValue: () => `Box${value}`,
})
```

```js
// identity law
const id = x => x

const result = Box(20)

const x1 = result
const x2 = result.map(id)

x2.map(trace) // value:: 1
x1.map(trace) // value:: 1

// composition law f(x) * g(x) = f(g(x))
```

That being said, I hope that this theme of "more simple than it looks" is a re-ocurring throughout your journey learning FP.

### Wrap up

And thus conclude this intro post on functors. Hopefully you've learned something that you didn't prior to reading this.

Need Improvemen? Give me a call!
The goal for this article, and every article in this series, is essentially the same: to remove the confusion that stems from FPs terminology.


Fun with Functors - Part 1


In my post on pure functions, we discussed the importance of avoiding mutable state when writing programs. In this post, we're going to take a look at internal JavaScript methods

### [Does it mutate](https://doesitmutate.xyz/)

# Immutable

### `forEach`

- interates over each item in an array.
- Using `.forEach` does not always mutate the array that it's iterating over. This is a common misconception in the JavaScript world.
- Mutation depends on it's usage but it's not uncommon, as many beneficial usecases result in mutation.

```js
const originalArr = ["Iron", "Super", "Ant", "Aqua"];
originalArr.forEach((name, index) => originalArr[index] = `${name}man`);
* Although you can get away with using `.forEach`, I advise against using for it in favor of `.map`.
* a common misconception is that using `.forEach` method always results in mutation.

```

### `flat`

- It was a highly anticipated addition to the language that was officially released in ES2019. (check)
- This method iterates over an array and flattens nested arrays (numbers + sub arrays)

### `p

### `includes`

### `indexOf`

### `find`

### `join`

### `keys`

### `slice`

### `some`

### `toSource`

### `values`

### `lastIndexOf`

### `fromEntires`

### `findIndex`

### `entries`

### `reduceRight`

### `reduce`

### `map`

### `filter`

## Arrays

### `push`

- Adds an item to the end of an array.
- Mutates the original array.

### `sort`

- The sort() method sorts the elements of an array in place and returns the array. The sort is not necessarily stable. The default sort order is according to string Unicode code points.

```
var months = ['March', 'Jan', 'Feb', 'Dec'];
months.sort();
console.log(months);
// expected output: Array ["Dec", "Feb", "Jan", "March"]

var array1 = [1, 30, 4, 21, 100000];
array1.sort();
console.log(array1);
// expected output: Array [1, 100000, 21, 30, 4]
```

Array.prototype.sort (comparefn)

### `copyWithin`

- The copyWithin() method shallow copies part of an array to another location in the same array and returns it without modifying its length.

```js
const array1 = ['a', 'b', 'c', 'd', 'e']
console.log(array1.copyWithin(0, 3, 4))
// expected output: Array ["d", "b", "c", "d", "e"]
// copy to index 1 all elements from index 3 to the end
console.log(array1.copyWithin(1, 3))
// expected output: Array ["d", "d", "e", "d", "e"]
```

### `shift`

- The shift() method removes the first elements of an array and returns the new length of the element.
- mutates the length of the array

Array.prototype.shift ( [ item1 [ , item2 [ , … ] ] ] )

### `unshift`

\*The unshift() method adds one or more elements to the beginning of an array and returns the new length of the array.

```js
Array.prototype.unshift ( [ item1 [ , item2 [ , … ] ] ] )
```

### `splice`

- The splice() method changes the content of an array by removing existing elements and/or adding new elements.
-

```js
Array.prototype.splice (start, deleteCount [ , item1 [ , item2 [ , … ] ] ] )
```

### `fill`ç

### `.pop`

- removes the last item of an array and returns that item.
- mutates input array.

```js
const trace = label => val => {
  console.log(`${label}`, val)
  return val
}
const plants = ['broccoli', 'cauliflower', 'cabbage', 'kale', 'tomato']

plants.pop()
// expected output: "tomato"

const head = ([firsst, ...rest] = (array = [])) => first
// pure
plants.slice(1)
```

### `.reverse`

- executes an in-place reversal on its inputs array.
- mutates the original array via in-place reversal.

```js
const reverseArray = (array, source = []) =>
  source.length === array.length
    ? source
    : source.concat(reverseArray(array.slice(1)), array[0])

//aka pass through an array with a sliced off first index

// 4) func() return
// 3) func(4),func(34), func(234),1
// 2) func(34),func(234),1
// 1) func(234),1

var reversedArr = reverseArray(arr)

console.log(reversedArr) // [4,3,2,1]
// console.log(arr)    // [1,2,3,4]

// describe("reversedArray", assert => {

//   const data = [1,2,3,4];
//   const output = reverseArray(dat)
//   assert({
//     given: 'an array of items',
//     should: 'reverse the array',
//     actual: output,
//     expected: [4,3,2,1]
//   })
// })
```


Deep dive into JavaScript's built-in array methods


### Pure Functions

#### Intro

Hello! My name is Thomas Greco, and this is the first of many posts regarding my time spent with Eric Elliott. Over the last 6 months, I have completely transformed my knowledge of JavaScript. I may have some times felt in over my head, however I never let myself give up. Instead, I continued to grind through the material so that my brain had no choice to absorb it! Now, 6 months after coming into contact with JS Cheerleader and Eric, I feel primed to take on any interview that comes my way. These posts also aim to further show my readiness as they will provide examples of my work while also showing that I truly understand the material.

My journey began focusing on pure functions, which is what I am going to discuss today. A pure function maps the same input to the same output every time. In order for a function to be pure, it must have the following characteristics:

- Always maps the same input to the same output.
- Does NOT rely shared state.
- It will produce no side effects.

The benefits of using pure functions are tremendous. As stated above, they always map the same input to the same output which means that they're completely predictable. In addition to being completely predictable, pure functions also possess the characteristic of being easily testable. Simply put, if you can think of a scenario, then you can test your code against it, ultimately making your code prepared for any inputs that comes its way. This is extremely helpful for UI development, especially when approached using a practice lke TDD.

Now that we know a little bit about the benefits of using pure functions, let's take a look at some example. Below we have our first pure function: `multiply`.

```javascript
const mutiply = x => y => x * y
add(4)(5) // 9
add(2)(4)
```

`mutiply` is a curried function and therefore it takes it's arguments seperately. Nonetheless, it still possesses all of the characterstics necessary in order to be considered a pure function. As a result of this, we can easily reason about the output that `mutiply` will produce by simply substituing it's `x` and `y` values for real numbers without even having to write any code!

> given `x` of 5 and a `y` of 3, we know that `mutiply` is going produce 8.

#### Staying focused

Our `mutiply` function fulfills all of the pure-function requirements, however it doesn't mean that we're free from running into issues when using it. In addition to modelling our functions to be pure, we can't forget to keep the rules of pure functions in mind when it becomes time to use it. In the code block below, we see an example of code that is no longer determistic. Can you tell which of the 3 purity rule this goes against?

```js
import { globalValue } from '../applicationState'
const mutiply = x => y => x * y
// glo
add(5)(globalValue) // 500
```

The issue lies within our `globalValue` import. For all we know, `globalValue` could be an array of numbers! Let's say that `globalValue` is a number. Better yet, let's imagine that it's bound to the correct value we're supposed to use. Do you think it's still OK to use? (Here's a hint: NO! :)) Let's imagine that we've just inpected the `applicationState` module and found `let globalValue = 5;`. We were relieved to find it, but are now concerned because the mutiplication doesn't line up. Instead of evaluating to `25`, `add(5)(globalValue)` is evaluating to 500. We're `425` away from our deired value. Even worse, we're stressed. After further investigation, we've come to see that it is being reassigned to equal `100`.

That example was even more contrived than I would rather have provided but I hope it benefited you. The main point is to always keep the 3 rules of function purity in mind until they become law.

### Seeing baby pure functions are made

Going back to examples of how to properly write code declarative code.

Let's make this a little bit more interesting. As I mentiond before, `mutiply` is a curried function. As a result, we can use `multiply` to create other functions that are also pure.

See if you can finish the example below:

> Hint - `multiply(5)(2)` evaluates to `10`

```js
// multiply :: Number -> (Number => Number)
const multiply = x => y => x * y;
// use multiply to finish creating the functions below
const doubleIt = multiply;
const multiplyByFive = ;
const multiplyByTen = ;
```

You can find the solution for above [here]. If you're still in the process of understanding the details that make up a functional codebase, and declarative code is different from code modeled around imperative expression, then you'll benefit from seeing examples of pure functions being used to create other pure functions. In addition to seeing function purity, we also get a glimpse of why JavaScript functions are considered "first-class citizens" within the language. This is due to their ability to take functions as input as well as return functions as output, which is exactly what we see in `mutiply`. Even though we eventually end up at a number, `mutiply` doesn't only return a number. Rather, it returns **a function that returns a number**, hence why we're able to use it to create new functions.

### First Class Functions + Pure functions = Composable Determisim

First-class functions is essential to FP so let's stay on this topic.

We just saw this in `mutiply`. The end result is a number

We can see the signature for `mutilply` we signature of `mutiply`

### Separation of Concerns

This theme of code re-use is central to functional programming paradigm. By employing nothing but pure functions As you immerse yourself deeper and deeper in FP it will be come second nature like our `mutiply` function, wure functions allows us to break our applications up into reusable bits of code. This fits in well with the ideas behind functional programming, where the goal is to have one function perform one piece of functionality. We can then use function composition to have these functions run in-sequence in a points-free manner to perform some transformation on an input, however that is a conversation for a different time! For now, I want to continue focusing on the things that makes functions pure. As I mentioned before, pure functions can not rely on shared, mutable state. This will remove a slew of bugs from name-clashing to race-conditions, thus allowing an application to perform better. In addition to these benefits, code with pure functions is generally cleaner, and much more modular than non-pure functions.

Continuing on, let’s discuss how to approach making functions pure.

### Making Impure Functions Pure

When I initially tackled pure functions, I had a hard time making the tests pass in [this codepen]() from Eric Elliott’s post on the topic. In order to complete the example, users are instructed to refactor the block of code below, so that each function was pure.

```
const setPrice = (item, price) => Object.assign(item, { price });

// addToCart(cart: Array, item: Object) => cart: Array
const addToCart = (cart, item) => {
  cart.push(item);
  return cart;
};
```

I immediately gravitated towards the `push` method, which returns a modified version of whatever it is pushing on to (in this case the cart). This will result in a mutation, so I knew that I had to remove this. When `concat` did not solve my problems, I turned to `Object.assign` to return a new object that merged the contents in the existing cart with the item being added. I eventually ended up with the `addToCart` function below.

```javascript
const addToCart = (cart, item) => {
  return Object.assign({}, cart, [item])
}
```

After that code rewrite, my tests for the `addToCart` function were passing, however I still needed to make some changes to `setPrice`. Taking a look at the code, I was able to quickly reason that an empty object was needed to as the first argument `Object.assign`. Once that modification was made, all tests were showing green and I was feeling pretty good myself.

The completed code for these functions can be shown below.

```javascript
// don’t these one-liners look neat?!
const setPrice = (item, price) => Object.assign({}, item, { price });
const addToCart = (cart, item) =>  return Object.assign({},cart, [item]);
```

And you can check out the completed codepen below.

<p data-height="300" data-theme-id="18714" data-slug-hash="xdjEBr" data-default-tab="result" data-user="thomasgreco" data-embed-version="2" data-pen-title="Pure Functions" class="codepen">See the Pen <a href="https://codepen.io/thomasgreco/pen/xdjEBr/">Pure Functions</a> by Thomas J Greco (<a href="https://codepen.io/thomasgreco">@thomasgreco</a>) on <a href="https://codepen.io">CodePen</a>.</p>
<script async src="https://production-assets.codepen.io/assets/embed/ei.js"></script>

#### Final Words

It’s safe to say that all roads in declarative programming lead to pure functions. They are the building block of everything I learned over the last 6 months, so I thought it was important that I kicked off these posts with this topic. As I continue forward to tackle like Higher-Order React components and Redux, I will almost always be using pure functions so I hope you like them as much as I do :)


Understanding the Importance of Function Purity

A website for learning about applying functional programming concepts to web application development. 

Abstractions in JS

Apr 27 2020

Fun with Functors - Part 1

Mar 20 2020

Deep dive into JavaScript's built-in array methods

Apr 27 2020

Understanding the Importance of Function Purity

Apr 27 2020