DEV Community: Anton Holmberg

Understanding TypeScripts Exclude

Anton Holmberg — Thu, 04 Jul 2019 12:56:03 +0000

I recently started to do more TypeScript. I have plenty of previous experiences
with typed languages but there were still some things in TypeScript that I didn't
really feel comfortable with at first.

That Weird Exclude Type

While reading release notes for TypeScript 2.8 I stumbled across Omit. Not
knowing what it was I set out to understand it. However, the problem grew since
I found that Omit was defined as a combination of Pick and Exclude. I just
couldn't for the life of me figure out what Exclude did.

Most of the articles I found about Exclude would show an example of how it was
used in conjunction with another type. It felt like they sort of assumed that
the reader already knew what Exclude did.

Lets Start With Union Types

So TypeScript has this awesome feature called union types. I think it is
easier to show an example of a union type rather than explaining it in text.

type Language = "swedish" | "danish" | "english" | "french":

const firstLanguage: Language = "swedish";
const secondLanguage: Language = "english";

// Will not compile
const thirdLanguage = "meowing"

So in the example above we create a type called Language. A variable of type
Language can now only be one of the languages we defined in the type. In this
case meowing is not an acceptable language and therefore the program above
will not compile.

So What Is This Exclude Thing?

This is when Exclude comes in. Exclude takes two union types and, sort of,
subtracts the values in the second union type from the first union type.

type Language = "swedish" | "danish" | "english" | "french":
type NordicLanguage = Exclude<Language, "english" | "french">;

const firstLanguage: NordicLanguage = "swedish";
// This will not compile
const secondLanguage: NordicLanguage = "english";

So in the above example we create another type called NordicLanguage. This
type can take on all the same values as Language except for the excluded values
english and french. This is more or less the same as writing.

type Language = "swedish" | "danish" | "english" | "french":
type NordicLanguage = "swedish" | "danish";

A Cool Use Case

So I recently had a problem where I had an object that contained multiple keys of
the same type. I also wanted to store which keys was currently
active/selected.

As it turned out; this perfect case for Exclude.

type AvailableArea = Exclude<keyof Map, 'selectedArea'>;

type Climate = 'grass' | 'snow' | 'sand' | 'water';
interface Area {
  climate: Climate;
}

interface Map {
  selectedArea: AvailableArea;
  north: Area;
  south: Area;
  west: Area;
  east: Area;
}

The first thing that we need to understand if what keyof means.

// Same as: type keys = "selectedArea" | "north" | "south" | "west" | "east";
type keys = keyof Map;

interface Map {
  selectedArea: AvailableArea;
  north: Area;
  south: Area;
  west: Area;
  east: Area;
}

So now that we have that down the question is: Do we really want selectedArea
to be able to refer to it self? In this case the answer was no. If I create a
union type with the key names hard coded, what if I start adding more areas
like southWest? These questions lead me to the conclusion that probably it is
best if I use Exclude here.

We know that keyof returns a union type where the values can be any of the
keys in the object. All we need to do now is to "exclude" selectedArea and we
should be left with exactly what we want!

type AvailableArea = Exclude<keyof Map, 'selectedArea'>;

This gives me the possibility to include more areas in the future and still keep
type safety throughout my application.

Closing Thoughts

Hopefully someone found this useful in some way. Next time I might cover Pick
but there are plenty of tutorials out there for that and once I understood
Exclude I found that Pick wasn't that hard to grasp.

Getting Physical Units With Styled Components

Anton Holmberg — Thu, 23 May 2019 16:33:34 +0000

Today I came across an interesting problem. I had to draw a React component in the browser and it had to be a specific width and height in centimeters.

So I naively thought that this would be as simple as setting the width and the height in css using the cm unit. I quite quickly found out that this would not work. I found this answer on stack overflow, so follow the link if you are interested in finding out why it doesn't work.

My Initial Code

Lets start out by looking at my initial attempt:

const SomeComponent = styled.div`
  background-color: black;
  width: 8.4cm;
  height: 2.2cm;
`;

function App() {
  return <SomeComponent />;
}

As previously stated this doesn't work. So let's try to fix it!

