DEV Community: Daniel Lemay

Better Dependency Management Using Renovate

Daniel Lemay — Tue, 26 Nov 2019 14:29:43 +0000

Over the past few months I have been moving most of my projects to Renovate for managing dependencies. From my experience, Renovate offers several key benefits over other solutions such as Greenkeeper and Dependabot. This blog post will focus on what Renovate is and what differentiates it from other dependency management solutions. For a higher level overview on dependency management, I recommend checking out how to manage dependencies with confidence.

What is Renovate

Renovate is a GitHub, or GitLab, application that monitors dependency updates for a given repository and opens Pull Requests when new versions are available. While I have used them for JavaScript dependency management, Renovate also supports the following languages and package managers: Bazel, Docker, Golang, Java, Nuget, PHP, Python, and Ruby. For JavaScript applications, Renovate works for projects managed with npm or yarn.

Renovate uses a configuration file, renovate.json, that lives at the root of each repository to handle how Renovate manages the dependencies for that project. These files behave similar to an .eslintrc file, providing multiple presets and reasonable defaults for various use cases using the extends property. A benefit of this approach is that dependency management approaches can be replicated across projects by copying the configuration file. Renovate itself is un-opinionated, giving developers granular control. Below is the renovate.json from one of my projects.

{
  "extends": ["config:base"],
  "baseBranches": ["develop"],
  "bumpVersion": null,
  "packageRules": [
    {
      "depTypeList": ["devDependencies"],
      "updateTypes": ["minor"],
      "automerge": true
    }
  ],
  "prHourlyLimit": 5,
  "prConcurrentLimit": 10,
  "rangeStrategy": "bump"
}

Most of the configuration comes by extending the base config from Renovate. Out of the box, Renovate will PR against your default branch which is generally master. Setting the baseBranches key allows you to override this behavior and PR against different branches. This configuration also opts to update the package.json version in addition to the package-lock.

What makes Renovate different

A key differentiating factor that Renovate provides is the ability for fine-grained control of automerging dependencies based on rules set in the config. Other dependency management tools have required a binary decision to enable or disable across the board. In the configuration above, inside the packageRules array I have specified that all devDependencies which are minor or patch updates can be automerged if the CI pipeline succeeds. Automerging is disabled by default, but can be a useful tool for keeping lower risk dependencies updated with reduced friction. Renovate also allows matching or ignoring certain packages from automerge using regular expressions, if you require tighter control.

Another benefit of Renovate, is the grouping of monorepo updates in a single PR. Other solutions I have used will open a PR for each dependency. This causes problems with the proliferation of monorepos such as Babel and React. In most cases, these dependencies need to be updated at the same time or they can break the application. For example, I would not want to have my application using React 16.8.0 and React DOM 16.9.0. However, other tools can put your application in this state which can be a problem for Continuous Deployment scenarios. Renovate takes a different approach. When a monorepo publishes multiple package updates, Renovate opens a single PR for all of the updates. This means that all of your React updates or Babel updates live in one PR.

Keeping dependencies up to date can be a chore, especially in a fast moving ecosystem like JavaScript. Renovate reduces this friction by automating this process through fine-tuned configuration. I have moved most of my open source projects to Renovate, and found I simultaneously spend less time focusing on dependency updates and have more current dependencies. While I find the automerging of select dependencies beneficial, the grouping of updates for monorepo packages is a huge win in itself. If you dive into Renovate and have questions about your specific configuration, they also have a repository that you can open an issue against for additional support.

Personal Retrospective: Q3 2019

Daniel Lemay — Thu, 07 Nov 2019 15:11:13 +0000

Back in August, I completed my first quarterly personal retrospective as a means of being more intentional with life. I believe increased introspection allows for finer course corrections and recognizing the milestones of accomplishments along the way. For me, a setting intentions allows me to more proactively engage with life, rather than having it happen to me. For more details on the why, please check out the original blog post.

Q3 saw a lot of progress in the focus areas I had set, with some exceptions. In this retrospective I want to revisit the year end goals, what went well in Q3, and what I want to invest in for Q4.

What are my 2019 year end goals and progress?

In my Q2 retrospective I set 3 goals for the remainder of the year. Overall, I am satisfied with the direction and progress towards these goals.

Write more: I have been make substantial headway in this focus area. Q2 was the most prolific I had been in terms of writing blog posts, coming in at 10 posts published. This has been an energizing experience for me and also helped to solidify my learning path. Synthesizing topics I have learned or experienced increases my retention of them.
Continue building and engaging with community: I have been consistent in this area as well. Spending quality time with individuals has been great for fostering relationships, connecting at a deeper level, and having long term conversations. There have also been many great conversations at meetups talking with others working to break into the technology scene.
Read 4 books: This past quarter I read two books, one fiction and the other non-fiction. I am on track to complete this goal by year's end. It has been beneficial to prioritize reading fiction again. It spurs creativity through the appreciation of other art forms.

