DEV Community: JM Santos

Why Code Review Might Be Something You Need

JM Santos — Sun, 28 Feb 2021 12:12:09 +0000

Code review doesn’t create perfect software but it allows you to create better software

How to Install Multiple Versions of the Same Package in NPM

JM Santos — Mon, 26 Oct 2020 07:19:39 +0000

Have you encountered when you are working on a project and you want to upgrade a dependency but you can’t do because you will have to migrate a lot of code?

Let’s say I have this as my package.json and I want to upgrade the package formik to the latest version. The latest version is standing at the version 2.2.0 which is a little bit far from our current version.

We want to upgrade formik to the latest version so we can take advantage of the new features and other new improvements.

But for some reason, we can’t just update it directly because our current version and the latest version contains some breaking changes. Yes, there is a migration step illustrated but we can’t just migrate all the places where it is being used due to time constraints and priorities.

And the fact that it takes a lot of hard work to make sure everything is working as expected. We don’t want to break existing parts just because we missed some migration steps.

Is it possible to install the latest version in isolation so it will not affect other parts of our code?

Would it be great if we can install multiple versions of formik and we can gradually migrate each part of our code instead of one big migration?

Yes oh yes. But before that, let’s make sure we are on the correct version of Node.js and NPM. Let’s get started with that!

📝 System Requirements

In order for us to successfully work with it, let’s make sure our NPM version is 6.9.0 or above because that is the version where it started supporting it based on the release notes.

$ npm -v

NPM comes with Node.js so you have to make sure your Node.js version is 10.16.0 based on the release notes.

$ node -v

You can use this Node package manager (nvm) to handle different versions of Node.js without installing the bundle.

To sum it up:

NPM version: 6.9.0 or above ✅

Node version: 10.16.0 or above ✅

⚙ ️Install Them All

Now that we already have the correct version, let’s see our command to execute.

The NPM command we are going to use is called package aliases and here is the command:

npm i <package_name_alias>@npm:<package_name>

Let’s replace those placeholders with our real values

npm i formik-latest@npm:formik

This will install the latest version available on NPM.

The latest version of formik is 2.2.0 but what if you want to get a specific version? Let’s say we want the version 2.0.0 exactly. Add the version like you normally do. An example of that would be like this:

npm i formik-latest@npm:formik@2.0.0

This is now how our package.json looks like after installing the latest version of formik.

The usage of that would be something like:

// file1.js

import { Formik } from 'formik';

Then if you want to use the latest one, just use the alias name in the import

// file2.js

import { Formik } from 'formik-latest';

I have created a codesandbox, however, it is not loading correctly not sure what’s wrong with that. But, locally it is working (you can copy the package.json above and install it). Codesandbox started supporting that as of late in May 2020. You can read it here https://github.com/codesandbox/codesandbox-client/pull/3730.

🤖 Bringing It All Together

Installing with alias is a great way to do especially if you have a legacy project which is one of the best use cases for it since you can upgrade the packages gradually.

You don’t have to worry about regressions or breaking other parts of the system easily.

You can try the latest version of your favorite library in isolation on your new task that you are working on without worries.

But on the other side, we shouldn’t do a lot of package aliases instead we should be responsible for migrating other parts little by little because it will pile up. And when it comes to the point you have a lot of package aliases, it might slow down the performance of installing your project (this can result in longer hours in the pipeline) and a bigger bundle of the application.

Did I miss something? Let me know in the comment section and let’s work on that.

Thank you for reading. I hope this will help you on your journey! ❤️

Patterns for Doing API Calls in ReactJS

JM Santos — Sun, 20 Sep 2020 14:10:54 +0000

Photo by Clint Adair on Unsplash

There are a lot of approaches we can make to do an API call in React. I will share what I’ve learned and discovered after dealing with different types of making an API call in React. This includes executions through hooks and without hooks.

I’m also here to try and rethink the approaches that we always have but we tend to forget because of the new things. How well do we know the fundamentals?