Some Prerequisites

I found a solution that worked for me. It is not perfect but it got the job done. If anyone have a better solution I would love to hear about it!

I will assume that you are familiar with styled-components; if not, you should probably read up a bit and come back later!

A prerequisite for my solution is the fact that I knew what device the code will run on. I started out by measuring the actual screen I had. In this example I will be using a 13.3" MacBook; I was actually able to find the measurements online so no ruler was needed (11.25" x 7").

The Solution

The first step I took was to define a variable that maps between vw and centimeters. I decided to define it in a styled-components theme since this will allow me to easily access it from anywhere in the component tree:

function App() {
  return (
    <ThemeProvider theme={{ oneCmInVw: 100 / 28.575 }}>
      <SomeComponent />
    </ThemeProvider>
  );
}

So my screen is 28.575cm (11.25") wide. If I divide 100 by 28.575 I get how many vw goes into one centimeter (given that the page is full screen on my 13.3" MacBook). I can now access this variable and set the actual width and height for SomeComponent in centimeters.

const SomeComponent = styled.div`
  background-color: black;
  width: ${props => props.theme.oneCmInVw * 8.4}vw;
  height: ${props => props.theme.oneCmInVw * 2.2}vw;
`;

function App() {
  return (
    <ThemeProvider theme={{ oneCmInVw: 100 / 28.575 }}>
      <SomeComponent />
    </ThemeProvider>
  );
}

The end result is a black box that is 84 x 22 millimeters.

I Made a Visual Studio Code Plugin

Anton Holmberg — Thu, 23 May 2019 09:00:05 +0000

I recently found remove.bg. It is a really cool project that allows you to (as the name suggests) remove the background from an image. So I decided to make a plugin for vscode that would allow me to right click an image and remove the background from that image.

I have been switching back and forth between vscode and vim a lot lately but one of the things that intrigued me with vscode was the fact that plugins were written in JavaScript.

The main reason why I like JavaScript, and also the entire web stack, is the fact that it runs everywhere. Knowledge in JavaScript remain relevant even if you want to write a Sketch plugin, a mobile app, a backend, a CLI or a desktop app.

But enough talking about JavaScript and lets get in to it!

Starting Out

First of all I needed start a project. To do this I followed the Official Documentation. Scaffolding of a new project can be done with Yeoman. Yeoman is a project that I have looked at before so I was pleasantly surprised that this was the tool that Microsoft decided to use for their scaffolding.

From here I decided to do some research. I knew that remove.bg had an HTTP API that I could use but it got even better! There was already an npm package out there that handled it all for me.

Running an Extension

So once the project was scaffolded I had to figure out how to run it; this was by far the easiest step. The whole process was as easy as going to the debug tab and press run. A new vscode window opened and in that window my plugin was already installed and ready to use, NEAT!

Wrapping the NPM Package in Visual Studio Code

I started out by installing the NPM package. This was no harder than installing a dependency for a regular node or web project.

npm install remove.bg

So, for starters, I knew that the API required an API key. So it would be great if that API key could be specified in the vscode settings. By adding these lines to the package.json file the setting titled Api Key was added to the settings menu in vscode (under the section named Remove-bg):

{
  "contributes": {
    "configuration": [
      {
        "title": "Remove.bg configuration",
        "properties": {
          "remove-bg.apiKey": {
            "type": "string",
            "description": "The API key for remove.bg"
          }
        }
      }
    ]
  }
}

The next step was to make the menu appear when you right click a file. This was, unfortunately, less well documented but some trial and error lead me to this solution:

  "contributes": {
    ...
    "menus": {
      "explorer/context": [
        {
          "command": "remove-bg.removeBg",
          "when": "resourceExtname =~ /\\.png$|\\.jpg$|\\.jpeg$/",
          "group": "navigation"
        }
      ]
    },
    "commands": [
      {
        "command": "remove-bg.removeBg",
        "title": "Remove background"
      }
    ]
  },

Okay, there is a lot to take in here so lets just start with the command part. The command part tells vscode that this extension will provide a command called remove-bg.removeBg; we will come to the part where this command is implemented, so hang tight.

