DEV Community: Dariusz Cichorski

3 effective methods of learning new programming technologies (and tips on how to use them)

Dariusz Cichorski — Wed, 31 Aug 2022 08:13:19 +0000

Introduction

Software development is a profession that requires great flexibility in the ever-changing world of technology and programming languages. It doesn't matter if you're just at the beginning of your career or if you're already an experienced dev, you'll have to adapt and learn new things.

Here's a list of 3 effective methods of learning new technologies that you can use.

Method 1: Learn from video tutorials

Video tutorials are a great way of learning new things. You can easily find free ones on popular video-streaming websites that will be enough for most cases. If you're unsure what exactly you should learn on your path of, let's say, front-end mastery, you can search for Bootcamp-type video tutorials curated by professionals. That will help you develop new skills along some predefined path.

When starting learning from a video tutorial it's good to skim it before spending much time on it. There are many reasons the tutorial might not be suitable for you - it may not teach the things you're interested in or its style might not fit your preferences. If that's the case, don't waste your time on it and search for another one. The internet’s resources are endless, therefore it's worth learning how to pick the good ones.

The important thing to note is that just watching videos is not enough. You can spend hours binge-watching and learn nothing. That's because the human mind always tries to save energy whenever it's possible and loses focus easily. To take the most out of watching video tutorials, don't rush it. Take the time you need to process the knowledge. If the tutorial takes 1 hour, it doesn't mean you have to finish it just as quickly. No time pressure, it's not a race! You'll benefit more from a learning process divided into days than rushing through one take.

Usually, you're asked to code along to the video. That's a good idea in most cases, as it boosts learning straight away, but there are drawbacks to that! You are forced to constantly pause the video and it may lead to losing focus. If that's the case for you, I recommend fully focusing on only the part of the tutorial, as they are usually divided into shorter, 10-30min sections, and then after finishing it, trying to write the same code (or solve the same problem) as the teacher from memory. If you can't remember something, try googling it - this way you'll learn effectively and practice searching (which will quickly become beneficial). If you're unable to find the solution this way, rewind the video and get back to it.

Method 2: Learn from blog posts and written tutorials

Another effective method of learning is reading blog posts and written tutorials. There are tons of those all over the internet. You can find ones created by respected teachers or code enthusiasts.

Written tutorials are no different from videos when it comes to approaching the problem and building your knowledge, so they can be treated as an alternative. Naturally, everyone is different so it's down to personal preferences which method you will like more.

The good thing about reading tutorials is that you can easily search through them (CTRL + F), which comes in handy in many situations and reduces the time needed to find something. What's more, you don't have to rewrite the code, as you can copy the snippets straight away. It's not always a good thing, as rewriting something may help in understanding and remembering it, so it's up to you to decide and use it as you need.

The nature of online publications keeps them easy to create and maintain. That's great because if you're interested in some novelty technology, there's a big chance someone has already written something about it. This form of learning has an advantage over reading official documentation as it's more human-user-friendly and often written in the non-robotic language. Most of the time it's also covering real-world scenarios and it's easier to use that knowledge in your work.

Method 3: Learn from the official documentation

Another alternative for learning new technology is going through its official documentation. In contrast to written tutorials, official docs have a particular form, as they are written in the specialized, more robotic language, which often makes them sound uninteresting. This can often be a problem for beginner programmers and can lead to not fully understanding it, but there's another side of the coin - this reference book form makes it great if you're already familiar with the technology and looking for some specific detail.

The great advantage of docs over other types of materials is that it packs the most accurate answers to all potential questions in one place, which saves you time searching them in other places.

Nowadays, good technology docs should contain a "Getting Started" guide, which often gives you a huge boost in getting on board with it and quickly learning the basics. Many other materials (video and written tutorials included) are based on them - or even just paraphrasing them. Despite that, docs may not be the perfect place to start for beginner programmers as they often assume that you already know a lot of programming fundamentals. This makes them great as an additional source of knowledge to tutorials or if you're learning a programming language, textbooks.

The docs are perfect when you want to search for something specific. You often find yourself in a situation where you remember the function name and want to learn the details - that's when you should use the docs search tool and you will be quickly redirected to the right place. It's always easier than trying to find it in a 700-page book or several hours-long video tutorials.

Conclusion

Those are 3 of the methods I've used the most while learning new technologies during my programming journey. It is very important to learn what method fits your preferences and is the most effective for you.