How did Q3 stack up compared to goals set?

Overall, I came close to meeting most of my goals for Q3. The main lacking area was increased physical activity.

Exercise more: 😞 This goal was the weakest for me. I made no progress in this area. I continued taking walking breaks at work, which was good, but did not fulfill the goal of being more active.
Play more games: 🎉 We have been playing more games as a family, and it has been wonderful. We enjoy each other's company doing something intentional together as a group. This has been noticeably better than defaulting to watching something together. We still watch movies together, but have a more balanced approach. I would love to see a continued emphasis in this area.
2 hours a week writing: 🤷🏼‍♂️ I am really happy with the amount of writing I did this past quarter, publishing 10 blog posts. September proved to be a dry spell in writing for me. I didn't hit the strict average I had originally set as a metric,but am pleased with the increased emphasis on writing.
2 Community 1:1s per month: 🔥 This was a great area to prioritize. I engaged with people at a deeper level, which lead to great conversations that weren't possible in a meetup structure. This has been a fantastic way to cultivate relationships for me personally. The amount feels right and achievable. This past quarter I had 5 community 1:1s.
Read 2 books: 📚 I completed this goal just in time. This past quarter I read Professor Frisby's Mostly Adequate Guide to Functional Programming and The Handmaid's Tale. This also accomplished my goal of being more balanced in my reading between fiction and non-fiction.

What do I want to start doing in Q4?

Exercise more: I need to be more active. My energy levels are not where I would like them to be. My biggest challenge is making time for the gym a priority. My goal is to spend at least 30 minutes a week engaged in more strenuous activity.
Experiment with a new language: I have so far focused my development knowledge within the JavaScript ecosystem. I have an increasing appreciation for typed languages and want to revisit using ReasonML on a personal project. An additional benefit is that ReasonML is a functional language, which should further reinforce lessons learned from my 30 Days of Functional Programming challenge. More to come on this in the near future.

What do I want to keep doing in Q4?

Keep writing: I am really pleased with the increased focus on writing. It has been great as a learning and communication tool. Last quarter I focused on the amount of time spent writing each week. I don't think this is a valuable metric for me and was too prescriptive. This quarter I want to maintain the velocity of 10 posts published within the quarter.
Keep reading: I want to continue my progress towards reading 4 books before year's end. I have started reading the next book on my list, The Subtle Art of not Giving a Fuck. Similar to last quarter I want to read one fiction and one non-fiction book.
Continue community 1:1s: There is so much value to being connected to community and investing in it. Even as a strongly introverted person, I need community to thrive. I want to continue developing more in depth relationships with people through an average of 2 community 1:1s each month. This was a really valuable experience for me the past quarter and worth continuing to prioritize.

Completing this structured reflection has been a substantial benefit to how I engage daily life with increased intention. I would love to hear what goals you are working towards, and what helps you move forward in your desired direction. You can connect with me on Twitter.

How to Configure Jest for Vue apps Using Vuetify

Daniel Lemay — Mon, 21 Oct 2019 16:16:41 +0000

I have recently been working on a Vue project which utilizes Vuetify for the base of some of it's components. Vue has the ability to register components globally, eliminating the need for importing base components. This works great in development, but I came across an error when testing the component with Vue Testing Library.

This error occurred because Jest had not been configured to recognize Vuetify's global components. In order to resolve this, some additional information was required in the Jest setup file.

// jest/setupFiles.ts
import '@testing-library/jest-dom/extend-expect';
import Vue from 'vue';
import Vuetify from 'vuetify';

Vue.use(Vuetify);

// Required for Vuetify
const app = document.createElement('div');
app.setAttribute('data-app', 'true');
document.body.appendChild(app);

First, we need to import both Vue and Vuetify in the setup file. By calling Vue.use(Vuetify), Jest becomes aware of the plugin and the globally available components it provides. This solved the console error, but introduced a new warning, that no <v-app> or div with a data-app attribute was found. Vuetify requires one of these at the root of the application in order to mount its components to the page. Creating a div with this attribute and appending it to the body resolves this warning.

Now we have a test environment in jsdom that mirrors the requirements for Vuetify and can proceed with integration testing. Currently I have been using Vue Testing Library for integration tests with good results. It uses Vue Test utils under the good, while hiding some methods that can encourage implementation testing practices.

8 New ESLint Rules - Jest

Daniel Lemay — Wed, 09 Oct 2019 16:59:10 +0000

Maintaining an ESLint config has several benefits, a significant one being seeing new rules as they become available. ESLint shapes the way we use JavaScript, and now TypeScript too. As I prepared for the latest release of my own ESLint config, I became aware of several new and helpful rules for testing with Jest. In this post, I'll dive into what some of these new rules are and some considerations for why they aren't added to the recommended options.