The next part is the menu part. Here we define that we want to add an item to the dropdown menu that is shown when the user rights click something in the explorer tab. We provide a condition that it should only be displayed when the user clicks something with a file extension that matched the regex:

/\.png$|\.jpg$|\.jpeg$/;

So basically any image that is supported by remove.bg. We also specify that this menu item should trigger the command that we specified in the command section.

Lets Write Some JavaScript!

So when I said that vscode plugins are made with JavaScript I wasn't lying - I did however decide to use Typescript for this and it is also the language that is generally used to make vscode plugins.

In the src folder of the scaffolded project there is a file called extension.ts. This is the file that will run once your extension is loaded. At first I knew that I would have to, somehow, grab the API key that the user hopefully specified in the settings

function loadApiKey(): string | undefined {
  const config = vscode.workspace.getConfiguration('remove-bg');
  return config.get('apiKey');
}

The function above attempts to get the apiKey from the settings; if the setting is not specified it returns undefined.

Okay so next up I decided that I didn't want to overwrite the file once the background was removed but instead I wanted to create a new file. I decided to add the suffix -no-bg to the output file and to handle this I added a utility function. This would allow me to quickly change to some other suffix/extension if I wanted to; the function looks like this:

interface SuffixConfig {
  path: string;
  suffix: string;
  extension: string;
}


export function addSuffix({ path, suffix, extension }: SuffixConfig): string {
  const dots = path.split('.');
  return `${dots.slice(0, -1).join('.')}${suffix}.${extension}`;
}

The wonky part here is the slice between zero and minus one. What this does is return a new array where the last item in the original array is removed. In this case the thing that comes after the last dot will be removed.

So now that I had my initial building blocks I was able to stitch together the the pieces using the Official Documentation and the npm package.

This is the final code in the extensions.ts file:

// this method is called when your extension is activated
// your extension is activated the very first time the command is executed
export function activate(context: vscode.ExtensionContext) {
  const disposable = vscode.commands.registerCommand(
    'remove-bg.removeBg',
    async (uri: vscode.Uri) => {
      const apiKey = loadApiKey();
      if (!apiKey) {
        vscode.window.showErrorMessage('No API key was set.');
        return;
      }


      const sourceFile = uri.path;
      const outFile = addSuffix({
        path: sourceFile,
        suffix: '-no-bg',
        extension: 'png',
      });


      try {
        await removeBackgroundFromImageFile({
          path: sourceFile,
          apiKey: apiKey,
          outputFile: outFile,
          size: 'regular',
          type: 'auto',
        });


        vscode.window.showInformationMessage('Background remove successfully!');
      } catch (e) {
        vscode.window.showErrorMessage('Failed to remove background.');
      }
    },
  );


  context.subscriptions.push(disposable);
}

Closing Thoughts

The plugin can be found here and the code for the plugin is available here I actually decided to write an email to the creators of remove.bg to ask them if it was okay for me to use their logo. They were completely fine with this and actually responded very quickly.

This whole thing was a great learning experience and I regularly come up with new ideas for vscode plugins - if only a day had more hours.

I know that this article might not have been the most educational things ever but hopefully someone got inspired to make a plugin for a tool that they use regularly. A lot of the times somethings as trivial as wrapping a tool that someone else has made in order to make that tool easier to reach for is enough.

I would also like to make a shout out to the people working with remove.bg for being awesome enough to let me use their logo and for setting aside time replying to some random swedish guy who made a vscode plugin.

The BaseClass Anti-Pattern

Anton Holmberg — Thu, 23 May 2019 08:07:05 +0000

As a consultant I get to see a lot of code bases and on Android, by far, the most common anti-pattern that I find is what I call the BaseClass anti-pattern.

In this article I will explain what it is, why it is bad and why it is so seductive.

What is it?

So what is the BaseClass anti-pattern and how do I detect it?

Start out by opening the android project.
Locate an activity or a fragment class.
Does it extend something called BaseActivity or BaseFragment?

If the answer to #3 is yes then you my friend has fallen victim to the BaseClass anti-pattern. If you open the BaseActivity or the BaseFragment class and that class contains more than 50 lines of code then you're probably in deep trouble.

