以累加器为最终参数的无点归约函数 - 函数式编程 - Javascript - Immutable.js

Question

I've run into a pattern that I feel may be some sort of anti-pattern, or perhaps there's just a better way to accomplish.

Consider the following utility function that renames a key in an object similar to renaming a file with the terminal command mv .

import { curry, get, omit, pipe, set, reduce } from 'lodash/fp'

const mv = curry(
  (oldPath, newPath, source) =>
    get(oldPath, source)
      ? pipe(
          set(newPath, get(oldPath, source)),
          omit(oldPath)
        )(source)
      : source
)

test('mv', () => {
  const largeDataSet = { a: 'z', b: 'y', c: 'x' }
  const expected = { a: 'z', q: 'y', c: 'x' }
  const result = mv('b', 'q', largeDataSet)

  expect(result).toEqual(expected)
})

It's just an example function that can be used anywhere. Next consider then a large data set that may have a small list of keys to rename.

test('mvMore', () => {
  const largeDataSet = { a: 'z', b: 'y', c: 'x' }
  const expected = { a: 'z', q: 'y', m: 'x' }
  const keysToRename = [['b', 'q'], ['c', 'm']]

  const result = reduce(
    (acc, [oldPath, newPath]) => mv(oldPath, newPath, acc),
    largeDataSet,
    keysToRename
  )

  expect(result).toEqual(expected)
})

So now we get to the subject of my question which revolves around a pattern where you may have a large data set and many small lists of different operations similar to mv to perform upon said data set. Setting up a point-free pipe to pass the data set down from one reduce function to the next seems ideal; however, each must pass the data set as the accumulator argument, becuase we are not iterating over the data set, but over a small lists of operations.

test('pipe mvMore and similar transforms', () => {
  const largeDataSet = { a: 'z', b: 'y', c: 'x' }
  const expected = { u: 'z', r: 'y', m: 'x' }
  const keysToRename = [['b', 'q'], ['c', 'm']]
  const keysToRename2 = [['q', 'r'], ['a', 'u']]
  const mvCall = (source, [oldPath, newPath]) => mv(oldPath, newPath, source)
  const reduceAccLast = curry((fn, it, acc) => reduce(fn, acc, it))

  const result = pipe(
    // imagine other similar transform
    reduceAccLast(mvCall, keysToRename),
    // imagine other similar transform
    reduceAccLast(mvCall, keysToRename2)
  )(largeDataSet)

  expect(result).toEqual(expected)
})

My question is whether this is an anti-pattern of some sort, or if there is a better way to accomplish the same result. What gives me consternation is that typically the accumulator argument of a reducer function is used as internal state and the data set is iterated over; however, here it is the other way around. Most reducer iteratee functions will mutate the accumulator with the understanding that it is only being used internally. Here, the dataset is being passed from reducer to reducer as the accumulator argument because it does not make sense to iterate over a large data set where there are only lists of a few operations to perform on the data set. As long as the reducer iteratee functions, eg, mv do not mutate the accumulator, is there any problem with this pattern or is there something simple I am missing?

---

Based on @tokland's answer I rewrote the tests to use Immutable.js to see if the guarantees of immutability and the potential gain in performance were worth the effort. There was some hoopla on the internets about Immutable.js not being a good fit for point-free style functional programming. There is some truth to that; however, not much. From what I can tell, all one has to do is write a few basic functions that call the methods you want to use, eg, map , filter , reduce . Lodash functions that do not deal with Javascript Arrays or Objects can still be used; in otherwords, Lodash functions that deal with functions, like curry and pipe , or with strings, like upperCase seem to be fine.

import { curry, pipe, upperCase } from 'lodash/fp'
import { Map } from 'immutable'

const remove = curry((oldPath, imm) => imm.remove(oldPath))
const get = curry((path, imm) => imm.get(path))
const set = curry((path, source, imm) => imm.set(path, source))
const reduce = curry((fn, acc, it) => it.reduce(fn, acc))
const reduceAcc = curry((fn, it, acc) => reduce(fn, acc, it))
const map = curry((fn, input) => input.map(fn))

const mv = curry((oldPath, newPath, source) =>
  pipe(
    set(newPath, get(oldPath, source)),
    remove(oldPath)
  )(source)
)

const mvCall = (acc, newPath, oldPath) => mv(oldPath, newPath, acc)

function log(x) {
  console.log(x)
  return x
}

test('mv', () => {
  const largeDataSet = Map({ a: 'z', b: 'y', c: 'x' })
  const expected = Map({ a: 'z', q: 'y', c: 'x' })
  const result = mv('b', 'q', largeDataSet)

  expect(result).toEqual(expected)
})

test('mvMore', () => {
  const largeDataSet = Map({ a: 'z', b: 'y', c: 'x' })
  const expected = Map({ a: 'z', q: 'y', m: 'x' })
  const keysToRename = Map({ b: 'q', c: 'm' })
  const result = reduce(mvCall, largeDataSet, keysToRename)

  expect(result).toEqual(expected)
})