The interesting balance of ESLint semver

ESLint rules are an interesting interplay with semantic versioning or semver. Adding a new rule as an option is considered a feature and warrants bumping the package a minor version. However, enabling the rule as an error can cause new lint errors. This is considered a breaking change and requires bumping a major version. I imagine that this is one of the significant reasons that larger ESLint configs enable new rules on a less frequent basis. For example, almost a year passed between major versions of the AirBnB ESLint style guide. Reading through the ruleset before the latest major version uncovered many TODOS for rules to enable.

The recommended settings that an ESLint plugin provides, are also held to such constraints. While these rules are available now, they won't be available in the recommended configuration until the next major version. There is also the possibility that the library authors may choose to not enable them in the recommended config if the rule serves an edge case. If you discover a rule you think would be beneficial, please make sure to add it to your eslintrc specifically.

New Jest rules

The Jest ESLint plugin has recently come out with 8 new ESLint rules. Below is a quick explanation of each rule, and how I configured them in my ESLint config.

No commented out tests: The Jest plugin already had a rule for checking against disabled tests. However, that rule does not catch if the test has been commented out. This new rule captures this use case as long as the author does not create aliases for Jest globals, ie const testSkip = test.skip. Similar to disabled tests, I have this rule set to warn.
No duplicate hooks: This rule calls out having duplicate instances of a given hook (beforeEach, afterEach, beforeAll, afterAll) in a given describe block. Duplicating a given hook instance is likely developer error from missing an existing hook. I have this rule set to error.
No if: This rule watches for if statements or ternaries within a given test. The existence of this branching logic within a test can be indicative that a test is too complex and covering too much. It is best to break these into separate tests, and keep each test case clear. I have this rule set to error.
No try expect: Nesting tests inside of a try catch block and asserting on the error state can pose some problems where the catch block is silently skipped. This reduces testing confidence. A more robust means of handling this scenario is using the toThrow method within Jest. This asserts that an exception was thrown and that the error's contents match the expected output. This rule flags usage of expect within a try catch block. I have this rule set to error.
No standalone expect: expect assertions will only run if they are inside a test or it block. They will not run if they are placed inside a describe block but outside of the test/if blocks. Placing them in these locations is likely developer error and bound to cause confusion. I have this rule set to error.
No export: In my opinion, test files are designed to import the various pieces they need to run the code under test and make assertions. Following this mindset, it does not make sense for a test file to export anything. This rule tracks if anything is exported from a test file. I have this rule set to error.
No expect resolves: This rule is tailored for testing promise resolved values. It favors using expect(await promise) over await expect(promise).resolves. The rule is cited as increasing readability. I personally haven't experienced these testing patterns and currently have the rule set to off.
Require top level describe: This rule favors nesting all tests and hooks within a describe block. It will fail if any hooks or tests are written outside a describe block. Personally, I find a lot of value in grouping particular tests within a suite via describe. I estimate that I use it in 90% of my test suites. However, this rule seems overly prescriptive outside a given team or project's considerations. I have this rule set to off.

Dive into your plugins

ESLint configs, plugins, and recommended settings are a great place to get started with a base level of configuration. As noted above, the recommended setting may exclude many rules. It can be helpful to review rules which are not enabled by default to see if they may benefit a project. Taking these steps can increase the automated checks on a codebase and does not require reading the entire ESLint ruleset.

The Completion of 30 Days of Functional Programming

Daniel Lemay — Mon, 09 Sep 2019 15:14:47 +0000

This past week I completed my challenge of spending 30 days diving into functional programming. It was a valuable experience filled to the brim with new or fledgling concepts. Apart from my experience with 100 Days of Code, this was one of my first forays into the increasingly popular concept of #LearnInPublic as well. In this post, I break down some of the structures that were beneficial or not to my learning process, as well as a 50,000 foot overview of the concepts learned along the way.

Approach as a medium of learning

The process of committing to spend 30 minutes a day for 30 days on one given topic was a beneficial learning tactic. It provided enough structure to catalyze and focus my learning efforts, without being overly prescriptive. Investigating functional programming had long been an item on the to learn list, but had not yet been prioritized. I definitely will be following this model for other focused learning ventures in the future.

The concept of learning in public was also beneficial to this experiment. Several tweets on the day's progress were short overview posts. However, there were also many tweets covering concepts in greater detail. Reducing a concept down to a tweet or two requires revisiting content and synthesizing lessons learned. This is a valuable part of the learning process. Additionally, I found the process of writing a blog post on roughly the lessons learned in a given week helpful for my understanding. In addition to revisiting concepts, the blog post format allowed integration of multiple concepts to achieve a wider vantage point. Seeing and writing about how it all came together reinforced the importance of earlier concepts.

Learning in Public also enables community collaboration. By completing this exercise in public, multiple people were able to step in and clarify concepts that I had difficulty with, challenge me to break down topics into a tweet, and overall push and support my learning. Overall, I found this part of the process to be highly rewarding.

