The Hard Parts of Functional JavaScript

Partial Application Clarifications

Will Sentance

Will Sentance

The Hard Parts of Functional JavaScript

Check out a free preview of the full The Hard Parts of Functional JavaScript course

The "Partial Application Clarifications" Lesson is part of the full, The Hard Parts of Functional JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Will clarifies what partial application is by showing how data is partially applied to a function, and compares partial application and the use of closure in the example shared previously.


Transcript from the "Partial Application Clarifications" Lesson

>> Will Sentance: A function with two inputs. Remember, we can auto run a list of functions, each of which returns at one output and hopefully inserts into the next function. If that next function needs two inputs. We need to reduce it to one input. So this is not gonna work.

So instead we run our prefill function on it inside of which we create a brand new function which grabs the function we want to pre fill. And a valued refill it stores in the function's backpack returns that out, has code such that when in a runs under its new labor multiply by two with a single input of five.

And by the way, we could call this anything of course but I'm trying to make it intuitive in that sense for my read for my you know my team. In those the five and inside of multiply by two really inner because it has this backpack of a function and data.

I'm able to run that backpack function of multiply that got passed in when it was created. And the prefill value, return at the result of that return it out and appear to just have had multiply by two with my value of two pre filled in multiply. So this here is partial application.

Partially applying data to a function. This is closure in functional programming style because you notice we ain't changing the pre-filled value. When we use closure, albeit my favorite concept in JavaScript, if we're being strictly functional, is it pure? Well, it's not. Notice when I run the function I altered stuff in its backpack because it means next time I run this function, I got to remember that stuff changed here.

Meaning, my code is not independent line to line, is having consequences albeit not in global namespace. But technically I run that function again, and the backpack value and we have the counter going up. That's changing, that's reducing the purity my function. It's saying next time you run this code, even wants to find multiple by two does this, next time you run it is behaving differently.

That means that that line wants to find multiple way to the first time you run is affecting the rest of my code base. Wherever I call that function, again, it's affected, it's changed. That is not every single line being independent unit. And that goes back to my final sort of, you know, my overarching thesis with functional programming.

These are techniques that make our code dramatically more readable, but we don't always have to achieve them in perfection. But our use of closure or giving functions backpack here is very legitimate functional permissions like called functional programming. Because here, we are taking a function, editing it by by running it with our value pre filled.

And every time I run multiple by two There is nothing changing in this backpack. This line is still truly independent. This line, I can run it knowing there is no other consequences. The next time it gets run, this stuff is still in the backpack the same.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now