It's worth mentioning that whatever method you use, it's crucial to practice everything on your own. Those methods are just boosters for the learning process, and they should always be considered support for practical training.

Which methods of learning do you find the most effective and what are your opinions on them? The comment section is yours!

5 things I wish I knew before starting serious development (a journey into code perfection)

Dariusz Cichorski — Thu, 23 Jun 2022 10:00:43 +0000

Writing code that does the job is easy. Writing a beautiful code that is worthy of being called clean could be more troublesome. There are many opinions about what a clean code is. Some say it should be elegant, nice and pleasant. Others say it should be easily readable. Whatever definition you find, you can notice that the idea is for the author to care about the code that's being created.

According to Uncle Bob, the ratio between reading and writing code is equal to 10:1. Because of this, it's important to make sure the code meets the principles mentioned in this article (and many, many more that are not mentioned). Writing quality code is harder and takes more time, but trust me, it's a good investment.

There are several rules that you can follow while writing code that will improve its quality and take you a step closer to clean code mastery.

Use names that represent your intentions

Names are a fundamental part of writing code. There are names of the functions, parameters, classes, files, and folders. Using the right name can be crucial. Look at it as a time investment - it takes some, but it saves more.

The name of the function or class should be an answer to every potential question - it should indicate why it exists, what it does and how it's meant to be used. If the name requires a comment it may be an indication it does not represent the intention.

You can notice it's not easy to understand what the meaning of the field (even with the comment as the description):

m: number; // solving time

The name m does not explain anything - it doesn't indicate what the actual purpose of the field, and even the comment isn't precise enough. The below example of the name is much better as it answers every potential question about it and does not require any additional explanation:

solvingTimeInMinutes: number;

The same goes for functions. What's the purpose of the function below?

function calculate(value: number) {
  return (5 / 9) * (value - 32);
}

It's quite difficult to say, even though it's just a one-liner function. That's because the name and the parameter are not self-explanatory. Here's the same function, but represented with a clear intention:

function fahrenheitToCelsius(fahrenheit: number) {
  return (5 / 9) * (fahrenheit - 32);
}

To learn more about good naming practices search for:

programming naming conventions

Avoid comments (until you really need them)

A good comment can be a lifesaver. An unclear one can be deceptive and cause confusion. Unnecessary comments should be avoided, as the clean code should be self-explanatory and should tell the story on its own.

Here's an exaple of a very bad comment:

// Always returns true
function returnFalse() {
  return false;
}

The function above does not do what the comment says. Just imagine using a wrongly commented function in some real-world scenario. The consequences could be bad, right?

Same goes for the below situation:

// Checks if player takes part in rating
if (player.contexts.includes(PlayerContext.RankPlayer) && player.isActive())

It's much better to restructure the code and use something like this:

if (player.takesPartInRating())

The instruction above is much cleaner than its previous version - it clearly explains its purpose without the need for a comment.

But there's more than this - having code that regurarly uses comments as a sort of documentation requires more resources to keep it updated. You not only have to work on the code, but you also have to work on the comments to make sure they represent the intention behind the code. You also have to remember to keep them updated!

Another example of poor practice is keeping the commented-out code in the repository. There's nothing worse than the code like this:

const player = this.service.getPlayer();
player.initializeSession();
// player.setSessionStartTime();
// player.setNewlyCreatedSession();

The other developers working on that code will think the commented-out part is an important one and it should be kept for some reason. This leads to keeping some old junk code in the codebase, which should be avoided. Instead of commenting on the code, it should be removed.

In most cases seeing a comment means the code could be better, but there are some exceptions. One of them is a TODO comment.

// @TODO: integrate with amazing-service once it's ready
function doSomethingAmazing(): void {
  (...)
}

TODO comments indicate tasks that should be done, but are impossible to do right now. It can be a reminder to remove old functions or an indication that some problem should be solved. Most of the IDEs have features that allow targeting TODO comments quickly - they should be regularly targeted and solved.

Another example of a valuable comment is the one that describes the decision behind the code. Sometimes we are forced to use some frameworks or browser-specific stuff - in that case, a comment can be a lifesaver and reduce the time needed to understand it.

// Fix for scroll position computations
// See https://github.com/swimlane/ngx-datatable/issues/669 for details
setTimeout(() => 
  this.doSomething();
}, 200);

It's important to get rid of any noise in the code, but also take advantage of the knowledge that some comments are valuable and can be helpful.