There were a few things that could have gone better or are good to know for next time. First, there were several break days where I did not complete any meaningful learning time for this goal. This was caused by factors such as family outings, a mini vacation, and some times mental exhaustion. I think that this is normal, expected, and acceptable. The purpose of the experiment was focused mental learning which was achieved. In the future, I am wondering if it may be beneficial to provide built in rest days, or continue with a mindset of grace. The other item of future focus is identifying practical application ahead of time or in the process. While I completed a few code experiments and mini quizzes on what I had learned, there was less writing code than I expected. Maybe this expectation is off base given the time spent, and I expect to spend more time applying these concepts in the future.

Concepts learned

During the past 30 days, I gained a working knowledge of the following concepts and more:

An intro to Functional Programming -#30DaysofFP Week 1
- Functional Composition
- Pointfree programming
- A better grasp of currying and partial application
What is a Side Effect Anyway? - #30DaysofFP Week 2
- Side effects and side causes
- Functional purity, including encapsulating side effects to the call site
Functors and Monads - #30DaysofFP Week 3
- What comprises a functor or a monad
- Benefit of the Maybe type
- Deferred application of promises using the Async type

What's next

Now that the 30 day challenge is over, I'm focusing on what's next on the horizon. I plan to review some existing codebases for opportunities to apply functional programming principles. Notably, I have several areas in mind that seem perfect use for currying. I also want to examine which concepts are most transferrable in team environments. In talking with other developers I anticipate concepts such as compose, functors, or monads may be a harder sell or provide less value in those contexts. However, I do want to continue to explore them further in personal projects.

I appreciated the 30 day challenge as a learning medium and anticipate doing something similar on a different topic in the future. Conversations with several developers as a which enhanced my learning experience. I fully support the Learning in Public process. More to come on that in the future.

Functors and Monads - #30DaysofFP Week 3

Daniel Lemay — Thu, 05 Sep 2019 15:49:38 +0000

Functors and monads may sound like some dark secret ingredient from the recesses of functional programming. For our purposes we will begin to approach them as data types that follow a base set of rules. In this post we will dive into working definitions for functors and monads as well as a working example tying them all together.

What is a functor

A functor is a type which contains a map function and adheres to several rules. At their core, they are containers which encapsulate a value. The map function reaches into the container, performs an operation on the inner value, and ultimately returns it back to the container. Arrays in JavaScript are actually functors. Surprise!

const double = x => x * 2

const arr = [7, 3, 12, 5]
const dblArr = arr.map(double) // [ 14, 6, 24, 10 ]

The array type has a map method which accepts a function to perform against the values inside of it. After the operation is completed, the new values are returned back to the container as a new array. This makes it a functor. We can also create our own Functors, keeping in mind these two rules. Here we will create a Container functor which holds a value. This code has been adapted from Dr Frisby's Mostly Adequate Guide to Functional Programming. If you are interested in learning more about functional programming overall, including functors and monads, I highly recommend reading this free book.

const add = x => y => x + y

class Container {
  static of(x) {
    return new Container(x)
  }

  constructor(x) {
    this.$value = x
  }

  map(fn) {
    return Container.of(fn(this.$value))  
  }
} 

console.log(Container.of(2).map(add(2)))
// Container { '$value': 4 }

Here we have a basic functor which holds a value in closure. Each time we run map we are given a new instance of the container with the current value. This functor is basic, but serves as the building block for more complex functors.

What is a Monad

A monad is a functor which adheres to some additional rules. All monads must contain an of method, similar to our container example above. This method instantiates the container with a value so that it can immediately be mapped against. A functor which implements the of method is known as a pointed functor.

In some situations, functors can become nested within each other. This requires additional calls to map to unwrap these layers before reaching the inner value. This is mitigated through a join method to flatten the extra layer. A basic implementation of the Maybe type can help illustrate this.

class Maybe {
  static of(x) {
    return new Maybe(x)
  }

  get isNothing() {
    return this.$value === null || this.$value === undefined
  }

  constructor(x) {
    this.$value = x
  }

  join() {
    return this.isNothing ? Maybe.of(null) : this.$value
  }

  map(fn) {
    return this.isNothing ? this : Maybe.of(fn(this.$value))
  }

  inspect() {
    return this.isNothing ? 'Nothing' : `Just(${this.$value})`
  }
}

const nestedMaybe = Maybe.of(Maybe.of(3))
// Maybe(Maybe(3))

nestedMaybe.join()
// Maybe(3)

