DEV Community: Martin Belev

How to keep cleaner React components with object map?

Martin Belev — Sun, 26 Jul 2020 15:45:29 +0000

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.

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:

import React from 'react';

interface Props {
  errorField: 'name' | 'email' | 'password' | 'date';
}

const ErrorMessageWithSwitch: React.FC<Props> = ({ errorField }) => {
  switch (errorField) {
    case 'name':
      return <div>Please enter valid name.</div>;
    case 'email':
      return <div>Please enter valid email address.</div>;
    case 'password':
      return <div>Please enter valid password.</div>;
    case 'date':
      return <div>Please enter valid date of birth.</div>;
    default:
      return <div>Invalid field.</div>;
  }
};

const ErrorMessageWithIf: React.FC<Props> = ({ errorField }) => {
  if (errorField === 'name') {
    return <div>Please enter valid name.</div>;
  }

  if (errorField === 'email') {
    return <div>Please enter valid email address.</div>;
  }

  if (errorField === 'password') {
    return <div>Please enter valid password.</div>;
  }

  if (errorField === 'date') {
    return <div>Please enter valid date of birth.</div>;
  }

  return <div>Invalid field.</div>;
};

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:

import React from 'react';

interface Props {
  errorField: 'name' | 'email' | 'password' | 'date';
}

const errorFields = {
  name: 'Please enter valid name.',
  email: 'Please enter valid email address.',
  password: 'Please enter valid password.',
  date: 'Please enter valid date of birth.',
  default: 'Invalid field.'
};

const ErrorMessage: React.FC<Props> = ({ errorField }) => {
  const message = errorFields[errorField] || errorFields.default;
  return <div>{message}</div>;
};

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.

More complex example

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

import React from "react";

const ConnectTwitterButton: React.FC = () => {
  const handleClick = () => {
    // Connect Twitter
  };

  return (
    <button onClick={handleClick}>
      Connect with <TwitterIcon> Twitter
    </button>
  );
};

export 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:

import React from 'react';

interface Props {
  providerType: 'twitter' | 'twitch' | 'fb';
}

const ConnectAccountButton: React.FC<Props> = ({ providerType }) => {
  const getProviderName = () => {
    switch (providerType) {
      case 'twitter':
        return 'Twitter';
      case 'twitch':
        return 'Twitch';
      case 'fb':
        return 'Facebook';
      default:
        return 'Unknown';
    }
  };
  const getProviderIcon = () => {
    // return SVG icon
  };
  const providerName = getProviderName();
  const icon = getProviderIcon();

  const connectWithTwitter = () => {
    // Connect Twitter
  };
  const connectWithTwitch = () => {
    // Connect Twitch
  };
  const connectWithFacebook = () => {
    // Connect Facebook
  };
  const handleClick = () => {
    if (providerType === 'twitter') {
      return connectWithTwitter();
    }
    if (providerType === 'twitch') {
      return connectWithTwitch();
    }
    if (providerType === 'fb') {
      return connectWithFacebook();
    }
  };

  return (
    <button onClick={handleClick}>
      Connect with {icon} {providerName}
    </button>
  );
};

export default ConnectAccountButton;

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

import React from 'react';

type ProviderType = 'twitter' | 'twitch' | 'fb';

interface Props {
  providerType: ProviderType;
}

interface Provider {
  icon: React.ReactNode;
  name: string;
  connect: () => void;
}

const providers: { [key in ProviderType]: Provider } = {
  twitter: {
    icon: <TwitterIcon />,
    name: 'Twitter',
    connect: connectWithTwitter
  },
  twitch: {
    icon: <TwitchIcon />,
    name: 'Twitch',
    connect: connectWithTwitch
  },
  fb: {
    icon: <FacebookIcon />,
    name: 'Facebook',
    connect: connectWithFacebook
  }
};

const ConnectAccountButton: React.FC<Props> = ({ providerType }) => {
  const { icon, name, connect } = providers[providerType];

  return (
    <button onClick={() => connect()}>
      Connect with {icon} {name}
    </button>
  );
};

export default ConnectAccountButton;

The important part is the refactoring itself - providers object and ConnectAccountButton component. 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.

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.

const navigationItems = [
  {
    path: 'Nav 1',
    visible: () => {
      // Some visibility logic
    }
  },
  {
    path: 'Nav 2',
    visible: () => {
      // Some visibility logic
    }
  }
];

// Then we can simply use filter and map to construct our navigation
navigationItems.filter((item) => item.visible()).map((item) => /* The mapped item */ item.path);

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.