To learn more about good comments practices and how to write code without the need for comments search for:

programming comments best practices
programming self-documenting code

Keep your code formatted

You only get one chance to make a first impression. That's why you should really focus on the code formatting as it's the first thing everyone reading the code sees. It's an aspect that instantly makes a statement about code quality and its consistency. The code should always be perfectly formatted and it's every line polished.

It's important to specify the rules of formatting code in the project to keep it consistent. Each project is different so the rules may also be different, but once we decide on them, they should be respected. Many tools can help to automatically format the code according to the rules.

What do you think about the below code?

  function  doSomethingAmazing ()  : void
    {
const data = this.service.loadData();

  data.executeImportantLogic() ;

    if(data.somethingHappening)
{

data.executeMoreImportantLogic();
 }


this.service.saveData(data);

 }

The function above would compile without any problem, but is it even readable? It's formatted very poorly and it becomes impossible to understand. As you can see the indent level is not respected (or even specified), there are many unnecessary blank spaces and blank lines that make it impossible to effectively read it.

We can format the function above like this:

function doSomethingAmazing(): void {
  const data = this.service.loadData();
  data.executeImportantLogic();

  if (data.somethingHappening) {
    data.executeMoreImportantLogic();
  }

  this.service.saveData(data);
}

It's much better this way, right?

It's important to stick to the guidelines of the language we use while formatting the code. Each language or framework comes with its own formatting standards that should be known and respected. Respecting them is crucial as it helps new team members in writing their first code in the project. With every new custom formatting rule, it becomes more difficult for newcomers to quickly adapt to it (and also for older team members).

Creating code that works is not enough. To keep code clean we need to focus on its formatting, which will improve its quality.

To learn more about code formatting search for:

code formatting best practices
insert your technology coding style guide

Keep your functions short (and their purpose straight)

One of the main principles of creating functions should be to keep them short and simple. Functions should be easy to understand as they focus on one thing only. Honoring that rule will greatly reduce the time needed to understand it.

It should also operate on one level of abstraction to prevent mixing up less important technical details with crucial logic. The abstraction in this case means a metaphorical layer in which we create the functions. If we had a function that creates a list and increments it, it would operate on two levels of abstraction: first for creating the list, second for incrementing it.

Let's analyse the below function (but don't spend too much time on this):

function solveTask(solution: TaskSolution): void {
  const player = this.playerService.getPlayer();

  if (!player.gamingProfile) {
    this.profileService.createNewProfileForPlayer(player);

    this.playerService.startSession();

    if (this.settingsService.notificationsEnabled) {
      this.notificationService.notify('Player profile session started.');
    }
  }

  const solutions = this.trainingService.getTaskSolutions(player);

  if (!solutions.any(sol => sol.id === solution.id)) {
    this.trainingService.reportPlayerSolution(solution, player);

    if (this.settingsService.notificationsEnabled) {
      this.notificationService.notify('Task completed!');
    }

    const achievementReached = this.achievementService.reportSolutionEvent(solution, player);

    if (achievementReached && this.settingsService.notificationsEnabled) {
      this.notificationService.notify('Achievement unlocked!');
    }
  }
}

As you can see the function above is not too long, but it fails the important principles we've covered before. Firstly, it does more than one thing. Secondly, it does not operate on one abstraction level - it mixes different abstraction levels. Also, there's a code duplication there as the same code exists more than once. This function could be restructured by decomposing as per the below:

function solveTask(solution: TaskSolution): void {
  const player = this.playerService.getPlayer();
  this.handleGamingProfileCreation(player);
  this.handleReportingSolvedTask(player, solution);
}

Which would then use the functions below:

function handleGamingProfileCreation(player: Player): void {
  if (this.hasGamingProfile(player)) {
    return;                                                
  }

  this.createPlayerGamingProfile(player);
}

function handleReportingSolvedTask(player: Player, solution: TaskSolutin): void {
  if (this.alreadySolvedTask(player, solution)) {
    return;
  }

  this.reportSolvedTask(player, solution);
}

The functions handleGamingProfileCreation and handleTaskSolving have been decomposed from the original function.

This way solveTask function does one thing only - solves a task. It's operating on its abstraction level and it delegates its original logic into functions that are smaller, more focused, and easier to understand. Note that each function operates on a different abstraction level - one handles gaming profile creation and the other one handles reporting of the solved task.

The decomposing process we've covered may become very handy in restructuring (or creating) complex functions and can lead to a cleaner and better code.