Without further ado, let’s get started!

👨‍💻 Designing our Hooks

Before we get started with the different patterns, let’s start designing how our hooks will look like and also discuss why it was structured that way. I will start by creating a specialized API hook to fetch a list of todos.

We structured our hook this way in order to be flexible in different scenarios. The different scenarios will be discussed as we go through the list. I want to say that there are still unknowns and this isn’t perfect, but this is progress.

I know you will be having a lot of questions, here are some I can answer right now on this section, and let’s see if you can get an answer as we go through. If you don’t get an answer, let’s discuss it in another section.

Why do we have two functions re-exported? One is the getTodos and another one is the useGetTodos

The reason we did that is to allow the consumer — the one who will be using our hook, to have the ability to execute the API in a “hook way” version or in a “non-hook way” version.

The idea here is that, to be able to reuse the same API core logic across the app. This is helpful when you are dealing with SSR with Next.js or Gatsby or also if you don’t need states into it.

Should the logic be avoided in the hook implementation?

As much as possible we should avoid some logic on the hook that may alter the behavior of the API call. Let’s say you add some data transformers. It’s better to add that in the non-hook version so that you have one place for it. In that way, we can add test coverage and all consumers regardless if using the hook and non-hook version will benefit from it.

What is the use of the return value from the hook if the execute method returns the data already?

There are scenarios where you need the data immediately on the handler function (i.e onSubmit handler) for extra processing instead of relying on useEffect. Both are important, but as much as possible if we can do it on the handler function, do it there instead of listening through the useEffect for changes and react to it.

If the process depends on each other like the 2nd API call needs the result of the 1st API call, it’s hard to “chain” those process together through useEffect.

Those are the questions I can answer now. I hope some of it gives you a better idea of it. Let’s get started now for the different patterns we will be learning together!

💡 API Call on Component Mount

Scenario: When the user hits the page, we want to hit an API call on the component mount.

Intentionally didn’t wrap the hook in useEffect because we want to let the consumer decides when to run and how to run. I think that is important to consider. With this approach, we always control the execution and it’s pure. When I say pure, it means we know when and how it is run without going through our hook implementation itself. Which means it is easy to track when it fires off.

Demo:

https://medium.com/media/87873c79a7799615f15191b12c8d77f6/href

💡 API Call on User Event (i.e. onClick, Form Submission)

Scenario: When the user submits the form, we want to do an API call to save the form.

https://medium.com/media/c04fb850afee92cc8c91450e4c922bf6/href https://medium.com/media/4afef3c2a7a316f7e979066e9bbaf0e8/href

The pattern for doing a POST API call is similar also with how we did the GET API call. They both have the hook and non-hook version exposed so that the consumer has the option to choose between the two on which is appropriate.

Also, the important thing on this hook implementation, if you will observe our execute method, it returns the data or it throws an error when there is. The return of data is important because there are scenarios where you need the response immediately instead of using a useEffect. You will see more about this when we go on running API calls in a serialized mode — where one response is needed to the next API call.

Demo:

https://medium.com/media/1e52ba8b8a690b4e95d03ece2840db4f/href

💡 API Call on Search Field (autocomplete, table search)

Scenario: When the user types on a search field, we want to do an API call using the value that the user entered.

https://medium.com/media/2c0052ddfb2f6c4c0b3f2ba788ee1d54/href https://medium.com/media/1e8d707498df22643060aee00572d6a8/href

Demo:

https://medium.com/media/3743b2d9636d9b53383002fed4d96d3b/href

💡 API Call on Paginate (with a limit)

Scenario: When the user selects a new page on the table, we want to do an API call to get the data on the selected page with the given limit. This can be applied also with other pagination options such as offset or sorting.

https://medium.com/media/b3eb220d2bec9d7def1143be619b5978/href https://medium.com/media/98252e84b195d37f50a759f08b27b94d/href

Demo:

https://medium.com/media/c8deb19f25ed84702b8728b547c628f3/href

💡 API Call on Serialize Requests (2nd API call based on the 1st API call)

Scenario: When the user submits the form, we want to do multiple API calls in a serialize mode to process the form values.

https://medium.com/media/47fc0fce81021870ef2f412a7f3d24d8/href

The alternative of this is using the useEffect pattern, but I think it is incorrect to do that when the request is coming from a user event. What do I mean with that? Let me show you how it will look like on useEffect .

https://medium.com/media/4632d6c4d32c3c5f2d71ef41f56952da/href

When we do the useEffect approach, we need to add an extra flag state to teach our useEffect how it will react intellectually because if not, it will run infinite times. The inconvenience also on this approach is the resetting of the state value which will probably be tedious as the app grows big.

Here’s another example:

https://medium.com/media/f3a5508d8b5af0e84c8ea2c39fdbe89b/href

It’s hard to track states, understand the flow or sequence and the error handling is hard. To handle errors using this approach, you have to listen to the error object on each hook and put it inside the useEffect. This is also prone to infinite re-render. Prone to multiple API requests if not handled correctly. One incorrect flag and then there you go sending multiple API requests.

You might ask, why did I just put everything in one hook? That’s a good question. That will actually work and that is much better than with all these useEffect . That approach is like putting a lot inside of things into a single plastic. We’re mixing a lot of things and putting a lot of responsibility to that hook. It will be hard to test it and make sure it is doing what it is supposed to do so. It’s hard to reason that. Another reason why I didn’t do that is I want the API hooks to be used interdependently with each other. For example, I want to use API hook A to this page but I don’t want to fire API hook B. It’s hard to do composition at a bigger level when all of those operations are inside a single hook.

Demo:

https://medium.com/media/4a67d83a3564ae917e6677f5d5aa4916/href

🤖 Bringing It All Together

There are a lot of use-cases I’m not yet aware of and so this list can’t provide all of the examples but I think this provides good progress and pattern on how you will work on your API calls on React.

If you will observe most of the examples, it doesn’t have a lot of useEffect implementations. The reason is, I did encounter a lot of infinite loops already, implemented a lot through it, and got to the point where I realized that there are other options out there. Other options that existed way before this comes up. That option was the non-hook approach. It’s always been there. But, we did substitute it with these new approaches.

I wonder if how many approaches can we solve with the basic approaches? I’m not saying one is good and one is bad. I don’t know a lot to say that one is good and one is bad. I’m trying to see if do I/we really have the right understanding of the fundamentals?

At the end of the day, this isn’t a silver bullet guide on how to perfectly do your API call on React but this will help you strategize or have another option on how to do it in another approach. Try it out and let me hear your experience with it!

Did I miss something? Comment down and let’s work on that!

Thank you for reading. I hope this will help you on your journey! ❤️

How Coding Helps Me In My Non-Tech Life

JM Santos — Wed, 16 Sep 2020 01:01:01 +0000

Photo by Markus Spiske on Unsplash

Programming or coding is both the same for me. Create an application through codes, solve problems through codes or anything code related. It boils down to code.

Sit in front of the computer for hours, you sleep, then you wake up and code again. Repeat it every day. That’s how other people see programmers, some geeks that have some tasks out of the Earth, and just code all day.

This afternoon, someone asked me, aren’t you tired of coding? Aren’t you getting burn out from doing it every day?

Did you ever have that kind of question where you had to stop for a minute and think? I stopped everything I’m doing at that moment and think. Those questions were great. Questions that will allow you to think and re-evaluate your current state.

I Get Tired And That’s Why I Love It

Am I not tired of coding? I code almost every day regardless of how many lines I wrote. I read articles about code too. I listen or watch videos on YouTube about code too. The people I have on my small circle also do coding. Basically, I am surrounded by codes!

Do I get tired from coding? Yes.

