DEV Community: Conan

5 JavaScript Pipelining Techniques

Conan — Thu, 04 Nov 2021 02:57:03 +0000

Pipelining using 5 different techniques, current and future.

We'll refactor two chunks of code lifted from the TC39 pipeline proposal:

i) "Side-effect" chunk

const envarString = Object.keys(envars)
  .map(envar => `${envar}=${envars[envar]}`)
  .join(' ')
const consoleText = `$ ${envarString}`
const coloredConsoleText = chalk.dim(consoleText, 'node', args.join(' '))
console.log(coloredConsoleText)

ii) "Pure" chunk

const keys = Object.keys(values)
const uniqueKeys = Array.from(new Set(keys))
const items = uniqueKeys.map(item => <li>{item}</li>)
const unorderedList = <ul>{items}</ul>
return unorderedList

Each has a "chain" of operations used one after the other against the previous value.

The first chunk logs the final value, the second returns it:

envars > envarString > consoleText > coloredConsoleText > log
values > keys > uniqueKeys > items > unorderedList > return

In both cases, the final value is the only one we're really interested in, so this makes them candidates for pipelining!

Let's start with...

i) The "Side-effect" chunk

1. Using `let tmp`

The simplest way to drop those temporary variables is to declare a mutable let tmp and continuously reassign it:

let tmp = envars
tmp = Object.keys(tmp)
tmp = tmp.map(envar => `${envar}=${envars[envar]}`)
tmp = tmp.join(' ')
tmp = `$ ${tmp}`
tmp = chalk.dim(tmp, 'node', args.join(' '))
console.log(tmp)

It'll work, but maybe there are less error-prone ways of achieving the same thing. Also, mutable variables aren't exactly en vogue these days. 🤔

2. Using `Promise`

We can use Promise.resolve and a sequence of then's to keep the scope of each temporary variable under control:

Promise.resolve(envars)
  .then(_ => Object.keys(_))
  .then(_ => _.map(envar => `${envar}=${envars[envar]}`))
  .then(_ => _.join(' '))
  .then(_ => `$ ${_}`)
  .then(_ => chalk.dim(_, 'node', args.join(' ')))
  .then(_ => console.log(_))

No polluting the enclosing scope with tmp here! A Promise carries the idea of "piping" from envars all the way to logging the final colourised output without overwriting a temporary variable.

Not quite how we'd typically use Promise perhaps, but since many of us are familiar with how they chain together it's a useful jumping-off point for understanding pipelining for those not already familiar.

By the way, we could have used Object.keys and console.log first-class:

Promise.resolve(envars)
  .then(Object.keys) // instead of: _ => Object.keys(_)
  .then(console.log) // instead of: _ => console.log(_)

But I'll avoid using this "tacit" style here.

I'm also intentionally avoiding:

Promise.resolve(
  Object.keys(envars)
    .map(envar => `${envar}=${envars[envar]}`)
    .join(' ')
)
  .then(_ => `$ ${_}`)
  .then(_ => chalk.dim(_, 'node', args.join(' ')))
  .then(console.log)

Instead I'll try to keep the first level of indentation equal, as I think it helps convey the full pipelined-operation a bit better.

Anyway, using a Promise isn't ideal if we want a synchronous side-effect.

Popping an await before the whole chain is possible of course, but only if the pipeline sits inside an async function itself, which might not be what we want.

So let's try some synchronous pipelining techniques!

3. Using `pipe()`

With this magic spell:

function pipe(x, ...fns) {
  return fns.reduce((g, f) => f(g), x)
}

...we can have:

pipe(
  envars,
  _ => Object.keys(_),
  _ => _.map(envar => `${envar}=${envars[envar]}`),
  _ => _.join(' '),
  _ => `$ ${_}`,
  _ => chalk.dim(_, 'node', args.join(' ')),
  _ => console.log(_)
)

We dropped all those .then()'s and left the lambdas (arrow-functions) behind as arguments to pipe that will run in sequence, with the first argument providing the starting value to the first lambda.

Handy!

4. Using `Hack-pipes`

If you're using Babel or living in a future where the TC39 pipeline proposal has landed, you can use Hack-pipes:

envars
  |> Object.keys(^)
  |> ^.map(envar => `${envar}=${envars[envar]}`)
  |> ^.join(' ')
  |> `$ ${^}`
  |> chalk.dim(^, 'node', args.join(' '))
  |> console.log(^)

