Tip: Use Bit (Github) to “harvest” React/Angular/Vue components from any codebase and share them on bit.dev. Let your team reuse and collaborate on components to write scalable code, speed up development and maintain a consistent UI.

Example: searching for shared React components in bit.dev

So What Is The Point?

The point is simple. If you saw me write code like this, you would (rightfully) slap me in the face.

const toUpperArray = array => {

// unbox the value

const text = array[0] // transform the value

const upper = text.toUpperCase() // box it back up

return [upper]

}

Why did we pull the value out of the Array , just to put it back an the Array ?

But that is how we write code with async / await . We unbox the value then box it back into a Promise when the function returns.

// this is a contrived function representative of a lot of

// async/await code. const toUpperPromise = async promise => {

// unbox the value

const text = await promise // transform the value

const upper = text.toUpperCase() // box it back up

return upper

}

toUpperPromise returns upper wrapped up in a resolved Promise .

Leave it in The Box

It doesn’t make much sense to unbox the value and then put it back a the box when the values can be transformed (without unboxing) by using map or then / catch .

cat in a box

const toUpper = text => text.toUpperCase() array.map(toUpper)

promise.then(toUpper)

2+ Arity Functions

.map and .then are amazing functions when working with one value at a time.

The “leave it in the box” solution gets complicated when you get into 2+ arity (argument) functions.

const add = (x, y) => x + y const array1 = [3]

const array2 = [4] const value = array1.flatMap(x => array2.map(y => add(x, y)))

// [7]

It’s not much better with a Promise either.

const add = (x, y) => x + y const promise1 = Promise.resolve(3)

const promise2 = Promise.resolve(4) const value = promise1.then(x => promise2.then(y => add(x, y)))

Quick recap:

1 arity solution good 👍

2+ arity solution bad 👎

The async/await Solution

await makes it easy to unbox a value from a Promise . But because our function is now async , the value will be boxed back up into a Promise .

const add = (x, y) => x + y const compute = async () => {

const value1 = await Promise.resolve(3)

const value2 = await Promise.resolve(4) return add(value1, value2)

}

This is better than the 2+ arity solutions, but we are still unboxing values and reboxing them again.

What I Want

If I got my wish, it would be to be able to write asynchronous code in a way that is similar to this synchronous code block.

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

const value2 = 4 const result = add(value1, value2)

Promise Lifting can help us get there.

Promise Lifting

The term lift comes from functional programming, which in turn got the term from mathematics. Everything is math. You can think of a lift as a transformation to another type.

So far all of the solutions have been focusing on transforming the data. But what if instead we flip this and we transformed the function?

Let’s lift the add function from number to Promise<number> and see what the code looks like.

/**

* @param {number} x

* @param {number} x

* @returns {number}

*/

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

* @param {Promise<number>} x

* @param {Promise<number>} x

* @returns {Promise<number>}

*/

const addP = liftP(add) const promise1 = Promise.resolve(3)

const promise2 = Promise.resolve(4) const promiseValue = addP(promise1, promise2)

So in this example, add is wrapped with the liftP function (decorator). This converts the function from one that accepts numbers as arguments to a function that accepts Promises as arguments.

Now we no longer need to unbox the values! And if you look again at the synchronous example, that is EXACTLY how our code works!

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

const value2 = 4 const result = add(value1, value2)

head exploding

Wow! We are writing asynchronous code, but we are writing it the same way we write synchronous code!

Another Example

Let’s take some synchronous code. Ya I know this code is junk. It’s a contrived example to so the liftP has something to lift.

It’s just two functions. It could be any two functions.

const getComparisonText = (being1, being2) => {

if (being1.height === being2.height)

return 'the same height'

if (Number(being1.height) > Number(being2.height))

return 'taller than' return 'shorter than'

} const compareHeight = (being1, being2) => {

const compareText = getComparisonText(being1, being2)

return `${being1.name} is ${compareText} as ${being2.name}`

}

Now lift the compareHeight and call it compareHeightP . I add an P to the end so I know this version takes Promises.

const compareHeightP = liftP(compareHeight)

Now just call the function the same way you would if the code was synchronous.

const luke = httpGet('https://swapi.co/api/people/1/?format=json')

const c3po = httpGet('https://swapi.co/api/people/2/?format=json') compareHeightP(luke, c3po)

// Promise("Luke Skywalker is taller than as C-3PO")

The Code

The liftP function is a short one-liner. The P on the end there is for Promise . This is so the function does not get confused with the liftA or liftA2 functions (for Applicatives). But that’s for another time.

const liftP = func => (...args) =>

Promise.all(args).then(values => func(...values))

Play Time

Press run below to start playing with the code:

(start reading at line 29)

Summary

Promise Lifting changes the focus from converting our values to work with our functions, to converting the functions to work with our values .

. Promise Lifted code appears structurally similar to synchronous code .

. Boxed values are no longer unboxed and then reboxed.

Am I recommending converting all your async / await code to Promise Lifted code? Absolutely not.

There are valid places to use a Promise, async / await as well as a Promise Lift.

This is just one more tool in your box to choose from.

Cheers!

Follow the discussion on Twitter: @joelnet

Learn More