Yes, I do get tired of coding. There were a lot of times where I don’t want to code and just want to stay on the bed. There were also a lot of times where I wanted to take a shortcut just to make things work so I can rest already. There were also times where I started coding in the morning and end at midnight.

So yes, I get tired from coding and that’s why I love it. I love it deeply. Getting tired means that is the time where the real game begins. That’s is the time for me to up my game and be more ready for more battles. During this time, a lot of unknown will now come. A lot of weird codes will somehow produce an error out of nowhere. The challenge is to control the energy and avoid unnecessary arguments or frustrations.

I love coding even though it is making me tired and exhausted. On the other side of restlessness is the fulfillment and happiness I get out of it.

Code As The Bridge

Since the night I’ve felt and understood that my purpose is to help other people. I continued serving that purpose with everything I have. And so, I’ve pledged alliance with coding. I have promised that I will use coding as the bridge to help me serve my purpose.

I’ve recognized numerous times where through coding I’ve helped a lot of people on the tasks in front of them. I’ve also changed the lives of other people through the teaching of codes and many more.

Little did I know along with the process, code helped me to become a better person as well. It helped me to become more disciplined, to continue learning, and to continue persevering despite how many iterations is the task in front of me. Most importantly, it helped me with my mindset. It helped me improve it and push it to the next level.

I thought that code is the bridge for me to help other people. I didn’t know it will also be the bridge for me to help myself to continue getting better. A bridge for me to develop my best version. A bridge for me and to my purpose in life.

Bringing It All Together

Programming or coding has been a part of my life for many years. I’m grateful to discover this passion in me. I am not sure where it will bring me in the future but I am sure that it will help me serve my purpose in life. It will help me connect to different people across the world and have a positive effect on those people.

It is tiring and exhausting but it’s worth it. I have seen it affect the lives of the people in my life and all I can say that it’s worth it.

This also applies to anything you are doing passionately. Regardless of how tired or exhausted you are, you still want to do it over and over again. That’s love. Something that brings joy to the inner-self. Something that brings fire within. That’s passion.

“Working hard for something we hate is called stress. Working hard for something we love is called passion.”

But, on top of everything, I don’t want to be remembered as a programmer but someone who used programming as a way to connect with other people. Someone that able to reach out to other people across the ocean and provide value. The person who has a love for the game and be able to inspire others. The person who used programming to serve. I think that’s much better.

May you reach your dreams.

Transduction in JavaScript

JM Santos — Sun, 23 Aug 2020 09:18:16 +0000

Photo by Ross Sneddon on Unsplash

This is a continuation of the previous article I wrote titled, Fusion in JavaScript. Fusion is a technique of combining pure functions — taking advantage of composition and removing the intermediary copies of data on each layer. If you haven’t read about it, please do so! You can find it here.

📖 Introduction to Transduction

In applying the Fusion technique, you can only use it if all the functions have the same shape of arguments and the same shape of return. Here’s our example back there

You can see that our mapper functions have the same shape — both accept a number and they both return the same shape. A sum and a product.

That’s the Fusion technique. For us to “fuse” the functions or compose them, we have to follow a rule. A rule that in order for us to fuse or compose our functions they should have the same function shape. On our example, the add and multiplyBy2 both have the same shape and that’s why we were able to take advantage of composition.

But, what if there’s an additional requirement? Let’s say we need to filter our result by only getting the numbers below 10 and get the total of all the numbers?

Okay, I hear you. We will add Array.prototype.filter() to remove other items since we only need the items that are below 10 and an Array.prototype.reduce() to get the total of all the numbers. That’s actually correct!

But, this approach suffers also from the fact that on each chain layer, it will create a new copy of the data and iterate on each item again to apply the function.

Maybe you are now starting to wonder, is it possible to combine Array.prototype.map(), Array.prototype.filter() and Array.prototype.reduce() into a single call to avoid creating intermediary copies of data on each layer?

