DEV Community: Jonas Winzen

Transducers - a Generalized Concept for Data Transformations

Jonas Winzen — Mon, 27 May 2019 08:44:42 +0000

When developing software, we sometimes can't get around of handling data in some way.
No matter, if you work on the frontend (where the UI you are building is basically a function of the data) - or on the backend (backends tend to be rather data heavy).

Typical tasks when processing data include (but are not limited to):

Filtering out datasets (like a facebook search should only give me matches with my search term or redacting information of privacy reasons - like bank numbers, email addresses or even passwords)
Mapping binary data into a human readable format or vice versa

...well, okay. Facebook might not be the best example for demonstrating applied data privacy...

TL;DR You can skip the theory, if you're not interested or already know the basics.

Theory of Data and Transformations

Data

Before working on data, we need to have an idea of how the data looks like. In general the structure can be defined as a collection of items like:

Rows in a database table - where the table is the collection and rows are the items
Elements in a set - with elements as items, the set as the collection
Fields in an array
Elements in a list
Entries in a dictionary
Nodes in a tree

Any collection could be embedded as an item into another collection. Let's formalize this statement:

-- an Item is defined as either:
-- 1. a Primitive value
-- 2. a Collection of Items
data Item = Primitive | Collection Item

Note: I also tried to find a representation for this in Typescript notation. But Typescripts type system doesn't seem to be powerful enough to describe recursive types

Transformable Data

Since our definition of data consists of just two kinds of types (Item and Collection), we can only have transformations on the collection level or on the item level. Where filtering (deciding for each element whether or not to include it in the result) is a transformation on the collection level.
A collection that can be filtered is called Filterable.

Mapping is the process of taking each item from its container (the collection), applying a transform to the item, and putting it back into a container of the same kind of collection where it came from. Mapping is a transformation on the item level.
A collection (or container), where you can map over its contents is called Functor.

In Practice

The Common Approach

Javascript comes with native array methods for mapping and filtering array data. Most notable:

Array.prototype.map(mapFn)
Array.prototype.filter(predicateFn)
Array.prototype.reduce(reducerFn [, init])

Now let's make up a simple example, to see how each of them works.
We have a collection of bibliographical data. Each item represents a Book or publication, that has a unique id, a title, was written by one or more authors and has a publication date (in form of a unix timestamp) in ms since epoch.

type BookOrArticle = {
  id: string,
  title: string,
  authors: Array<string>,
  publicationDate: number,
};