Terse! And starting to look like an actual pipe on the left there, no?

Notice that a token ^ acts as our "previous value" variable when we use |>, just like when we used _ or tmp previously.

5. Using the `Identity Functor`

Let's cast another magic spell:

const Box = x => ({
  map: f => Box(f(x))
})

...and make a pipeline with it:

Box(envars)
  .map(_ => Object.keys(_))
  .map(_ => _.map(envar => `${envar}=${envars[envar]}`))
  .map(_ => _.join(' '))
  .map(_ => `$ ${_}`)
  .map(_ => chalk.dim(_, 'node', args.join(' ')))
  .map(_ => console.log(_))

Looks suspiciously like the Promise pipeline, except then is replaced with map. 🤔

So that's 5 different pipelining techniques! We'll apply them now in reverse-order for...

ii) The "Pure" chunk

Here's the reference code again as a reminder:

const keys = Object.keys(values)
const uniqueKeys = Array.from(new Set(keys))
const items = uniqueKeys.map(item => <li>{item}</li>)
const unorderedList = <ul>{items}</ul>
return unorderedList

To start, we'll first make Box a monad:

const Box = x => ({
  map: f => Box(f(x)),
  chain: f => f(x) // there we go
})

By adding chain we can return the JSX at the end of a pipeline without transforming it into yet another Box (which didn't really matter in the side-effect chunk since we weren't returning anything):

return Box(values)
  .map(_ => Object.keys(_))
  .map(_ => Array.from(new Set(_)))
  .map(_ => _.map(item => <li>{item}</li>))
  .chain(_ => <ul>{_}</ul>)

Kinda feels like the Promise.resolve pipeline if it had an await at the beginning, eh? Instead it's a Box with a chain at the end. 🤔

And synchronous too, like pipe()!

Speaking of which, let's go back and use it now:

Using `pipe()`

return pipe(
  values,
  _ => Object.keys(_),
  _ => Array.from(new Set(_)),
  _ => _.map(item => <li>{item}</li>),
  _ => <ul>{_}</ul>
)

Fairly similar to the side-effect chunk, except to reveal that yes, pipe will indeed give us back the value returned by the last lambda in the chain. (That lovely <ul /> in this case.)

Using `Promise`

Back in the land of async, does it make sense to return JSX from a Promise? I'll leave the morals of it up to you, but here it is anyway:

return await Promise.resolve(values)
  .then(_ => Object.keys(_))
  .then(_ => Array.from(new Set(_)))
  .then(_ => _.map(item => <li>{item}</li>))
  .then(_ => <ul>{_}</ul>)

