Martin Belev

7 tips for writing cleaner functions

Wed, 28 Jul 2021 00:00:00 GMT

Functions are one of the fundamental building blocks of our programs.

It's our responsibility as developers to keep them concise, easy to understand, and reason about.

Let's explore 7 language-agnostic tips that will help us to do so.

Link to this heading
1. Use descriptive and intent-revealing names for your functions

Don't be afraid to use long names as well. It's better than comments, abbreviations, etc.

Naming is not an easy thing to do and it's OK if it takes more time to think about how to name something!

I've written a separate post for naming which you can find useful as well.

Link to this heading
2. Functions should do only one thing and they should do it well

💡 If another function can be extracted with a name that is not merely a restatement of its implementation, it would mean that your function is doing too much.

Link to this heading
3. Avoid functions that depend on an external (hidden) state which if changed will result in a change of the function's behavior

You don't know when and where this external state can be changed. Therefore, you don't know what to expect from invoking your function.

1// ❌ Avoid
2// cartInformation is external state for the function.
3// External state can be changed from outside and can lead to hard to find bugs.
4
5const cartInformation = getCartInformation();
6
7const calculateTotalPrice = () => {
8  return cartInformation.items.reduce((acc, item) => item.price + acc, 0);
9};

Passing a variable as an argument to the function is a very simple, yet powerful solution in such situations to avoid external state usage.

1// ✅ Prefer
2// Pass it as argument and avoid external state.
3const calculateTotalPrice = (cartInformation) => {
4  return cartInformation.items.reduce((acc, item) => item.price + acc, 0);
5};

Link to this heading
4. Use pure functions whenever you can

Meaning given the same input, the function will always behave in the same way and return the same output.

Avoid mutating input arguments but use the returned value from your function.

1// ❌ Avoid
2const isAvailableForSale = (product) => {
3  product.availableForSale = product.numberOfItemsLeft > 0;
4};
5
6// Usage
7const product = getProduct('iPad Pro');
8isAvailableForSale(product);
9
10if (product.availableForSale) {
11  // do something
12}
13
14// ✅ Prefer
15const isAvailableForSale = (product) => product.numberOfItemsLeft > 0;
16
17// Usage
18const product = getProduct('iPad Pro');
19
20if (isAvailableForSale(product)) {
21  // do something
22}

Some of the benefits of using pure functions:

idempotent - produces the same output when called over and over with the same input
easier to understand and reason about
easier to test
easier for function composition

Link to this heading
5. Try to keep your functions with up to 2-3 arguments (ideally even less)

More arguments are making the function harder to understand and to test as well because of all of the different arguments' combinations.

Try to look for logical groupings of arguments and combine them in an object/class and then pass them as a single argument to the function.

This is a way to try and reduce the number of arguments that a function needs instead of passing separately each argument.

Configuration options can be a good example.

We start by adding just one argument to configure something, then another is introduced, etc. but some of them can be skipped.

1// ❌ From
2// true, null, false, 42, 'config' - doesn't make sense until we go and read the function itself.
3someFunc(true, null, false, 42, 'config');
4
5// ✅ To
6// By grouping the arguments in a config object, we will get better naming and readability as well and we will know what "true" means, etc.
7someFunc(config);

It also helps for:

consistency - as all functions will use the same new data structure
explicit argument relationship

Link to this heading
6. Avoid mixing different levels of abstraction in functions

If we do so, it's easier to spread around even more (like the broken windows theory) and most probably means that we have violated the single responsibility principle.

Link to this heading
7. Avoid having object state changes and retrieving information about the object in the same function

✅ Prefer separate functions - one doing state change, another one answering a question about the object.

Mixing the two can create confusion and ambiguity.

Link to this heading
Conclusion

What we've covered:

Use descriptive and intent-revealing names for your functions
Functions should do only one thing and they should do it well
Avoid functions that depend on an external (hidden) state which if changed will result in a change in the function's behavior
Use pure functions whenever you can
Try to keep your functions with up to 2-3 arguments (ideally even less)
Avoid mixing different levels of abstraction in functions
Avoid having object state changes and retrieving information about the object in the same function

As one of the fundamental building blocks in our software, it's essential to have and keep our functions as clean as possible.

6 tips to improve naming and why it is so important

Sat, 24 Jul 2021 00:00:00 GMT

How would you feel when someone calls you a bad name?

Choosing bad names for our variables, functions, etc. can relate to the feeling 👆.

Let's explore 6 things that can help to improve our naming and why it is so important.

Link to this heading
1. Intention revealing names

The chosen name should answer the following questions:

why it exists?
what does it do?
how it's used?

Don't be afraid to use long names as well. It's better than comments, abbreviations, etc.

For example:

1// ❌
2// responsible for deciding if verification modal will be displayed in days
3const seven = 7;
4
5// ✅
6const verificationVisibilityThresholdInDays = 7;

Link to this heading
2. Prefer explicit over implicit names

🔴 Implicit names assume we have additional knowledge to understand it - e.g. know the answers of the intent revealing names.

🟢 By using explicit names this should be understood from the name itself.

Implicit example:

1// Very simple code but hard to understand because of it's implicit nature.
2// The code requires us to know additional details in order to understand it.
3const filter = (list) => {
4  return list.filter((item) => item.value === 'A' || item.value === 'K');
5};

Explicit example:

1const aceValue = 'A';
2const kingValue = 'K';
3const twoHighestValueCards = [aceValue, kingValue];
4
5const filterTwoHighestValueCards = (cards) => {
6  return cards.filter((card) => twoHighestValueCards.includes(card.value));
7};

Link to this heading
3. Distinguish variable names

avoid using conflicting information - e.g. don't name a variable list if it's not a list
avoid numbering - e.g. var1, var2, etc.
avoid adding noise words that are not providing any value - e.g. theUser, ageNumber.

Link to this heading
4. Pronounancable names (avoid using abbreviations)

If we think about the association between literature and code, we should be able to read easily our code.

We can't do this if we are not able to pronounce the names that we are using in our code.

Link to this heading
5. Use developer aware language when possible

There are a lot of terms that almost all developers know. It's a common language between use.

Try to use them when you choose your naming - take for example design patterns.

Using a domain term can be a fallback option.