Thank you for reading this to the end. I hope you enjoyed it and learned something new. If so, you can support me by following me on Twitter where I will share other tips, new articles, and things I learn. If you would like to learn more, have a chat about software development, or give me some feedback, don't be shy and drop me a DM.

How to use pattern matching in JavaScript - an alternative?

Martin Belev — Sun, 19 Jul 2020 09:53:48 +0000

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!

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.

Scala pattern matching examples

One of the simplest cases is match by value:

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

JavaScript version:

const getMonthName = (month) => {
  switch (month) {
    case 1:
      return 'January';
    case 2:
      return 'February';
    // .etc
    default:
      return 'Unknown';
  }
};

getMonthName(13); // Unknown
getMonthName(1); // January

We can have matching on type:

abstract class Device
case class Phone(model: String) extends Device {
  def screenOff = "Turning screen off"
}
case class Computer(model: String) extends Device {
  def screenSaverOn = "Turning screen saver on..."
}

def goIdle(device: Device) = device match {
  case p: Phone => p.screenOff
  case c: Computer => c.screenSaverOn
}

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.

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:

const value = 'Papayas';
switch (value) {
  case 'Oranges':
    console.log('Oranges are $0.59 a pound.');
    break;
  case 'Mangoes':
  case 'Papayas':
    console.log('Mangoes and papayas are $2.79 a pound.');
    // expected output: "Mangoes and papayas are $2.79 a pound."
    break;
  default:
    console.log(`Sorry, we are out of ${value}.`);
}

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?

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:

const getCompactAmount = (amount) => {
  switch (true) {
    case amount / 1000000 >= 1:
      return `${amount / 1000000}M`;
    case amount / 1000 >= 1:
      return `${amount / 1000}K`;
    default:
      return amount;
  }
};