The Maybe type is a monad which tracks two potential states of the container. Either the container can Just have a value, or it can be Nothing. The Nothing differs from usage of null or undefined in JavaScript. With those cases we need to guard against performing operations that are not valid, such as accessing a property from undefined. The upcoming optional chaining and null coalescing features currently in stage 3 hope to mitigate some of this. The Maybe type behaves differently. If it's current value is Nothing any subsequent map calls are bypassed. As long as the Maybe type stays in the Just case, it will continue to execute the map calls. When we are ready to pull the value out of the Maybe type, we can also provide a fallback value for the Nothing leg.

Maybe types are useful when the structure of the data is not known at runtime. An example of this is REST calls. Since there is no data contract in REST, a change in the backend structure can result in previously relied upon keys not being present. We expect them to be there in the success case, but they may not be.

Putting it all Together

Now that we know what a monad and functor is, why does it actually matter? Recently I have been experimenting with a functional wrapper around fetch calls with currying. This code example uses the crocks library, which provides many functional utilities including the Maybe type discussed above. You can find the running example of the code below on Code Sandbox.

import Async from 'crocks/Async'
import chain from 'crocks/pointfree/chain'
import compose from 'crocks/helpers/compose'
import curry from 'crocks/helpers/curry'
import getProp from 'crocks/Maybe/getProp'
import map from 'crocks/pointfree/map'
import maybeToArray from 'crocks/Maybe/maybeToArray'

const safeFetch = curry((baseUrl, endpoint, options) =>
  Async((reject, resolve) => {
    fetch(`${baseUrl}/${endpoint}`, options)
      .then(res => res.json())
      .then(resolve)
      .catch(reject)
  })
)

const printRepos = repos => {
  const list = document.getElementById('repo-list');
  repos.forEach(repo => {
    const li = document.createElement('li');
    li.innerHTML = repo;
    list.append(li);
  })
}

const fetchGithub = safeFetch('https://api.github.com');
const fetchDslemay = fetchGithub('users/dslemay/repos')({});

fetchDslemay.fork(
  console.log,
  compose(
    printRepos,
    chain(maybeToArray),
    map(getProp('name'))
  )
)

This example is using two different data types: Async and Maybe. The Maybe type is a Monad according to the rules discussed above. Async behaves similar to a promise, in that it receives a resolved and rejected arguments. However, they are reversed with rejected coming first. Using the Async type, we delay the execution of this function until later. To run it, we call the fork method and provide two functions, one to run on the rejected case, and the other to run on the success case.

In our success case we compose a series of functions to run against the data result. We first run getProp to pull off the name property of each object in the data array. This function returns a Maybe type. If the property is found, it is placed in the Just leg, otherwise the Maybe's value is Nothing. The chain function handles calling map and immediately calling join on the result. This is useful for actions which will nest types, and helps us avoid calling both methods individually. The maybeToArray utility from crocks provides a means of converting an array of Maybe types to a regular array. If the item in the array is a Just type it will be replaced with it's inner value. If the item in the array is a Nothing type, it will not be added to resultant array. Given an array of Nothing types, this function will return an empty array. Lastly, we pass the array of repository names to the printRepos function and display them in the DOM.

TLDR

Functors are a data type which contains a map method and follow several rules
A functor which contains an of method to immediately instantiate it is a pointed functor.
A monad has additional rules beyond a functor. They must be pointed functors, but also utilize a join method to flatten nested types

Functors and monads can provide additional utility and types when working with JavaScript. In the end they are containers which serve a specific purpose and follow a series of rules. There are many other methods that they may contain, but these core methods are the required basis for their classification.

What is a Side Effect Anyway? - #30DaysofFP Week 2

Daniel Lemay — Mon, 02 Sep 2019 15:59:52 +0000

Managing side effects is a core principle of functional programming. The existence of side effects can make a program more volatile, error prone, and harder to reason about. In this post, we'll dive into what side effects (and side causes) are, how to manage them, and functional purity.

What is a Side Effect

A side effect occurs when a function changes something outside of itself. This could be mutating a global variable, pushing data into an array, tracking application state, and more. An application must have side effects in order to run, or else there would be no feedback that it ran in the first place. Writing to the DOM, emitting a console.log, and making an API call are all side effects. As such they cannot be eliminated entirely. Functional programming seeks to minimize them as much as possible, controlling when and how they occur.

Side effects which alter application state make functions non-deterministic. In other words, calling a function with the same input multiple times in sequence does not result in the same output or effect. This problematic, as it increases the surface area for bugs and makes it harder to reason about what a function is doing. Take this example:

const results = []

const addToResults = x => results.push(x)

addToResults(2)
console.log(results); // [2]

addToResults(2)
console.log(results); // [2, 2]

Here our function addToResults is pushing directly onto our results array. This is outside of the function's scope and is a side effect. This function also has no direct return. While this may not seem problematic in this example, the complexity increases as the function grows, calls other functions, or lives in a different module. Debugging or understanding this programming approach requires the developer to trace through the function call stack, seeing what pieces of state were mutated. This is less than ideal, and additionally ties functions to specific implementation details.