It's worth mentioning that not all of the code should be decomposed into small functions. Some cases could lead to having 10 different functions that are used only in our decomposed function. It's a trap that should be avoided if possible. You should make decisions about decomposition based on the function readability. If you struggle with that, there are some questions worth asking that may be helpful in making the decision:

Will someone else make use of that function?
Can the decomposed function be public?
Will it help in creating unit tests?
Am I getting rid of complexity or adding it?

To learn more about creating quality functions search for:

programming functions good practices
programming functions abstractions
programming refactoring decomposition

Be a team player

The last (but not least) rule while working on the code quality is to be a team player. Most of the projects are developed by a multi-developer team. That's why it becomes crucial to cooperatively work on the code quality.

Being a team player is also treating the code as ours, not mine or theirs. Each team member is evenly responsible for its quality. There will be many cases in which you will encounter code blocks that were written in the past and require some treatment, e.g. badly named fields or wrongly formatted functions. In those cases the rule of leaving the code in a better shape than we saw it comes to life - it's not forbidden to improve code that someone else wrote earlier as we all work on the same codebase. The code will benefit greatly from respecting this rule, as its quality will always increase.

It's also important to remember, especially while doing code reviews, that we are reviewing someone else's code and not the actual person - this is a crucial part of keeping team spirit and respecting each other. This way of thinking about the code also helps in sharing code with others - as it decreases the fear of being offended by another project member. It also increases the discussions about the code itself, which is a key aspect of constantly increasing code quality.

Conclusion

A professional developer should always write the best code possible. It isn't easy, it's the process of constantly learning new aspects of improving things, but it's the way to go as it decreases many potential issues and increases overall quality.

Writing code is a work of art - it should be perfect, but perfect doesn't always mean the same.

A quest to find TypeScript's inheritance tree (with top and bottom types as main NPCs)

Dariusz Cichorski — Thu, 07 Apr 2022 11:00:02 +0000

Introduction

I need you to imagine that you’re a lvl 5 software developer aka. computer mage trying to level up fast. What’s the quickest way to do that? By doing NPC’s quests!

And today’s mission is to find TypeScript's inheritance tree. You constantly need to get some experience to develop your skills.

Object-oriented programming is a way of reflecting anything with the usage of objects with specific behaviors. As in life, those objects can share certain similarities - that's where inheritance comes in.

It's a very important aspect of programming, as it is one of the key factors that impact the code quality, especially in highly scalable systems.

TypeScript, as an example of object-oriented programming language, also supports inheritance, but it comes with some specifics worth knowing.

Join me in a quest of finding TypeScript's inheritance tree and learning about the associated top and bottom types. And trust me, such a quest can become a real journey with highs and lows on our way (literally).

Quest started - Difficulty level: MEDIUM

Finding class inheritance tree

To start, let's get straight to the point and create our first class: a Hero:

class Hero {
  private name: string;

  constructor (name: string) {
    this.name = name;
  }
}

With that sorted out, let's go further and create two other classes which will extend the Hero class:

class Jedi extends Hero {
  constructor() {
    super('Luke Skywalker')
  }
}

class BountyHunter extends Hero {
  constructor() {
    super('Bossk')
  }
}

The above code is a perfect example of how inheritance works in TypeScript. By extending the base class Hero, we've created two other classes: Jedi and BountyHunter, which now share all of the Hero's attributes (in our case: a name).

We can therefore say that:

A Jedi is a child class and the Hero is the parent class.

A BountyHunter is a child class and the Hero is the parent class.

If you think about it, we've just created a simple inheritance tree, which in our case looks like this:

The class inheritance tree is a reflection of how different classes extend each other and what the relationships are between them. Every type in TypeScript is part of the inheritance tree.

The tree always has multiple levels - like the one above has two (one with Hero, the second one with Jedi and BountyHunter).

Looking at the inheritance tree we can see how specific the types are on certain levels. In our case, the Hero class is the least specific type because it's above the others. Jedi and BountyHunter are more specific extensions of the Hero type.

Climbing up the inheritance tree

What if I told you there's more than that at the top of our tree? Right now the tree looks more like this:

In TypeScript every type inherits from the Object type, which means that our Hero class is the extension of that type, too. This type comes with some familiar methods that we can use, e.g. toString(), hasOwnProperty().