We have an array of (let's say) 10,000 books and and articles and we need to get all items that contain the word "guide" in the title, written by J. Doe and published in 2007. The result items should be in the form:

type Result = {
  title: string,
  author: string,
  date: string
};

1. Naive Approach

Lets take a first approach:

const booksAndArticlesArray = [
  /* our array of books and articles */
];

function getResults(inputArray) {
  return inputArray
    .map(item => ({
      ...item,
      year: new Date(item.publicationDate).getFullYear()
    }))
    .filter(({ year }) => year === 2007)
    .filter(({ title }) => /guide/i.test(title))
    .map(({ title, authors, publicationDate }) => ({
      title,
      author: authors.join(", "),
      date: new Date(publicationDate).toDateString()
    }))
    .filter(({author}) => author.includes("J. Doe"))
}

It might not be immediately visible, but each step of filtering or mapping creates an intermediate array containing the result, that is used as an input for the next filter/map step.

2. Optimized Approach

To reduce the number of intermediate data structures created, one could try and reduce the number of transformation steps by collapsing consecutive map and filter operations:


// collapse consecutive filter operations

function getResults(inputArray) {
  return inputArray
    .map(item => ({
      ...item,
      year: new Date(item.publicationDate).getFullYear()
    }))
    .filter(
      ({ year, title }) => year === 2007 && /guide/i.test(title)
    )
    .map(({ title, authors, publicationDate }) => ({
      title,
      author: authors.join(", "),
      date: new Date(publicationDate).toDateString()
    }))
    .filter(({ author }) => author.includes("J. Doe"));
}

We could further optimize this by moving the mapping from the authors array field in the second map operation into the first map operation. This would allow us to collapse the the final filter operation with the other filter:


// 1. move mapping authors array to author string into first map operation
// 2. collapse final filter operation with previous filter operation

function getResults(inputArray) {
  return inputArray
    .map(({ publicationDate, authors, ...item }) => ({
      ...item,
      author: authors.join(", "),
      year: new Date(publicationDate).getFullYear()
    }))
    .filter(
      ({ year, title, author }) =>
        year === 2007 &&
        /guide/i.test(title) &&
        author.includes("J. Doe")
    )
    .map(({ title, author, publicationDate }) => ({
      title,
      author,
      date: new Date(publicationDate).toDateString()
    }));
}

We reduced the number of intermediate data structures created from 5 to 3, but at the cost of readability. Further reduction is possible by moving the author and year transforms from the first map operation into the filter step and remove the first map operation (this comes at the cost of reducing readability, too).

Mapping and Filtering via Reduce

What if we could express filter and map in a way, that allows us to directly compose them.

Reminder: Compose or function composition means, that you call one function with the result of another function.
I.E: Given the functions f: X -> Y and g: Y -> Z, we call g.f(x) := g(f(x)) the composition of f with g with g.f: X -> Z (that means f.g(x) takes values of X as argument and returns values of Z as result).
Example: Composing f(x) => x + 1 and g(x) => x * x to g(f(x)) = h(x) results in h(x) => (x + 1) * (x + 1). We get this result by substituting x in g(x) with the function body of f(x).

So it looks like function composition is the right tool to express all our map and filter transformation steps at once. As reduce is one of the most versatile operations on arrays (or any other iterable structure), let's try to express map and filter as reducers.

Reminder: Reducers are functions, that can be used as a callback in Array.prototype.reduce(). The first argument of a reducer is the accumulator (the return value of the last reducer call). The second argument is the element we are looking at (just like the first argument in filter and map). Thus a reducer has the following signature: reducer(acc: A, elem: B) => A, or in Hindley-Milner notation: reducer :: A -> B -> A (The HM notation assumes that every function is curried. So a function that should take two arguments is expressed a function (A -> B -> C):

that takes one argument (A) -> returns a function (B -> C)

that takes one argument (B) -> returns the result (C)

Let's try to rebuild map and filter as a reducer. For map we need a function that takes a mapping function as argument and returns a reducer function as result. For filter we need a function, that takes a filter predicate and also returns a reducer function as result:

const map = mapFn => (acc, elem) => acc.concat(mapFn(elem));

const filter = predicateFn => (acc, elem) => {
  if (predicateFn(elem)) {
    /*
     * append the element
     * if predicate evaluates to a truthy result
     */
    return acc.concat(elem);
  }
  /*
   * don't append anything otherwise
   */
  return acc;
};

If you are now wondering 'How would one compose this?', you are wondering right. Composing two functions requires that the argument type of the outer function, matches the return type of the inner function. In the above functions, neither the result of map(mapFn) would fit into map nor into filter or vice versa. There is simply no way to do so.

What we would need, is that map(mapFn) (or filter(predicateFn)) returns a function that expects a function of its own type (I know it becomes very convoluted here, but sty with me: the resolution is simple).

We resolve this problem, by further generalising map and filter. The above implementations are just suited to work with arrays as output. But one could imagine having any type of data structure as output, that allows adding elements (like trees, heaps, maps, sets, linked lists, etc.). So let's get rid of acc.concat(x) calls in the above code and replace it with combine(acc, x), where combine is provided via an argument of the initially returned function:

const map = mapFn => combine => (acc, elem) => combine(acc, mapFn(elem));

const filter = predicateFn => combine => (acc, elem) => {
  if (predicateFn(elem)) {
    /*
     * add the element to the result data structure
     * if predicate evaluates to a truthy result
     */
    return combine(acc, elem);
  }
  /*
   * don't add anything otherwise
   */
  return acc;
};

Now take a close look, how combine is being used:

First argument: the accumulator (i.e. the result data structure)
Second argument: the element that should be added to the result data structure
Return value: the result data structure, containing the element

This not only looks like a reducer, it is a reducer!

xform (1)

Let's start using our new map and filter and build our example transform from above:

const booksAndArticlesArray = [
  /* our array of books and articles */
];

const xform = (acc, elem) =>
  map(item => ({
    ...item,
    year: new Date(item.publicationDate).getFullYear()
  }))(
    filter(({ year }) => year === 2007)(
      filter(({ title }) => /guide/i.test(title))(
        map(({ title, authors, publicationDate }) => ({
          title,
          author: authors.join(", "),
          date: new Date(publicationDate).toDateString()
        }))(
          filter(({ author }) => author.includes("J. Doe"))(
            (acc, elem) => acc.push(elem)
          )
        )
      )
    )
  )(acc, elem);

const result = booksAndArticlesArray.reduce(xform, []);

... I don't know about you, but I find this horrible 🤮. I would't approve any PR, that contains a thing like this.
To simplify readability, we introduce a general notion of compose, that composes n functions:

const compose = (...functs) => (...args) =>
  functs.length > 1
    ? compose(...functs.slice(0, -1))(
        functs[functs.length - 1](...args)
      )
    : functs[0](...args);

Note: The above implementation of compose is tail-recursive. So you could rewrite the recursion into a loop. Feel free to take this as an exercise. I'm happy to review your solution in the comments 🤓.

We now have a proper implementation for compose. Let's refactor our xform from above and bring it into a readable form:

xform(2)


const xform = compose(
  map(item => ({
    ...item,
    year: new Date(item.publicationDate).getFullYear()
  })),
  filter(({ year }) => year === 2007),
  filter(({ title }) => /guide/i.test(title)),
  map(({ title, authors, publicationDate }) => ({
    title,
    author: authors.join(", "),
    date: new Date(publicationDate).toDateString()
  })),
  filter(({ author }) => author.includes("J. Doe"))
);

As we have now a clean xform, we could define the function, that will use it, to apply our transforms. We call the "framework" for running xforms against data xduce. xduce takes four arguments:

the xform
a combiner (combine)
an initializer (getInitial)
the input data (inputArr)

/*
 * xduce draft
 */
const xduce = (xform, combine, getInitial, inputArr) =>
  inputArr.reduce(xform(combine), getInitial());

As we might want reuse the transform, we curry the last argument and default combine and getInitial arguments (for our convenience 😇):

/*
 * xduce (reworked - curried-data-last)
 */
const xduce = (
  xform,
  combine = (acc, elem) => (acc.push(elem), acc), 
  getInitial = () => []
) => inputArr => inputArr.reduce(xform(combine), getInitial());

Note: The above code uses Array.prototype.push as the combiner. Since push is a mutating operation, we have to make sure, to create a new initial collection with every call to xduce. Otherwise subsequent calls would add up results to the same array. This is usually not what we want and produces unexpected results. Alternatively you could use (acc, elem) => acc.concat(elem) as combiner. Array.prototype.concat does not mutate its source, but will be considerably slower (especially with large arrays).

Besides the provided default, you could use any data structure you like for your results. Just make sure, that the combiner and your initial collection fit together (e.g. for ES Set use (acc, elem) => acc.add(elem) as combiner and () => new Set() as your getInitial arguments).

Next step is to use our xform with xduce:

/*
 * reminder: xduce(xform) returns a reusable transform
 * that just expects input data
 */
const bookFilterMapTransform = xduce(xform);


/*
 * using bookFilterMapTransform
 */
const result = bookFilterMapTransform(booksAndArticlesArray);

The Concept

The concept explained here is also known as transducers. As transducers is such a complicated sounding word, I chose a more descriptive name for the article.
The first transducers implementation was provided in Clojure. The concept gained popularity and was ported to other languages like Javascript, Python, ReasonML/OCaml, Elixir and many more.

There are some notable library implementations of transducers available:

If you want to know more about transducers, you'll find a reading list at the end of the article.

Benchmarks

The real power of transducers will show up when using them with really large sets of data.
I made some benchmarking, to give you an idea of the performance advantage of the transducers approach. The xduce, map, filter and compose implementations, are exactly the ones I provided in this article.

Following transformations were used for the benchmark:

Transducer

const benchmarkTransducer = xduce(
  compose(
    map(function(x) {
      return x + 10;
    }),
    map(function(x) {
      return x * 2;
    }),
    filter(function(x) {
      return x % 5 === 0;
    }),
    filter(function(x) {
      return x % 2 === 0;
    })
  )
);

Native/Classic Transform

const classicTransform = arr =>
  arr
    .map(function(x) {
      return x + 10;
    })
    .map(function(x) {
      return x * 2;
    })
    .filter(function(x) {
      return x % 5 === 0;
    })
    .filter(function(x) {
      return x % 2 === 0;
    });

For time values of each array length, I took the average time from running each implementation 16 times (both on the exact same array). I created 64 equidistant steps. The smallest array had a length of 10417, the largest had a length of 489583 items.

Both implementations behave very similar in their runtime characteristics below an array size of 60k values (with transducers being only minimally faster than the classical transformation chain). Between 60k and 70k we see an almost immediate increase in the running time of the classical approach. I don't know the exact reasons for this jump (if someone has an idea, please let me know in a comment 🙃).
Here is a more detailed image of this region:

Transducers also perform great in comparison with other libraries (e.g. Immutable.js):

Lenses: The What and How

Jonas Winzen — Wed, 12 Dec 2018 23:39:32 +0000

In this post, I want to show you what lenses in functional programming are, how you could use them, and most importantly: how you could write your own lenses implementation.

TL;DR
Lenses are directly composable accessors. Read on, to learn how they work, and how you could write your own.

I created a little Notebook on Runkit for you, that contains all examples and a second, alternative implementation. So you could play around with that at any time (before-, while- or after- reading this article). See here: https://runkit.com/mister-what/lenses

Intro

Let's start with a description of a problem. Imagine you have the following data structure, that lists employees by their location and position.

const locations = {
  berlin: {
    employees: {
      staff: {
        list: [
          {
            name: "Wiley Moen",
            phone: "688-031-5608",
            id: "cdfa-f2ae"
          },
          {
            name: "Sydni Keebler",
            phone: "129-526-0289",
            id: "e0ec-e480"
          }
        ]
      },
      managers: {
        list: [
          {
            name: "Cecilia Wisoky",
            phone: "148-188-6725",
            id: "9ebf-5a73"
          }
        ]
      },
      students: {
        list: [
          {
            name: "Kirsten Denesik",
            phone: "938-634-9476",
            id: "c816-2234"
          }
        ]
      }
    }
  },
  paris: {
    employees: {
      staff: {
        list: [
          {
            name: "Lucius Herman",
            phone: "264-660-0107",
            id: "c2fc-55da"
          }
        ]
      },
      managers: {
        list: [
          {
            name: "Miss Rickie Smith",
            phone: "734-742-5829",
            id: "2095-69a7"
          }
        ]
      }
    }
  }
};

Accessing data in this structure from different places all over your application gives you a lot of repetition and might lead to hard to find bugs, when the data structure changed (for whatever reason).
So let's explore an alternative approach for this problem: Lenses

Lenses

Lenses are used for accessing and manipulating data in a safe and immutable way. Well the same is true for accessors (getter & setters) on objects, its not fancy and nothing special. What makes lenses really powerful (and really coool) is that they are directly composable. So what does that mean? If you ever had some maths class in your life, you know, that functions can be composed with each other, i.e. you have then you can define the composition of f with g as and means nothing else than .

So how would we express a composition in Javascript? Simply like that:

function compose(g, f) {
    return function(x) {
        return g(f(x));
    }
}

// or with fat-arrow functions:
const compose = (g, f) => x => g(f(x));

We could define higher orders of composition in three (or more ways):

// recursive version
const compose = (...fns) => x =>
  fns.length
    ? compose(...fns.slice(0, -1))(
        fns[fns.length - 1](x)
      )
    : x;

// iterative version
const composeItr = (...fns) => x => {
  const functions = Array.from(
    fns
  ).reverse();
  /* `reverse` mutates the array,
    so we make a shallow copy of the functions array */
  let result = x;
  for (const f of functions) {
    result = f(result);
  }
  return result;
};

// with Array.prototype.reduce
const composeReduce = (...fns) => x =>
  fns.reduceRight(
    (result, f) => f(result),
    x
  );

// use it!
console.log(
  compose(
    x => `Hello ${x}`,
    x => `${x}!`
  )("World")
); // -> "Hello World!"

We know now how to compose functions. One thing you may have noticed already, is that function composition works best, when the argument and return value of the composed functions are of the same type.

Let's define a composed getter for the students of a location:

const studentsAtLocation = compose(
    (students = {}) => students.list || [],
    (employees = {}) => employees.students,
    (location = {}) => location.employees
  );

const locationWithName = locationName => (
  locations = {}
) => locations[locationName];

const getBerlinStudents = compose(
  studentsAtLocation,
  locationWithName("berlin")
);

const getParisStudents = compose(
  studentsAtLocation,
  locationWithName("paris")
);

console.log(
  getBerlinStudents(locations)
); // [ { name: 'Kirsten Denesik', ... ]

console.log(
  getParisStudents(locations)
); // []

If you are still with me, you might have noticed, that the getter functions are somehow provided in a reverse order. We will resolve this, by using functions that take a getter as argument and return a getter. This pattern (passing a function and returning a function) will allow us to compose basically from getter/setter pairs, by passing a function that takes a value and returns us a getter/setter pair. Let's take a look, how this could look like:

const createComposableGetterSetter = (
  getter, // (1)
  // -- getter(targetData: TargetData): Value
  setter // (4)
  // -- setter(value: Value, targetData: TargetData) => TargetData
) => toGetterAndSetter => targetData => { // (2)
  const getterSetter = toGetterAndSetter(
    getter(targetData)
  ); // (3)
  /**
   * toGetterAndSetter is called with
   * "data" as argument
   * and returns a GetterSetter object:
   * @typedef {
   *  {
   *    get: function(): *,
   *    set: function(newData: *): GetterSetter
   *  }
   * } GetterSetter
   *
   */
  return getterSetter.set(
    setter(
      getterSetter.get(),
      targetData
    )
  ); // (5)
};

Even if this is "just" a two-line function body, it takes some time to understand what's going on here, so I'll explain step by step:

After calling createComposableGetterSetter with a getter and a setter function as arguments, we get back the actutal composableGetterSetter.
Our composableGetterSetter will get a toGetterAndSetter function, that takes some data as input and returns an object with a get and a set method. We return a function, that expects the target data as its only argument.
We construct a GetterSetter object by calling (1) with the target data from (2) and passing the return value to the toGetterAndSetter function.
We use the GetterSetter objects set() method with the return value of calling the setter (4) with the value of the constructed GetterSetter object (we call getterSetter.get() to simply retrieve this value) and the targetData (we expect, that the setter will return a new version of targetData with its focused value set to the return value from getterSetter.get()).
We return the value (which is again a GetterSetter object) that is returned from getterSetter.set(...) in (5).

toGetterAndSetter

We have now defined our createComposableGetterSetter function. We still need to define our toGetterAndSetter function, that we will use, to either just get data from the target or set data on the target. Let's define our toSetAccessors first:

const toSetAccessors = data => ({
  get: () => data,
  set: newData => toSetAccessors(newData)
});

So simple function constructs an object for us, that is used, whenever we want to set data on the target object. Whenever its set method is called with new data, it will create a new instance of itself that holds the new data and returns this instance.

Next the toGetAccessors function:

const toGetAccessors = data => ({
  get: () => data,
  set() {
    return this;
  }
});

A GetAccessor object should only allow to retrieve its data. When trying to set new data, it will simply return its own instance. This makes it impossible to change after creating it.

Using ComposableGetterSetters (Lenses)

We are now going to create three ComposableGetterSetters -- aka lenses -- to see how they work and what is needed to use them for retrieving values or changing the data (in an immutable way).

Creating lenses

We are going to create one lens that focuses on the property "paris", one lens that has focus on the property "employees" and a third one that has focus on the property "students".
We will use default values in getters (to avoid exceptions) and object spread to maintain immutability in setters.

const parisLens = createComposableGetterSetter(
  obj => (obj || {}).paris,
  (value, obj) => ({
    ...obj,
    paris: value
  })
);

const employeesLens = createComposableGetterSetter(
  obj => (obj || {}).employees,
  (value, obj) => ({
    ...obj,
    employees: value
  })
);

const studentsLens = createComposableGetterSetter(
  obj => (obj || {}).students,
  (value, obj) => ({
    ...obj,
    students: value
  })
);

We notice some repetition here, so let's refactor that:

const lensProp = propName =>
  createComposableGetterSetter(
    obj => (obj || {})[propName],
    (value, obj) => ({
      ...obj,
      [propName]: value
    })
  );

// we can now create lenses for props like this:

const parisLens = lensProp("paris");

const employeesLens = lensProp(
  "employees"
);

const studentsLens = lensProp(
  "students"
);

const listLens = lensProp("list"); // needed to get the list of students

We can now start composing (and using) our lenses:

const parisStudentListLens = compose(
  parisLens,
  employeesLens,
  studentsLens,
  listLens
);

const parisStudentList = parisStudentListLens(
  toGetAccessors
)(locations).get();

console.log(parisStudentList);
// -> undefined, since there is no list of students for paris defined.

const locationsWithStudentListForParis = parisStudentListLens(
  _list => toSetAccessors([])
  // ignore current list and replace it with an empty array
)(locations).get();

console.log(
  locationsWithStudentListForParis
);// -> { ..., paris: { employees:{ ..., students: { list: [] } } } }

As this would be very verbose to use, let's define some helpers:

const view = (lens, targetData) =>
  lens(toGetAccessors)(
    targetData
  ).get();

const over = (
  lens,
  overFn /* like the `mapf` callback in `Array.prototype.map(mapf)`.
    i.e.: You get a value and return a new value. */,
  targetData
) =>
  lens(data =>
    toSetAccessors(overFn(data))
  )(targetData).get();

const set = (lens, value, targetData) =>
  over(
    lens,
    () =>
      value /* we use `over` with a `overFn` function, 
        that just returns the value argument */,
    targetData
  );

Let's try to use our helpers:

// using get, set, over:

const locationsWithStudentListForParis = set(
  parisStudentListLens,
  [],
  locations
);

const locationsWithOneStudentInParis = over(
  parisStudentListLens,
  (list = []) => [
    ...list,
    { name: "You", setVia: "Lens" }
  ],
  locations
);

const locationsWithTwoStudentInParis = over(
  parisStudentListLens,
  (list = []) => [
    ...list,
    { name: "Me", setVia: "Lens" }
  ],
  locationsWithOneStudentInParis
);

// logging the results:

console.log(
  view(parisStudentListLens, locations)
); // -> undefined

console.log(
  view(
    parisStudentListLens,
    locationsWithStudentListForParis
  )
); // -> []

console.log(
  view(
    parisStudentListLens,
    locationsWithTwoStudentInParis
  )
); // -> [ { name: 'You', setVia: 'Lens' }, { name: 'Me', setVia: 'Lens' } ]

console.log(
  view(
    parisStudentListLens,
    locationsWithOneStudentInParis
  )
); // -> [ { name: 'Me', setVia: 'Lens' } ]

console.log(
  locationsWithTwoStudentInParis
); // -> ...

This approach makes upating deeply nested immutable data structures a breeze. To make it even simpler, you could define lensIndex(index: number) and lensPath(path: Array<string|number>) lens creator helpers. lensIndex is then being used to focus on array values. lensPath creates a lens that focuses on deeply nested object properties and array indexes, by creating and pre-composing lenses lensProp and lensIndex lenses for you.

More areas of application for lenses

Lenses are perfect for conversions between all kinds of values like currencies, temperature, units (metric units to imperial units and vise versa), sanitizing user input, parsing and stringifying JSON and much more.

Enjoy trying and playing around with lenses (don't miss to check out the Runkit Notebook). If you didn't understand some of my gibberish, please feel free to ask!

I'm happy to answer any questions :)

Introduction to Array.Reduce()

Jonas Winzen — Fri, 15 Sep 2017 00:36:20 +0000

The concept of "Reducing" data

For this introduction I will use an imaginary music library (consisting of tracks and playlists) application for the context of examples. The underlying concepts also apply to any other kind of application.

When operating on data, it is often necessary to have knowledge about the data in a more abstract form than just the plain elements. In our music library you might want to know how many different titles of a single artist exist, or how many artists are in your library. You might also need to know all tracks being used in one or more playlists. You also might want to display how much hours of music the library (or a playlist) contains.
These are all typical use cases for reduce. (in general all kinds of counting, filtering, grouping, categorizing, unifying, concatenating data can be solved by applying reduce. You can even abuse reduce for mapping data.)

Be aware: Sorting data with reduce won't work out fine and is nowhere near the makes-sense horizon.

How `reduce` works

A reducer function is in general a function that takes a accumulator (this is an object or value that you can think of as a state that is the result of the previous call to your reducer function) and a data element as parameters and returns a new value/object:

(accumulator, element) => resultValue

What makes reduce very special - in the scope of functional programming - is that it has a state. Not the reducer function itself (this one is ideally stateless - to make it easy to test and easy to reuse across your project), but the process of reducing the data itself. Each accumulator value gives you the intermediate result of the previous step.

The concept of reducing is especially applied in Array.prototype.reduce() (thats probably also the reason for its name). Another well known use of reduce is in the Redux state management library. It uses reducer functions in order to change the state in a reproduceable way using an action and the current state. The current state is passed as the accumulator and the action is the element parameter being passed to the reducer.

Back to `array.reduce()`

Array.prototype.reduce() (or array.reduce() of every Javascript instance of Array in JS) iterates over every element of its instance array, starting on the left side (array[0]) of the array, calling your reducer for each element and the result of the reducer for the previous element.

const array = [ 1, 2, 3, 5 ];
const finalResult = array.reduce((accumulator, element) => {
    console.log("accumulator: ", accumulator);
    console.log("element: ", element);
    const result = accumulator + element;
    console.log("result: ", result);
    return result;
});
console.log("final result: ", finalResult);

// Console output:
//
// > accumulator: 1
// > element: 2
// > intermediate result: 3
// > accumulator: 3
// > element: 3
// > intermediate result: 6
// > accumulator: 6
// > element: 5
// > intermediate result: 11
// > final result: 11
//

The example above seems to be just fine. With a closer look, we can find a fundamental problem, that makes writing more complex reducers not practicable:
The first value that is passed to the element parameter of our reducer is actually the second value in the array while the actual first array value is passed to as the accumulator value at the first invocation.
Why is this a problem?
For more complex reducers, it would mean that we have to distinguish between the first invocation and following invocations, since the first accumulator value might be of completely different type than the array elements are (leading to potential undefined is not a function exceptions during execution, when not carefully handled.
Before you now instantly close this article and start writing reducers that can handle data of the type of array elements AND accumulator type:

Array.prototype.reduce() provides a way to completely avoid this problem:

It allows you to specify a second parameter, next to your reducer function, to be used as the first accumulator value. Setting this parameter will completly avoid this problem:

const array = [ 1, 2, 3, 5 ];
const finalResult = array.reduce((accumulator, element) => {
    console.log("accumulator: ", accumulator);
    console.log("element: ", element);
    const result = accumulator + element;
    console.log("result: ", result);
    return result;
}, 0);
console.log("final result: ", finalResult);

// Console output:
//
// > accumulator: 0
// > element: 1
// > intermediate result: 1
// > accumulator: 1
// > element: 2
// > intermediate result: 3
// > accumulator: 3
// > element: 3
// > intermediate result: 6
// > accumulator: 6
// > element: 5
// > intermediate result: 11
// > final result: 11
//

And it also allows us to pass a different accumulator type (but with same interface), to alter the way data is reduced completely:

const array = [ 1, 2, 3, 5 ];
const finalResult = array.reduce((accumulator, element) => {
    console.log("accumulator: ", accumulator);
    console.log("element: ", element);
    const result = accumulator + element;
    console.log("result: ", result);
    return result;
}, "ConcatedElements: ");
console.log("final result: ", finalResult);

// Console output:
//
// > accumulator: ConcatedElements: 
// > element: 1
// > intermediate result: ConcatedElements: 1
// > accumulator: ConcatedElements: 1
// > element: 2
// > intermediate result: ConcatedElements: 12
// > accumulator: ConcatedElements: 12
// > element: 3
// > intermediate result: ConcatedElements: 123
// > accumulator: ConcatedElements: 123
// > element: 5
// > intermediate result: ConcatedElements: 1235
// > final result: ConcatedElements: 1235
//

Using a string as first accumulator value, will concat the the elements, instead of adding them.

Available in Different Flavours

Besides Array.prototype.reduce() there is also Array.prototype.reduceRight(). This is basically the same thing, but operates into the opposite direction:

const array_left = ['1', '2', '3', '4', '5'];
const array_right = ['1', '2', '3', '4', '5'];

const left = array_left.reduce((accumulator, element) => {
    return accumulator + element;
});

const right = array_right.reduceRight((accumulator, element) => {
    return accumulator + element;
});

const equivalentRight = array_left.reverse().reduce((accumulator, element) => {
    return accumulator + element;
});

const equivalentLeft = array_right.reverse().reduceRight((accumulator, element) => {
    return accumulator + element;
});

console.log(left);            
console.log(right);           
console.log(equivalentRight);
console.log(equivalentLeft);

// Console output:
//
// > "12345"
// > "54321"
// > "54321"
// > "12345"
//

That's it, for this short introduction on array.reduce(). Maybe you know some handy recipes for reducers (e.g. grouping data, unifying data, transforming an array into an Object (maybe to use it later as hashmap) or any other idea, you are welcome to post it into the comments. I will include the recipes (with a link to the author) in my next article about reducers.
I also appreciate any feedback, critics or corrections.

I hope this article helps to put more Fun into Functional Programming ;-)