The existence of side effects in this function make it impure. The purity of a function is determined by it's absence of side effects or side causes. Pure functions are desirable, because they ensure that we will always get the same output given the same input. This allows for greater reuse, composition, and certainty. Impure functions also impact the purity of other functions. If a function calls or relies on an impure function, it too is impure.

How Are Side Effects Managed

These side effects can be managed through directly outputting a new instance of the results array. This eliminates the side effect and makes the function calls deterministic. We can be confident that if we call the function with the same arguments we will receive the same results.

const addToResults = (arr, x) => arr.concat(x)

const results = []

console.log(addToResults(results, 2)) // [2]

const newResults = addToResults(results, 2)
console.log(newResults) // [2]

Now we directly pass in our current results array and concat the new value onto it. This returns a new array directly rather than mutating our variable outside the scope of the function. We have also replaced our method of push for concat to favor immutable data structures, but more on that a little later on. We can store the result of this operation onto a new variable, or call additional functions off the result, without needing to worry about those changes impacting dependents on a global state.

What about Side Causes

Side causes are another area of functional impurity. They exist when a function directly relies upon a value that it does not receive directly as an argument. The existence of side causes also make a function impure.

let y = 5

const add = x => x + y

console.log(add(2)) // 7

y = 10

console.log(add(2)) // 12

Here we have a variable which impacts the output value of our sum function, but is not an explicit output. The function is relying on this side cause to be in the application's state. However, even in this simple example, changing the value of the side cause impacts the output of our function. This makes our function impure. In order to resolve this issue, we need to make y an explicit input as an argument.

const add = (x, y) => x + y

console.log(add(2, 5)) // 7

console.log(add(2, 10)) // 12

Now our function is pure and does not rely on external state in the application. Pure functions are also easier to test. Since they are not dependent on the application's state, they can be exported and tested independently. This is another example of how pure functions result in more reusable code.

Favor value immutability

Functional programming also favors immutable values. When an argument is passed to a function, generally JavaScript passes on it's value. However, in the case of objects and arrays, the function receives a reference to the original object. This can result in some sticky situations if the values are mutated.

const recipe = {
  name: 'Risotto',
  ingredients: ['rice', 'stock'],
}

const recipe2 = recipe

const addIngredients = (recipe, ...ingredients) =>
  recipe.ingredients.push(...ingredients)

addIngredients(recipe2, 'onions', 'butter')
console.log(recipe) // { name: 'Risotto', ingredients: ['rice', 'stock', 'onions', 'butter'] }
console.log(recipe2) // { name: 'Risotto', ingredients: ['rice', 'stock', 'onions', 'butter'] }
console.log(recipe === recipe2) // true

In this example recipe2 references the original recipe object. They are not separate objects. Mutating one object impacts the other object, because they both point to the same reference. This is undesirable, and makes our code harder to reason about. If we need to use a previous copy of the object, this mutation makes it impossible. In order to combat this, we need to make a copy of our object before mutating it.

const recipe = {
  name: 'Risotto',
  ingredients: ['rice', 'stock'],
}

const addIngredients = (recipe, ...ingredients) => ({
  ...recipe,
  ingredients: recipe.ingredients.concat(ingredients)
})

const recipe2 = addIngredients(recipe, 'onions', 'butter')
console.log(recipe) // { name: 'Risotto', ingredients: ['rice', 'stock'] }
console.log(recipe2) // { name: 'Risotto', ingredients: ['rice', 'stock', 'onions', 'butter'] }
console.log(recipe === recipe2) // false

Now our addIngredients function makes a copy of the recipe object, before updating the ingredients array. Now that we have a copy of the object, we can update it without affecting the original object. It is important to note that the spread operator only copies one level deep. If your data structure has objects nested multiple layers deep, the lower levels will still be referencing the original data structure.

Many of the array methods mutate the existing array rather than return a new array. Helper utilities which copy the array before mutating them assist with maintaining value immutability. Array methods which mutate the array instance directly include:

pop
push
reverse
shift
sort
splice
unshift
Directly setting a value, such as arr[0] = 'foo'

TLDR

A side effect occurs when a function impacts the application state outside itself (ie outputting to the DOM, updating a global variable, etc)
A side cause occurs when a function references data outside its scope to complete it's operation. This causes the function to output different results if the outer data changes
Both side effects and side causes make a function impure. Any function which also calls an impure function becomes impure.
Pure functions do not have side effects or side causes. They are preferred for predictability, testing, and reasoning through an application.
Favor value immutability. Be aware that arrays and objects in function arguments are by reference not value. Make a new copy of the data structure to avoid mutating the reference.

Managing side effects and the purity of functions is an important part of functional programming. They allow for more robust and testable code. Next week we will be diving into functors and monads. You can join in the learning discussion on Twitter.

An intro to Functional Programming - #30DaysofFP Week 1