The answer is YES and that’s where Transduction will come! That is our goal, to put thoseArray.prototype.map(), Array.prototype.filter() and Array.prototype.reduce() into a single call.

🧬 Reduce Them All

Before we try to implement Transduction technique, it’s important to realize how this specific method that I’m going to tell you is powerful.

The Array.prototype.reduce() is a powerful function because it allows you to implement anything you would like. You can implement the logic of Array.prototype.filter() inside it, also the logic of Array.prototype.map() and so on!

Let’s see how we can implement our map and filter inside the reduce as we move forward.

I have removed the implementation of pipe for now to avoid extra confusion with the new functions created. There’s also some ground-breaking understanding of the flow of data when using thepipe or compose utilities which I’ll be discussing as we go on.

We’ve created mapReduce and filterReduce as curried functions because in functional programming it is inconvenient to have more than one argument because of composition. These helper functions allow us to use our functions inside Array.prototype.reduce() and make it “compatible” with the Array.prototype.reduce() signature. If you will observe the two functions, you can see that on the 2nd call of the function, it is expecting two inputs (accumulator, currentValue). That function signature is the signature from the Array.prototype.reduce() . We’ve curried the two functions because that allows us to partially create the function or in other words, lazy evaluation.

This is how it looks like without those two functions utilities in raw form.

If we can do it in this raw form, why did we implement some curried functions?

Look at those reductions (the functions inside the Array.prototype.reduce()) and you will see something in common.

Have you spotted it?

Yes, those accumulator.push and returning the accumulator declarations are called combiner functions. A combiner function is simply a function that combines the result. A combiner function is not limited to combining items to the list. In fact, it can combine anything! Here on our example, it is doing accumulator.push which sounded like a “concat” combiner. Let’s create a combiner function and name it combinerConcat .

Okay, that looks good… We’ve extracted our combiner function and that gives us a somehow generic combiner function on our Array.prototype.reduce() calls.

But, there’s a problem with this raw version and why it is important to switch to the curried functions. With this raw version, we will not be able to take advantage of composition and won’t allow us to reduce our calls into a single call operation.

Let’s tidy it up as this will also prepare us for the succeeding steps.

We haven’t reduced our calls into a single call. But, hang on there! We’re almost there! It will make sense later on why we need to curry it!

I want you to be aware of the result. It is 18 and that what we should be expecting throughout the end result.

📈 Going Above With Transduction

Transduction is a process of making Array.prototype.map(), Array.prototype.filter() and Array.prototype.reduce() to be compatible with each other regardless if they have different function shape.

Kyle Simpson on the frontend masters course said that Transduction is a way to use a mathematical process to reshape map and filter into reducers so that map, filter, and reduce can all be used in conjunction.

Transduction uses transducers to compose multiple reducers in order for those reducers to be composable with each other.

A transducer is a higher-order reducer or a composed reducer. A function that is composed of reducers, accepts a reducer, and returns a reducer.

Compared with normal reducers, they are not composable because their signature is different. They accept two inputs (accumulator, currentValue) and returns a single value. With transducer, it accepts a reducer and returns a reducer. And that makes the transducer valid for composition.

On our last example, we were able to convert those Array.prototype.map() and Array.prototype.filter() in a way of Array.prototype.reduce(). That’s actually great progress because we are now able to reshape it into a common signature. Which then, if functions have the same signature, it means we can take advantage of…? Guess what! Yes, Composition!

We haven’t reduced it into a single call and that’s what we are going to do now! Let’s try that one.

We’ve now removed the comments on our pipe and use it to create a transducer in line 37. We now know that a transducer is a higher-order reducer or a composed reducer.

We have two new things here. The first one is transducer which we will tackle shortly and the last one is the result. It is now 35 and not 18 . Remember when I told you to aware of that? We will address it after our transducer . Hang-on tight!

You might wonder about our transducer, why did we not have them combinerConcat on it?

The reason is that will break the signature of our reducers. Let me show you why it will break the signature of our reducers.