What's interesting in the tree is that when you look closely, you will notice the String class is another type extending the Object and it's at the same level as our Hero! There are in fact more types on this level - including all of the classes we create.

But the Object isn't our final destination. At the very top of our tree is the Unknown type - it's the least specific type in TypeScript's inheritance mechanism. You're probably wondering what's the purpose of this type, as it is in fact completely empty, without any properties and methods. Let me explain, as this is a very useful one.

Into the unknown

I'm sure you've had thousands of situations in which it was hard to specify what the exact type of the value was. It happens a lot when you work with some external APIs or libraries. I've seen the type Any being used many times in such scenarios. But that's actually a big antipattern and potential danger for our code. Unknown type requires some additional handling but it also decreases the potential for bugs thanks to the help of a compiler.

It's worth noting that a lot of the time, a programmer is responsible for using the Unknown type. It's a clear indication that the type you're dealing with should be double checked before using. And such indication comes with a lot of support from the compiler, as you'll learn in the cases below.

Type guards

The cases in which there is no guarantee what the value is, are a perfect opportunity to use the Unknown type. It makes sure that those values are not used without being strictly checked. To do so we can implement type guards:

function isString(value: unknown): value is string {
  return typeof value === 'string';
}

function isHero(maybeHero: unknown): maybeHero is Hero {
  return maybeHero instanceof Hero;
}

Using such functions makes us secure about the type of the value. As you can see it is a very easy way of checking if the unknown value is some simple type (e.g. string) or some complex class (e.g. Hero). What's more is that once you use such a function, the compiler will know the type of checked value:

const something: unknown = 'something';

if (!isString(something)) {
  // something is of type unknown here
  throw new Error('Unsupported type.')
}

console.log(something); // something is of type string here

Type assertions

You can use type assertions while working with Unknown type:

function func(value: unknown) {
  (value as number).toFixed(2);
}

Such an assertion tells the compiler the type of the value, so it becomes possible to use type specific methods (e.g. toFixed() for a number). But at this point, as the NPC would say, "BEWARE! This way you are responsible for the type, not the compiler!"

Equality

In cases where you want to execute some logic when the Unknown type equals some specific value, you can do as follows:

function doSomethingAmazing(value: unknown) {
  if (value === 123) {
    amazeMe(value); // value is of type number
  }
}

What's interesting here is that the compiler knows exactly what the type of the value is if it passes the above conditional expression. So if the value equals 123, it means the value is a number! If a string (or any other type) is passed to the above function, it will execute without any error, but the conditional result will not be positive.

Falling down from the tree

We've already reached the top of the inheritance tree, but there's some unexplored area at the bottom of it. From that perspective it looks like this:

The Never type is the bottom of the inheritence tree. It inherits from every other type in the tree. Thanks to that nothing else is assignable to it. It's more specific than any other type so it can be assigned to everything else. There are some specific cases in which this type may be helpful.

Exhaustive checking

The most common use for the Never type is to achieve exhaustive checking in conditionals:

const heroOrHunter: Jedi | BountyHunter = new Jedi();

if (heroOrHunter instanceof Jedi) {
  console.log('I am a Jedi');
} else if (heroOrHunter instanceof BountyHunter) {
  console.log('I am a BountyHunter');
} else {
  const exhaustiveCheck: never = heroOrHunter;
  throw new Error(`Unknown type ${exhaustiveCheck}`);
}

The above code checks the type of heroOrHunter and executes some conditional logic. But in case there will be some other type in it, it will mark the type as Never, to make sure the compiler will stand strong against any other specific usage of that value. It can be very helpful and provide a higher level of code safety in more complex cases.

Error throwing function

Another common use of the Never type is as the return type of a function that exists only to throw an error:

function throwError(message: string): never {
  throw new Error(message);
}

This way we can prevent someone from using the value returned from this function as it now returns the Never type - which is the bottom type, so it cannot be assigned to anything. This makes it a reasonable alternative for returning Void.

In TypeScript a function that does not return a value returns undefined. Returning the Never type instead of Void produces a compiler error and prevents us from such a scenario:

function sayHi(): void {
  console.log('Hi');
}

const hi: void = sayHi();
console.log(speech); // Outputs: undefined

Conclusion and gaining EXP

We've explored TypeScript's inheritance tree and in doing so, we've covered the top and bottom types. That knowledge is one of the milestones of TypeScript's mastery.

Writing code that compiles successfully is one thing, the other is writing the code that is effective and bug-free. Using the knowledge we've learned during our quest will surely make it so.