(await thrown-in just to communicate intention, but it's not required.)

Lastly, let's bring it right back to let tmp:

Using `let tmp`

let tmp = values
tmp = Object.keys(tmp)
tmp = Array.from(new Set(tmp))
tmp = tmp.map(item => <li>{item}</li>)
tmp = <ul>{tmp}</ul>
return tmp

And that's where we came in!

Conclusion

All in all we covered 5 different ways of pipelining: A way of transforming one value into another in a sequence of steps without worrying about what to call the bits in between.

let tmp
Promise#then
pipe(startingValue, ...throughTheseFunctions)
Hack |> pipes(^)
Identity Functor/Monad (Box#map/chain)

If you learned something new or have something to follow-up with, please drop a comment below. In any case, thanks for reading!

Debouncing / throttling

Conan — Sat, 18 Sep 2021 14:24:20 +0000

Photo by Jp Valery on Unsplash

This short Q&A on setTimeout() hopes to lead you into writing your own debouncers & throttlers -- handy tools for treating repeated events that happen across short periods of time as a single event.

Debouncing:

       Time : -   - --> -   - --> -   - --> -
Key-presses :        X X X X   X X X X X
     Events :              O           O

Throttling:

       Time : -   - --> -   - --> -   - --> -
Key-presses :        X X X X X X X X X
     Events :        O     O     O

All code below assumes the following header:

const seconds = n => n * 1000
const log = x => console.log(`hello, ${x}`)

So, the question is:

"At the end of each run, what will be logged to the console?" 🤔

1. setTimeout / clearTimeout

let id

function run() {
  id = setTimeout(log, seconds(1), 'world')
}

function clear() {
  clearTimeout(id)
}

// 1a)
run()
// What will be logged?

// 1b)
run()
clear()
// What will be logged?

2. runAfter

function runAfter(ms, fn, ...args) {
  const id = setTimeout(fn, ms, ...args)
  return () => clearTimeout(id) 
}

// 2)
const clear = runAfter(
  seconds(1),
  () => log('world')
)

clear()
// What will be logged?

3. RunAfter

function RunAfter(ms, fn) {
  let id
  const clear = () => clearTimeout(id)
  const run = (...args) => {
    id = setTimeout(fn, ms, ...args)
  }
  return [run, clear]
}

const [run, clear] = RunAfter(
  seconds(1),
  () => log('world')
)

// 3)
run()
// What will be logged?

4. makeDebouncer

function makeDebouncer(ms, fn) {
  const [run, clear] = RunAfter(ms, fn)
  const debouncer = (...args) => (
    clear(), run(...args)
  )
  return [debouncer, clear]
}

const [run, clear] = makeDebouncer(
  seconds(1),
  () => log('world')
)

// 4)
run()
run()
run()
// What will be logged?

5. makeThrottler

function makeThrottler(ms, fn) {
  let canRun = true
  const [run, clear] = RunAfter(ms, reset)
  return [throttler, reset]

  function throttler(...args) {
    if (!canRun) return
    canRun = false
    run()
    fn(...args)
  }

  function reset() {
    clear()
    canRun = true
  }
}

const [run, clear] = makeThrottler(
  seconds(1),
  () => log('world')
)

// 5)
run()
run()
run()
clear()
// What will be logged?

If you need a little help, I made a corresponding interactive version of the article that offers some very basic visuals.

I'm not sure if they help intuit what's going on, but they give the answers at least! Did they meet your expectations?

Array sorting callbacks

Conan — Sat, 11 Sep 2021 10:39:15 +0000

Photo by Edu Grande on Unsplash

A short Q&A on Array#sort() and passing a basic callback.

Before starting, let's just shorten console.log:

const { log } = console

Similar to before, the question is:

"At the end of each run, can you guess what will be logged?" 🤔

1. `array` vs. `[...array]`

const chars = ['a', '🪴', 'n', 'Z']
const sort = arr => [...arr].sort()
const sortInPlace = arr => arr.sort()

// 1a)
const output1 = sort()
log('output1 === ', output1)
log('chars === ', chars)

// 1b)
const output2 = sortInPlace()
log('output2 === ', output2)
log('chars === ', chars)

2. numbers vs. strings

const numbers = [2, 3, 1, 10]
const strings = ['2', '3', '1', '10']
const sort = arr => [...arr].sort()

// 2a)
const output1 = sort(numbers)
log('output1 === ', output1)

// 2b)
const output2 = sort(strings)
log('output2 === ', output2)

3. using a callback

If callback looks like this...

function compare(a, b) {
  if (a < b) return -1
  if (a === b) return 0
  if (a > b) return 1
}

...then:

const numbers = [2, 3, 1, 10]

const sort = () =>
  [...numbers].sort()

const sortCompare = () =>
  [...numbers].sort(compare)

// 3a)
const output1 = sort()
log('output1 === ', output1)

// 3b)
const output2 = sortCompare()
log('output2 === ', output2)

If you need a little help, I made a corresponding interactive version of the article that offers some very basic visuals (with a few extras toward the bottom!)

I'm not sure if they help intuit what's going on, but they give the answers at least! Did they meet your expectations?

forEach / break / continue

Conan — Sat, 04 Sep 2021 17:34:12 +0000

Photo by Dan Meyers on Unsplash

A short Q&A on loops of the standard and functional variety, breaking out of them, and skipping iterations.

All code below assumes the following header:

const { log } = console

const oneThousandItems = () =>
  Array.from({ length: 1000 })

So, the question is:

"At the end of each run, what will the value of index and count be?" 🤔

1. `for` vs. `forEach`, full-loops

// 1a)
function forLoop() {
  let index = 0
  let count = 0
  for (; index < 1000; index += 1) {
    count = count + 1
  }
  log('index === ', index)
  log('count === ', count)
}

// 1b)
function usingForEach() {
  let index
  let count = 0
  oneThousandItems().forEach(
    (_, _index) => {
      index = _index
      count = count + 1
    }
  )
  log('index === ', index)
  log('count === ', count) 
}

Next up, breaking-out of loops:

2. `for` vs. `some` vs. `every`, broken loops

// 2a)
function breakLoop() {
  let index = 0
  let count = 0
  for (; index < 1000; index += 1) {
    if (index > 499) { 
      break
    }
    count = count + 1
  }
  log('index === ', index)
  log('count === ', count)
}

// 2b)
function usingSome() {
  let index
  let count = 0
  oneThousandItems().some((_, _index) => {
    index = _index
    if (index > 499) { 
      return true
    }
    count = count + 1
  })
  log('index === ', index)
  log('count === ', count)
}

// 2c)
function usingEvery() {
  let index
  let count = 0
  oneThousandItems().every((_, _index) => {
    index = _index
    count = count + 1
    if (index < 499) { 
      return true
    }
  })
  log('index === ', index)
  log('count === ', count)
}

Finally, skipping to the next iteration:

3. `for` vs. `forEach`, skipped loops

// 3a)
function continuedLoop() {
  let index = 0
  let count = 0
  for (; index < 1000; index += 1) {
    if (index > 249) continue 
    count = count + 1
  }
  log('index === ', index)
  log('count === ', count)
}

// 3b)
function usingForEach() {
  let index
  let count = 0
  oneThousandItems().forEach(
    (_, _index) => {
      index = _index
      if (index > 249) return 
      count = count + 1
    }
  )
  log('index === ', index)
  log('count === ', count)
}

If you need a little help, I made a corresponding interactive version of the article that offers some very basic visuals.

I'm not sure if they help intuit what's going on, but they give the answers at least! Did they meet your expectations?

Pattern-matching in JavaScript

Conan — Wed, 18 Aug 2021 21:41:59 +0000

Photo by Parham Moieni on Unsplash

Pattern-matching is something I've leaned-on a lot recently, and I'm starting to anticipate its inclusion in the language more and more. It's currently a Stage 1 proposal.

Well, maybe to help it along I can share this little library I've been tinkering with.

I've tried to, ahem, match the TC39 spec as closely as I could in anticipation of the hopeful day when I don't need to use it anymore:

import { match, when, otherwise } from 'match-iz'

let result = match(data)(
  when(pattern, result || handler),
  when(pattern, result || handler),
  otherwise(result || handler)
)

If pattern-matching is new to you, it's essentially a declarative version of if and switch, where you describe the expected shape of your data using "patterns".

Patterns are a combination of both functions and data, and because of this certain assumptions can be made to help reduce the amount of boilerplate normally required to check that your data looks a certain way:

// Imperative:
if (typeof res?.statusCode === 'number') {
  if (res.statusCode >= 200 && res.statusCode < 300) {
    return res.body
  }
}

// Declarative:
return match(res)(
  when({ statusCode: inRange(200, 299) }, () => res.body),
  otherwise(() => {})
)

match-iz will check that statusCode is a key of res by implication of the when() being passed an object-literal { ... }.
The inRange() pattern-helper guards against non-numbers before trying to determine if its input is within a certain range.

I think match-iz (along with many similar libraries) is a reasonable tool for constructing some of the more complex conditional logic we use in our JavaScript. Stuff that's usually a mess of if/else/switch statements.

If you'd like to see pattern-matching used "in the wild", I've used match-iz myself for these other little projects: sift-r and viddy

DEV Community: Conan

5 JavaScript Pipelining Techniques

i) "Side-effect" chunk

ii) "Pure" chunk

i) The "Side-effect" chunk

1. Using let tmp

2. Using Promise

3. Using pipe()

4. Using Hack-pipes

5. Using the Identity Functor

ii) The "Pure" chunk

Using pipe()

Using Promise

Using let tmp

Conclusion

Debouncing / throttling

1. setTimeout / clearTimeout

2. runAfter

3. RunAfter

4. makeDebouncer

5. makeThrottler

Array sorting callbacks

1. array vs. [...array]

2. numbers vs. strings

3. using a callback

forEach / break / continue

1. for vs. forEach, full-loops

2. for vs. some vs. every, broken loops

3. for vs. forEach, skipped loops

Pattern-matching in JavaScript

1. Using `let tmp`

2. Using `Promise`

3. Using `pipe()`

4. Using `Hack-pipes`

5. Using the `Identity Functor`

Using `pipe()`

Using `Promise`

Using `let tmp`

1. `array` vs. `[...array]`

1. `for` vs. `forEach`, full-loops

2. `for` vs. `some` vs. `every`, broken loops

3. `for` vs. `forEach`, skipped loops