getCompactAmount(2000000); // 2M
getCompactAmount(5000); // 5K
getCompactAmount(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.

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.

Thank you for reading this to the end. I hope you enjoyed it and learned something new. If so, please follow me on Twitter where I will share other tips, new articles, and things I learn. If you would like to learn more, have a chat about software development, or give me some feedback, don't be shy and drop me a DM.

What are you using for your documentation?

Martin Belev — Tue, 30 Jun 2020 10:51:48 +0000

Hi everyone,

I am sure there is no "best" tool for it but what are your recommendations for documentation. It should support MDX.

Gatsby has some nice themes for documentation
there is Docz which is built on top of Gatsby
Dokz which is powered by NextJS
I am sure there are a lot more tools out there

What is your preferred choice? What would you use if you have to start writing documentation today?

How to effectively use git rebase --onto?

Martin Belev — Sat, 20 Jun 2020 15:39:37 +0000

This post was originally published on https://belev.dev/how-to-effectively-use-git-rebase-onto

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!

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.

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>.

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.

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.

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.

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

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

Martin Belev — Sat, 13 Jun 2020 21:23:06 +0000

This post was originally published on https://belev.dev/some-of-the-most-used-git-interactive-rebase-options

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.

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.

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

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

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

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.

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.

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.

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.

Thank you for reading this to the end. I hope you enjoyed it and learned something new. If so, please follow me on Twitter where I will share other tips, new articles, and things I learn. If you would like to learn more, have a chat about software development or give me some feedback, don't be shy and drop me a DM.

My first personal website

Martin Belev — Sat, 06 Jun 2020 16:34:00 +0000

Hi all,

Having a personal website was a long wanted project of mine but I always postponed it for different reasons. Today, I am extremely excited to share it with all of you - https://belev.dev/. I am going to use it as a blog and mainly share things around software development from my experience.

The site is built using Gatsby and LekoArts minimal blog theme. It is deployed using Netlify. I bought the domain name from Namecheap and afterwards configure the DNS through Netlify DNS.

Most probably I am going to write a blog post about my experience building my first personal website and my impressions about Gatsby and Netlify because it was my first touch with them.

Thank you for reading this and I would really appreciate it if you give the website a try. Any feedback is welcome.

Git `merge` vs `rebase` to keep feature branch up to date

Martin Belev — Mon, 25 May 2020 14:47:57 +0000

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 master branch into our feature branch.

`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:

* c5d39ef (HEAD -> feature) update 1 feature.txt
* 0c4d97c add feature.txt
| * 4d55c54 (master) update 1 master.txt
|/
* 2358179 add master.txt

// Different representation of the situation
A---B  master
 \
  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 mean time someone made a commit B in 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:

*   ec3f6dc (HEAD -> feature) Merge branch 'master' into feature
|\
| * 4d55c54 (master) update 1 master.txt
* | c5d39ef update 1 feature.txt
* | 0c4d97c add feature.txt
|/
* 2358179 add master.txt

// Different representation of the situation
A---B  master
 \
  C-B-D-E  feature

It has it's benefits, of course, as every other thing in software development but the drawbacks in 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 merge commits which are redundant. 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.

`rebase` to the rescue

So what is rebase doing:

Reapply commits on top of another base tip

We will review the same scenario but using rebase instead.

A---B  master
 \
  C---D  feature

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

* 7d4b7c0 (HEAD -> feature) update from-rebase.txt
* 5b61ccd add from-rebase.txt
* d694446 (master) update rebase.txt
* 8f8b0e3 add rebase.txt

// Different representation of the situation
A---B  master
     \
      C'-D'  feature

We got our changes reapplied over the latest commit from 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.

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 loosing the chronological order - IMO this is not a problem at all because we achieve 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 to blindly use rebase to keep your feature branches up to date but for larger projects my preference is to use rebase instead of merge.

When I started using Git I find those concepts very confusing, so I hope someone will enjoy this and will find it useful. If this is the case, please follow me on Twitter where I will share another tips and upcoming articles from my experience.

How to detect that mobile keyboard pops up in Web?

Martin Belev — Sat, 16 May 2020 11:33:42 +0000

Recently we had a feature in which we had to make an animation on our header only when the keyboard on mobiles devices has been displayed so that we can decrease the size of the header and make more space for the user on the screen.

I think there is no standard way to do this. The options were either listen for input focus events and based on them to apply our changes, or resize events where some height calculations could be made to achieve the wanted behaviour. However, both options have their drawbacks:

with focus event we are trying to fight the browser's default behaviour when the keyboard pops up. This being the case the solution seems a little patchy.
with the resize event there are some problems on iOS devices

Does someone know another way of detecting that the mobile keyboard is displayed?

How to prevent React setState on unmounted component - a different approach

Martin Belev — Sat, 16 May 2020 09:45:59 +0000

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
asynchronous request to the server for fetching data when component mounts
form submit handler sending request to the server

What is this indicating?

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

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 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 details about RxJS as well.

How do we ended 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 work around 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.

What is the solution?

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 details 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.

Choosing `RxJS` operator

We described in 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.

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:

import { Observable } from "rxjs";
const useUnmount$ = (): Observable<void> => {};

export default useUnmount$;

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

import { Observable, Subject } from "rxjs";
const useUnmount$ = (): Observable<void> => {
  const unmount$ = new Subject<void>();

  return unmount$;
};

export 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.

import { Observable, Subject } from "rxjs";
import { useEffect } from "react";

const useUnmount$ = (): Observable<void> => {
  const unmount$ = new Subject<void>();

  useEffect(
    () => () => { // implicit return instead of wrapping in {} and using return
      unmount$.next();
      unmount$.complete();
    },
    [unmount$]
  );

  return unmount$;
};

export 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.

import { Observable, Subject } from "rxjs";
import { useEffect, useMemo } from "react";

const useUnmount$ = (): Observable<void> => {
  const unmount$ = useMemo(() => new Subject<void>(), []);

  useEffect(
    () => () => {
      unmount$.next();
      unmount$.complete();
    },
    [unmount$]
  );

  return unmount$;
};

export 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.

import { useCallback } from "react";
import { from } from "rxjs";
import { takeUntil } from "rxjs/operators";

import useUnmount$ from "./useUnmount";

const useRequest = () => {
  const unmount$ = useUnmount$();

  // from("response") should be replaced by your implementation returning Observable
  return useCallback(() => from("response").pipe(takeUntil(unmount$)), [
    unmount$,
  ]);
};

export default useRequest;

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.

Create PR against release branch from merged into develop branch?

Martin Belev — Wed, 21 Aug 2019 17:11:26 +0000

Given the following scenario:

the main development branch is develop
a feature branch (f for short) is created from develop
a pull request is opened for the implemented feature
the new feature should land in the new release but a release branch is created from develop before the feature is reviewed and merged
the PR gets reviewed and merged

After the f branch is merged into develop we should create a PR to the new release branch.

P.S. f branch is rebased over develop

We decided to go with a new branch from the release branch and just cherry pick the commit that we wanted. But it was because we were in a hurry and the commit was only 1. I am still wondering if there is some other easier way to do this.

What do you think will be the best and easiest way to do it?

How to enable JUnit 5 in new Spring Boot project

Martin Belev — Sun, 03 Feb 2019 13:54:41 +0000

This post was originally posted on Medium.

In this article, we will learn how to enable JUnit 5 in a newly created Spring
Boot project. We are going through the following steps:

Initialize new Sprint Boot project
Having a look at our pom.xml and mostly on sprint-boot-starter-test dependency, going a little deeper in spring-boot-starter-test and see what JUnit version it uses
How to exclude child dependency that comes from one of our dependencies using Maven
Add JUnit 5
Migrate JUnit 4 to JUnit 5

1) First, let’s go to Spring Boot initializr and generate a new project.

The defaults should be fine and you can click the “Generate Project” button. You should have downloaded a .zip archive of the starter Sprint Boot project. Unzip it and open it with IDE of your choice (I am using IntelliJ and the following code samples and examples will be shown from it). After opening it, you should see the following structure:

2) Now let’s focus on the pom.xml.

In our pom.xml we can see the following dependency which includes libraries (such as JUnit, Hamcrest, and Mockito) for testing Spring Boot applications.



<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test</artifactId>
  <scope>test</scope>
</dependency>

We are going a little deeper to see the exact dependencies and their versions focusing on junit with which spring-boot-starter-test comes (in IntelliJ you can do this by Ctrl + click onto spring-boot-starter-test. In the snippet below, we can see that sprint-boot-starter-test comes with JUnit 4.12 but there is JUnit 5 already. So how can we use the newer version of JUnit in our new Spring Boot project?



<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.12</version>
  <scope>compile</scope>
</dependency>

3) We should have a way to exclude JUnit 4 because we are currently depending on it because of spring-boot-starter-test. We can do this by adding the following lines to our spring-boot-starter-test dependency by which we exclude JUnit 4.



<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test</artifactId>
  <scope>test</scope>

  <exclusions>
    <exclusion>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </exclusion>
  </exclusions>
</dependency>

4) We are now going to configure JUnit 5 as a dependency using Maven. We will add the following dependencies in pom.xml



<dependency>
  <groupId>org.junit.jupiter</groupId>
  <artifactId>junit-jupiter-api</artifactId>
  <version>5.3.2</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.junit.jupiter</groupId>
  <artifactId>junit-jupiter-engine</artifactId>
  <version>5.3.2</version>
  <scope>test</scope>
</dependency>

And we should add the following maven plugin to our build plugins



<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.22.0</version>
</plugin>

5) We have removed the dependency of JUnit 4, we have added JUnit 5 and now it is time to make a little code changes in order to use JUnit 5. Let’s focus on DemoApplicationTests.java where we can see the following code




package com.example.demo;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringRunner.class)
@SpringBootTest
public class DemoApplicationTests {

    @Test
    public void contextLoads() {
    }

}

Actually, the only things that we have to change are the RunWith annotation because it’s from JUnit 4 and the import of Test annotation. After the change, our test should look like



package com.example.demo;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit.jupiter.SpringExtension;

@ExtendWith(SpringExtension.class)
@SpringBootTest
public class DemoApplicationTests {

    @Test
    public void contextLoads() {
    }

}

You should be ready to start writing tests using JUnit 5 now. : )

DEV Community: Martin Belev

How to keep cleaner React components with object map?

Simple conditionals example

More complex example

Bonus round using array

Conclusion

How to use pattern matching in JavaScript - an alternative?

What is pattern matching?

Scala pattern matching examples

JavaScript switch statement quick overview

One less known usage of switch statement in JavaScript

Conclusion

What are you using for your documentation?

How to effectively use git rebase --onto?

Quick git rebase recap

What is git rebase --onto?

How to rebase with skipping not needed commits?

How to fix branch from a branch after rebase

How to change Git branch's base?

How to use the third argument of git rebase --onto?

Conclusion

Some of the most used Git interactive rebase options

Amend the last commit

Interactive rebase

Squash several commits into a single commit

Discard a commit message

Drop a commit

Fix older commit

Reorder commits

Conclusion

My first personal website

Git `merge` vs `rebase` to keep feature branch up to date

merge

rebase to the rescue

Conclusion

How to detect that mobile keyboard pops up in Web?

How to prevent React setState on unmounted component - a different approach

What is this indicating?

What are we going to cover in this post?

How do we ended up here?

What is the solution?

Different way to think about our problem

Choosing RxJS operator

Going for the implementation

Conclusion

Create PR against release branch from merged into develop branch?

Given the following scenario:

How to enable JUnit 5 in new Spring Boot project

Quick `git rebase` recap

What is `git rebase --onto`?

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

`merge`

`rebase` to the rescue

Choosing `RxJS` operator