So why is this bad?

I will answer why it is bad by asking a question. What is the responsibility of the BaseActivity? Except for being an Activity what does the class name tell you?
NOTHING right...

So the naming is bad, lets give it a better name! Well if you open the class
chances are that you will find something like this:

class BaseActivity extends AppCompatActivity {
  @Inject
  Analytics analytics;

  @Override
  public void onCreate() {
    AppInjector.inject();
    super.onCreate();
  }

  @Override
  public void onStart() {
    super.onStart();
    analytics.trackScreen(this);
  }
}

Now try to come up with a name for this class, what is it responsible for?
ActivityWithInjectionAndAnalytics is not a very nice name and the "And" part indicates that the class has more than one responsibility and therefore is in violation of the single responsibility principle. So people resort to calling it things like BaseActivity and this creates a very non-explicit abstraction. Extending BaseActivity tells you nothing about what code you are bringing to your newly created activity.

So now you might think to your self that "This doesn't look too bad" and i would admit that no, two methods are not the end of the world. However this is usually not where the story ends. I have found the size of such a BaseClass usually has a linear correlation with time. It starts to accumulate things like creating a ViewModel / Presenter, adding utility functions that depend on a Context and sometimes even implementing business logic.

As time goes on people start to extend BaseActivity almost as a ritual rather than out of a need for some functionality that BaseActivity provides. Maybe you only care about one of the 150 methods overridden in the BaseActivity. Once you get to that point you have effectively created a static dependency on code that you don't have to depend on. You run code that doesn't have to run. Maybe the fact that the extra code gets executed doesn't hurt you (right now) but it will still execute and I absolutely promise you that one day, someone (maybe you) will modify some of the code in the BaseActivity to fit the need of a completely unrelated class and the class that you wrote in the first place will have a RuntimeException. You or your colleague will be blamed,
fired and die alone.

So why use a BaseClass?

I can only guess why other people do it but as someone who has created plenty of BaseClasses in the past I can say that, for me, it was mostly due to two things.

It was the easiest way of writing DRY (Do not repeat yourself) code.
Android specific classes aren't that suited for the decorator pattern.

I probably had some piece of code, like injecting dependencies, that I thought: "Hey I inject all of my activities in onCreate! That is duplicated code... lets get rid of that!". So I created my initial BaseActivity to handle the injection and started hacking away. Later on I would find some other piece of code that I would run in a lot of the activities, for instance converting from dp to px. To do this I required access to a Context. Since I learned in school that OOP is all about dat inheritance I just added a method to the BaseClass that did this conversion. Of course what I should have done was creating a static method in a utility class:

public final class Units {
  public static int dpToPx(Context context, float dp) {
    Resources resources = context.getResources();
    return (int) TypedValue.applyDimension(
        TypedValue.COMPLEX_UNIT_DIP,
        dp,
        resources.getDisplayMetrics()
    );
  }
}

Now any class that needs this can call it. There is simply no need to inherit any BaseClass so the caller of the method can sleep safe knowing that nothing strange runs in onStart, onCreate or any of the other callback methods that belong to the Activity.

If you can't get by with using a static helper method then create a class that handles your use case and instantiate it in the Activity. Better yet, inject it with your dependency injector of choice!

But what if we need to run something that depends on the callback methods, like subscribing to some observable data and then unsubscribing later on? Well in this case i would still prefer to be explicit over implementing it the implicit way with a BaseClass. Luckily we have even better options today with LifecycleObserver.

Conclusion

DO NOT CREATE A BASE CLASS FOR ALL OF YOUR ACTIVITIES AND FRAGMENTS!

It creates implicit, but very strong, coupling between your code and code that you probably, mostly, don't even care about.
It makes it very hard to get a full picture of what an class does.
It will grow and become a hot mess.
There is probably a lot of code in the BaseClass that would be really easy to unit test if it was in it's own class, but the fact that it is in the BaseClass makes you unwilling or unable to test it.

This is very much a rant and an opinion piece and I would love to hear your opinion on the matter!