Our quest is now complete and you, dear reader, are reaching the next level of your technical skills.

+1500 EXP!

Congrats! You are now lvl 6 software developer/computer mage.

Your next Quest awaits...

Can a man become a starship? Yes, in TypeScript. A guide to structural and nominal typing

Dariusz Cichorski — Wed, 09 Feb 2022 11:02:45 +0000

*TikTok music playing* You can do anything you want when you're... a programmer! But for real - programming has become a way of reflecting real-world, often providing a helping hand in various processes by using code. We can create all sorts of things.

Those things can have different shapes and meanings, serve different purposes and do all sorts of different stuff. Like making a man become a starship. Let's learn how to achieve that using TypeScript and, on the ocassion, gain some knowledge about structural and nominal typing.

TypeScript can be a good example of our starship-theorem because it's here for you when you need it. Nowadays, it's basically everywhere - both in front-end and back-end worlds, but to be precise and effective you have to remember some important things and use them to provide a valid solution to the problem.

Our assumption is as follows:

"A man cannot become a starship."

Sounds very simple and straightforward, right? Well, it's actually not so simple and I'll prove it to you.

Shaping the world

Let's play with our assumption in TypeScript. Let's say we have a man and a starship - they all have the same properties: name and id:

interface Person {
  name: string;
  id: number;
}

interface Starship {
  name: string;
  id: number;
}

Let's prepare some typical real-world situation:

const person: Person = {
  name: 'Han Solo',
  id: 1,
}

const starship: Starship = person;

Surprisingly, the code above is absolutely correct and will compile without any errors, but if you think about it, our assumption is broken. Why is that?

TypeScript (as the name suggests...) is built over types. If something has the exact same properties, it's the same thing. It doesn't matter that it's technically a different interface.

The difference comes when one of the interfaces is more specific than the other. Let's discuss the scenario as below:

interface Person {
  name: string;
  id: number;
}

interface Starship {
  name: string;
  id: number;
  serialNumber: string; // newly added field
}

This time, our real-world situation will behave a little differently:

const person: Person = {
  name: 'Han Solo',
  id: 1,
}

const starship: Starship = person; 
// Compiler error:
// Property serialNumber is missing in type 'Person' 
// but required in type 'Starship'.

Compiler error message pretty much sums that up, but why is that happening? By adding a new field serialNumber to the Starship interface it became a more specific type than the Person, which made it impossible assigning its value to the starship. Let's now change the rules and invert the real-world scenario:

const starship: Starship {
  name: 'Millenium Falcon',
  id: 1,
  serialNumber: 'YT 492727ZED'
}

const person: Person = starship;

The above scenario will compile successfully, because the starship contains all fields required in person type (name, id), so it can in fact become one.

To sum that up, it's safe to say that:

Types are considered the same if they share the same structure (fields).

More specific type can be assigned to the less specific type (but has to come with all required fields of the less specific type).

Less specific type cannot be assigned to the more specific type (as it does not come with all required fields).

What does that mean for our assumption? It means that a man can actually become a starship, but only when they share the same fields.

In TypeScript, all of that is called structural typing, which is the default type checking mechanism. It works well in most cases, but there are some that require more precision. In those cases, nominal typing comes to the rescue.

Being more serious

In situations when type integrity becomes a key aspect of our code, we have to dive a little deeper into what TypeScript is able to provide.

Nominal typing is a star in this case. Being able to relate objects strictly based on their types, not their members, it stands in contrast with structural typing.

Currently TypeScript has no native support for nominal types (see history of the topic), but there are a few ways we can easily implement it ourselves.

Branding

The first technique is called branding. It requires adding a brand field with a string literal as a value. Let's get back to our previous real-world situation, but this time, let's 'brand' our interfaces:

interface BrandedPerson {
  brand: 'person';
  name: string;
  id: number;
}

interface BrandedStarship {
  brand: 'starship';
  name: string;
  id: number;
}

const person = {
  name: 'Boba Fett',
  id: 1,
} as BrandedPerson;

const starship: BrandedStarship = person;
// Compiler error:
// Types of property 'brand' are incompatible.

The above code is pretty much the same that we implemented before using structural typing, but this time the compiler stands strong against letting a man become the starship, as they are in fact a different types.

As you probably already noticed, this technique comes with the disadvantage of requiring the implementation of additional fake object properties.

Enum Intersected Types

