DEV Community

Cover image for Don't use TypeScript types like this. Use Map Pattern instead
Nikola Perišić
Nikola Perišić

Posted on • Edited on

111 6 4 8 9

Don't use TypeScript types like this. Use Map Pattern instead

Introduction

While working on a real-life project, I came across a particular TypeScript implementation that was functional but lacked flexibility. In this blog, I'll walk you through the problem I encountered, and how I improved the design by making a more dynamic approach using the Map pattern.

Table of Contents

  1. The problem
  2. The issue with this approach
  3. Solution
  4. Clean code
  5. More secure solution
  6. Visual representation
  7. Conslusion

The problem

I came across this TypeScript type:

// FinalResponse.ts
import { Reaction } from './Reaction'

export type FinalResponse = {
  totalScore: number
  headingsPenalty: number
  sentencesPenalty: number
  charactersPenalty: number
  wordsPenalty: number
  headings: string[]
  sentences: string[]
  words: string[]
  links: { href: string; text: string }[]
  exceeded: {
    exceededSentences: string[]
    repeatedWords: { word: string; count: number }[]
  }
  reactions: {
    likes: Reaction
    unicorns: Reaction
    explodingHeads: Reaction
    raisedHands: Reaction
    fire: Reaction
  }
}
Enter fullscreen mode Exit fullscreen mode

Additionally, this Reaction type was defined:

// Reaction.ts
export type Reaction = {
  count: number
  percentage: number
}
Enter fullscreen mode Exit fullscreen mode

And this was being used in a function like so:

// calculator.ts
export const calculateScore = (
  headings: string[],
  sentences: string[],
  words: string[],
  totalPostCharactersCount: number,
  links: { href: string; text: string }[],
  reactions: {
    likes: Reaction
    unicorns: Reaction
    explodingHeads: Reaction
    raisedHands: Reaction
    fire: Reaction
  },
): FinalResponse => {
  // Score calculation logic...
}

Enter fullscreen mode Exit fullscreen mode

The Issue with This Approach

Now, imagine the scenario where the developer needs to add a new reaction (e.g., hearts, claps, etc.).
Given the current setup, they would have to:

  • Modify the FinalResponse.ts file to add the new reaction type.
  • Update the Reaction.ts type if necessary.
  • Modify the calculateScore function to include the new reaction.
  • Possibly update other parts of the application that rely on this structure.

So instead of just adding the new reaction in one place, they end up making changes in three or more files, which increases the potential for errors and redundancy. This approach is tightly coupled.

Solution

I came up with a cleaner solution by introducing a more flexible and reusable structure.

// FinalResponse.ts
import { Reaction } from './Reaction'

export type ReactionMap = Record<string, Reaction>

export type FinalResponse = {
  totalScore: number
  headingsPenalty: number
  sentencesPenalty: number
  charactersPenalty: number
  wordsPenalty: number
  headings: string[]
  sentences: string[]
  words: string[]
  links: { href: string; text: string }[]
  exceeded: {
    exceededSentences: string[]
    repeatedWords: { word: string; count: number }[]
  }
  reactions: ReactionMap
}
Enter fullscreen mode Exit fullscreen mode

Explanation:

  • ReactionMap: This type uses Record<string, Reaction>, which means any string can be a key, and the value will always be of type Reaction.
  • FinalResponse: Now, the reactions field in FinalResponse is of type ReactionMap, allowing you to add any reaction dynamically without having to modify multiple files.

Clean code

In the calculator.ts file, the function now looks like this:

// calculator.ts
export const calculateScore = (
  headings: string[],
  sentences: string[],
  words: string[],
  totalPostCharactersCount: number,
  links: { href: string; text: string }[],
  reactions: ReactionMap,
): FinalResponse => {
  // Score calculation logic...
}
Enter fullscreen mode Exit fullscreen mode

But Wait! We Need Some Control

Although the new solution provides flexibility, it also introduces the risk of adding unchecked reactions, meaning anyone could potentially add any string as a reaction. We definitely don't want that.