Daniel Lemay — Mon, 02 Sep 2019 15:57:59 +0000

1.5 weeks ago I set out to learn more about Functional Programming with a 30 day challenge. I started knowing little about functional programming, apart from the various array methods within JavaScript. Kyle Simpson's Functional Light JavaScript book, has been a great introduction of concepts and practical application. For those interested, the book can also be read for free on GitHub.

In this post, I share some of the practical concepts of functional programming I have learned since starting this challenge, as well as refactor a code example using functional composition. There's lots of code examples and functional goodies along the way. Note: The code snippets include several functional programming helper functions. An example implementation of these utilities is included in the snippets, but can also be found in libraries such as Ramda.

Partial Application

Partial application applies some of the arguments that a function needs to operate, and returns a function that is awaiting the remaining arguments. This allows pre-loading a more generic function to make it a more specific one.

const partial = (fn, ...presetArgs) =>
  (...laterArgs) =>
    fn(...presetArgs, ...laterArgs)

const add = (x, y) => x + y
console.log(add(5, 8)); //13

const add5 = partial(add, 5)
console.log(add5(8)); // 13

When we call partial, it gathers all of the arguments after the first one and stores them in the presetArgs parameter. This then returns a function which awaits any additional number of arguments. Once those arguments are received, the function is called, spreading presetArgs and laterArgs into the function call. Using this pattern we can create more specific implementations of a generic function. This could be used for other cases such as preloading a url for a fetch call, while awaiting query parameters or post data, and more. Some additional implementation examples are included in the sections below.

Currying

Currying is another means of partially applying functions, but is different in it's approach. Unlike the partial function described above, currying returns functions that only accept one argument at a time. This can provide additional control over making the functions more specific and reusable.

Before diving into the specific implementations of currying it is important to understand the concept of arity. Arity refers to the number of arguments a function can accept. For example, our add function above accepts two arguments and has an arity of 2. A function which accepts three argument has an arity of 3. There are some specific terms to describe an arity of 1 or 2.

A function which has an arity of 1 is unary.
A function which has an arity of 2 binary.
Functions with three or more arguments are referred to as arity of n, i.e. arity of 3

Currying takes a function of any given arity and breaks them into that many unary functions. For example:

const curry = (fn, arity = fn.length, nextCurried) =>
  (nextCurried = prevArgs =>
    nextArg => {
      const args = [...prevArgs, nextArg]
      if (args.length >= arity) {
        return fn(...args)
      }
      return nextCurried(args)
    })([])

const add = (x, y) => x + y
const curriedAdd = curry(add)

const add5 = curriedAdd(5)
console.log(add5(12)); // 17

console.log(curriedAdd(5)(12)); // 17

The curry utility only accepts the first argument it is provided before returning the new function. For instance, curriedAdd(5, 3)(12) would still evaluate to 17 as the 3 is discarded.

Functional Composition

Functional programming enables arranging functions to work together to complete a larger block of logic. This provides greater code reuse, and can preload the logic of more complex functions, waiting to receive their data.

These concepts already exist with some of the array methods in JavaScript. For example, let's say that I want to write a function which accepts an array of numbers, filters out any that are less than 5, and then returns the sum of the remaining numbers. Writing this function with array methods may look something like this:

const nums = [2, 5, 8, 12, 3]

const sum = nums
  .filter(num => num > 5)
  .reduce((acc, val) => acc + val)

console.log(sum); // 20

There is nothing wrong with this approach, and I know I have written many functions in a similar manner. However, the logic for the given filter and addition is locked into this particular implementation. Since filter and reduce both accept functions, we can refactor the logic out of this implementation to their own external functions:

const nums = [2, 5, 8, 12, 3]

const greaterThan5 = num => num > 5
const adder = (x, y) => x + y

const sum = nums.filter(greaterThan5).reduce(adder)
console.log(sum); // 20

This code snippet is logically the same as the previous implementation. The main difference is that we have pulled out the logic for the functions so that they can be reused in other parts of the codebase. It can also be argued that the callsite of calculating sum is clearer. The filter and reduce now focus on what is happening rather than how it is being achieved. This function is now more declarative rather than imperative. If you are unfamiliar with these concepts, I highly recommend reading Tyler McGinnis' breakdown of the them.

This approach still maintains the chaining of the filter and reduce onto an array. Using our partial utility from earlier, we can abstract some of this chaining further to pre-load a filter function that is awaiting an array of data.

const nums = [2, 5, 8, 12, 3]

const partial = (fn, ...presetArgs) =>
  (...laterArgs) =>
    fn(...presetArgs, ...laterArgs)
const filter = (fn, arr) => arr.filter(fn)
const reduce = (fn, arr) => arr.reduce(fn)

const greaterThan5 = num => num > 5
const adder = (x, y) => x + y
const filterGreaterThan5 = partial(filter, greaterThan5)
const reduceAdder = partial(reduce, adder)