Another way of implementing nominal typing is using enums. In TypeScript enums are unique, so any type intersected with an enum becomes unique as well. Let's use that knowledge in our scenario:

enum PersonType {}
type Person = PersonType & {
  name: string;
  id: number;
}

enum StarshipType {}
type Starship = StarshipType & {
  name: string;
  id: number;
}

const person = {
  name: 'Boba Fett',
  id: 1,
} as Person;

const starship: Starship = person;
// Compiler error:
// Type ... is not assignable to type Starship.

As before, this serves our purpose of not letting a man become a starship, but this time using a type intersection with unique enum.

This technique comes with the advantage of not adding any fake properties (as in branding), but also with the disadvantage of returning two type declarations for every type.

Private Class Members

Yet another way of handling nominal typing is the usage of private class members that denote the types. As previously, let's look at the example below:

class Person {
  private person: void;
  name: string;
  id: number;
}

class Starship {
  private starship: void;
  name: string;
  id: number;
}

const person = {
  name: 'Boba Fett',
  id: 1,
} as Person;

const starship: Starship = person;
// Compiler error:
// Property 'starship' is missing in type 'Person'
// but required in type 'Starship'.

Given the compiler error we've got, this method also serves our purpose.

The concept of this is actually the same as branding, but if you look closely it comes with the advantage of not showing up additional property (brand) on the object, as it is private. Private class members can also be encapsulated.

Private Class Members Encapsulation

Let's be like Agent 47 for a moment with elegant and effective technique and play with some encapsulation. Here are our fundamentals:

class Tagged<T> { 
  private _secret_tag: T 
}

type Nominal<Type, Tag> = Type & Tagged<Tag>;

Having that prepared, let's get back to our previous scenario and code it using Nominal type:

type Person = Nominal<{
  name: string;
  id: number;
}, 'Person'>;

type Starship = Nominal<{
  name: string;
  id: number;
}, 'Starship'>;

const person = {
  name: 'Boba Fett',
  id: 1,
} as Person;

const starship: Starship = person;
// Compiler error:
// Type 'Person' is not assignable to type 'Starrship'.

Once again, the above implementation prevents a man from becoming a starship, which solves our issue.

The encapsulation gives us the power of hiding it in a utility file or utility library, which has a positive impact on our code quality. It also comes with the advantage of brand property not appearing on the object (like in previous techniques).

Motivation

Okay, we've come a long way since the start - we've learned about two different ways of type handling in TypeScript: structural and nominal typing and how to achieve them. But let's ask ourselves a question: is nominal typing really that important? It actually depends on the case.

Let's think about some system that requires encapsulation, e.g. encapsulation within modules - a scenario in which no code from the outside should interact with module code, except through explicit predefined channels.

In that case, nominal typing can be responsible for making sure that some predefined functions will not be called with simply any object that happens to have the same properties like the one that is required.

Nominal type makes a statement that the code using it is created specifically with this type in mind.

Let's go a little bit further with our encapsulation case and create a library that will play relaxing songs to keep us motivated in work for a certain amount of time. Instead of implementing it like that:

export function play<T>(time: number) {
  this.playSongsByBand('Slayer', time);
}

we can use nominal typing:

export type Minutes = Nominal<number, 'Minutes'>;

export function play<T>(time: Minutes) {
  this.playSongsByBand('Slayer', time);
}

As you can see, the above scenario benefits highly from using nominal typing. Instead of a function that takes an unspecified amount of time as a parameter, we end up with a self-explaining parameter in which you don't have to look to the documentation to understand its unit. And, as the type is nominal, you won't pass your age by mistake!

Conclusion

TypeScript mastery comes with understanding it. By knowing how it handles typing we can take our code to new heights.

Is nominal typing better than structural typing? No, the default typing mechanism will still be the one to go for most of the cases, but if you have a real need of being type sensitive, you know what you need to do.

We started with the starship-theorem. We did it not only because it gave me right to put here a cool transformers gif (or not only why) but also because it’s true. But to be true it must be as follows:

A man cannot become a starship. Unless you're using structural typing. Then in some cases it can...

A little bonus

Let's say we have a collection of different types that share the same property, e.g. name. We can implement a function that will take anything containing a name field and return its length.

function getNameLength(something: { name: string }) {
  return something.name.length;
}

This way, you can pass any type (e.g. Person, Starship, Company, Band, etc.) containing name field to this function.

This can be useful, right?