
If you were to look up what a closure is, [Wikipedia's definition](https://en.wikipedia.org/wiki/Closure_(computer_programming)) has this to say in the first two lines:

> In programming languages, a closure, also lexical closure or function closure, is a technique for implementing lexically scoped name binding in a language with first-class functions. Operationally, a closure is a record storing a function together with an environment. 

That is a bit of a dense definition, but its not a complex as it seems at first glance!  This article aims to explain what this means, bit by bit, so you can use closures with confidence.

## Scoping
I first want to touch on what scoping means in JavaScript.  Before ES6, JavaScript only had **Global Scope** and **Function Scope**.  You have probably seen how variables are accessible based on what scope they were declared in.  Here is an annotated example:

```javascript
// Variable declared at the global scope.
var globalVariable = 'Neat';

function func() {
  // Variable declared in function scope.
  var funcVar = 12;

  console.log(globalVariable);
}

console.log(funcVar);
func();
```

If you were to execute the above code, you would get a `ReferenceError: funcVar is not defined` error.  If you remove the `console.log(funcVar);` line, the output would be `Neat`.  The reason for this is that scopes can only reference variable declared in their own scope (local) and any outer scopes relative to the current scope.  In this case, the scope in `func()` can access the outer scope (global) to get the value of `globalVariable`, however the global scope does not have access to the scope created for `func()` so it cannot access the funcVar variable.  One more example to show how inner scopes can access values in outer scopes.

```javascript
var globalVar = 'Hello';

function func() {
  var innerVar = 'World';

  function innerFunc() {
    var name = 'innerFunc';

    console.log(`${globalVar} ${innerVar}, from ${name}`);
  } 
  innerFunc();
}

func();
```

Executing the above will show `Hello World, from innerFunc` in the console.  We can see that `innerFunc()` has access to its local scope, the scope of `func()` and the global scope.

## Closure
The example above is actually a closure!  It represents the second part of the Wikipedia definition, `Operationally, a closure is a record storing a function together with an environment.`  In this case, the function is `innerFunc()` and the environment that is being stored is the local scope along with all of the outer scopes present at the time of function creation.

Thats it!  If you have been writing functions, you have been creating closures this whole time!

## Whats the Big Deal
The reason this can be a confusing topic is that closures can enable a handful of different patterns and ideas in JavaScript, even if they don't seem related at all.  So here are some quick examples of things that are possible because of closures:

### Access Data Through Interface
Say you wanted to create a simple counter with a variable representing the current count, and four functions: add, subtract, reset, show.

```javascript
let count = 0;

const add = () => {
  count = count + 1;
};

const subtract = () => {
  count = count - 1;
};

const reset = () => {
  count = 0;
};

const show = () => {
  console.log('Count: ', count);
};
```

If you were to use these functions to add and show, like
```javascript
add();
add();
add();
add();
show();
```

you would get `Count: 4`.  The issue is that if I were to throw in `count = 0;` right before the `show()` it would show `Count: 0`!  We are operating on a variable that any scope can access and modify, since it is global, and that is dangerous.  Something can accidentally mess with count and cause a headache of a bug.  This can be written in a different way:

```javascript
const mkCounter = () => {
  let count = 0;

  const add = () => {
    count = count + 1;
  };

  const subtract = () => {
    count = count - 1;
  };

  const reset = () => {
    count = 0;
  };

  const show = () => {
    console.log('Count: ', count);
  };

  return {
    add,
    subtract,
    reset,
    show
  };
};
```

This code is very similar, but you can see that we have declared it inside of a new function called `mkCounter` that defined the count variable locally to its scope.  At the end, we return an object that exposes the four functions but **not** the count variable, however since all of these functions are defined inside the `mkCounter` scope, the closing environment for all of them contain `count`!  Here is how it would be used:

```javascript
const counter1 = mkCounter();
const counter2 = mkCounter();

counter1.add();
counter1.add();
counter1.add();
counter1.subtract();

counter2.subtract();
counter2.subtract();

counter1.show();
counter2.show();
console.log(counter1.count);
```

which will give the output of:
```
Count: 2
Count: -2
undefined
```

Awesome, so not only can we **not** access the count as shown by the last line, each counter has its own count in their own environment to work with!

### Partial Application
Another closure example that I use all the time is partial application.  A simple example could be formatting a log with some data that you don't want to set every time you invoke the function:

```javascript
const mkLogger = (route, showDate = false) => {
  return message => {
    const date = new Date().toISOString();
    const header = showDate ? `${date} | ${route}` : route;
    console.log(`${header} | ${message}`);
  };
};
```

Then you can use the function like:

```javascript
const docLogger = mkLogger('DOCS', true);

docLogger('This is my log message');
docLogger('Another log message');
```

with the output of:
```
2021-11-15T23:55:26.672Z | DOCS | This is my log message 
2021-11-15T23:55:26.672Z | DOCS | Another log message 
```

This is nice because you can initialize things like the route and if you want to display the date when the program starts, then pass the simple `docLogger` function to other parts of the application that need to use it instead of calling something like `logger('DOCS', true, 'This is my log message')` every time you want to use it.

### Other uses
I just wanted to mention some other use cases that you can explore as well: Memoization, Singleton, Event Listeners.

## Conclusion
Hopefully the concept of closure isn't too complex any more!  If you do have any questions please let me know and I will do my best to address them and refine the article for clarity.  

**TLDR:** Closure is the concept of storing a function and its environment together.  When you create a function, it stores the functions local environment and its outer environment together.  If you are ever confused about what value will be present, understand what value existed when the function scope was created!


If you have ever been looking at JavaScript code and wondered what the heck the `?` and `:` is doing, look no further!

These two characters (?:) when used together is collectively called the ternary conditional operator, or ternary for short.  It is used to express a basic conditional operation, in the form:

```javascript
predicate ? truthy : falsey
```

The operand that comes before the `?` is the predicate, or the expression that you are basing your decision logic on.  The expression that follows the `?` will be what is executed if the predicate is *true*.  The expression after the `:` is what is executed if the predicate is *false*

## Example
Lets imagine you have an object that represents a `user`, and it potentially has a key `username` that would store that users username.  If we wanted to determine what to display in the UI, we could decide to show the username if it exists, or Anonymous if it does not.  We can quickly create a variable called username that will hold the correct value:
  
```javascript
const username = user.username ? user.username : 'Anonymous';
```

This would be opposed to writing the same functionality with a traditional `if` statement:

```javascript
let username;

if (user.username) {
    username = user.username;
} else {
    username = 'Anonymous';
}
```

Of course, the two expressions after the `?` can be anything that evaluates to a value:

```javascript
const someVal = checkSomething() ? doCoolThingSinceTrue() : doOtherLogicSinceFalse();
```

## Suggestions
This part is opinionated, but I try to avoid using multiple ternary operators chained together.  Nothing stops you from doing:

```javascript
const res = check() ? (checkTwo ? 'true checkTwo' : 'false checkTwo') : 'false check';
```
but in my opinion this causes more confusion than clarity and it would be better to write it in a more traditional if/else structure.

I usually prefer ternary if it is a quick 'inline' computation that I am passing as a parameter, or like in the original example, I am picking one of two expressions to execute at runtime and I need the result.

## Conclusion
Hopefully that helps clear up what this operator is all about and how it can be used.  If you have any questions, feel free to ask them below!


Hello, and welcome to the my first ever Devlog!  I wanted to attempt to build a new web application in public, mostly so I can look back on the experience one day, but also to possibly connect with other developers and builders that I wouldn't meet if I worked in the shadows!

My plan for this first post is to explain the application and what it attempts to solve, and then talk about the first steps I have taken in the first week of development.  I will also try to do some small tweets about what I am doing throughout the week and if you are interested in seeing those, give me a follow [@BoudroBam](https://twitter.com/boudrobam)!

## The Problem

When trying to decide on what to build, I wanted to make sure that I was addressing a problem.  It didn't have to be a big problem - in fact I spent a lot of time thinking of smaller problems to try and attempt to solve, but I was usually greeted with a handful of Software as a Service (SaaS) solutions that already existed! However, I didn't let that deter me and I finally settled on a problem to attempt to solve...

**Finding information within a company is a massive pain!**

I believe this is true for most industries, but it is especially true for software jobs.  Not only do you have to know about the systems you are developing and interacting with, you also need to know about the domain of the business, the business rules, which teams own what part of the system, and the list goes on and on.

When you are part of a company for a long enough time you may learn a lot of the things that I pointed out above through conversations and past experiences, but there is usually still some gap in knowledge.  If you are new to a company those points are even worse as you drown in a flood of domain knowledge and acronym soup.

I have found that if I was lucky my company had some sort of wiki or knowledge base where people published documentation.  However, I still find that with such a system in place, the issue still exists.  In fact, I feel that having a wiki gives false security that there is *correct*, and *useful* documentation.

## The Goals

I decided to title this section "The Goals" because ill be honest, I don't really have a solution!  This will be a hard problem to solve, and I imagine there will be many mistakes, learning opportunities, and pivots as I start building.  Instead I want to state some goals that will help define what a system that wants to solve this problem should be able to do.  It should:

* Assist with clarifying documentation.
* Surface the subject matter experts (SMEs) of topics.
* Ensure knowledge is up to date.
* Enable users discovery.
* Identify knowledge gaps.

I believe a system that does all of these things would massivly improve the correctness and usefulness of information sharing.  The goal that is the most daunting, but also the most important in terms of changing how information is compiled, is identifying knowledge gaps.  If the system can automatically detect, then ask for someone to fill the gap, that would be huge!

Of course, these goals may change as time goes on.  I may add new ones, or rework existing ones to capture new ideas, all based on user feedback.

## First Milestone - Clarifying Documentation Through Key Word Detection
With all of the goals laid out, I need to pick something to start driving toward.  While I can't tackle all of a singular goal in one go, I can at least start making milestones that I think will address them!  So the first goal area I am going to work on is assiting with clarifying documentation, and I think a good place to start would be to help highlight missing definitions.

The idea is that as pages of documentation are added and modified, the system can start to pick out keywords and request that maintainers of the space add definitions to a glossary.  I want to start here because it *appears* to be a pretty simple process and will allow me to get the basic infrastructure of the app set up.  I also think it would be a good launching point for starting to add layers of complexity to the process - first ill start with a simple detection and alert system, but then I can move on to suggesting definitions for industry terms, searching for "synonyms" if its a term used internally by the company, etc.

So, that is what I will be working towards first!

## Some Wireframes
That has been a lot of words, so I figured now is a decent time for pictures!  I have drafted up some wireframes to get just enough of a UI to drive the system.  Most are pretty basic and boring, focusing on creating flows for creating Organizations and Workspaces.  What I do want to show is just the initial "dashboard", and the two concepts that will help me drive towards the first milestone, the inbox and glossary.

![tilld dashboard](/images/main-hub-wireframe.png)
This is the main view when you are in an organization.  Its a pretty common layout but its a starting point, and there isn't really a point in reinventing the wheel at this point!

![tilld inbox](/images/inbox-wireframe.png)
I wanted to add an inbox as the feedback loop for how the system will indicate to the user when something actionable is detected.  In this case, when something should have an entry created in the glossary.  You can see in the mock up some other ideas I have for use of the inbox such as identifying SMEs, calling out gaps in documentation, etc.

![tilld glossary](/images/glossary-wireframe.png)
Having an easily accessible glossary is and important first step in achieving usefulness and clarity.  At this point in time it will be a basic list of term to definition mappings, but I imagine this will become more content rich as time goes on.


## Initial System Design
![tilld system design](/images/first-tilld-system-diagram.png)

Now that you have seen some of the visual ideas for the initial UI, I thought it would be good to show the first pass at an overall system design.
I went back and forth in my mind deciding on certain parts of the tech stack, seeing if there was any reason to use some languages and frameworks I wouldn't usually use on my own projects such as Rust with Actix Web or Haskell with Servant for the API but I ended up deciding to keep it simple and use Node with Express for the server since I was going to be using JavaScript anyways for the React front end!

That API server will then be responsible for the common CRUD operations for the things we see in all apps such as Users, and domain specific things like Organizations and Workspaces.  These will be written to a PostgreSQL database, since a lot of this info makes sense in a relational database.  I decided to go with a second database, a NoSQL database, increasing complexity a bit.  This is where the documents will be stored but this may end up being a mistake that I try and roll back in the future.  My thinking is that because im not really sure what kind of metadata ill be associating with documents to power this app, it will be easier to work quickly and try new things.

Finally the server will also be responsible for sending messages to a RabbitMQ queue for processors to consume.  Again, you can see that there is a plan to create a lot of processors to work off of messages being generated on document CRUD operations.  The first one is the keyword processor but ill need to process images to extract data, for example, and I will want to start building a graph of how things in the organization are connected, and who knows what else in the future!

The processors themselves will be written in whatever language makes the most sense, since it is highly decoupled they don't need to interact.  That being said, I am starting with Python for the first few because it was the best option when it comes to machine learning and data libraries, and I am keeping them all in the same codebase to allow for code reuse for the common tasks of working with the queues and database.

## Current Progress
So, I am not sure the best way of showing progress from a coding and development standpoint.  **If you have any suggestions of what you would like to see let me know in the comments!**

### General Notes
As of this writing I started working on the shell of the backend.  I wrote a docker-compose file to spin up containers to run the PostgreSQL DB, MongoDB, and RabbitMQ services for local development, and I created two new projects on Gitlab: api and data-processors.

### Data Processors
The data processor has been setup to take a command line argument to determine which processor to run on launch, so something like `python data-processors.py keyword` will start the processor and kick off the logic to pull from the queue and take actions to determine keywords (currently it does nothing besides echo any messages it gets, no fun keyword extraction yet!).  It pulls from the message queue using the [pika](https://pika.readthedocs.io/en/stable/).  Unfortunately there isn't too much that is interesting going on in here yet to show code wise.

The next thing to do will be to connect to the MongoDB instance to enable read/write operations on the documents. 

### API
Similar to the data processor, the first thing I did besides just the basic "Hello World" setup of an express server was create the functionality to write to the queue.  I set it up to be a singleton connection to avoid opening and closing all the time, and I can show the first pass of that code here real quick:

```javascript
const amqp = require('amqplib');

/**
 * Function to create a singleton connection to the RabbitMQ host.
 * Returns a function `get` to return the connection to the caller, and
 * `release` to close the connection.
 * 
 * `release` should only really be invoked if the server is closing and is added
 * for completness.
 */
const conn = (() => {
  let connection = null;

  const connect = async () => {
    try {
      return await amqp.connect(process.env.RABBITMQ_HOST);
    } catch (e) {
      console.log('Failed to connect to RabbitMQ Host: ', e);
    }
  }

  const get = async () => {
    if (connection === null) {
      connection = await connect();
    }

    return connection;
  }

  const release = async () => {
    if (connection !== null) {
      await connection.close();
    }
  }

  return {
    get,
    release
  };
})();

/**
 * A channel is just a multiplexed connection on the open TCP connection.  This allows us to have distinct channels for different logical
 * operations without maintaining extra TCP connections.
 */
const createChannel = async () => {
  const connection = await conn.get();
  const channel = await connection.createChannel();

  return channel;
};

/**
 * We make use of an exchange under the hood since most messages will be intended for more than
 * one consumer, and a standard queue is a 1-to-1 producer to consumer ratio.
 */
const createExchange = async (exhange) => {
  const channel = await createChannel();
  await channel.assertExchange(exhange, 'topic', { durable: false });

  return channel;
}

/**
 * The only function that should be used outside of this file.
 * 
 * Given an exchange name and a topic, return two functions.  One to publish to the exchange, and one 
 * to close the channel connection when done.
 * 
 * TODO - Write up some documentation to link to where we record all the exchanges / keys in use.
 */
const mkQueue = async (exchange) => {
  const channel = await createExchange(exchange);

  const publish = (key, msg) => {
    channel.publish(exchange, key, Buffer.from(msg));
  };

  const close = async () => {
    await channel.close();
  }

  return [publish, close];
}

module.exports = mkQueue
```

This allows me to make use of just the exported function like this:

```javascript
const { rabbitmq }  = require('./queue');

const [publish, close] = rabbitmq('docs');

publish('#', 'This is my message');

await close();
```

So anywhere that I want to write to the queue (any API endpoint that needs to produce a message), I can pass a handle to the publish function to and boom!

The next thing I did was setup my connection the PostgreSQL database using the [node-postgres](https://node-postgres.com/) library, and setup migrations to define my schema with [node-pg-migrate](https://salsita.github.io/node-pg-migrate/#/).  I created some simple `create` functions for the various parts of the database like this one for creating an organization:

```javascript
const createOrganization = query => {
  return async (name, description = '', industry = '') => {
    const { rows } = await query('INSERT INTO organizations (name, description, industry) VALUES ($1, $2, $3) RETURNING *', [name, description, industry]);
    const { id } = rows[0];

    return id;
  };
};
```

I might end up moving away from the migration library, but it seemed like it would work for my current use case.

As you can see from the code above, its not really production ready.  I need to set up error handling & recovery when executing these operations and do some logging, but ill probably do that at a later time when I am getting close to releasing the first milestone.

## Next Steps
This upcomming week I hope to achieve the following:
* Establish the connection to MongoDB for both the API and the data processor.
* Build the `/api/docs` route for all the verbs (GET, POST, PUT, DELETE)
* Persist docs to the MongoDB instance, send a message to the queue, and see the processor successfully retrieve the doc from MongoDB.
* Determine which data science package to use for keyword extraction
  * Implement the keyword extraction!
* Stretch: setting up the rest of the API routes for CRUD operations would be good as well.

## What Are You Building?
If you made it this far, thank you so much for reading!  I am hoping to release these either on a weekly or bi-weekly basis, so make sure to follow if you want to see the progress!

I would love to hear about what you are building as well!  Is it a library, a program to solve a problem that has been nagging you, the next Google? Let me know in the comments!


Pure functions are a cornerstone of functional programming, but even if you are writing code that isn't purely functional its a great idea to prefer them!

## Defining Pure Function

The two properties of a pure function:
* Given the same set of arguments, the function will always produce the same result.
* Invoking the function produces no side effects.

A side effect can be thought of as any observable effect *besides* returning a value to the invoker.

A simple example of a pure function:

```javascript
const add = (a, b) => a + b;
```

For any input into this function, it will always produce the same value.  That is to say, invoking the function like `add(5,2)` will **always** produce 7.  It is also possible to see that nothing else, such as modifying state or interacting with other systems, so this function is pure!

Technically, if we were to rewrite the previous function to call `console.log` to output some info, that would make the function *impure* because it is having an observable effect that is not just returning the function.  

Another example of an impure function would be `Math.random()` as it modifies the internal state of the Math object (breaking point 2) and you get different results each time the function is invoked (breaking point 1).

## Side Effects Cause Complexity
Functions that are pure are easier to reason about - you can create a mapping of inputs to outputs, and that mapping will always hold true.  It doesn't depend on external state or effects to produce a result!

Lets look at a function that might be written to determine the number of days since the UNIX epoch (January 1, 1970 00:00:00 UTC) to now (don't use this, and prefer a library if you are working with time, this is just an example 😉)

```javascript
const daysSinceUnixEpoch = () => {
  const currentDate = new Date();
  const epochDate = new Date('1/1/1970');

  return Math.floor((currentDate - epochDate) /  (24 * 60 * 60 * 1000));
}
```

This function will produce the value `18930`, and every time I run it it will produce that value.  Well, it will produce that every time I run that **today**.  Depending on when you read this, if you were to copy this function and invoke it, I have no idea what value it will produce!  This makes it difficult to reason about, because I need to know the external state, namely the current day, to try and figure out what value should be produced.  This function would also be incredibly difficult to test, and any test that might be written would be very brittle.  We can see that the issue is that we are making use of an impure value produced by `new Date()` to determine the current date.  We could refactor this to make a function that is pure and testable by doing the following:

```javascript
const daysSinceUnixEpoch = (dateString) => {
  const currentDate = new Date(dateString);
  const epochDate = new Date('1/1/1970');
  return Math.floor((currentDate - epochDate) /  (24 * 60 * 60 * 1000));
}
```

A simple swap to require a date string for computing the difference makes this a pure function since we will **always** get the same result for a given input, and we are not make use of any effectful code.  Now, if I were to call this with `daysSinceUnixEpoch('10/31/2021')` I get the same result, but now if you were to call it you should also get `18930`, neat!

## Side Effects Are Unavoidable
Now, while pure functions are awesome, we can't really build an app that does anything of note without side effects.  If the user can't see output, or interact with the app in any way, they probably won't have much reason to stick around!  Therefore, the idea of preferring pure functions isn't to get rid of side effect, but to reduce the surface area where effectful code is executed and extract pure functionality into reusable and testable functions. 

Let's look at another example of some code that might be written server side with the Express web framework.  A common thing that is done server side is ensuring that the data sent in a request contains all the expected values.  Imagine writing a handler for a POST request to an endpoint `/api/comment` that expected a request body with keys for `postId`, `userId`, `comment` to indicate who posted the comment, what post the comment was on, and what the comment was. Lets take a first stab at this:

```javascript
router.post('/api/comment', async (req, res) => {
  const {postId, userId, comment} = req.body

  try {
    if (postId !== null && userId !== null && comment != null) {
      const res = await Comment.create({postId, userId, comment})
      return res.send(res)
    } else {
      return res.status(400).json({message: 'Expected keys for postId, userId, and comment'})
    }
  } catch (e) {
    return res.status(500).json({error: e})
  }
})
```

This would work, we see that we pull the keys out of the request body, then we check that they all exists.  If they do we do something to create the comment, otherwise we send back a 400 with the message saying we expected certain keys.  If we want to test that our logic for rejecting the request based on the payload is correct we would need to do a lot of mocking and faking a request with different payloads.  Thats a huge pain!  What if we instead extracted the pure code from this effectful function?

```javascript
const expectedReqBody = (body, keys) => {
  return keys.every(key => key in body)
}

router.post('/api/comment', async (req, res) => {
  const expectedKeys = ['postId', 'userId', 'comment']

  if(!expectedReqBody(req.body, expectedKeys)) {
    return res.status(400).json({message: `Body of request needs to contain the following keys: ${expectedKeys}`})
  }

  const {postId, userId, comment} = req.body

  try {
    const res = await Comment.create({postId, userId, comment})
    return res.send(res)
  } catch (e) {
    return res.status(500).json({error: e})
  }
})
```

Now, we have extracted out the pure functionality of checking if values exist.  If we are given an array of expected keys and the request body we can ensure they all exist.  Now we can test the functionality by testing the pure function `expectedReqBody` and feel safe when we are using this function as part of validation.  As a bonus, if you wanted to validate the body on other requests you have an already tested solution!

## Extra Bonuses
I have previously written briefly about [function composition](https://www.catstache.io/blog/js-hof-composition) and this works really well with pure functions!  If you compose a handful of pure functions it is really easy to reason about what will happen throughout the 'data pipeline'.  If you have effectful code sprinkled in, it can cause a massive headache!

Pure functions can also be memoized!  If you have functionality that takes a lot of CPU power to compute, but is pure, you can cache the results!  I can write a bit about memoization but some libraries to use include ramda's [memoizeWith](https://ramdajs.com/docs/#memoizeWith) and lodash's [memoize](https://lodash.com/docs/4.17.15#memoize)

## Conclusion
Thanks for taking the time to read about pure functions! I will leave you with a tldr bullet point list on the topic:

* Pure functions always map the same input to output, and contain no side effects.  
* We can reason about and test pure functions easily, and pure functions are easier to reuse and compose with.
* Side effect add extra complexity, but they are unavoidable if we want to write meaningful apps.  
* Writing pure functions allows us to reduce the surface area of effectful code.



Have you ever wondered what a Higher Order Function (HOF) is, and how it might help you when writing code? Well look no further! 

In this post I will show some examples of where HOFs are used in daily JavaScript, how you can write your own, and as a bonus a small section on composing functions.

## What are Higher Order Functions (HOF)?
Simply put, a higher order function is a function that does either, or both of the following:
1. Take one or more functions as arguments.
2. Returns a function.

Here is a simple example of some code that you may write that makes use of a HOF:

```javascript
const nums = [1,2,3,4,5,6];

const isEven = number => {
  return number % 2 === 0;
};

// evens will be an array with elements [2,4,6]
const evens = nums.filter(isEven);
```

Here we make use of the [array filter method](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) which takes as an argument a function that takes a single argument (an element of the array) and returns `true` if the element should be kept, and `false` if the element should be discarded.

You might also find the above code written with an anonymous function instead, which would look something like this:

```javascript
const nums = [1,2,3,4,5,6];
const evens = nums.filter(n => n % 2 === 0);
```

While the above code demonstrates filter, you will find many examples of passing in functions as arguments to other methods for arrays such as map, reduce, every, etc.  This pattern will start to pop up all over the place in JavaScript code - you probably were already making use of this concept without knowing its name!  

## Extending our isEven function
One thing that is nice about HOFs is that they allow use to write some code to combine functions in new and interesting ways.  Imagine our code from above is growing and we need to also be able to get a list of odd numbers.  We could easily write an `isOdd` function that would be very similar to `isEven`, but we also know that in this case it would just be the **exact opposite** of isEven.  Unfortunately we can't just write `const evens = nums.filter(!isEven)`, even though that is basically what we want.  What we **can** do is create a new function called `not` that takes a function as an argument, and returns a new function that will invert the value of the passed in function:

```javascript
const nums = [1,2,3,4,5,6];

const isEven = n => {
  return n % 2 === 0;
};

const not = f => {
  return x => !f(x);
};

const isOdd = not(isEven);

// odds will be an array with elements [1,3,5]
const odds = nums.filter(isOdd);
```

Awesome! Our function `not` satisfies both requirements for being a HOF because it takes a function as an argument and it returns a new function as its result, which we bind to `isOdd`.  You can make use of HOFs to build more complex functionality by reusing logic of smaller functions, sweet!

## Cleaner Code With Function Composition
While function composition isn't strictly related to the topic of HOF, it is something you may want to use for writing clean functional code.  I would suggest you reach for a library such as `lodash/fp` or `ramdajs` to grab their compose function.  Here is the documentation for ramdajs's [compose](https://ramdajs.com/docs/#compose).

While writing `not` as a HOF, I did add some extra machinery by taking a function and returning a function to work in my example.  The simplest, standalone version of `not` would be written as `const not = v => !v;`.  That is, it just takes a boolean value and returns the inverse.  I can write the `not` function this way if I make use of `compose`.  Here is an example of doing just that:

```javascript
import R from 'ramda';

const nums = [1,2,3,4,5,6];

const isEven = n => n % 2 === 0;
const not = v => !v;
const isOdd = R.compose(not, isEven);

const odds = nums.filter(isOdd);
```

In my opinion, this is the cleanest version of the code so far, and the best part is `R.compose` takes as many functions as necessary!  This allows us to start writing functional code that is composable and easy to test and reason about!

## Conclusion
In the end, Higher Order Functions are prevalent in JavaScript - if you stumbled across this while trying to learn there is a chance you were already making use of this concept without knowing it!  If you end up leaning towards writing more functional JavaScript, HOFs will be a concept you make use of heavily, and when paired with composition the code will become easy to test, combine, and reason about!


When working with arrays of data, it can be a bit confusing when you should reach for `map` or `forEach`, so in this post I hope to help clear that up!  
> tldr: use `map` if you want to make transformations to the data, use `forEach` if you want to perform side effects.

Lets imagine we have an array of store items that we would like to work with:

```javascript
const storeItems = [
  { name: 'Sunglasses', price: 15.00, memberDiscount: true},
  { name: 'Flip flops', price: 50.00, memberDiscount: true},
  { name: 'Sunscreen', price: 5.99, memberDiscount: false}
];
```

## Mapping
Say we wanted to use this data, but we wanted to modify the items to have all their names uppercase:

```javascript
const uppercaseItems = storeItems.map(item => {
  return {...item, name: item.name.toUpperCase()};
});
/*
[
  { name: 'SUNGLASSES', price: 15.00, memberDiscount: true},
  { name: 'FLIP FLOPS', price: 50.00, memberDiscount: true},
  { name: 'SUNSCREEN', price: 5.99, memberDiscount: false}
]
*/
```
The above function will return a new array with modified names, and it WONT update the storeItems array so that will continue to hold the initial values. 

For another example, what if we wanted to modify the price based on if there is a member discount, and the person currently viewing the data is a member.  We could write the following function: 

```javascript

const applyMemberDiscounts = (items, isMember) => {
  return items.map(item => {
    if (!item.memberDiscount || !isMember) return item;

    const price = item.price - (item.price * 0.20);
    return {...item, price};
  });
};

const discounted = applyMemberDiscounts(storeItems, true);
/*
[
  { name: 'Sunglasses', price: 12.00, memberDiscount: true},
  { name: 'Flip flops', price: 40.00, memberDiscount: true},
  { name: 'Sunscreen', price: 5.99, memberDiscount: false}
]
*/
```

For a final example, I'll talk about how I use map when rendering React components.  If I had some component, `<StoreItem>` that took all the values and made them look pretty, I would display them by building all the components and storing them in a new array, then later in the JSX I can just pass the array as children.

```javascript
const comps = storeItems.map(item => <StoreItem {...item} />)

...

// In component return
return (
  <div>
    {comps}
  </div>
)
```

You can probably start to imagine how you would use this in your code now - basically if you want to **transform** your data, and keep a copy of the old data, use map!

## Using forEach
The cases where you would want to use forEach would fall under "side effect" scenarios.  I pretty much only use `forEach` where I don't care about the result of the function that is being applied to the array elements. If you have some logging function (or in the simplest example `console.log`), the result of applying that function to the value is generally uninteresting, so `forEach` works well:

```javascript
storeItems.forEach(item => console.log(`${item.name}: $${item.price}`));
```

Or, if you have some sort of action dispatching system where you dont care about the result of dispatching, you could take some array of actions and use `forEach` to dispatch them all.

```javascript
const actions = [firstAction, secondAction]
actions.forEach(action => dispatch(action));
```

If you find yourself writing code like

```javascript
storeItems.forEach(item => item.name = item.name.toUpperCase());
```

I would highly suggest you swap to using `map` instead.  While the above is code that will compile and work, it is transforming the original dataset, and that can cause bugs that are difficult to track down!

## Conclusion
Both `map` and `forEach` have their place when working with arrays of data.  If you are wanting to make transformation to the data, reach for `map`.  If you are looking to do effectful computations based on the data without modifying it, reach for `forEach`!

I hope this helped in identifying the right tool for the job at hand!


Moving into 2020, a lot of developers have been focusing on what ECMAScript 2020 (ES2020) has to offer!  This is a short tutorial on how to take advantage of the the Nullish Coalescing operator `??` which is specified in this GitHub Repository: [Nullish Coalescing for JavaScript](https://github.com/tc39/proposal-nullish-coalescing)

## Getting and Adding The Plugin

If you already have babel configured in your workflow, it is as easy as installing the proposal plugin for babel (if you don't, check out part 1 of this series!)

`npm i --save-dev @babel/plugin-proposal-nullish-coalescing-operator`

and then updating your `babel.rc` plugin with the plugin you just installed!

```javascript
{
  ...,
  "plugins": [..., "@babel/plugin-proposal-nullish-coalescing-operator"]
}
```

That is all that you should need to be able to use the new operator `??` and compile to compatible code for the browser!

> Babel will parse, transform , and then print the code back out as the final output.  By default, the transform  phase doesn't do anything!  This is where the plugins come into play - generally you can get away with just using `@babel/preset-env` to use the latest and greatest JavaScript.  **However*, when you want to use the true bleeding edge like Nullish Coalescing you will need to seek out a specific plugin to use, like in this tutorial.

## Simple `??` Example

The basics of nullish coalescing is allowing for sane defaults when a value is either `null` or `undefined`.  The old way people would check for existence and then going to a default was using the or operator: `let displayname = username || "User Profile";` where this would check for the existence of username and if not found default to the string `"User Profile"`.

The problem with this old way was that something like an empty string `""` is coerced into being falsey in this expression!  The `??` operator *only* utilize the default for `null` or `undefined`.  Here is a quick example - this code:

```javascript
const logUsername = username => {
    let displayname = username ?? "User Profile";
    console.log(displayname);
}

const oldLogUsername = username => {
    let displayname = username || "User Profile";
    console.log(displayname);
}

console.log("New logging of username: ");
logUsername(null);
logUsername("");
logUsername("bamartindev");

console.log("\nOld logging of username: ");
oldLogUsername(null);
oldLogUsername("");
oldLogUsername("bamartindev");
```

will compile to:

```javascript
"use strict";

const logUsername = username => {
  let displayname = username !== null && username !== void 0 ? username : "User Profile";
  console.log(displayname);
};

const oldLogUsername = username => {
  let displayname = username || "User Profile";
  console.log(displayname);
};

console.log("New logging of username: ");
logUsername(null);
logUsername("");
logUsername("bamartindev");
console.log("\nOld logging of username: ");
oldLogUsername(null);
oldLogUsername("");
oldLogUsername("bamartindev");
```

and the following will be output:
```
New logging of username:
User Profile

bamartindev

Old logging of username:
User Profile
User Profile
bamartindev
```

Notice that this is the replacement for `??`:

```javascript
let displayname = username !== null && username !== void 0 ? username : "User Profile";
```

So, in theory we could also write `logUsername(void 0);` and get our output of `"User Profile"`, but I am not sure when that might happen 😉

## The End

This concludes this small tutorial on adding a plugin to your babel configuration and and why you might need to do that in the future!

*If you see any issues with this post, please let me know so I can make edits and give you a shout out!* 





One thing that I commonly see new JavaScript developers struggle with, and that I found particularly annoying when jumping back in, was this concept of having to compile when developing with modern JavaScript, as well as all of the other tooling in the ecosystem.

In this series, I want to jump into the "why" around having a build for your front end code, and walk through setting up a brand new project from scratch.

## What Happened to the Good Ole Days?
If I were to tell you to open the developer tools in your browser of choice, you could easily start writing JavaScript and executing it.  In FireFox I can just hop into the console and type `const f = a => a * a;` and after executing that code I could type `f(5);` and expect to see an output of 25.

In fact, I can continue this path and open up my favorite text editor, create an HTML 5 document with a script tag, and put most JavaScript that I would want in there:

```html
<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>My Test Page</title>
</head>

<body>
    <section>
        Hello, <span id="name"></span>!
    </section>
    <script type="text/javascript">
        const name = prompt("Please enter your name");
        if (name !== null) {
            document.getElementById("name").innerHTML = name;
        }
    </script>
</body>

</html>
```

This is all fine, and you will see that I made sure to still use "newer" syntax such as `const` with no issues.  But lets say that I want to get a little fancier and use the [rest parameters syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters):

```html
<script type="text/javascript">
    function sum(...nums) {
        return nums.reduce((prev, curr) => prev + curr);
    }

    console.log(sum(1, 2, 3, 4, 5));
</script>

```

When I open this up in FireFox it appears to work as intended, but as a good front end developer I start testing in all of my browsers.  I notice that I have issues with IE, Edge, and Safari!  A quick consultation of [caniuse.com](https://caniuse.com/#search=rest%20operator) shows me that this syntax is not supported in those browsers 😞

So, what are my options?  I can choose to move away from this new syntax and find something that works in all browsers, I can drop support for these three browsers (good luck with that!), or I can look into setting up process that will either polyfill or build backwards compatible code for me!

This article is focusing on the last option, the build option.

## I Can Live Without Rest Syntax
That may be true, but what was illustrated above was just one instance of backwards compatibility issues - many more exist today, and this will be an issue moving forward as new versions of ECMAScript are defined.

ECMAScript is the specification that JavaScript conforms to.  The latest version as of this writing is [ECMAScript 2019](https://www.ecma-international.org/ecma-262/10.0/index.html) which was published in June of 2019.  The rest syntax was added in the ECMAScript 2018 version, so that can show you how browsers lag behind!

JavaScript will most likely always have this issue - new standards will be created and released well before all of browser vendors will be able to update their JavaScript engine.  In some cases, like Internet Explorer, new updates will be dropped all together as the browser is [sunset](https://en.wikipedia.org/wiki/Application_retirement).  Unfortunately, depending on who your target audience is, you may have to support these browsers long after they have been "retired".

Since we want to take advantage of the new specification of ECMAScript while also targeting as many platforms as reasonably possible we need to look at solutions to help us achieve that!

## Babel to The Rescue   
[Babel](https://babeljs.io/) is what I am used to using when wanting to have my cake and eat it to.  The tagline on the banner of the webpage is even "Use next generation JavaScript, today." which is exactly what we are looking to do.

One thing that I suggest is to navigate to the ["Try it Out"](https://babeljs.io/repl) link, which will take you to a REPL (Read-Evaluate-Print Loop) with babel enabled.  If you write any next generation JavaScript, it will compile it to backwards compatible JavaScript!

An example that scrolls by on the main page takes the following snippet

```javascript
[1,2,3].map(n => n **2);
```

and the result is as follows:
```javascript
"use strict";

[1, 2, 3].map(function (n) {
  return Math.pow(n, 2);
});
``` 

Awesome!  Take some time to play around with different functionality to see what compiled JavaScript is returned.

And just for completion, and because one can never have enough code snippets, here is the rest operator code we wrote earlier, and its compiled output.

Before:

```javascript
function sum(...nums) {
    return nums.reduce((prev, curr) => prev + curr);
}

console.log(sum(1, 2, 3, 4, 5));
```
After:
```javascript
"use strict";

function sum() {
  for (var _len = arguments.length, nums = Array(_len), _key = 0; _key < _len; _key++) {
    nums[_key] = arguments[_key];
  }

  return nums.reduce(function (prev, curr) {
    return prev + curr;
  });
}

console.log(sum(1, 2, 3, 4, 5));
```

I don't know about you, but I much prefer writing the first snippet 😉

## Basics of Using Babel
Back over on the Babel webpage, there is a section for [setup](https://babeljs.io/setup) so lets take a look at that!  The first thing you will notice is there are a TON of different options, and if you are new to the ecosystem it will be overwhelming.  So, lets take a different approach for this first step - we will get back to this phase in a later post specifically about asset bundling , specifically looking at [Webpack](https://webpack.js.org/).

For now, we will focus on the [usage guide](https://babeljs.io/docs/en/usage) in the documentation.  You will also need to [install Node.js and npm](https://nodejs.org/en/download/) on your preferred platform to follow along.

The first step will to be to create a new directory that we will call, `build-tooling` and we will change into that directory and instantiate a new node project.

```
mkdir build-tooling

cd build-tooling

npm init -y
```

That will create a package.json for your project with the default settings!  Next we will follow step 1 from the babel usage guide:

```
npm i --save-dev @babel/core @babel/cli @babel/preset-env

npm i @babel/polyfill
```

[`@babel/core`](https://babeljs.io/docs/en/babel-core) is what it sounds like, the meat and potatoes of the compiler!  This is what will take the code we write, and output the backwards compatible code we saw earlier.

[`@babel/cli`](https://babeljs.io/docs/en/babel-cli) is the command line interface (CLI) that allows us to run a command that will specify our input directory and output directory.

[`@babel/preset-env`](https://babeljs.io/docs/en/babel-preset-env) is a preset that makes our lives a lot easier by not needing to micromanage which transforms to apply, and which polyfills to provide.

Next we will follow along and create a new file, `babel.config.js` to setup some basic properties for our project:

```javascript
const presets = [
  [
    "@babel/env",
    {
      targets: {
        edge: "17",
        firefox: "60",
        chrome: "67",
        safari: "11.1",
      },
      useBuiltIns: "usage",
    },
  ],
];

module.exports = { presets };
```

Now we just need to write some code and compile it!  Lets write the most interesting code in the world, and place it in `src/interesting.js`!

```javascript
const sum = (...nums) => {
    return nums.reduce((prev, curr) => prev + curr);
};

const mergeState = (curr, next) => {
    const updated = { ...curr, ...next };
    return [next, updated];
};

export { sum, mergeState };
```

This is obviously a very useful section of code, so lets get it compiled so we can ship it ASAP! 🚀

We then go to our command line and type the following command to invoke the babel CLI:

```
./node_modules/.bin/babel src --out-dir dist
```

When you execute the command, you *should* see a successful compilation method with a file called `interesting.js` in a new directory called dist.  If we open up that file, we are hit with this!

```javascript
"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.mergeState = exports.sum = void 0;

require("core-js/modules/es6.symbol");

require("core-js/modules/web.dom.iterable");

function ownKeys(object, enumerableOnly) { var keys = Object.keys(object); if (Object.getOwnPropertySymbols) { var symbols = Object.getOwnPropertySymbols(object); if (enumerableOnly) symbols = symbols.filter(function (sym) { return Object.getOwnPropertyDescriptor(object, sym).enumerable; }); keys.push.apply(keys, symbols); } return keys; }

function _objectSpread(target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i] != null ? arguments[i] : {}; if (i % 2) { ownKeys(Object(source), true).forEach(function (key) { _defineProperty(target, key, source[key]); }); } else if (Object.getOwnPropertyDescriptors) { Object.defineProperties(target, Object.getOwnPropertyDescriptors(source)); } else { ownKeys(Object(source)).forEach(function (key) { Object.defineProperty(target, key, Object.getOwnPropertyDescriptor(source, key)); }); } } return target; }

function _defineProperty(obj, key, value) { if (key in obj) { Object.defineProperty(obj, key, { value: value, enumerable: true, configurable: true, writable: true }); } else { obj[key] = value; } return obj; }

const sum = function sum() {
  for (var _len = arguments.length, nums = new Array(_len), _key = 0; _key < _len; _key++) {
    nums[_key] = arguments[_key];
  }

  return nums.reduce((prev, curr) => prev + curr);
};

exports.sum = sum;

const mergeState = (curr, next) => {
  const updated = _objectSpread({}, curr, {}, next);

  return [next, updated];
};

exports.mergeState = mergeState;
```

Wow!  That is pretty neat, and we hardly had to do anything.  Lets add a script to our package.json so we don't have to remember the CLI syntax every time we want to compile.  Your "scripts" key can be modified to look like this:

```javascript
"scripts": {
    "build": "./node_modules/.bin/babel src --out-dir dist"
  },
```

now executing `npm run build` should take everything in the `src` directory and compile it and place it in `dist`.  

## Now What?
Well, technically you have all you need to write next generation JavaScript and compile it in a backwards compatible way.  If you keep creating new files and compiling, you will start noticing that this will just create a new compiled of the same name in the `dist` directory - that doesn't seem very manageable or scalable.  That is where something like Webpack comes into play!  Next time we will take a look into what its purpose is, how it can be configured, and we will also take a look at some of the other tools in its space such as Rollup and Parcel.

If you have any questions, need clarifications, or want me to go into more detail about this first tool and process let me know!  I want to try and make this a holistic introduction to JavaScript tooling!

Recent Posts

Projects