Over the days of reading about Functional Programming, I was fortunate to understand part of it about its ideas. The purpose I went to learn about functional theory is to explain the writing of lodash/fp . And this seems to be the last in the series of functional programming articles in my JS. Hopefully, everyone has had a great time reading their posts.

Why should you write in a functional way?

Let’s start again with some examples to show why we should go towards functional. The first benefit is the transition from explicit to implicit.

Explicit

Here I want to calculate the area of ​​a square with an array of elements considered to be the length of one square edge.

With the above code, we had to explicitly define the steps that were needed to perform. From browsing through the elements of the array, to performing multiplication for each element, … By a normal thinking, when reading the above code, we can fully understand the purpose of the problem.

Implicit

We can completely use Array.map as follows:

In terms of brevity, you clearly notice when comparing the above two code snippets. This is fine, but we still need to call the numbers array manually. See the following paragraph?

I noticed that argument only change the location from map(array, function) to map(function, array) . One benefit of using fp is that the code is shorter, better able to test and maintain. In the next section we come across some of the more commonly referred terms such as ‘curried’ and ‘point-free’.

A delicious curry

Currying is a function that expects a given number of parameters to pass. In the case of fewer parameters passed, it will return a function with the purpose of waiting for the remaining arguments until the desired number and execution of the function. Only when it receives the desired parameters will the result be returned. In the normal case, if you provide all the necessary parameters for it at the same time, the function still works and returns the result.

The lodash / fp module promotes a more functional programming (FP) friendly style by exporting an instance of lodash with its methods wrapped to produce immutable auto-curried iteratee-first data-last methods.

The above paragraph I would like to get the whole doc in FP Guide .

With the above idea, we see why in the last squareAll example allows us to pass logic to the mapping first and then call it with an array after. We can write the following:

Compose yourself

The idea of composing (the flow function in lodash ) is to build a function from many smaller functions. Data is fed into one end and passed through the function until it finally produces the result. Each result of the previous function is the input of the next function.

In the above code we have created a convertEscape function from escape and trim . With this function, we pass the input parameter as an HTML string that will execute these two functions before giving us the final result.

Benefits of currying function

The functions in lodash/fp are auto-curried . So when you pass fewer parameters than expected, it returns a function. Let’s look at an example of flow :

In the above example, we use the two functions get and isEqual with the parameters passed. If these two functions are separated, there is nothing to care about much. But let’s see how that flow combine them. And the result of hasAllItems is a dòng chảy that results in the execution of both functions.

Point-free programming

Tacit programming, also called point-free style, is a programming paradigm in which function definitions do not identify the arguments (or “points”) on which they operate. Instead the definitions merely compose other functions, among which are combinators that manipulate the arguments.

Source: Wikipedia

We understand as above that the function definition does not define arguments but only combinations of operations with arguments.

See the following example:

But we can completely fix the following:

Point-free gives us a few advantages. It encourages us to write smaller, easier to test, and reusable functions in your application.

Conclude

The final article in the Functional Programming series is to introduce some examples of using lodash/fp . Although maybe my knowledge is still a bit thin, but I hope that there will not be too many mistakes when writing about FP in Javascript in the last articles. Thanks for watching. Hopefully next I can write about more useful knowledge.

Refer

https://github.com/lodash/lodash/wiki/FP-Guide https://en.wikipedia.org/wiki/Tacit_programming

A little stirring here

At this point, I found that I should finish the article . The series of dates I learned about Functional Programming made me realize many great things that it could do. If still with the old way of thinking, it might be okay, but knowing about FP makes me really happy. Learn about it just because of an annoyance when reading code to fix a bug. But the value of knowing about it is also somewhat less annoying (actually thanking the person who wrote the code in the project). :).