Caveat - there are cases where it makes sense to use an abbreviation (e.g. if it's a known term for developers).

For example:

❌ Uniform Resource Locator/Identifier

✅ URL/ID

Link to this heading
6. Keep the naming consistent

Avoid using the same wording for different things. This can be confusing and make other developers wondering what's the difference between them.

Instead, try to come up with 1-1 mappings for your concepts.

For example - if you are calling something a "service" or a "controller" or whatever, make sure that all other things that are named like that are referring to the same thing.

You would more easily create a common developer language in the project which is important.

Link to this heading
Why naming is so important?

It's almost certain that we are spending more time reading other people's code than writing code.

We are losing a lot of time in wondering what a variable does when it's "encrypted" and doesn't have an intent-revealing name.

If the lost time is not enough, getting the wrong understanding of what the variable is doing could do more harm.

Chances for introducing a bug are increasing a lot which is 🚩.

We can not completely protect ourselves from bugs but at least we can try to reduce the chance.

The cost for maintenance of the project and adding new features is 📈.

The cost is very high because our software becomes hard to understand and it's slowly becoming unmaintainable.

Adding even a small new feature can take days/weeks.

At the end of the day, the most important thing is to produce value for our customers.

And by having unreadable and hard to understand and maintain code, there is no chance for doing this with confidence, in an effective and timely manner.

Link to this heading
Conclusion

Naming is hard, it requires really good descriptive skills, it takes a lot of time to get good at but it's worth it and will pay off.

Other devs will appreciate your efforts for sure, as well as you will theirs.

This is not a complete list but just a few points to think about.

Hopefully, you're convinced of the importance of naming and its huge role in programming and can help to come up with better names by spending more time on it.

How to find an old introduced bug using Git - git bisect introduction?

Sat, 08 May 2021 00:00:00 GMT

Want to find a bug that was introduced some time ago?

We can use binary search using Git to find the culprit.

How?

The answer is - git bisect.

Let's dive into an introduction and see how we can use it.

Link to this heading
Where to start from?

You've seen something is broken with the latest changes on your development branch and want to find to the problem.

First, you need to find an old commit where everything was working as expected.

Then proceed with executing the following command:

1git bisect start

Link to this heading
Bad commit

Almost nothing is being done at this point.

Now you need to tell Git which is the bad commit. Most probably just going to be HEAD/latest commit.

Execute the following command:

1git bisect bad HEAD

You could use commit hash as well.

Link to this heading
Good commit

Then comes the part where we need to tell Git which is the good commit where everything was working fine.

Execute the following command:

1git bisect good <commit-hash>

Link to this heading
Bisect has been started

Awesome - you've started the bisecting now and should see something similar to:

1Bisecting: 157 revisions left to test after this (roughly 7 steps)
2[<commit-hash>] <commit-message>

You are now moved to a commit somewhere in the middle between the bad and good commit.

Link to this heading
What information is Git giving us?

157 revisions - showing the number of commits between the bad and the good commit.

roughly 7 steps - showing you how many steps you will need until the end.

[<commit-hash>] <commit-message> - showing at which commit you are currently at.

Link to this heading
Proceeding further

Test the commit and based on the result proceed further.

If the problem is not gone execute - git bisect bad
If it's working execute - git bisect good

You will be moved to the next commit for testing.

Repeat the process until there are no more steps and commits to check.

In the end, Git will output the first bad commit where the problem was introduced.

Link to this heading
Conclusion

Hopefully, it was useful and you have a new tool in your arsenal now to tackle a problem using Git 💪.

Waving hand animation using pure CSS

Sat, 06 Feb 2021 00:00:00 GMT

We are going to see how to build the following emoji waving hand animation below 👇.

See the Pen Waving hand by Martin Belev (@mbelev) on CodePen.

Link to this heading
Talk is cheap, show me the code

1<div>Hey there <span class="waving-hand">👋</span></div>

1@keyframes wave {
2  0% {
3    transform: rotate(0deg);
4  }
5  10% {
6    transform: rotate(16deg);
7  }
8  20% {
9    transform: rotate(-6deg);
10  }
11  30% {
12    transform: rotate(16deg);
13  }
14  40% {
15    transform: rotate(-4deg);
16  }
17  50% {
18    transform: rotate(16deg);
19  }
20  60% {
21    transform: rotate(0deg);
22  }
23  100% {
24    transform: rotate(0deg);
25  }
26}
27
28.waving-hand {
29  animation: wave 2.1s 0.6s infinite;
30  transform-origin: 75% 75%;
31  display: inline-block;
32}

This is the whole CSS that is needed to achieve the emoji waving hand animation.

Link to this heading
Explanation

Keyframes animation rotating the hand with different degrees.
- Using -6deg, -4deg and 0deg was to provide a little bouncing effect
- 60% { transform: rotate(0.0deg) } - to prevent animating slowly from 16deg to 0deg.
For more information about keyframes click here.
transform-origin to change the transformation position to the end of the palm.
For more information about transform-origin click here.
There is also a great CodePen created by Stephen Shaw visualizing where is the transform origin position when it is changed. You can check it out here.

Link to this heading
Conclusion

I am not very good at animations but I tried to make it more natural like a real hand wave which I could have failed at 🙈 You can play around and change the values to see how it's going to look like. It's not something too fancy but it's a good tiny detail to add IMO.

How to configure Git with multiple emails?

Mon, 23 Nov 2020 00:00:00 GMT

Most probably, everyone went through the simplest form of Git setup when we started using it. What I mean is configuring our username and email that is going to be used with Git. E.g. git config --global user.email "<your-email-address>" which will add a line into our .gitconfig file and it will be used throughout all of our Git repositories.

This is perfect when we haven't started a job yet but when we do, it's almost certain that the company will require from us to use our company email for company projects. However, it makes perfect sense that we would like to use our personal email for personal projects. Today we are going to see how we can achieve this and do it only once without the need of repeating the process.

Link to this heading
Simple .gitconfig setup

.gitconfig

1[user]
2  name = Martin Belev
3  email = <your-personal-email>

By using the ☝️ config, we are going to use the same username and email in every one of our Git repositories. We will need to make a change which will use one email or another based on some condition. Not as a surprise I guess, there is such functionality in Git and it's called conditional includes.

Link to this heading
Multiple emails .gitconfig setup

We are going to use conditional includes which is providing us with a way to include another config based on a certain condition.

.gitconfig

1[includeIf "gitdir:~/personal-work/"]
2  path = .gitconfig-personal
3[includeIf "gitdir:~/work/"]
4  path = .gitconfig-work
5
6[user]
7  name = Martin Belev

I like to keep things organized and keep my personal projects inside personal-work directory and my company work-related projects inside work directory. gitdir is a keyword which is used to match the location of the .git directory to the provided glob pattern. If so, the include condition will be true.

The content in the two additional config files is simply the email Git config:

.gitconfig-personal

1[user]
2  email = <your-personal-email>

.gitconfig-work

1[user]
2  email = <your-company-email>

If you would like to use your personal email always except for the cases with your work-related projects then you can leave the personal email in the .gitconfig and include the additional configuration for your work-related email at the end of the file.

.gitconfig

1[user]
2  name = Martin Belev
3  email = <your-personal-email>
4
5...
6
7[includeIf "gitdir:~/work/"]
8  path = .gitconfig-work

I am keeping the files at the root level to have them side by side, but this is not mandatory. If you think it's better structured to put the additional config somewhere else, it doesn't really matter and it should be working.

Link to this heading
Bonus

As a small bonus, I would like to share my current .gitconfig that I am using.

1[includeIf "gitdir:~/personal-work/"]
2  path = .gitconfig-personal
3[includeIf "gitdir:~/work/"]
4  path = .gitconfig-work
5
6[user]
7  name = Martin Belev
8[push]
9    default = simple
10[core]
11    editor = vim
12    excludesfile = /Users/belevmar/.gitignore_global
13    ignorecase = false
14[alias]
15    df = diff
16    st = status
17    co = commit
18    p = push
19    ch = checkout
20    chb = checkout -b
21    br = branch
22    dlb = branch -d
23    dlbh = branch -D
24    drb = push origin --delete
25    lg = log --graph --branches --remotes --pretty=format:'%C(red)%h%Creset -%C(yellow)%d%Creset %s %C(green)(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
26    pu = pull
27    pur = pull --rebase
28    puru = pull upstream master --rebase
29[credential]
30    helper = cache
31[rerere]
32    enabled = true
33[pull]
34    rebase = true

Link to this heading
Conclusion

We have seen how to configure Git to use 2 emails based on the location of the .git folder by loading additional configuration files using the feature of Git called conditional includes. If you saw something new that you don't know about in my .gitconfig file, I am more than happy to share more information about it, so don't be shy and reach out to me 🙃.

How to keep cleaner React components with object map?

Sun, 26 Jul 2020 00:00:00 GMT

We will see one way to refactor our React components by replacing conditionals with object map. This is a favorite refactoring of mine because it makes the components easier to understand and extend, groups the logic in a single place, and requires fewer lines of code.

Link to this heading
Simple conditionals example

A lot of times based on some input we want to display different information to our users. Let's see an example which should make things clearer:

1import React from 'react';
2
3interface Props {
4  errorField: 'name' | 'email' | 'password' | 'date';
5}
6
7const ErrorMessageWithSwitch: React.FC<Props> = ({ errorField }) => {
8  switch (errorField) {
9    case 'name':
10      return <div>Please enter valid name.</div>;
11    case 'email':
12      return <div>Please enter valid email address.</div>;
13    case 'password':
14      return <div>Please enter valid password.</div>;
15    case 'date':
16      return <div>Please enter valid date of birth.</div>;
17    default:
18      return <div>Invalid field.</div>;
19  }
20};
21
22const ErrorMessageWithIf: React.FC<Props> = ({ errorField }) => {
23  if (errorField === 'name') {
24    return <div>Please enter valid name.</div>;
25  }
26
27  if (errorField === 'email') {
28    return <div>Please enter valid email address.</div>;
29  }
30
31  if (errorField === 'password') {
32    return <div>Please enter valid password.</div>;
33  }
34
35  if (errorField === 'date') {
36    return <div>Please enter valid date of birth.</div>;
37  }
38
39  return <div>Invalid field.</div>;
40};

We have a component that should show the appropriate message for a certain errorField. It is a very simple one but by reading it we got some unpleasant feeling. A lot of writing and syntax which is making the code noisy and takes more time to go through. Not to speak about the fact that some tiny details can be missed as well.

By having a deeper look at the code, we can see that after all this is a simple mapping between one value to another. Doesn't this seem like a key/value structure? Here comes the object map, so let's see the refactored example:

1import React from 'react';
2
3interface Props {
4  errorField: 'name' | 'email' | 'password' | 'date';
5}
6
7const errorFields = {
8  name: 'Please enter valid name.',
9  email: 'Please enter valid email address.',
10  password: 'Please enter valid password.',
11  date: 'Please enter valid date of birth.',
12  default: 'Invalid field.'
13};
14
15const ErrorMessage: React.FC<Props> = ({ errorField }) => {
16  const message = errorFields[errorField] || errorFields.default;
17  return <div>{message}</div>;
18};

Such simple examples are easier to identify and start using object instead of if/switch. However, this kind of refactoring/technique is pretty powerful for a lot more complex cases where the benefits are bigger.

Link to this heading
More complex example

Let's say we have a button component for connecting our account with Twitter.

1import React from "react";
2
3const ConnectTwitterButton: React.FC = () => {
4  const handleClick = () => {
5    // Connect Twitter
6  };
7
8  return (
9    <button onClick={handleClick}>
10      Connect with <TwitterIcon> Twitter
11    </button>
12  );
13};
14
15export default ConnectTwitterButton;

This is great, but now imagine we need to extend the current button's functionality to connect with more providers like Twitch/Facebook/.etc and we end up with something like:

1import React from 'react';
2
3interface Props {
4  providerType: 'twitter' | 'twitch' | 'fb';
5}
6
7const ConnectAccountButton: React.FC<Props> = ({ providerType }) => {
8  const getProviderName = () => {
9    switch (providerType) {
10      case 'twitter':
11        return 'Twitter';
12      case 'twitch':
13        return 'Twitch';
14      case 'fb':
15        return 'Facebook';
16      default:
17        return 'Unknown';
18    }
19  };
20  const getProviderIcon = () => {
21    // return SVG icon
22  };
23  const providerName = getProviderName();
24  const icon = getProviderIcon();
25
26  const connectWithTwitter = () => {
27    // Connect Twitter
28  };
29  const connectWithTwitch = () => {
30    // Connect Twitch
31  };
32  const connectWithFacebook = () => {
33    // Connect Facebook
34  };
35  const handleClick = () => {
36    if (providerType === 'twitter') {
37      return connectWithTwitter();
38    }
39    if (providerType === 'twitch') {
40      return connectWithTwitch();
41    }
42    if (providerType === 'fb') {
43      return connectWithFacebook();
44    }
45  };
46
47  return (
48    <button onClick={handleClick}>
49      Connect with {icon} {providerName}
50    </button>
51  );
52};
53
54export default ConnectAccountButton;

We have a couple of things per provider - name, icon and connect function. So what we can do about it?

1import React from 'react';
2
3type ProviderType = 'twitter' | 'twitch' | 'fb';
4
5interface Props {
6  providerType: ProviderType;
7}
8
9interface Provider {
10  icon: React.ReactNode;
11  name: string;
12  connect: () => void;
13}
14
15const providers: { [key in ProviderType]: Provider } = {
16  twitter: {
17    icon: <TwitterIcon />,
18    name: 'Twitter',
19    connect: connectWithTwitter
20  },
21  twitch: {
22    icon: <TwitchIcon />,
23    name: 'Twitch',
24    connect: connectWithTwitch
25  },
26  fb: {
27    icon: <FacebookIcon />,
28    name: 'Facebook',
29    connect: connectWithFacebook
30  }
31};
32
33const ConnectAccountButton: React.FC<Props> = ({ providerType }) => {
34  const { icon, name, connect } = providers[providerType];
35
36  return (
37    <button onClick={() => connect()}>
38      Connect with {icon} {name}
39    </button>
40  );
41};
42
43export default ConnectAccountButton;

The important part is the refactoring itself which is highlighted - line 15 to line 41. Now we look at our component it is very easy to understand what is happening and we have the logic centralized in a simple object.

Maybe it would be a bit harder to identify similar cases if you haven't done similar refactoring but ones you have done a couple it becomes easier and more obvious.

Link to this heading
Bonus round using array

This one can be helpful with array usage as well. I think the most common example would be a navigation menu where the items are displayed based on some conditions - feature flags, simple checks based on the user data, .etc.

1const navigationItems = [
2  {
3    path: 'Nav 1',
4    visible: () => {
5      // Some visibility logic
6    }
7  },
8  {
9    path: 'Nav 2',
10    visible: () => {
11      // Some visibility logic
12    }
13  }
14];
15
16// Then we can simply use filter and map to construct our navigation
17navigationItems.filter((item) => item.visible()).map((item) => /* The mapped item */ item.path);

Link to this heading
Conclusion

We saw a simple and a more complex example of how we can use object map and avoid using conditionals. Hopefully, the code looks much cleaner and easier to understand and extend for everyone.

A pattern can be noticed for cases where we can apply the object map usage - when we have data that is mapped to other data or behavior.

This is a refactoring that is not related specifically to React and JavaScript/TypeScript. It can be used in other languages as well when you see fit.

Of course, this is not a silver bullet and not every if/switch statements can be converted to such configuration object.

How to use pattern matching in JavaScript - an alternative?

Sun, 19 Jul 2020 00:00:00 GMT

We are going to quickly see what is pattern matching, see basic examples of it in Scala and make an analogy with one less known usage of JavaScript switch statement.

There is no native support for pattern matching in JavaScript. However, there is an open proposal which is great and it would be nice to have support and use it in the future if it gets approved and goes through all of the stages.

Note: this isn't a tutorial about Scala pattern matching and the given examples will be simple ones without going into details.

Let's get started!

Link to this heading
What is pattern matching?

It is a mechanism for checking/testing a value against a given pattern. The match should be exact. The logic for the first pattern that matches the value is executed. The patterns can vary and the functional programming languages support a variety of different usages.

Based on the Scala docs:

It is a more powerful version of the switch statement in Java and it can likewise be used in place of a series of if/else statements.

They are far more powerful than the usual switch statement. We will see how we can make an analogy with JavaScript switch statement though and use it in a way that gives us more control to write complicated expressions.

Link to this heading
Scala pattern matching examples

One of the simplest cases is match by value:

1def getMonthName(month: Int): String = month match {
2  case 1 => "January"
3  case 2 => "February"
4  // .etc
5  case _ => "Unknown"
6}
7getMonthName(13)  // Unknown
8getMonthName(1)  // January

JavaScript version:

1const getMonthName = (month) => {
2  switch (month) {
3    case 1:
4      return 'January';
5    case 2:
6      return 'February';
7    // .etc
8    default:
9      return 'Unknown';
10  }
11};
12
13getMonthName(13); // Unknown
14getMonthName(1); // January

We can have matching on type:

1abstract class Device
2case class Phone(model: String) extends Device {
3  def screenOff = "Turning screen off"
4}
5case class Computer(model: String) extends Device {
6  def screenSaverOn = "Turning screen saver on..."
7}
8
9def goIdle(device: Device) = device match {
10  case p: Phone => p.screenOff
11  case c: Computer => c.screenSaverOn
12}

There are a lot of other different usages of pattern matching that Scala supports but this is not the focus of this blog post. If you are interested in seeing them you can check out pattern matching and match expressions.

Link to this heading
JavaScript switch statement quick overview

From my experience in almost all of the places I have worked, switch is used in its traditional form as switch (someValue) and then case statements with simple numbers or strings.

Let's see an example from MDN docs:

1const value = 'Papayas';
2switch (value) {
3  case 'Oranges':
4    console.log('Oranges are $0.59 a pound.');
5    break;
6  case 'Mangoes':
7  case 'Papayas':
8    console.log('Mangoes and papayas are $2.79 a pound.');
9    // expected output: "Mangoes and papayas are $2.79 a pound."
10    break;
11  default:
12    console.log(`Sorry, we are out of ${value}.`);
13}

This is great but it feels like we are limited to simple values only. What if we want to add additional conditions or we want to use more complex data structures like lists, dictionaries, .etc?

Link to this heading
One less known usage of switch statement in JavaScript

If we try to formulate a question of what we want to do, it would be - what should we do if we want to write whatever expressions we want in the case statements and if one is true execute some logic?

By asking the question we have already answered it by if some of them is true. We can pass true as value for our switch statement and then the logic for the first case expression that evaluates to true will be executed.

Let's take a look at an example:

1const getCompactAmount = (amount) => {
2  switch (true) {
3    case amount / 1000000 >= 1:
4      return `${amount / 1000000}M`;
5    case amount / 1000 >= 1:
6      return `${amount / 1000}K`;
7    default:
8      return amount;
9  }
10};
11
12getCompactAmount(2000000); // 2M
13getCompactAmount(5000); // 5K
14getCompactAmount(123); // 123

We want to match our expressions to true which gives us the power to write whatever expressions we would like with whatever complicated conditions we need.

Link to this heading
Conclusion

This, of course, can be achieved by using if/else if/else statements and I guess it is a matter of preference what to use. I am not saying that this should be always used but it gives some nice opportunities and I think is a less known usage which I haven't seen much. As someone who isn't a big fan of switch statements and tried to avoid using them, I would say that after I have used switch (true) for a while I am more than happy with it. I find it much easier to read than multiple if/else if statements and less error-prone.

How to effectively use git rebase --onto?

Sat, 20 Jun 2020 00:00:00 GMT

We are going to get a step further and explore the git rebase --onto command. What is it, how to use it to fix Git branches after rebase, how to change a branch's base, and a bit more? We will learn those things by exploring real-world scenarios in which git rebase --onto is really useful.

Let's get started!

Link to this heading
Quick `git rebase` recap

Visiting the docs, we will see the following explanation:

Reapply commits on top of another base tip

The most important bit here is what base means/refers to? This is the previous/parent commit. Let's see an example so that it can become clearer:

a--b--c--d--e  master
       \
        f--g--h  feature

h's previous commit is g. This means that h's base is g.

g's base is f
f's base is c
d's base is c as well. This shows us that one commit can be the base of multiple commits.

The current feature's base is c. By checking out the feature branch and executing git rebase master, we are going to change the feature branch's base to e.

a--b--c--d--e  master
             \
              f'--g'--h'  feature

Mentioned in a previous blog post this is creating new commits and the Git history is changed. With the ' after f, g, h we are showing that those are different commits. They contain the same set of changes though.

When we have only two branches which we want to keep in sync one on top of the other, git rebase is working perfectly. However, this is not enough when we need to make our changes based on the old base. Here git rebase --onto comes in help.

Link to this heading
What is `git rebase --onto`?

We can say that this is a more precise way of changing a parent branch. It accepts three arguments - <new-base>, <old-base>, <end-inclusive> where the third one is optional. This gives us complete control over what and where we want to rebase.

Let's take the previous example and achieve the same result using --onto.

a--b--c--d--e  master
       \
        f--g--h  feature

We want feature to be rebased off of master. So we know what our new base is, it is master. The old base is the base of our first commit in the branch which means it is going to be c. Now we know both the new and old base, and we can run the command: git rebase --onto master c.

This will lead us to:

a--b--c--d--e  master
             \
              f'--g'--h'  feature

The result is the same as using git rebase master. This shows us that they are doing the same thing. git rebase master is just a shorthand syntax for git rebase --onto master <old-base>.

Link to this heading
How to rebase with skipping not needed commits?

We have already seen the easiest case of using --onto. Let's take the previous example again but say that we don't want commit f to be present after the rebase because it is not relevant anymore.

a--b--c--d--e  master
       \
        f--g--h  feature

Running git rebase --onto master f gives us:

a--b--c--d--e  master
             \
              g--h  feature

Be careful with the value provided for <old-base>. It is a common mistake to think that it is inclusive.

It is important to remember/understand that we are working with bases, not a certain commit. g's base is f so when we say <old-base> is f this is going to be changed by the provided <new-base> and we are going to loose commit f this way.

Link to this heading
How to fix branch from a branch after rebase

Working with multiple people or in a large codebase, it is almost certain that at some point you will need to create a branch from a branch. For example, you need to start a new feature but it depends on another one so you need to start your branch from your previous branch. Or you have automation QAs which are creating a branch from your feature branch.

Let's see a visual representation of the problem:

a--b--c--d--e  master
       \
        f--g--h  feature-1
               \
                i--j--k--l  feature-2

Being in this situation, you would like to move the entire tree to be based on master. Meaning feature-1 is going to be rebased on top of master and feature-2 on top of feature-1.

Let's checkout feature-1 and run git rebase master. This will lead to:

a--b--c--d--e  master
      |      \
      |       f'--g'--h'  feature-1
       \
        f--g--h--i--j--k--l  feature-2

If you have opened PR from feature-2 to feature-1 branch, you are going to see the commits from feature-1 in your PR. There is no need to worry because as we can see from the visual representation above and the image below this is expected.

We can now checkout feature-2 and run git rebase --onto h' h. This gives us:

a--b--c--d--e  master
             \
              f'--g'--h'  feature-1
                       \
                        i'--j'--k'--l'  feature-2

Keep in mind that sometimes simple git rebase feature-1 is going to work if f/g/h is the same as f'/g'/h'. Git is smart enough and when we use rebase, it is going to/can remove the commits that are with the same set of changes. However, it is hard and annoying to check if everything is the same in another branch, and using --onto is the better option here because otherwise, it can lead to a branch with commits that don't belong in it.

You should give --onto a try. However, if you are not feeling ready or you don't want to use it and end up in the described situation above, there is a solution with an interactive rebase. Rebase feature-2 from feature-1. Check if there are commits that don't belong in the branch and drop those commits by doing an interactive rebase. If you are not familiar with how to do that, have a look at the previous blog post Some of the most used Git interactive rebase options.

This was a problem that we had for a few months. People were surprised by the changes that they have been seeing in open PRs. After all, you are not doing anything and all of a sudden you see some commits in your PR which don't belong there. It seems strange but hopefully, with this article, this will be cleared out and it won't be strange anymore.

Link to this heading
How to change Git branch's base?

From time to time we need to change the base of a branch. Two examples would be:

we haven't started our branch from the right branch
we started working on something from master but a colleague made some changes in his/her branch that are going to make our life easier. Then maybe we would like to change master as a base and use the colleague's branch changes.

Let's have a visual representation for a better understanding:

a--b--c--d--e  master
             \
              f--g  feature-1
                  \
                   h--i  feature-2

We started our branch feature-2 from feature-1 but we did that by mistake. The features turned out to be not connected at all and we would like our feature-2 branch to start from master.

It is not a surprise that we are going to use --onto. So we have git rebase --onto <new-base> <old-base>. Our old base is feature-1, we started our branch from there. Our new base should be master because we want our branch to start from it. We are going to execute git rebase --onto master feature-1.

This gives us:

a--b--c--d--e  master
            | \
            |  f--g  feature-1
             \
              h--i  feature-2

We are using Git flow at work and changing the base of a branch comes up from time to. In our case, it is mostly when the hotfix branch is not created from the proper branch. For example, the hotfix branch is opened, but we started our branch with a fix from the release branch. Then we would need to change the base from release to hotfix.

Link to this heading
How to use the third argument of `git rebase --onto`?

git rebase --onto takes up a third argument which is used as an end stop inclusive.

Let's have the following example:

a--b--c--d--e  master
       \
        f--g--h--i--j--k--l  feature

We want to rebase feature from master but take only certain commits - from h to j. We have seen how to skip redundant commits by using --onto. If we only want to do that, we would need to execute git rebase --onto master g.

Now we want a specific commit for the last one. The third argument of --onto is exactly what we want. So we would need only to say which is the last commit.

Note: it is taken inclusively.

Run git rebase --onto master g j and this gives us:

a--b--c--d--e  master
       \
        h--i--j  feature

Link to this heading
Conclusion

We dived deeper into git rebase --onto. It is one of the more advanced commands with which we can easily solve certain Git problems with our branches. Even if we don't know about it, we can solve our problems with a combination of commands - normal and interactive rebase, cherry-pick, .etc. As developers, we should try to automate our work as most as possible, so using less number of commands is a sufficient condition to learn about --onto.

We covered a lot of things so let's quickly summarize:

A quick recap about git rebase, what it base and what does rebase do
What does git rebase --onto give us by using it
How to use --onto to rebase a branch and skip not needed commits
How to fix our branches after rebase when we have a deeper branch structure - branch from a branch from a branch
How to change Git branch's base and why would it be useful
Use the complete form of git rebase --onto with 3 arguments which allows us to take only certain commits from start to end provided

Some of the most used Git interactive rebase options

Sat, 13 Jun 2020 00:00:00 GMT

In the previous blog post Git merge vs rebase to keep feature branch up to date we learn about the differences between merge and rebase. If you aren't very familiar with the basics of those commands and haven't read it yet, it is a good idea to do so before diving into this one.

The idea of this blog post is to show with examples some of the most used options of git rebase command. In my experience, I observed that this is one of the most misunderstood commands, especially for less experienced Git users. Hopefully, this article will provide useful information and things are going to be clearer after you read it. We will go through the following things:

amend the last commit
interactive rebase
squash several commits into a single commit
fix older commit
reorder commits

Mastering interactive git rebase is a good thing because it enables us to keep a clean and linear history of our changes. This is a great benefit especially when a regression has to be discovered. It is making the work of other people more pleasant as well by quicker and easier orientation.

Before we begin, we should know that all of the examples which we are going to explore from now on are changing Git history. So, please, if you are working on a public branch be extremely careful with it.

In general, we shouldn't change history for public branches like master/develop.

Let's get started now.

Link to this heading
Amend the last commit

The provided examples will be with simple text files but they are completely valid in real-life scenarios. Let's start by creating and committing a file with a typo in it.

echo "Helo world." > ./hello-world.txt
git add hello-world.txt
git commit -m "Add hello world"

git commit --amend is the command which we are going to use. It is a convenient way to change the latest commit. But what is it doing really?

It creates a new commit which means it changes the history as noted above.
It has the same parents and author. --reset-author can be used to change the author.
It is using the current commit as a base and the commit message is reused if one is not passed through the -m "Message" option.
All staged changes are applied to the commit.
Provide a way to change the commit message.

Let's fix the typo and execute git commit --amend.

echo "Hello world." > ./hello-world.txt
git add hello-world.txt
git commit --amend

This is going to open your Git editor - mine is Vim and the examples will be with it. We will see something similar to the snippet below:

Add hello world
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Wed Jun 10 19:48:04 2020 +0300
#
# On branch master
# Changes to be committed:
#       new file:   hello-world.txt

We didn't provide -m "Message" but Git allows us to change the message if we want. By click i to enter insert mode, we can change the commit message. If we are happy with the changes, click Esc and enter :wq + <Enter> to save and exit. With this, the amend is completed.

Link to this heading
Interactive rebase

git rebase re-applies one-by-one the commits from your current branch onto another. The --interactive (-i for short) option provides additional commands for altering individual commits - edit, re-word, squash, .etc. The syntax is the following git rebase -i <after-which-commit> where <after-which-commit> is exclusive. Below we can see a part of how it will look and the options from which we can choose to alter certain commit.

pick 70228b2 update master.txt
pick f1a75f4 Add hello world
# Rebase 6995ded..f1a75f4 onto 6995ded (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit

Link to this heading
Squash several commits into a single commit

I was asked to squash my commits into one in my first PR ever. It was 2015 and I had just started my first job. I didn't know much about Git back then. The only commands I have used were git commit and git push. When I received that comment I didn't know how to do it so my only option was to just search and learn something new.

Consider contributing to open source projects as soon as possible. You will only benefit from it. Don't think that fixing a typo or contributing to documentation is a small thing.

While working we can make a lot of small commits, WIP commits, have commits for fixing PR comments or whatever we decide basically. However, when it comes to merging our branch into master we couldn't allow everything to get into it. Most of the time, those commits are not bringing much value and there is no need to have them in our master branch after merging. Especially if you are using Conventional Commits and generate a Changelog from the commits. Squashing commits into one is there for us to achieve this.

Let's see an example of what we want to achieve in the following diagram:

// Current state
A  master
 \
  B--C--D  feature
* 367eb93 (HEAD -> master) Update text
* 30c1d6a Add hello world
* 70228b2 update master.txt
// Wanted state
A  master
 \
  B'
* 30c1d6a (HEAD -> master) update master.txt

Count how many commits you would like to squash and execute git rebase -i HEAD~<commit-count>. In our example it will be 3 commits, so we are going to execute git rebase -i HEAD~3 which will open our Git editor (most of the options will be removed for the sake of brevity):

Note: If you are using Vim after every prompt of the Git editor enter :wq + <Enter> to save and exit which will complete the Git command.

pick 70228b2 update master.txt
pick 30c1d6a Add hello world
pick 367eb93 Update text
# Commands:
# p, pick <commit> = use commit
# s, squash <commit> = use commit, but meld into previous commit

An important thing to keep in mind is that the commits shown in the list are in reverse order. This means the oldest commit will be first on the list. In our example, we will see them as D-C-B. We will pick the oldest commit and squash the other two into it. The squash command has a short form that can be used by changing pick to s. This is saving us from writing a couple of characters.

pick 70228b2 update master.txt
s 30c1d6a Add hello world  // short version
squash 367eb93 Update text // full version

After this we are going to see a pretty explanatory confirmation screen:

# This is a combination of 3 commits.
# This is the 1st commit message:
update master.txt
# This is the commit message #2:
Add hello world
# This is the commit message #3:
Update text

By using squash we are keeping all of our previous commit messages. They will be added in the description of the commit in which they were squashed. By using git log we can see it:

commit 1f4f780510181de87dd4358a1df1bb51f99e8c44 (HEAD -> master)
Author: Martin Belev <martinbelev93@gmail.com>
Date:   Wed Jun 10 19:48:04 2020 +0300
    update master.txt
    Add hello world
    Update text

Link to this heading
Discard a commit message

If you don't want the message of a commit consider using fixup (f for short) instead. It will discard the commit message but keep the changes from the commit.

pick 70228b2 update master.txt
squash 30c1d6a Add hello world
fixup 367eb93 Update text

This will result in:

commit 1f4f780510181de87dd4358a1df1bb51f99e8c44 (HEAD -> master)
Author: Martin Belev <martinbelev93@gmail.com>
Date:   Wed Jun 10 19:48:04 2020 +0300
    update master.txt
    Add hello world

Link to this heading
Drop a commit

If you don't want some commits' changes, then you can consider using drop (d for short) which will remove the commit.

pick 70228b2 update master.txt
drop 30c1d6a Add hello world
d 367eb93 Update text

This will result in removing the added hello-world.txt file and those two commits:

commit 1f4f780510181de87dd4358a1df1bb51f99e8c44 (HEAD -> master)
Author: Martin Belev <martinbelev93@gmail.com>
Date:   Wed Jun 10 19:48:04 2020 +0300
    update master.txt

With this, we have completed the squashing several commits into one example.

Link to this heading
Fix older commit

We will look at an example of how to fix older commit. Let's say we have made a couple of commits which we want to keep but we found out that in one of the older commits we missed something. In this case, we want to go back in history and make additional changes to some older commit.

// Mistake in commit D
A--B--C--D--E  feature

The commit where we made a mistake is 2nd one (counting from the last one inclusive). We will execute the already familiar command git rebase -i HEAD~2 from our previous example. This will lead to:

pick 30c1d6a Add hello world
pick 367eb93 Update text
# Commands:
# p, pick <commit> = use commit
# e, edit <commit> = use commit, but stop for amending

As mentioned previously, we are seeing the commits in reverse order. This means that the 2nd commit which we want to edit is displayed as first in the list. We will use the edit (e for short) command to fix our mistake.

e 30c1d6a Add hello world
pick 367eb93 Update text

By saving and existing Git editor:

$ git rebase -i HEAD~2
Stopped at 30c1d6a...  Add hello world
You can amend the commit now, with
  git commit --amend
Once you are satisfied with your changes, run
  git rebase --continue

We can see that we stopped at the commit which we want to edit. Git is providing us some helpful tips on what we can do.

Doesn't You can amend the commit now, with git commit --amend look familiar? This was our first example where we learn how to make a change to the last commit. We stopped on a specific commit which is making it last for the time being. Everything we should do now is making our changes and use git commit --amend like in the first example.

The only thing left to do, as Git suggested to us, is executing git rebase --continue with which we successfully fix a mistake in an older commit.

We went back only to the commit that we need to fix. This is not required specifically. We can rebase more commits and use the edit command which will stop us on the specified commit.

Link to this heading
Reorder commits

With git rebase -i we can reorder commits as well. If the commits which we want to reorder don't depend on each other and don't have changes in the same files, it is as simple as cutting the commit we want to move and pasting it before or after some other commit.

The use case I have when I needed reordering is to squash a commit into a specific one in history. An example would be having A--B--C and the need to squash A into C. Which can occur when we have:

fix for commit 1
useful commit 2
useful commit 1

In the end, we want to keep useful commit 1 and useful commit 2 but it doesn't make sense to have fix for commit 1 squashed into useful commit 2.

Now we can have a look at an example. Let's try and move 70228b2 update master.txt before 367eb93 (HEAD -> master) Update text.

* 367eb93 (HEAD -> master) Update text
* 30c1d6a Add hello world
* 70228b2 update master.txt

We want to change the history for 3 commits, so we are going to execute git rebase -i HEAD~3.

pick 70228b2 update master.txt
pick 30c1d6a Add hello world
pick 367eb93 Update text
# These lines can be re-ordered; they are executed from top to bottom.

We are going to cut pick 70228b2 update master.txt and paste it after pick 367eb93 Update text which is going to make it our latest commit.

pick 30c1d6a Add hello world
pick 367eb93 Update text
pick 70228b2 update master.txt

Save and exit the editor with which we have completed the commit reordering. By executing git log --oneline we can make sure that everything is as expected and update master.txt is the last commit in our history.

* c8502f8 (HEAD -> master) update master.txt
* ba137dd Update text
* 08497a9 Add hello world

If the commits which you want to reorder depend on each other - for example, we use the changes from commit A in commit B but we want to reorder A and B, I would strongly suggest reconsidering reordering. It is very likely to not need reordering but something else instead.

Link to this heading
Conclusion

My initial idea for this blog post was to be an in-depth, step-by-step tutorial of git rebase. However, writing it and thinking about the time when I started using Git I realized there is a bunch of stuff going on here and it can be difficult to grasp all at once. At least it was for me, a lot of going and practicing this command until I learned it. So I decided to split it and continue the other part in a separate one which will be about properly rebasing our branches.

Let's recap what we go through and why/how it can be useful in our day-to-day work:

Making changes to the latest commit - I am using it mostly for adding additional changes that I missed. I have seen some people who are using it when fixing PR comments instead of making separate commits. The drawback of this is that it is making the subsequent PR review harder because there is no way to see only the changes that were made.
What is interactive rebase and some of the options we can use with it
Squashing several commits into a single commit - I see this as one of the most important once in this article. We went through squashing by keeping and discarding commit messages, as well as deleting whole commits. This is extremely useful for keeping a cleaner history.
Fix older commit - to be honest, this one is rarely used IMO. However, it is good to know because it is used from time to time.
Reorder commits - I mostly used this when I needed to squash a commit into certain commit (not the previous one). Again, not very widely used but good to know.

We should already see how many things we can achieve by using git rebase -i. All of the seen options can be combined and used together which makes git rebase -i extremely powerful.

Git merge vs rebase to keep feature branch up to date

Mon, 25 May 2020 00:00:00 GMT

Today we are going to look at how Git merge and rebase commands behave while trying to keep feature branch up to date.

In a large codebase where a lot of people are working, we have constant updates to the master branch. We want to work on top of this branch and always have to latest changes. We can achieve this by either using merge or rebase to get the latest changes made in the master branch into our feature branch.

Link to this heading
merge

So what is merge doing:

Join two or more development histories together

Let's now look at an example using merge to keep our branch up to date. This is pretty simple example with a few commits in each branch:

1* c5d39ef (HEAD -> feature) update 1 feature.txt
2* 0c4d97c add feature.txt
3| * 4d55c54 (master) update 1 master.txt
4|/
5* 2358179 add master.txt
6
7// Different representation of the situation
8A---B  master
9 \
10  C---D  feature

We started our feature branch from master where at first there was only one commit A. We made a commit 'C' in our feature branch. In the meantime, someone made a commit B in the master branch and after that, we made another commit D in our feature branch. We now have to get the latest changes from master into our feature branch and we are going to use merge.

After executing git merge master from our feature branch we got:

1*   ec3f6dc (HEAD -> feature) Merge branch 'master' into feature
2|\
3| * 4d55c54 (master) update 1 master.txt
4* | c5d39ef update 1 feature.txt
5* | 0c4d97c add feature.txt
6|/
7* 2358179 add master.txt
8
9// Different representation of the situation
10A---B  master
11 \
12  C-B-D-E  feature

It has it's benefits, of course, like every other thing in software development but the drawbacks in the large codebase are huge.

It is hard to go back and change/clean our feature branch commits.
It is making hard to follow and find out when/why something was done.

In this simple example maybe it is understandable what happened. But in real life where we got hundreds of commits and we will make a lot of redundant merge commits. You can imagine that this is going to become almost impossible to follow when we are working for a long time on a feature because we will end up with a lot of merge commits.

Link to this heading
rebase to the rescue

So what is rebase doing:

Reapply commits on top of another base tip

We will review the same scenario using rebase instead.

1A---B  master
2 \
3  C---D  feature

After executing git rebase master from our feature branch we got:

1* 7d4b7c0 (HEAD -> feature) update from-rebase.txt
2* 5b61ccd add from-rebase.txt
3* d694446 (master) update rebase.txt
4* 8f8b0e3 add rebase.txt
5
6// Different representation of the situation
7A---B  master
8     \
9      C'-D'  feature

We got our changes reapplied over the latest commit from the master branch. Note: the commits have the same set of changes but from Git point of view they are completely different objects and have different hashes.

Link to this heading
Conclusion

By using rebase we benefit from:

making the history in our master branch much easier to follow because it is linear
long tramlines from long-lived feature branches
ability to easily change our feature branch history

There are a couple of things to keep in mind though:

it can be confusing for less experienced Git users
we are losing the chronological order - IMO this is not a problem at all because we achieve a series of intentional changes that are made to master branch
it can result in fixing the same conflict for every commit in the feature branch - for this one, I find really useful the git rerere configuration which is saving the resolved conflicts and then reusing them. With it, we don't have to resolve the same conflict all over again.

I don't recommend blindly use rebase to keep your feature branches up to date but for larger projects, my preference is to use rebase instead of merge.

Prevent React setState on unmounted component

Sat, 16 May 2020 00:00:00 GMT

If you are working with React, most probably you have already seen the below issues a lot.

Warning: Can only update a mounted or mounting component. This usually means you called setState, replaceState, or forceUpdate on an unmounted component. This is a no-op.
Warning: Can't call setState (or forceUpdate) on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.

They can be caused easily by not cleaning up when component unmounts or route is changed:

using setTimeout or setInterval
an asynchronous request to the server for fetching data when component mounts
form submit handler sending request to the server

Link to this heading
What is this indicating?

This is just a warning and it is not a stopper for development, but as such it is showing that in our application code there may be some issues - for example, we can have a memory leak which can lead to performance issues.

Link to this heading
What are we going to cover in this post?

Today we are going to look at a solution leveraging Observables by using RxJS which will make us almost forget about the described issues. The solution is focused on making requests to the server, we are not going to cover setTimeout/setInterval usage. We are also going to be using hooks. I am going to provide more information about our use case and how we ended up with this solution.

We are not going to look at other solutions like Cancellable Promises, AbortController or isMounted usage which is actually an antipattern - https://reactjs.org/blog/2015/12/16/ismounted-antipattern.html. We are not going to get in detail about RxJS as well.

Link to this heading
How do we end up here?

For a long time, we were using Promises for our requests. We started seeing the described warning more and more which was just showing us that we have to do something to solve it. I won't lie, at first we had a couple of usages of isMounted which no one liked. We felt that it is not actually solving the problem but it is just a workaround which prevented the call to setState. We knew that this can't be the solution for us because it doesn't seem OK to write such additional code for every request that we are going to make.

The good thing though was that under the hood we were already using RxJS and Observables. We are working in a really big application so just removing the Promise usage wasn't a solution. We were going to gradually remove the Promise usage and start using only Observables. We should mention that we can unsubscribe from Observable, but again this is something that we should do for every request which is just not good enough...

I am feeling grateful and want to thank Jafar Husain for the wonderful course Asynchronous Programming in JavaScript (with Rx.js Observables) from which I learned so much and found the solution. The course is also available in Pluralsight - link.

Link to this heading
What is the solution?

Link to this heading
Different way to think about our problem

As Front-end developers, if we think more deeply about it, most of the things that we are doing can be described as a collection/stream of events happening over time. If we think about them as collection then this gives us new horizons because we know so many operations that we can do over collections (or at least I felt so). With a couple of operations like map, filter, reduce, mergeMap, concatMap, flatMap, switchMap we can achieve so much. Jafar Husain is describing all of this in much greater detail with great examples in his course - just give it a try.

So, let's think about our request(s) as one collection (Observable) - let's call this one A. And our component unmounting as another - let's call it B. We would like to somehow combine those two in such a way that A should emit values until an event occurs in B.

Link to this heading
Choosing `RxJS` operator

We described in an abstract way what we want to achieve. Now let's look at some of the implementation details. We are using RxJS which comes with a great number of operators that will solve most of our problems. When we look at the operators, takeUntil looks perfect for our use case - "Emits the values emitted by the source Observable until a notifier Observable emits a value.". This is exactly what we wanted so now we know that we are going to use takeUntil.

Link to this heading
Going for the implementation

We are going to implement a custom hook which will be used to solve our problem. Let's start with the basics and just declare the structure of our hook:

1import { Observable } from 'rxjs';
2const useUnmount$ = (): Observable<void> => {};
3
4export default useUnmount$;

Now we have our hook, but we should add the implementation. We should return Observable and be able to emit values. We are going to use Subject for this.

1import { Observable, Subject } from 'rxjs';
2const useUnmount$ = (): Observable<void> => {
3  const unmount$ = new Subject<void>();
4
5  return unmount$;
6};
7
8export default useUnmount$;

Good, but we are not there yet. We know that unmount will happen only once so we can emit and complete after this happens. We are going to use useEffect cleanup function to understand when the component is unmounted.

1import { Observable, Subject } from 'rxjs';
2import { useEffect } from 'react';
3
4const useUnmount$ = (): Observable<void> => {
5  const unmount$ = new Subject<void>();
6
7  useEffect(
8    () => () => {
9      // implicit return instead of wrapping in {} and using return
10      unmount$.next();
11      unmount$.complete();
12    },
13    [unmount$]
14  );
15
16  return unmount$;
17};
18
19export default useUnmount$;

It looks like we completed our implementation, but we are not yet. What is going to happen if the component where useUnmount$ is used unmounts? We are going to create another Subject, emit, and complete the previous one. We wouldn't want this behavior, but instead emitting only once when the component in which is used unmounts. useMemo coming to the rescue here.

1import { Observable, Subject } from 'rxjs';
2import { useEffect, useMemo } from 'react';
3
4const useUnmount$ = (): Observable<void> => {
5  const unmount$ = useMemo(() => new Subject<void>(), []);
6
7  useEffect(
8    () => () => {
9      unmount$.next();
10      unmount$.complete();
11    },
12    [unmount$]
13  );
14
15  return unmount$;
16};
17
18export default useUnmount$;

With this, we completed the implementation of our custom hook, but we still have to plug it into our collection A which is responsible for our requests. We will imagine that our request abstraction is returning Observable. And now the only thing left is to use the useUnmount$ hook.

1import { useCallback } from 'react';
2import { from } from 'rxjs';
3import { takeUntil } from 'rxjs/operators';
4
5import useUnmount$ from './useUnmount';
6
7const useRequest = () => {
8  const unmount$ = useUnmount$();
9
10  // from("response") should be replaced by your implementation returning Observable
11  return useCallback(() => from('response').pipe(takeUntil(unmount$)), [unmount$]);
12};
13
14export default useRequest;

Link to this heading
Conclusion

Observables can come in handy in many ways. It is a topic worth learning about and I believe it is going to be used more and more in the future. In combination with hooks, IMO we had come up with a very clean solution. It is saving us the cognitive load to think about cleaning up after each request that is made. I think this is a great win because there is one thing less to think/worry about while developing or reviewing a PR.

Martin Belev

7 tips for writing cleaner functions

Link to this heading2. Functions should do only one thing and they should do it well

Link to this heading3. Avoid functions that depend on an external (hidden) state which if changed will result in a change of the function's behavior

Link to this heading4. Use pure functions whenever you can

Link to this heading5. Try to keep your functions with up to 2-3 arguments (ideally even less)

Link to this heading6. Avoid mixing different levels of abstraction in functions

Link to this heading7. Avoid having object state changes and retrieving information about the object in the same function

Link to this headingConclusion

6 tips to improve naming and why it is so important

Link to this heading2. Prefer explicit over implicit names

Link to this heading3. Distinguish variable names

Link to this heading4. Pronounancable names (avoid using abbreviations)

Link to this heading5. Use developer aware language when possible

Link to this heading6. Keep the naming consistent

Link to this headingWhy naming is so important?

Link to this headingConclusion

How to find an old introduced bug using Git - git bisect introduction?

Link to this headingBad commit

Link to this headingGood commit

Link to this headingBisect has been started

Link to this headingWhat information is Git giving us?

Link to this headingProceeding further

Link to this headingConclusion

Waving hand animation using pure CSS

Link to this headingExplanation

Link to this headingConclusion

How to configure Git with multiple emails?

Link to this headingMultiple emails .gitconfig setup

Link to this headingBonus

Link to this headingConclusion

How to keep cleaner React components with object map?

Link to this headingMore complex example

Link to this headingBonus round using array

Link to this headingConclusion

How to use pattern matching in JavaScript - an alternative?

Link to this headingScala pattern matching examples

Link to this headingJavaScript switch statement quick overview

Link to this headingOne less known usage of switch statement in JavaScript

Link to this headingConclusion

How to effectively use git rebase --onto?

Link to this headingWhat is git rebase --onto?

Link to this headingHow to rebase with skipping not needed commits?

Link to this headingHow to fix branch from a branch after rebase

Link to this headingHow to change Git branch's base?

Link to this headingHow to use the third argument of git rebase --onto?

Link to this headingConclusion

Some of the most used Git interactive rebase options

Link to this headingInteractive rebase

Link to this headingSquash several commits into a single commit

Link to this headingDiscard a commit message

Link to this headingDrop a commit

Link to this headingFix older commit

Link to this headingReorder commits

Link to this headingConclusion

Git merge vs rebase to keep feature branch up to date

Link to this headingrebase to the rescue

Link to this headingConclusion

Prevent React setState on unmounted component

Link to this headingWhat are we going to cover in this post?

Link to this headingHow do we end up here?

Link to this headingWhat is the solution?

Link to this headingDifferent way to think about our problem

Link to this headingChoosing RxJS operator

Link to this headingGoing for the implementation

Link to this headingConclusion

Link to this heading
2. Functions should do only one thing and they should do it well

Link to this heading
3. Avoid functions that depend on an external (hidden) state which if changed will result in a change of the function's behavior

Link to this heading
4. Use pure functions whenever you can

Link to this heading
5. Try to keep your functions with up to 2-3 arguments (ideally even less)

Link to this heading
6. Avoid mixing different levels of abstraction in functions

Link to this heading
7. Avoid having object state changes and retrieving information about the object in the same function

Link to this heading
Conclusion

Link to this heading
2. Prefer explicit over implicit names

Link to this heading
3. Distinguish variable names

Link to this heading
4. Pronounancable names (avoid using abbreviations)

Link to this heading
5. Use developer aware language when possible

Link to this heading
6. Keep the naming consistent

Link to this heading
Why naming is so important?

Link to this heading
Conclusion

Link to this heading
Bad commit

Link to this heading
Good commit

Link to this heading
Bisect has been started

Link to this heading
What information is Git giving us?

Link to this heading
Proceeding further

Link to this heading
Conclusion

Link to this heading
Explanation

Link to this heading
Conclusion

Link to this heading
Multiple emails .gitconfig setup

Link to this heading
Bonus

Link to this heading
Conclusion

Link to this heading
More complex example

Link to this heading
Bonus round using array

Link to this heading
Conclusion

Link to this heading
Scala pattern matching examples

Link to this heading
JavaScript switch statement quick overview

Link to this heading
One less known usage of switch statement in JavaScript

Link to this heading
Conclusion

Link to this heading
What is `git rebase --onto`?

Link to this heading
How to rebase with skipping not needed commits?

Link to this heading
How to fix branch from a branch after rebase

Link to this heading
How to change Git branch's base?

Link to this heading
How to use the third argument of `git rebase --onto`?

Link to this heading
Conclusion

Link to this heading
Interactive rebase

Link to this heading
Squash several commits into a single commit

Link to this heading
Discard a commit message

Link to this heading
Drop a commit

Link to this heading
Fix older commit

Link to this heading
Reorder commits

Link to this heading
Conclusion

Link to this heading
rebase to the rescue

Link to this heading
Conclusion

Link to this heading
What are we going to cover in this post?

Link to this heading
How do we end up here?

Link to this heading
What is the solution?

Link to this heading
Different way to think about our problem

Link to this heading
Choosing `RxJS` operator

Link to this heading
Going for the implementation

Link to this heading
Conclusion