To fix this, we can enforce stricter control over the allowed reactions.

More secure solution

Here’s the updated version where we restrict the reactions to a predefined set of allowed values:

// FinalResponse.ts
import { Reaction } from './Reaction'

type AllowedReactions =
  | 'likes'
  | 'unicorns'
  | 'explodingHeads'
  | 'raisedHands'
  | 'fire'

export type ReactionMap = {
  [key in AllowedReactions]: Reaction
}

export type FinalResponse = {
  totalScore: number
  headingsPenalty: number
  sentencesPenalty: number
  charactersPenalty: number
  wordsPenalty: number
  headings: string[]
  sentences: string[]
  words: string[]
  links: { href: string; text: string }[]
  exceeded: {
    exceededSentences: string[]
    repeatedWords: { word: string; count: number }[]
  }
  reactions: ReactionMap
}
Enter fullscreen mode Exit fullscreen mode

Visual representation

TypeScript Types

TypeScript Types

Conclusion

This approach strikes a balance between flexibility and control:

  • Flexibility: You can easily add new reactions by modifying just the AllowedReactions type.
  • Control: The use of a union type ensures that only the allowed reactions can be used, preventing the risk of invalid or unwanted reactions being added.

This code follows the Open/Closed Principle (OCP) by enabling the addition of new functionality through extensions, without the need to modify the existing code.

With this pattern, we can easily extend the list of reactions without modifying too many files, while still maintaining strict control over what can be added.

Code?

You can visit the repository here.


Hope you found this solution helpful! Thanks for reading. 😊

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

Top comments (28)

Collapse
 
manuchehr profile image
Manuchehr

There are bunch of bad codes there too. For example you can just use Record instead of

export type ReactionMap = {

}
Enter fullscreen mode Exit fullscreen mode
export type ReactionMap = Record<AllowedReactions, Reaction>
Enter fullscreen mode Exit fullscreen mode

You should also separate links according to your article

Collapse
 
perisicnikola37 profile image
Nikola Perišić • Edited

This is better. Thanks!

export type ReactionMap = Record<AllowedReactions, Reaction>
Enter fullscreen mode Exit fullscreen mode
Collapse
 
manuchehr profile image
Manuchehr • Edited

good luck mate. Dont stop writing

Collapse
 
manuchehr profile image
Manuchehr

Plus you can use interface for objects instead of types

Collapse
 
perisicnikola37 profile image
Nikola Perišić • Edited

I used type because it is immutable. Unlike interface, type cannot be extended later in the code and I wanted to ensure that ReactionMap structure remains same and does not change somewhere else in the code. Thanks for the comment

Thread Thread
 
manuchehr profile image
Manuchehr

It's not actually accurate I'm afraid do a little research

Collapse
 
slar_ee98aa75925 profile image
Slar

Hey. Care to explain why we should use interface instead of type?

Thread Thread
 
manuchehr profile image
Manuchehr

I said you CAN not you SHOULD

Collapse
 
lexlohr profile image
Alex Lohr

But wait, at some point, we need to give the user a list of available reactions, right? So we already have an array containing them. We should use that to construct our map:

export const userReactions = [...] as const; 

export type AllowedReaction = typeof userReactions[number];
Enter fullscreen mode Exit fullscreen mode
Collapse
 
perisicnikola37 profile image
Nikola Perišić • Edited

Hi, Alex. Yes, that is possible, if I fetch them from the database for example. But what when not? For case when I get the reactions list from the user?

For example: If I used Caido tool (security auditing toolkit) and append some non existing reaction, in your case, it would be added to the ReactionMap without check. That would require manual checking or AllowedReactions.

In my case the AllowedReactions are the predefined reactions available on Dev.to, and they are specified in the FinalResponse type. The list of reactions is passed to the user through the reactions property.

This is, I would say, a more advanced project with a lot of data parsing and calculation processes.
In this project, the reactions received on certain dev.to blog post are mapped and then the structure like this is created:

{
    "article_reaction_counts": [
        {
            "category": "like",
            "count": 596,
            "percentage": 73
        },
        {
            "category": "unicorn",
            "count": 11,
            "percentage": 1
        },
        {
            "category": "exploding_head",
            "count": 17,
            "percentage": 2
        },
        {
            "category": "raised_hands",
            "count": 18,
            "percentage": 2
        },
        {
            "category": "fire",
            "count": 19,
            "percentage": 2
        },
        {
            "category": "readinglist",
            "count": 160,
            "percentage": 19
        }
    ]
}
Enter fullscreen mode Exit fullscreen mode

If you are interested you can check the code in the repository.

  • This is how I pass it to the user -> code

You can also try it out here: dev-to-rater.xyz

Collapse
 
lexlohr profile image
Alex Lohr

If you add another reaction to the array of existing reactions, it is obviously an existing reaction itself. Saying the types are more true than your data is a fallacy.

A single source of truth reduces the chances of errors and saves time if you have to change something.

Collapse
 
joelbonetr profile image
JoelBonetR 🥇

Good post, thanks for sharing! 😃👍🏻

Collapse
 
perisicnikola37 profile image
Nikola Perišić • Edited

You're welcome! If you want to view it in a real action, feel free to do it in the repository.
Specifically, the files are:

Thanks for reading :)

Collapse
 
wizard798 profile image
Wizard

It's absolutely correct, and it's very easy to see which properties are in this, manageable
Gonna use this

Collapse
 
perisicnikola37 profile image
Nikola Perišić

Thanks for feedback. Glad it was useful

Collapse
 
slar_ee98aa75925 profile image
Slar

Cool! I was doing this without even acknowledging it. It's nice to give it a name (Map Pattern) so it feels solid. Definetely something everyone should know and apply.

I usually kind of skip the "control" part and just use Record<string, Whatever> and forget about it. I don't even use the extra type ReactionMap, I just straight go

reactions: Record<string, Reaction>
Enter fullscreen mode Exit fullscreen mode

Although yeah, for bigger projects the control should be included without a doubt.

Nice post my man.

Collapse
 
perisicnikola37 profile image
Nikola Perišić

Thanks for the comment and feedback man. Yes, it sounds solid. This is a problem that many people get wrong because they don't think about extensibility.

Collapse
 
toothlesstarantula profile image
Yannick Napsuciale

Nice

Collapse
 
perisicnikola37 profile image
Nikola Perišić

Glad you liked it

Collapse
 
mahmoudalaskalany profile image
Mahmoud Alaskalany

Good post very helpful and thanks to all the people in the comments that are suggesting and improving it

Collapse
 
perisicnikola37 profile image
Nikola Perišić

Yes, that is key. To help each other

Collapse
 
nahidulislam profile image
Nahidul Islam

Great one!

Collapse
 
perisicnikola37 profile image
Nikola Perišić

Thank you!

Collapse
 
mehdi_messaadi_5ef3ac67bb profile image
Mehdi Messaadi

Thanks, this a great tip!

Collapse
 
perisicnikola37 profile image
Nikola Perišić

You're welcome!

Collapse
 
realsergiy profile image
realSergiy
Comment hidden by post author

Some comments have been hidden by the post's author - find out more

Billboard image

The Next Generation Developer Platform

Coherence is the first Platform-as-a-Service you can control. Unlike "black-box" platforms that are opinionated about the infra you can deploy, Coherence is powered by CNC, the open-source IaC framework, which offers limitless customization.

Learn more

👋 Kindness is contagious

Dive into an ocean of knowledge with this thought-provoking post, revered deeply within the supportive DEV Community. Developers of all levels are welcome to join and enhance our collective intelligence.

Saying a simple "thank you" can brighten someone's day. Share your gratitude in the comments below!

On DEV, sharing ideas eases our path and fortifies our community connections. Found this helpful? Sending a quick thanks to the author can be profoundly valued.

Okay