InChapter 1,Becoming Functional, we went over what FP is, mentioned some advantages of applying it, and listed some tools we’d need in JavaScript. For now, let’s leave the theory behind and start by considering a simple problem and how to solve it in afunctional way.

In this chapter, we will dothe following:

• Look at a simple,e-commerce-related problem
• Consider several usual ways to solve it (with theirassociated defects)
• Find a way to solve the problem by looking atit functionally
• Devise a higher-order solution that can be applied toother problems
• Work out how to carry out unit testing forfunctional solutions

In future chapters, we’ll be returning to some of the topics listed here, so we won’t be going into too much detail. We’ll just show how FP can give a different outlook on our problem and leave further detailsfor later.

After working through this chapter, you will have had a first look at a common problem and at a way of solving it by thinking functionally, as a prelude for the rest ofthis book.

Let’sconsider a simple but common situation. You have developed an e-commerce site; the user can fill their shopping cart, and in the end, they must click on aBill me button so that their credit card will be charged. However, the user shouldn’t click twice (or more), or they will be billedseveral times.

The HTML part of your application might have something likethis somewhere:

<button    onclick="billTheUser(some, sales, data)">Bill me      </button>

And, among the scripts, you’d have something similar to thefollowing code:

function billTheUser(some, sales, data) {  window.alert("Billing the user...");  // actually bill the user}

A bad example

Assigning the events handler directly in HTML, the way I did it, isn’t recommended. Instead, unobtrusively, you should set the handler through code. So,do as I say, not asI do!

This is a bare-bones explanation of the web page problem, but it’s enough for our purposes. Now, let’s get to thinking about ways of avoiding repeated clicks on that button. How can we manage to prevent the user from clicking more than once? That’s an interesting problem, with several possible solutions – let’s start by looking atbad ones!

How many ways can you think of to solve our problem? Let’s go over several solutions and analyzetheir quality.

Solution 1 – hoping for the best!

How can we solve theproblem? The first solution may seem like a joke: do nothing, tell the user not to click twice, and hope for the best! Your page might look likeFigure 2.1:

Figure 2.1 – An actual screenshot of a page, just warning you against clicking more than once

This is a way to weasel out of the problem; I’ve seen several websites that just warn the user about the risks of clicking more than once and do nothing to prevent the situation. So, the user got billed twice? We warned them... it’stheir fault!

Your solution might simply look like thefollowing code:

<button  id="billButton"  onclick="billTheUser(some, sales, data)">Bill me</button><b>WARNING: PRESS ONLY ONCE, DO NOT PRESS AGAIN!!</b>

Okay, this isn’t anactual solution; let’s move on to moreserious proposals.

Solution 2 – using a global flag

The solutionmost people would probably think of first is using some global variable to record whether the user has already clicked on the button. You define a flag named something likeclicked, initialized withfalse. When the user clicks on the button, ifclicked isfalse, you change it totrue and execute the function; otherwise, you do nothing at all. This can be seen in thefollowing code:

let clicked = false;...function billTheUser(some, sales, data) {  if (!clicked) {    clicked = true;    window.alert("Billing the user...");    // actually bill the user  }}

This works, but it has several problems that mustbe addressed:

• You are using a global variable, and you could change its value by accident. Global variables aren’t a good idea, in JavaScript or other languages. You must also remember to re-initialize it tofalse when the user starts buying again. If you don’t, the user won’t be able to make a second purchase because paying willbecome impossible.
• You will have difficulties testing this code because it depends on external things (that is, theclicked variable).

So, this isn’t a very good solution. Let’skeep thinking!

Solution 3 – removing the handler

We maygo for a lateral kind of solution, and instead of having the function avoid repeated clicks, we might just remove the possibility of clicking altogether. The following code does just that; the first thing thatbillTheUser() does is remove theonclick handler from the button, so no further calls willbe possible:

function billTheUser(some, sales, data) {  document    .getElementById("billButton")    .onclick = null;  window.alert("Billing the user...");  // actually bill the user}

This solution also hassome problems:

• The code is tightly coupled to the button, so you won’t be able to reuseit elsewhere
• You must remember to reset the handler; otherwise, the user won’t be able to make asecond purchase
• Testing will also be more complex because you’ll have to provide someDOM elements

We can enhance this solution a bit and avoid coupling the function to the button by providing the latter’s ID as an extra argument in the call. (This idea can also be applied to some of the further solutions that we’ll see.) The HTML part would be as follows; note the extra argumenttobillTheUser():

<button  id="billButton"  onclick="billTheUser('billButton', some, sales, data)">Bill me</button>

We also have to change the called function so that it will use the receivedbuttonId value to access thecorresponding button:

function billTheUser(buttonId, some, sales, data) {  document.getElementById(buttonId).onclick = null;  window.alert("Billing the user...");  // actually bill the user}

This solution is somewhat better. But, in essence, we are still using a global element – not a variable, but theonclick value. So, despite the enhancement, this isn’t a very good solution either. Let’smove on.

Solution 4 – changing the handler

A variant to the previous solution would be not to remove the click function, but to assign a new one instead. We are using functions as first-class objects here when we assign thealreadyBilled() function to the click event. The function warning the user that they have already clicked could look somethinglike this:

function alreadyBilled() {  window.alert("Your billing process is running; don't    click, please.");}

OurbillTheUser() function would then be like the following code – note how instead of assigningnull to theonclick handler as in the previous section, now, thealreadyBilled() functionis assigned:

function billTheUser(some, sales, data) {  document    .getElementById("billButton")    .onclick = alreadyBilled;  window.alert("Billing the user...");  // actually bill the user}

There’s a good point to this solution; if the user clicks a second time, they’ll get a warning not to do that, but they won’t be billed again. (From the point of view of user experience, it’s better.) However, this solution still has the very same objections as the previous one (code coupled to the button, needing to reset the handler, and harder testing), so we don’tconsider it quitegood anyway.

Solution 5 – disabling the button

A similar idea hereis instead of removing the event handler, we can disable the button so the user won’t be able to click. You might have a function such as the one shown in the following code, which does exactly that by setting thedisabled attribute ofthe button:

function billTheUser(some, sales, data) {  document    .getElementById("billButton")    .setAttribute("disabled", "true");  window.alert("Billing the user...");  // actually bill the user}

This also works, but we still have objections as with the previous solutions (coupling the code to the button, needing to re-enable the button, and harder testing), so we don’t like thissolution either.

Solution 6 – redefining the handler

Another idea: instead ofchanging anything in the button, let’s have the event handler change itself. The trick is in the second line of the following code; by assigning a new value to thebillTheUser variable, we are dynamically changing what the function does! The first time you call the function, it will do its thing, but it will also change itself out of existence by giving its name to anew function:

function billTheUser(some, sales, data) {  billTheUser = function() {};  window.alert("Billing the user...");  // actually bill the user}

There’s aspecial trick in the solution. Functions are global, so thebillTheUser=... line changes the function’s inner workings. From that point on,billTheUser will be the new (null) function. This solution is still hard to test. Even worse, how would you restore the functionality ofbillTheUser, setting it back to itsoriginal objective?

Solution 7 – using a local flag

We can goback to the idea of using a flag, but instead of making it global (which was our main objection to the second solution), we canuse anImmediately Invoked Function Expression (IIFE), which we’ll see more about inChapter 3,Starting Out with Functions, andChapter 11,Implementing Design Patterns. With this, we can use a closure, soclicked will be local to the function and not visibleanywhere else:

var billTheUser = (clicked => {  return (some, sales, data) => {    if (!clicked) {      clicked = true;      window.alert("Billing the user...");      // actually bill the user    }  };})(false);

This solution is along the lines of the global variable solution, but using a private, local variable is an enhancement. (Note howclicked gets its initial value from the call at the end.) The only drawback we could find is that we'll have to rework every function that needs to be called only once to work in this fashion (and, as we’ll see in the following section, our FP solution is similar to it in some ways). Okay, it’s not too hard to do, but don’t forget theDon’t Repeat Yourself (DRY),usualadvice!

We have now gone through multiple ways of solving our “do something only once” problem – but as we’ve seen, they were not very good! Let’s think about the problem functionally so that we get a moregeneral solution.

Let’s try to be moregeneral; after all, requiring that some function or other be executed only once isn’t that outlandish, and may be required elsewhere! Let’s lay downsome principles:

• The original function (the one that may be called only once) should do whatever it is expected to do andnothing else
• We don’t want to modify the original function inany way
• We need a new function that will call the original oneonly once
• We want a general solution that we can apply to any number oforiginal functions

A SOLID base

The first principle listed previously is the single responsibility principle (the S in theSOLID acronym), which states that every function should be responsible for a single functionality. For more on SOLID, check the article by Uncle Bob (Robert C. Martin, who wrote the five principles)atbutunclebob.com/ArticleS.UncleBob.PrinciplesOfOod.

Can we do it? Yes, and we’ll write a higher-order function, which we’ll be able to apply to any function, to produce a new function that will work only once. Let’s see how! We will introduce higher-order functions inChapter 6,Producing Functions. There, we’ll go about testing our functional solution, as well as making some enhancementsto it.

A higher-order solution

If we don’t want to modifythe original function, we can create a higher-order function, which we’ll (inspiredly!) nameonce(). This function will receive a function as a parameter and return a new function, which will work only once. (As we mentioned previously, we’ll be seeing more of higher-order functions later; in particular, see theDoing things once, revisited section ofChapter 6,Producing Functions).

Many solutions

Underscore and Lodash already have a similar function, invoked as_.once(). Ramda also providesR.once(), and most FP libraries include similar functionality, so you wouldn’t have to program it onyour own.

Ouronce() function may seem imposing at first, but as you get accustomed to working in an FP fashion, you’ll get used to this sort of code and find it to bequite understable:

// once.tsconst once = <FNType extends (...args: any[]) => any>(  fn: FNType) => {  let done = false;  return ((...args: Parameters<FNType>) => {    if (!done) {      done = true;      return fn(...args);    }  }) as FNType;};

Let’s go over some of the finer points ofthis function:

• Ouronce() function receives a function (fn) as its parameter and returns a new function, of the same type. (We’ll discuss this typing in moredetail shortly.)
• We define an internal, privatedone variable, by taking advantage ofclosure, as inSolution 7. We opted not to call itclicked (as we did previously) because you don’t necessarily need to click on a button to call the function; we went for a more general term. Each time you applyonce() to some function, a new, distinctdone variable will be created and will be accessible only from thereturned function.
• Thereturn statement shows thatonce() will return a function, with the same type of parameters as the originalfn() one. We are using the spread syntax we saw inChapter 1,Becoming Functional. With older versions of JavaScript, you’d have to work with the arguments object; seedeveloper.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/arguments for more on that. The modern way is simplerand shorter!
• We assigndone = true before callingfn(), just in case that function throws an exception. Of course, if you don’t want to disable the function unless it has successfully ended, you could move the assignment below thefn() call. (SeeQuestion 2.4 in theQuestions section for another takeon this.)
• After the setting is done, we finally call the original function. Note the use of the spread operator to pass along whatever parameters the originalfn() had.

Typing foronce() may be obscure. We have to specify that the type of the input function and the type ofonce() are the same, and that’s the reason for definingFNType.Figure 2.2 shows that TypeScript correctly understands this (Check the answer toQuestion 1.7 at the end of this book for another exampleof this):

Figure 2.2 – Hovering shows that the type of once()’s output matches the type of its input

If you’re not still used to TypeScript, let’s see the pure JavaScript equivalent, which is the same code butfor typing:

// once_JS.jsconst once = (fn) => {  let done = false;  return (...args) => {    if (!done) {      done = true;      return fn(...args);    }  };};

So, how would we use it? We first create a new version of thebilling function.

const billOnce = once(billTheUser);

Then, we rewrite theonclick methodas follows:

<button  onclick="billOnce(some, sales, data)">Bill me</button>;

When the userclicks on the button, the function that gets called with the(some, sales, data) argument isn’t the originalbillTheUser() but rather the result of having appliedonce() to it. The result of that is a function that can be called only asingle time.

You can’t always get what you want!

Note that ouronce() function uses functions such as first-class objects, arrow functions, closures, and the spread operator. Back inChapter 1,Becoming Functional, we said we’d be needing those, so we’re keeping our word! All we are missing from that chapter is recursion, but as the Rolling Stones sang,You Can’t Always Get WhatYou Want!

We now have a functional way of getting a function to do its thing only once, but how would we test it? Let’s get into thattopic now.

Testing the solution manually

We can run asimple test. Let’s write asqueak() function that will, appropriately,squeak when called! The codeis simple:

// once.manual.tsconst squeak = a => console.log(a, " squeak!!");squeak("original"); // "original squeak!!"squeak("original"); // "original squeak!!"squeak("original"); // "original squeak!!"

If we applyonce() to it, we get a new function that will squeak only once. See the highlighted line in thefollowing code:

// continued...const squeakOnce = once(squeak);squeakOnce("only once"); // "only once squeak!!" squeakOnce("only once"); // no outputsqueakOnce("only once"); // no output

The previous steps showed us how we could test ouronce() function by hand, but our method is not exactly ideal. In the next section, we’ll see why and how todo better.

Testing the solution automatically

Running tests byhand isn’t suitable: it gets tiresome and boring, and it leads, after a while, to not running the tests any longer. Let’s do better and write some automatic testswithJest:

// once.test.tsimport once } from "./once";describe("once", () => {  it("without 'once', a function always runs", () => {    const myFn = jest.fn();    myFn();    myFn();    myFn();    expect(myFn).toHaveBeenCalledTimes(3);  });  it("with 'once', a function runs one time", () => {    const myFn = jest.fn();    const onceFn = jest.fn(once(myFn));    onceFn();    onceFn();    onceFn();    expect(onceFn).toHaveBeenCalledTimes(3);    expect(myFn).toHaveBeenCalledTimes(1);  });});

There areseveral points tonote here:

• To spy on a function (for instance, to count how many times it was called), we need to pass it as an argument tojest.fn(); we can apply tests to the result, which works exactly like the original function, but can bespied on.
• When you spy on a function, Jest intercepts your calls and registers that the function was called, with which arguments, and how many times itwas called.
• The first test only checks that if we call the function several times, it gets called that number of times. This is trivial, but we’d be doing something wrong if thatdidn’t happen!
• In the second test, we applyonce() to a (dummy)myFn() function, and we call the result (onceFn()) several times. We then check thatmyFn() was called only once, thoughonceFn() was calledthree times.

We can see the results inFigure 2.3:

Figure 2.3 – Running automatic tests on our function with Jest

With that, wehave seen not only how to test our functional solution by hand but also in an automatic way, so we are done with testing. Let’s just finish by considering an even better solution, also achieved in afunctional way.

Producing an even better solution

In one of the previous solutions, we mentioned that it would be a good idea to do something every time after the first click, and not silently ignore the user’s clicks. We’ll write a new higher-order function that takes a second parameter – a function to be called every time from the second call onward. Our new function will be calledonceAndAfter() and can be writtenas follows:

// onceAndAfter.tsconst onceAndAfter = <  FNType extends (...args: any[]) => any>(  f: FNType,  g: FNType) => {  let done = false;  return ((...args: Parameters<FNType>) => {    if (!done) {      done = true;      return f(...args);    } else {      return g(...args);    }  }) as FNType;};

We have ventured further into higher-order functions;onceAndAfter() takes two functions as parameters and produces a third one, which includes the othertwo within.

Function as default

You could makeonceAndAfter() more powerful by giving a default value forg, such as() => {}, so if you didn’t specify the second function, it would still work fine because the default do-nothing function would be called instead of causingan error.

We can do a quick-and-dirty test along the same lines as we did earlier. Let’s add acreak() creaking function to our previoussqueak() one and check out what happens if we applyonceAndAfter() to them. We can then get amakeSound() function that should squeak once andcreak afterward:

// onceAndAfter.manual.tsimport { onceAndAfter } from "./onceAndAfter";const squeak = (x: string) => console.log(x, "squeak!!");const creak = (x: string) => console.log(x, "creak!!");const makeSound = onceAndAfter(squeak, creak);makeSound("door"); // "door squeak!!"makeSound("door"); // "door creak!!"makeSound("door"); // "door creak!!"makeSound("door"); // "door creak!!"

Writing a test for this new function isn’t hard, only a bit longer. We have to check which functionwas called and howmany times:

// onceAndAfter.test.tsimport { onceAndAfter } from "./onceAndAfter";describe("onceAndAfter", () => {  it("calls the 1st function once & the 2nd after", () => {    const func1 = jest.fn();    const func2 = jest.fn();    const testFn = jest.fn(onceAndAfter(func1, func2));    testFn();    testFn();    testFn();    testFn();    expect(testFn).toHaveBeenCalledTimes(4);    expect(func1).toHaveBeenCalledTimes(1);    expect(func2).toHaveBeenCalledTimes(3);  });});

Notice that wealways check thatfunc1() is called only once. Similarly, we checkfunc2(); the count of calls starts at zero (the time thatfunc1() is called), and from then on, it goes up by one oneach call.

In this chapter, we’ve seen a common, simple problem based on a real-life situation. After analyzing several typical ways of solving that, we went for a functional thinking solution. We saw how to apply FP to our problem and found a more general higher-order solution that we could apply to similar problems with no further code changes. We saw how to write unit tests for our code to round out thedevelopment job.

Finally, we produced an even better solution (from the point of view of the user experience) and saw how to code it and how to unit-test it. Now, you’ve started to get a grip on how to solve a problem functionally; next, inChapter 3,Starting Out with Functions, we’ll delve more deeply into functions, which are at the core ofall FP.

2.1No extra variables: Our functional implementation required using an extra variable,done, to mark whether the function had already been called. Not that it matters, but could you make do without using any extra variables? Note that we aren’t telling you not to use any variables, it’s just a matter of not adding any new ones, such asdone, and only asan exercise!

2.2Alternating functions: In the spirit of ouronceAndAfter() function, can you write analternator() higher-order function that gets two functions as arguments and, on each call, alternatively calls one and another? The expected behavior should be as in thefollowing example:

const sayA = () => console.log("A");const sayB = () => console.log("B");const alt = alternator(sayA, sayB);alt(); // Aalt(); // Balt(); // Aalt(); // Balt(); // Aalt(); // B

2.3Everything has a limit! As an extension ofonce(), could you write a higher-order function,thisManyTimes(fn,n), that would let you call thefn() function up ton times, but would do nothing afterward? To give an example,once(fn) andthisManyTimes(fn,1) would produce functions that behave the same way. Do also write testsfor it.

2.4Allow for crashing: Suppose we applyonce() to a function, and the first time that function gets called, it crashes. Here, we may want to allow a second call to the function, hoping it wouldn’t crash again. We want anonceIfSuccess() function, that will get a function as a parameter and produce a new function that will run successfully only once, but will be allowed to fail (throwing exceptions) many times if need be. ImplementonceIfSuccess(), and don’t forget to write unit testsfor it.

2.5Say no to arrows: Implementonce() using classic functions, instead of arrow functions. This is just meant to help you explore the slightly different needed datatyping syntax.