const sum = reduceAdder(filterGreaterThan5(nums))
console.log(sum); // 20

We are continuing to move farther into the functional programming and composition approach. Here we have created utility helpers for filter and reduce. Both accept a function as the first argument, and the array to operate on as the second argument. Using our partial function defined earlier, we can preload these functions with our filter and adder from previous implementations. Here filterGreaterThan5 is a function which is waiting for an array and then will filter that array with our greaterThan5 function. Similarly, reduceAdder is a function awaiting an array and then will reduce the array with our adder function.

In this example the functions called to calculate sum may seem strange. I know it was for me at first. Unlike English, nested functions like this are read inside out. In other words this can be read as follows:

filterGreaterThan5 is given a nums argument and executes.
The output of filterGreaterThan5 (another array) is passed in as the input to reduceAdder
reduceAdder runs on this input. The output of this function is assign the to the const sum.

This approach uses more functions, but each one is smaller in scope. As we build up our application we create functions more specific to our use case. A major benefit of this approach is that each of the functions can now be used elsewhere in the application without rewriting the logic. One last obstacle and point of refactoring for our example is cleaning up the nested function calls. This particular example only has the calls nested 2 layers deep, but you can imagine that this could become tedious to do consistently. Thankfully there is a compose function utility that can help us out.

Compose is a function which will accept other functions as it's arguments, And programmatically wrap them inside each other. The end result is a function waiting for the data. This allows us to not manually wrap our functions as in the above example.

const nums = [2, 5, 8, 12, 3]

// Utility functions
const partial = (fn, ...presetArgs) =>
  (...laterArgs) =>
    fn(...presetArgs, ...laterArgs)
const compose = (...fns) =>
  result =>
    [...fns].reverse().reduce((result, fn) =>
      fn(result),
    result)
const filter = (fn, arr) => arr.filter(fn)
const reduce = (fn, arr) => arr.reduce(fn)

const greaterThan5 = num => num > 5
const adder = (x, y) => x + y
const filterGreaterThan5 = partial(filter, greaterThan5)
const reduceAdder = partial(reduce, adder)

const addNumsGreaterThan5 = compose(reduceAdder, filterGreaterThan5)
const sum = addNumsGreaterThan5(nums)
console.log(sum); // 20

Our addNumsGreaterThan5 function now is waiting for an array of numbers. Upon receiving it, the filter and reduce functions will be ran, returning the sum. We can now call this function with any array of numbers within our application. Additionally, this compose structure allows us to swap out on functional LEGO brick for another to change the implementation. For example, we could switch our filter function to one that filters for numbers less than 5 rather than greater than 5.

Next Steps

Functional programming aims to make code readable and easier to reason about. If functions have direct inputs and outputs, the developer does not need to trace through the functional call stack to see what pieces of the application state are managed. It becomes easier to mentally parse the effects of running the function. Much of this is governed by the purity of the functions and managing side causes and effects, which will be a discussion for next week. Composing smaller functions makes our code more declarative, focusing on what is happening rather than the implementation details.

Week 1 of my 30 Days of Functional Programming was a wild ride of learning new materials. You can join in the learning discussion on Twitter.

30 Days of Functional Programming

Daniel Lemay — Mon, 02 Sep 2019 15:57:35 +0000

I have long had a fascination with learning new things. However, it is generally unstructured and follows whatever the interest of the moment is. I have been and continue to be a proponent of motivation based learning, believing that we learn best when there is an internal vested interest. At least for me, one downside of this approach is a propensity for cursory knowledge on many topics without revisiting them in more depth. This large surface area of topics has resulted in consistently saying, “One day I will get back to exploring topic X in depth”. Anecdotal experience has indicates lower follow through.

A Proposed Solution

In a desire to explore topics in greater depth, I am engaging on a sort of gamified learning experiment. Over the next 30 days I am committing to spend at least 30 minutes each day on focused study on a topic of interest. From my experience completing the 100 Days of Code challenge, I found the consistent application on a focused goal a rewarding pursuit. It provides a sense of direction and loose boundaries around the learning process. With so many exciting things to learn and explore, it can be easy to shift from one to another as I have been known to do.

My vision for this experience is a means to have time-boxed focused study of a given topic. They may not occur every month, and a given topic may warrant more than one round of 30 days. I elected a shorter calendar duration than the 100 days of code challenge given the more specific nature of the topics.

So why functional programming? I’ve been looking for various areas to branch out of my normally realm of focus and further diversify my programming knowledge. I have come to appreciate the functional paradigms of the array methods in JavaScript and want to further my understanding of functional programming concepts. I have a couple of resources that I have been meaning to work through on the topic, and plan to finally make them a priority. In the same vein as 100 Days of Code, I will be sharing progress and lessons learned along the way with the hashtag #30DaysofFP on Twitter.