test('pipe mvMore and similar transforms', () => {
  const largeDataSet = Map({ a: 'z', b: 'y', c: 'x' })
  const expected = Map({ u: 'Z', r: 'Y', m: 'X' })
  const keysToRename = Map({ b: 'q', c: 'm' })
  const keysToRename2 = Map({ q: 'r', a: 'u' })

  const result = pipe(
    reduceAcc(mvCall, keysToRename),
    reduceAcc(mvCall, keysToRename2),
    map(upperCase)
  )(largeDataSet)

  const result2 = keysToRename2
    .reduce(mvCall, keysToRename.reduce(mvCall, largeDataSet))
    .map(upperCase)

  expect(result).toEqual(expected)
  expect(result2).toEqual(expected)
})

Typescript seems to have some problems handling higher-order functions so gotta throw the // @ts-ignore s up before pipe if you're testing with tsc .

Answer 1

There is nothing wrong with your approach. Sometimes you fold over the input object, sometimes you use it as the initial accumulator, it depends on the algorithm. If a reducer mutates a value passed by the function caller, then this reducer cannot be used whenever immutability is required.

That said, your code may have performance issues, depending on the size of the objects (input, key mappings). Every time you change a key, you create a brand new object. If you see that's a problem, you'd typically use some efficient immutable structure that reuses data for the input (not necessary for the mappings, since you do not update them). Look for example at Map from immutable.js.

Answer 2

Based on @tokland's answer I rewrote the tests to use Immutable.js to see if the guarantees of immutability and the potential gain in performance were worth the effort. There was some hoopla on the internets about Immutable.js not being a good fit for point-free style functional programming. There is some truth to that; however, not much. From what I can tell, all one has to do is write a few basic functions that call the methods you want to use, eg, map , filter , reduce . Lodash functions that do not deal with Javascript Arrays or Objects can still be used; in otherwords, Lodash functions that deal with functions, like curry and pipe , or with strings, like upperCase seem to be fine.

import { curry, pipe, upperCase } from 'lodash/fp'
import { Map } from 'immutable'

const remove = curry((oldPath, imm) => imm.remove(oldPath))
const get = curry((path, imm) => imm.get(path))
const set = curry((path, source, imm) => imm.set(path, source))
const reduce = curry((fn, acc, it) => it.reduce(fn, acc))
const reduceAcc = curry((fn, it, acc) => reduce(fn, acc, it))
const map = curry((fn, input) => input.map(fn))

const mv = curry((oldPath, newPath, source) =>
  pipe(
    set(newPath, get(oldPath, source)),
    remove(oldPath)
  )(source)
)

const mvCall = (acc, newPath, oldPath) => mv(oldPath, newPath, acc)

function log(x) {
  console.log(x)
  return x
}

test('mv', () => {
  const largeDataSet = Map({ a: 'z', b: 'y', c: 'x' })
  const expected = Map({ a: 'z', q: 'y', c: 'x' })
  const result = mv('b', 'q', largeDataSet)

  expect(result).toEqual(expected)
})

test('mvMore', () => {
  const largeDataSet = Map({ a: 'z', b: 'y', c: 'x' })
  const expected = Map({ a: 'z', q: 'y', m: 'x' })
  const keysToRename = Map({ b: 'q', c: 'm' })
  const result = reduce(mvCall, largeDataSet, keysToRename)

  expect(result).toEqual(expected)
})

test('pipe mvMore and similar transforms', () => {
  const largeDataSet = Map({ a: 'z', b: 'y', c: 'x' })
  const expected = Map({ u: 'Z', r: 'Y', m: 'X' })
  const keysToRename = Map({ b: 'q', c: 'm' })
  const keysToRename2 = Map({ q: 'r', a: 'u' })

  const result = pipe(
    reduceAcc(mvCall, keysToRename),
    reduceAcc(mvCall, keysToRename2),
    map(upperCase)
  )(largeDataSet)

  const result2 = keysToRename2
    .reduce(mvCall, keysToRename.reduce(mvCall, largeDataSet))
    .map(upperCase)

  expect(result).toEqual(expected)
  expect(result2).toEqual(expected)
})

Typescript seems to have some problems handling higher-order functions so gotta throw the // @ts-ignore s up before pipe if you're testing with tsc .

Answer 3

I think the answer to your question is yes and no. What I mean by that is in functional programming pure functions are a thing and your are trying to do it in a functional way but mutate the input. So I think you need to consider having a convert approach similar to how lodash/fp does it:

Although lodash/fp & its method modules come pre-converted, there are times when you may want to customize the conversion. That's when the convert method comes in handy.

// Every option is true by default.

var _fp = fp.convert({
  // Specify capping iteratee arguments.
  'cap': true,
  // Specify currying.
  'curry': true,
  // Specify fixed arity.
  'fixed': true,
  // Specify immutable operations.
  'immutable': true,
  // Specify rearranging arguments.
  'rearg': true
});

Notice the immutable converter there. So this is the yes part of my answer ... but the no part would be that you still need to have a immutable approach as a default to be truly pure/functional.