Recurring code pattern #1: currying

In almost every module, I see this pattern:

function functionName (func, iter) { ... }

export default function curriedFunctionName (func, iter) {
  if (typeof iter === 'undefined') {
    return iter => functionName(iter)
  }
  return functionName (func, iter)
}

These patterns can be eliminated by using a curry wrapper:

// src/internal/curry.mjs

export default function curry (func, length) {
  const curried = (...args) => args.length < length
    ? (...suffix) => curried(...args, ...suffix)
    : func(...args)
  return curried
}

// src/function-name.mjs

import curry from './internal/curry'

function functionName (func, iter) { ... }

export default curry(functionName, 2)

I also saw that some test suites test currying support of their test subjects. A curry wrapper should eliminate the needs of writing those tests over and over again by replacing them all with 1 single test suite that tests curry() itself.

[KSXGitHub]

Are you going to work on it @KSXGitHub ?

Writing curry itself is relatively quick, but refactor the whole codebase to use the new curry function is repetitive, time-consuming, and boring. I prefer not to.

[KSXGitHub]

• some function has variable args in the curried version. That logic needs to be moved into the original function here for example

We just need to change curry a little.

• it is possible to give to the output function a meaningful name. This is battle tested for that task

I don’t think this is necessary: The reason you want a named function is for it to appear in error stack trace, is this the only reason? When use an error-proof curry(), the only place where errors could occur is func (a.k.a. function functionName ()), which is always guaranteed to have a name.