This lesson teaches you what pointfree programming is, passing a named function as an argument to avoid writing an anonymous function with interim variables instead. Pointfree programming increases code legibility, decreases the surface area for bugs, and makes our code more composable and unit testable. We will demonstrate this by removing the anonymous arrow function passed as a callback to a map
method with a named function.
Kyle Shevlin: [00:00] Often, when we pass functions as arguments into other functions or methods, we use anonymous functions with interim variables. If we consider the map method, you might see something like this in order to double the numbers of our array.
[00:16] While this works, this actually leaves us a lot of surface area for bugs and misunderstanding. X acts as an interim variable. It is a placeholder for our data. We can just as easily name it foo, bar, or Y. None of those tell us much about what the data is or even what we are doing to the data.
[00:39] Pointfree programming is when we remove those anonymous functions and interim variables and instead pass in named functions directly into other functions. This works by pulling the anonymous function out and making a named function with it.
[00:53] In this case, we'll make a double function that receives any value and returns its double. Then we can pass double directly into array. What we gain from pointfree programming is legibility.
[01:07] It's really easy to read map and double and know that each item is being doubled. We reduce the surface area for bugs by not introducing new interim variables. We gain the ability to unit test our named functions.
Does this eventuality become hard to follow with so many small units? I wanna try the approach but, this is a concern from a few people on my project. Have any examples of this approach at scale?
Hi Darryl,
Does this eventually become hard to follow with so many small units?
"Hard to follow" is subjective. With practice, reading compositions and the use of pointfree functions can become very natural. Then you might wonder if it's not harder to follow a more imperative code base.
I think it's reasonable that this might be difficult or tedious to adopt, but what's great about what I teach here is that it can be adopted incrementally or not at all. I don't always do pointfree programming. I use many lambdas in my codebase, but knowing how to code pointfree gives me options.
I most often use pointfree programming in two places: when I am transforming data (which is a lot of what we do in frontend development) and within React classes for lists. I can create a method that will render a portion of my output, say the individual item of a list and then pass that method in to the map to create the list.
const Item = ({ id, text }) => <li key={id}>{text}</li>
const List = ({ items }) => (
<ul>
{items.map(Item)}
</ul>
)
Have any examples of this approach at scale?
I've never tried to make an entire codebase with this approach, but decent portions of my own projects and some of Webflow's codebase uses pointfree programming. It's all about using it where it makes sense and where it adds value to your work. In JavaScript, we have so much flexibility that often that's a challenging question to answer, but that's why we're paid, to make decisions about what's best for our specific situation.
This one is my favourite