We can see that the transducer with a combiner will make the signature kinda like the normal reducers. It accepts two inputs (accumulator, currentValue). We also understand that normal reducers aren’t composable because of their signature are different compared with transducers.

Here’s our statement from the start of this topic:

Compared with normal reducers, they are not composable because their signature is different. They accept two inputs (accumulator, currentValue) and returns a single value. With transducer, it accepts a reducer and returns a reducer. And that makes the transducer valid for composition.

In order for our transducer to be valid for composition, the function shapes should be the same for all the functions.

That is why our transducer doesn’t have a combinerFn . I know that is hard to digest. Take your time. I still have a hard time wrapping my brain about it.

Let’s now get back with our result.

Why is it 35 and not 18? Our pipe’s flow looks the same with our initial implementation.

Do you remember why I commented out our pipe function awhile ago? The reason is that thepipe and compose behaves differently when applying in the transduction.

When we say it behaves differently, what do we mean by that? We understand that the execution ofpipe runs from left-to-right and compose runs from right-to-left.

We can see that compose executes those functions starting from the end (right) until to the start (left). It is running from right to left indeed.

We can also see that pipe executes those functions starting from the start (left) until to the end (right). It is running from left to right indeed.

Those rules are reversed when it is applied in transduction. I didn’t know this at first. I spent almost 2hrs figuring out why this is happening at midnight. I did a lot of research but something is not clicking. I can’t seem to understand what I am reading from different articles.

My last option is to contact Kyle Simpson on Twitter to shed some light on me.

// Detect dark theme var iframe = document.getElementById('tweet-1297240820861538306-425'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1297240820861538306&theme=dark" }

Shooting for the moon! After waking up, he indeed gave an answer and it starts clicking and making sense! So grateful!

This is what he said to my problem.

https://gist.github.com/jmaicaaan/7f217cf3f7d638596d7c503a4083f491

That is confusing at first but I re-read multiple times to start clicking. In addition to that answer, the reason why we are getting a different result is that we think that the “data” that is flowing through the pipe is the actual value — numbers from our list. But, that is incorrect.

A mental shift is needed.

The “data” that is flowing through the pipe is the “reducer” function and not the actual number from our array. It is actually our combinerFn.

With that one, let’s replace our pipe with compose as that would feel “natural” in the flow.

After changing that one, let’s update our transducer as well and see the result.

Hooray! Our result is now correct! Pat your back for sticking through it.

We’re almost there with our final step to complete this journey! We haven’t reduced our calls into a single call. We’ve now achieved to combine Array.prototype.map() and Array.prototype.filter() into a single call but there’s still one more step that we need to do.

Take a look closely on the combinerConcat and sum function.

What do you notice? They both have the same signature. They accept the same input signature and return the same value signature.

The sum function is also a combiner function! And knowing that it is a combiner function as well. We can now remove our combinerConcat and put the sum combiner function in that!

We’ve replaced the initial value from [] to 0 as well because our combiner function — combinerSum is dealing with summing numbers and not working with the collection/list.

We’ve now applied the Transduction technique and that should greatly help us in terms of performance and also provides readability and easier to reason out on our code.

🤖 Bringing It All Together

We’ve converted those Array.prototype.map() , Array.prototype.filter() , and Array.prototype.reduce() into a single call by making them compatible with each other. Making their function signatures be the same in order for us to take advantage of composition. That is the Transduction — the process of converting those functions into a compatible shape through transducers.

There are libraries such a Ramda.js and transducer-js that will you out implementing this and you don’t have to go through implementing this on your own. The goal of this article is to give us knowledge and understanding of how these things work, what problems it is solving, and how we can apply it to our code.

If you are interested in checking it out more, here are some references:

Functional-Light JavaScript course by Kyle Simpson (https://frontendmasters.com/courses/functional-javascript-v3/transduction)
Functional-Light JavaScript Github by Kyle Simpson (https://github.com/getify/Functional-Light-JS/blob/master/manuscript/apA.md/#appendix-a-transducing)
Transducers by Funfunfunction (https://www.youtube.com/watch?v=xcGbhU_DtRg)
Transducer composition reversal (http://isaaccambron.com/blog/2014/12/13/transducer-composition.html)

Thank you for reading. I hope this will help you on your journey! ❤️

Fusion in JavaScript

JM Santos — Sun, 26 Jul 2020 16:40:19 +0000

Nowadays it is extremely common to see the usage of Array methods such as Array.prototype.map(), Array.prototype.filter() and Array.prototype.reduce() to name a few in manipulating list data structures.

You can see a lot of method chaining such as a chain of Array.prototype.map() to process the transforming of a data, a chain of Array.prototype.filter() to include/exclude specific items in the array or a mixture of two (2) Array.prototype.map() and a Array.prototype.reduce() at the end. Those sorts of chainings are extremely common and that happens very often.

It's actually a great result having those sorts of chainings to manipulate data but there's a hidden cost on that in terms of performance and that's where the Fusion comes in.

⚡ Fuse 'em all

Fusion is a technique of combining pure functions — taking advantage of composition and removing the intermediary copies of data on each layer.

Let’s see an example comparing the non-fusion and a fusion approach.

I would like to start noting that a mapper function that is passed on to the Array.prototype.map() should always, at least, handle it process in a pure manner to avoid unexpected results. Avoid using it and accessing outside variables or mutating another variable outside its lexical scope. Make it pure.

With the given example, you would think it’s well written and easily understandable but what’s the big deal? What is the hidden cost of having a chain of Array.prototype.map()?

Let’s discover it together by unpacking this chain.

Are you surprised? I am too at first.

Each chain of method whether it is Array.prototype.map(), Array.prototype.filter() or Array.prototype.reduce() comes with a cost. It will result in iterating the whole list again and again which will affect the performance especially if we are talking about large datasets.

You might think why not join the two (2) mapper functions in one call of Array.prototype.map()?

Yes we can join them in a single mapper to avoid chaining of Array.prototype.map(). That is actually a semi-fusion approach already. A full fusion approach is taking advantage of the composition.

I have a question for you, isn’t it inconvenient to manually pass the result from one function to the next function? What if the order is changed? How can we make it better?

Let’s now see how we can make this thing better by applying the Fusion technique.

The pipe() utility accepts an infinite number of functions that it will run from left to right. Meaning that it will execute the functions, add() and multiplyBy2() from left to right and the result of the current function will be passed to the next one. That is kinda the shortcut instead of manually passing the result from one function to another function as we did on our previous example.

When a function is pure it means we can take advantage of composition. The composition is the act of combining pure functions to create a new single function. In our example, we created a new single function that is a composition of the two (2) pure mapper functions using the pipe() utility.

Now that we’ve applied the Fusion technique, our code will now handle even large datasets in a single iteration without duplicate iteration cost and also we’ve taken advantage of the composition in here which is great!

🤖 Bringing It All Together

Fusion is a great simple technique to have on our hands. It can help us when we are dealing with List data structures to take advantage of composition and also get the benefits in performance as well.

If we have a chain of maps together, composition is a much better way of declaratively saying what all of those steps are gonna be. Rather than three (3) .map calls, it would be preferrable from functional perspective to use composition. — Kyle Simpsons

If you are interested in checking it out more, here are some references:

Fusion Explained with Ramda.js (https://www.youtube.com/watch?v=l7cCwl9lIX0)
Functional-Light JavaScript course by Kyle Simpsons (https://frontendmasters.com/courses/functional-javascript-v3/fusion)
Functional-Light JavaScript Github by Kyle Simpsons (https://github.com/getify/Functional-Light-JS/blob/master/manuscript/ch9.md/#fusion)

Thank you for reading. I hope this will help you on your journey! ❤️