7 reasons to use functional programming on frontend 1/2
Wiktor ToporekSenior Frontend Developer
Functional programming has recently become a big thing in the frontend development domain. Why so? Is it an example of hype-driven development or are there any reasonable arguments to use it? To answer this question, I’ve prepared a list of 7 reasons which may make you decide to use functional programming on frontend during your next software project. Below are the first 3 of them.
This is one of the reasons why functional programming on frontend might have gained such popularity rather than an argument to use functional programming paradigm. Although, it’s worth mentioning this “weirdness” in the name of the better context. A little bit of history…
Before the age of transpilers like Babel and alternative frontend programming languages, there was almost no alternative for programming language than ones ran in a browser. If we exclude plugins like Java Applets and Flash. Oh… and VBScript which worked on the famous Microsoft Internet Explorer only.
Hence, it might be the reason why not all the people adopted ES6 classes syntax in their codebase. Of course, classes have become popular in React or Angular based apps, although considering standalone micro-libraries which NPM repositories are famous for, the class keyword is rare and functional approach beats it.
2. Immutability can reduce bugs
Sites became applications and the bigger apps are, the more complex issues developers have to deal with.
Frontend developers already have a “bug-friendly” environment thanks to the things like:
innumerable amount of devices with different parameters where the app should display correctly (responsive web design tries to deal with it),
API connection problems which have to be handled neatly.
And many more. So, naturally, tools and approaches which help narrowing the scope of problems down are highly appreciated.
Functional programming itself has more strict variation called “pure functional programming”. Pure FP is a paradigm that imposes strong restrictions: immutability and side-effects avoidance. At first glance, these may feel like an unnecessary complication (especially for developers with an imperative programming background). But they bear fruit when it comes to the master application state.
In terms of immutability, let’s study the two following functions:
Perhaps you have already spotted a bug. 😉 Nevertheless, let’s test their behavior in JS console:
> median([2, 1, 3, 7, 2, 4, 0, 5]) 2.5
> getLast([2, 1, 3, 7, 2, 4, 0, 5]) 5
They seem to work properly and would pass the unit tests easily. But note what happens in the following code:
The console.log output for such case is:
5 for getLast which is correct,
2 for median which is not the value that we expected.
The problem is that values.pop function inside getLast function mutates the array which is passed into by popping the last of elements.
So, let’s redefine getLast function with immutable (or, so called, pure) principle in mind:
Then, let’s try again:
Did it work as expected or not? Well, there’s another bug we might have missed.
Let’s try to change just one, tiny thing. Namely – let’s swap the console.log lines:
The console.log output is as follows:
median gives us 2.5, as we expected,
getLast gives us… 7!?
The problem here is that our median function is not pure. It mutates the array that is passed in as it was in our first implementation of getLast.
What makes this function not pure is that it calls another not-pure function – Array.prototype.sort:
Array.prototype.sort behavior may confuse. It returns a sorted version of an array that has been passed into it, although the sorted version is just a reference to the original array which has been mutated.
Taking the functions from preceding code examples into consideration, we can see that mutation made them not working properly when we used them one by one and swapped the order of their execution. It has revealed another bug which might have been missed at first glance.
So, let’s finally fix the code example:
What we’ve done in the code above is that we implemented a sort function. And it does not mutate the original array.
Our pure sorting solution makes use of a simple trick of calling Array.prototype.slice().It creates a copy of the original array before sorting. This behavior guarantees that our sort function won’t mutate the passed in argument, hence it is pure.
And as we use our pure sorting function in the median function, it’s also pure. It guarantees that median won’t mutate the argument neither.
Now, no matter which function is executed at the first place, the results are always predictable and correct:
3. It’s easier to test
No matter which programming language I use, there’s a thing that I always associate with tests. It’s mocking/stubbing. When you write unit tests, sooner or later you’ll have to fake some objects and functions that tested unit relies on.
Pure functions can help you with that. The way they work is simple:
just compare them to functions that are not pure:
Due to the fact that in pure functions there is no mutation, side-effects and functions have referential transparency (we’ll focus on this later), it’s guaranteed that the only place where you can change the result of such function are arguments that are an input.
Consider how much easier is writing tests for functions that rely only on what you pass to them explicitly. For instance, functions that have to deal with date and time. Normally, it would be tempting to write such a code:
But because such function relies on the current time (which passes by), you’ll have to mock fthe date object before testing the function. Although this function is easy to write, it’s more difficult to test, as it requires you to fake the time when writing the tests.
Referential transparency is something that can help us in such cases because it guarantees that the function is deterministic. Referential transparency guarantees the specific input which will always give you the same result – no matter how many times (and when) function is called. Hence, call expressions of functions that met the referential transparency condition can just be replaced with output value like in the following example:
The number variable can be replaced with the following:
let number =4;
So, coming back to our tokenExpired function example. We can rewrite it to a pure version which meets the referential transparency requirement:
This function will no longer depend on the current time behind the scenes, and the tests can be simplified as the current time has to be passed explicitly as the second argument:
To be continued…
We’ve also learned some basic features of functional programming on frontend in practice. Nevertheless, these features are universal and frontend is not the only domain which can benefit from it. Having some basics though, we’re ready to study some further examples.
So, stay tuned. In the second part, we’ll focus on another four reasons to use functional programming on frontend. And on some other features that frontend can benefit from.
Wiktor is a huge fan of functional programming and React-Redux enthusiast, but he likes lesser-known technologies too. Being involved in frontend development doesn’t stop him from programming on backend. In free time, Wiktor reads books about human brain and consciousness.