DEV Community: Sachit

Are custom decentralised app the future?

Sachit — Tue, 23 Dec 2025 13:18:31 +0000

Building custom apps are not easy, they are expensive and they take a lot of time to build. It requires team of people to interpret the problems and find solutions for not just one use case but most often generic enough that others can also find it useful.

Every app I've used, has had the same problems that I've experienced. For example:

The app have a long onboarding process.
The app needs a lot of data before it starts becoming useful.
The app needs to have friends or community for it to be useful.
The app is bloated and slow and 80% of the features are useless to me.
The app is generic and I have to fit my workflow or my process into how the app want's me to, which is backward and not natural.
The app requires me to pay for features that I don't need.
The app requires a subscription and its cheaper to buy an annual subscription than monthly.
The app shows me ads that only distracts me from doing what I need to and some apps give options to be a paid customer to remove ads but charge an arm and a leg for the privilege.
They want data that has no requirement for the app, e.g. location or microphone etc. just so that they can collect and sell that data to brokers.

Many more but i don't want to go on and on ...

This has got me thinking, with the advancements in technology specially Artificial Intelligence, Machine leaning and Large language models that are for even becoming smarter and better at coding, why can't we build tailored custom apps that can run securely on the user's computers or hosted by them securely in the cloud ? They control the data and privacy, they only get features they need and no bloat or ads that get in the way and not to mention the keeping you hooked for longer hours that will only make us do things like:

Not spending time with family or friends.
Not having time to exercise or staying healthy.
Not having time to cook and having take out food using apps like Uber eats and pay higher amount to have the same meal that they can either by going to the restaurant or picking up the food themself ?
and many more ...

Now admittedly, I've been building apps for almost two decades and I am very comfortable with building apps that are secure and privacy aware. Operating systems vendors like Apple, Microsoft, and Linux can be the platforms that allow users to build custom tailored applications: Nothing more, nothing less that runs on their infrastructure so that the user can have the peace of mind and focus on just building out a solution for their very specific problem and their way of solving it for what will work for them.

I'm starting on this journey on building apps for my problems. Along the way I will try and figure out how this can scale to other users that might not be as technology versed or aware as someone like myself who has relevant industry experience.

Here's an example of an app that is very specific to my needs, a very simple fitness tracker. This is built using Claude Opus 4.5 and claude code. It's very specific to what my fitness goals are and any feature in this application thus far is what I need, nothing more, nothing less. I will build on this and improve the application as my needs or requirements progress. And I don't need to share this data with anyone, everything stays on my computer, in my control, safe and sound.

This is in a way a decentralised application. If a hacker wants to get this data, they will have to hack my computer which takes a lot of time and effort. If they have to do it for every single user in the world, it will be a very expensive exercise on their part to do this which makes it's not as viable as attacking a central server where a lot of data is stored is a lot more attractive.

Here's the app: Its not hosted anywhere, it sits on my computer, is available to me locally on any of my devices and is hosted within my private network.

My Custom Fitness App

I would encourage everyone to learn this technology and not be fearful of the future that this promises. Centralisation and DecentraliSation both have their advantages and disadvantages so by no means is this the solution that will solve all the problems in the world, but at least it will give the user the power of using or creating solutions to their problems in the way that really works for how they think and how they work. If you have a question on how I've built this, feel free to leave a comment and I'm happy to share how I've built this so that you can be on the same journey as I am.

Start local to mitigate any risks of your data being exposed or sensitive information getting in the hands of people. Once the infrastructure catches up with this idea, I'm hopeful that those things will not be something a user will have to think about. Eventually they will only think about their problems and their solutions.

Declaimer: This article is fully human written, no help from AI to write or polish this article, this is original human content.

How I Finally Solved My 500+ Bookmark Problem with AI

Sachit — Thu, 04 Sep 2025 13:39:50 +0000

In our day-to-day work as developers, we save dozens of links - documentation, Stack Overflow answers, interesting blog posts, GitHub repos. But lets be honest, how often do we actually find and use these bookmarks again?

Lets look at the problem first.

The Problem

You have hundreds or thousands of bookmarks scattered across browsers and devices. You need that one specific Stack Overflow answer about React hooks that you saved 6 months ago. You spend 15 minutes searching through nested folders, give up, and Google it again.

So basically, our bookmark system is broken. Here's what typically happens:

// How we think bookmarks work
const savedBookmark = {
  url: "https://important-article.com",
  location: "Web Dev > React > Hooks",
  accessibility: "Easy to find"
}

// How bookmarks actually work
const realityBookmark = {
  url: "https://important-article.com",
  location: "Misc? JavaScript? TODO? Who knows...",
  accessibility: null,
  lastSeen: "Never again"
}

What Makes This Hard

So i can already think of few issues with traditional bookmarks:

We save links without context - three months later "Important!!!" means nothing
Manual folder organization doesn't scale beyond 50 bookmarks
Browser bookmarks are tied to single devices
No way to search by content, only by title
Dead links accumulate over time (30% of my bookmarks were 404s)

The Technical Requirements

For a bookmark system to actually work for developers, it needs:

interface IdealBookmarkManager {
  organization: "automatic" | "ai-powered"
  search: "full-text" | "semantic"
  sync: "cross-device"
  context: "visual-preview" | "summary"
  maintenance: "self-cleaning"
}

Enter AI-Powered Organization

After trying to build my own solution (classic developer move), i realized this was a solved problem - we just needed to apply AI to it properly.

The key insight: AI can understand content and organize it better than we can manually.

Lets look at how this works in practice. I've been testing Bookmarkify, an AI-powered bookmark manager, and here's what changed:

Before (Manual Process)

Find interesting article about TypeScript generics
Spend 30 seconds deciding which folder
Create new folder because it doesn't fit existing ones
Save and forget where
Never find it again

After (AI Process)

Save link
AI reads content and auto-categorizes
AI generates relevant tags
Content becomes searchable
Find it instantly with "typescript generics tutorial"

The Technical Implementation

What makes this work is fairly straightforward:

// Traditional bookmark
{
  title: "Page Title",
  url: "https://...",
  folder: "/manually/created/path"
}

// AI-enhanced bookmark
{
  title: "Page Title",
  url: "https://...",
  tags: ["auto-generated", "by-content-analysis"],
  category: "Determined by NLP",
  summary: "AI-generated excerpt",
  fullText: "Searchable content",
  preview: "Visual screenshot"
}

The AI reads the actual content, understands what it's about, and organizes accordingly. No manual intervention needed.

Real Results After Using It

After importing my 500+ bookmarks into Bookmarkify, here's what happened:

Automatic cleanup: Found and removed 150+ dead links
Duplicate detection: Merged 80+ duplicate saves
Zero-effort organization: Everything categorized without any input from me
Actually using bookmarks: From maybe 5% usage to about 40%
Time saved: ~45 minutes per week not searching for links

The visual cards feature is particularly useful - i can recognize articles by their preview images much faster than reading through text lists.

Practical Features for Developers

What's actually useful:

Import existing bookmarks: Imported all my Chrome bookmarks, it organized them automatically
Natural language search: Type "react performance optimization" and it finds everything related
Text-to-speech: Listen to articles during commute
Instant summaries: Get the key points without reading entire articles
Cross-device sync: Same bookmarks on all devices

The Migration Process

If you're sitting on hundreds of unorganized bookmarks like i was:

Export your bookmarks from your browser (usually HTML format)
Import into Bookmarkify (accepts HTML and CSV formats)
Let AI do the heavy lifting of categorization
Review and use the search instead of browsing

The whole process took me about 10 minutes for 500+ bookmarks.

Summary

Traditional bookmarks don't work because they require manual organization that we'll never maintain. AI-powered tools like Bookmarkify solve this by understanding content and organizing automatically.

If you're drowning in bookmarks, its worth trying. They're in beta and accepting users - perfect time to influence the product direction with developer feedback.

Until next time, happy bookmarking (the organized way)!

PS: Would love to hear about your bookmark organization strategies (or lack thereof) in the comments.

Built a Pocket alternative - a bookmarking app - need your feedback!

Sachit — Mon, 01 Sep 2025 12:03:07 +0000

Hey fellow devs,

Like many of you, I was frustrated when Pocket shut down was announced. So I spent the last 6 weeks building Bookmarkify - but instead of just cloning Pocket, I added the features we actually need as developers.

What I've built so far:

🤖 AI auto-tagging - Never manually organize again
🔍 Smart search - Find bookmarks by content, not just titles
📺 Native embeds - Watch YouTube videos, view code snippets, all in-app
📖 Reader mode with AI - Summaries + text-to-speech for any article
👁️ Rich previews - Visual grid/list views that actually help you find stuff

Why I need you:

I'm at the point where it's useful but needs real-world testing. Your feedback will directly shape what I build next.

🎁 The deal: First 50 beta testers get lifetime access free forever (including all future premium features).

I genuinely want to build this with the community, not just for it. What bookmark management problems drive you crazy?

Join the beta: Bookmarkify

The tech stack i've used:

Typescript
Nextjs
Supabase Auth and database
OpenRouter to use some AI models

Ask me how i've used Claude Code to build this, its been an amazing journey thus far building AI assisted products.

Looking forward to your thoughts!

Building my own ChatGPT

Sachit — Sat, 25 May 2024 16:16:27 +0000

I was watching a YouTube tutorial, and the speaker mentioned that you don’t need to subscribe to the ChatGPT monthly plan. Instead, you can use their API directly, which is cheaper. That got me thinking: how easy would it be to build my own ChatGPT with the option of using locally hosted models like Ollama 3?

Today, we’re taking a quick dive into building a simple ChatGPT clone using some cool tech:

Our Tech Stack

Nextjs: This React meta framework is perfect for building fast, scalable web apps with features like server-side rendering.
TypeScript: Adding types to JavaScript makes your code more reliable and easier to maintain.
ShadCN/UI: Helps us build beautiful, responsive user interfaces, fast and easily.
Vercel AI SDK: Simplifies connecting our app to OpenAI's GPT-4, making it easy to work with AI.
OpenAI GPT-4o: The star of the show, GPT-4 can generate human-like text and is super versatile.
Auth0: User authentication made for developers
React-Markdown: Renders Markdown content in our React app, making text display neat and user-friendly.

Here’s a little sneak peek of where I am so far. In the coming posts, I’ll share the code and instructions on how it was built. The chosen tech stack makes it super easy to build something like this quickly and effectively.

Stay tuned for more. Until then, stay safe.

Streamlining Your Code with JavaScript's Reduce Method

Sachit — Sat, 17 Jun 2023 15:22:03 +0000

Whether you're just starting out with TypeScript/JavaScript or you're already comfortable with the basics, understanding array methods can significantly enhance your coding efficiency. In this short article, we'll introduce an array method that's often overlooked but incredibly powerful: reduce.

Understanding the Basics

Typically, to manipulate array data, we'd use methods like filter and map. For example, consider an array of students, where each student has a name, score, and class. Say we want to find the average score of all students in Class A who have scored above 50. A traditional approach using filter and map might look like this:

// Define student interface
interface Student {
    name: string;
    score: number;
    class: string;
}

// Array of students
const students: Student[] = [
    { name: 'John', score: 80, class: 'Class A' },
    { name: 'Jane', score: 40, class: 'Class A' },
    { name: 'Doe', score: 70, class: 'Class B' },
    { name: 'Smith', score: 60, class: 'Class A' },
];

// Filter the students based on class and score
const filteredStudents = students.filter(student => student.class === 'Class A' && student.score > 50);

// Get the total score
const total = filteredStudents.map(student => student.score).reduce((acc, score) => acc + score, 0);

// Calculate average
const average = total / filteredStudents.length;

console.log(average);

This code does the job, but it loops over the array three times. Could we make this more efficient?

Enter `reduce`

The reduce method can perform the job of both filter and map in just a single pass. It might seem complex at first, but the power it brings to your code is worth the effort.

Here's how you might solve the above problem using reduce:

// Define student interface
interface Student {
    name: string;
    score: number;
    class: string;
}

// Define an interface for the data we'll track
interface StudentScoreData {
    totalScore: number;
    studentCount: number;
}

const students: Student[] = [
    { name: 'John', score: 80, class: 'Class A' },
    { name: 'Jane', score: 40, class: 'Class A' },
    { name: 'Doe', score: 70, class: 'Class B' },
    { name: 'Smith', score: 60, class: 'Class A' },
];

// Initialize our tracking data
const initialData: StudentScoreData = { totalScore: 0, studentCount: 0 };

// Use reduce to calculate the total score and student count
const studentScoreData = students.reduce((data, student) => {
    if (student.class === 'Class A' && student.score > 50) {
        return { 
            totalScore: data.totalScore + student.score, 
            studentCount: data.studentCount + 1 
        };
    }
    return data;
}, initialData);

// Calculate average
const averageReduce = studentScoreData.totalScore / studentScoreData.studentCount;

console.log(averageReduce);

In this example, we only loop through the array once, increasing efficiency, particularly when dealing with large arrays.

Wrapping Up

Embracing reduce over filter and map might seem daunting at first, but it's a step worth taking. Not only does it make your code more efficient by reducing the number of iterations, but it also challenges you to think about problems in a slightly different way.

This article was inspired by this video i saw recently:

Happy coding!

My Struggles with TDD ( Test driven development )

Sachit — Sun, 07 May 2023 13:28:50 +0000

With nearly 15 years of experience in software development under my belt, one area I've consistently found challenging is Test-Driven Development (TDD). It's not that I don't appreciate the importance of writing tests, nor do I neglect to write them; it's just that I don't adhere to the TDD methodology. To better understand my perspective, let's first explore the what is TDD:

Test-Driven Development (TDD) is a software development approach focused on writing tests before writing code. Developers create tests for expected functionality, write minimal code to pass those tests, and then refactor for optimisation. This iterative process promotes code reliability, maintainability, and easier debugging.

Another way to look at TDD:

Loop(Red->Green->Refactor) - until equilibrium

Despite its apparent simplicity in theory, I've grappled with TDD throughout my professional journey. Driven by a desire to uncover the underlying reasons for this struggle and improve my practices, I am determined to embrace the TDD methodology more effectively, ultimately resulting in the production of robust and reliable code.

Here is what i’ve uncovered so far:

1: Personality

Upon delving deeper into my personality traits, particularly optimism and pessimism, I discovered the following:

I generally lean towards the optimistic side. But how does this optimism influence my tendency to write code first and test later? It's possible that my optimistic nature leads me to believe that my code will function as intended, causing me to prioritise writing code over testing.

2: Mindset

As an inherently optimistic individual, I possess a success-oriented mindset accompanied by an innate aversion to failure. This fear has held me back from pursuing numerous opportunities in life. But how does this relate to my reluctance to adopt TDD? It's plausible that my fear of failure deters me from writing tests first; instead, I gravitate towards writing code initially. Once confident in my code's functionality, I then create tests, reinforcing my optimism and success-driven mentality.

3: Processes

In a team or company setting, adhering to established processes is crucial. While TDD may initially appear time-consuming, its long-term benefits are undeniable. However, some teams fail to recognise the advantages of TDD, opting instead to prioritise a high output of code and features, inadvertently sacrificing quality for speed. This shortsighted approach can lead to an accumulation of technical debt. My reluctance to follow TDD may be influenced by working in environments where teams disregard the methodology, focusing on short-term productivity while neglecting the long-term stability and maintainability of the codebase.

4: Rewards and Recognition

Closely connected to the previous point, there is often a tendency to celebrate teams that rapidly deliver features and code, while inadvertently overlooking those who prioritise quality (a byproduct of TDD). Driven by the desire for rewards and recognition, I may find myself inclined to sidestep TDD methodologies in favour of accelerated output. This behaviour not only impacts my adherence to TDD but also perpetuates a culture that undervalues the long-term benefits of quality-focused development practices.

In conclusion, my journey to understand the factors contributing to my reluctance in adopting TDD has led me to identify four key areas: personality, mindset, processes, and rewards and recognition. These aspects have shaped my approach to software development, resulting in a tendency to prioritise code creation over testing. Now that I have a some understanding of the underlying reasons, I am better equipped to make conscious efforts towards embracing TDD in my development practices. In my next post, I will outline the strategies and steps I am taking to mitigate these influences and fully integrate TDD into my workflow, ultimately producing more robust and reliable software.

Unleash the power of Partial for mock data perfection!

Sachit — Sat, 15 Apr 2023 04:59:46 +0000

TypeScript Partial is a utility type that allows you to create a new type based on an existing one, making all of its properties optional. It is particularly useful when working with partial updates or constructing objects incrementally. In the context of testing, Partial can be a valuable tool for creating mock data.

Lets take an example:

interface User {
  id: number;
  firstName: string;
  lastName: string;
  email: string;
}

Now lets define a function that creates a mock user for testing:

function createMockUser(userPartial: Partial<User>): User {
  const defaultUser: User = {
    id: 1,
    firstName: 'John',
    lastName: 'Doe',
    email: 'john.doe@example.com',
  };

  return { ...defaultUser, ...userPartial };
}

The createMockUser accepts a Partial<User> object and merges it with a defaultUser object. This way, you only need to provide the properties relevant to your test, and the function will take care of the rest:

const mockUser1 = createMockUser({ firstName: 'Jane', lastName: 'Smith' });

const mockUser2 = createMockUser({ email: 'jane.doe@example.com' });

So what are the advantages of this approach:

Focussed testing: You can concentrate on testing specific properties or functionality rather than being overwhelmed by a complex object structure ( which is probably a code smell but a topic for another post ). This helps you write more targeted, efficient tests and makes it easier to identify the purpose of each test.
Increased maintainability: Because you no longer need to specify all properties for your mock data, you minimise the need to update your tests when your interfaces change. This makes your tests more maintainable and less prone to breaking due to changes in the underlying data structures.
Less boilerplate: With Partial, you only need to define the properties relevant to your test case, reducing the amount of boilerplate code and making your tests more focused and easier to understand.
Reusable mock data creation: You can use functions like this that leverage Partial to create mock data easily and consistently across your tests. This promotes reusability and can help you maintain a consistent approach to creating mock data in your test suite.
Enhanced readability: When using Partial, it becomes clearer which properties of the mocked object are relevant to the test case. This improves the readability of your tests, making it easier for you and your team members to understand and maintain the test suite.

So in summary, Partials can be your best friend when it comes to testing, helping you write clean, consistent, maintainable tests that are more focussed.

There's one more approach that I have recently come across by none other than our Typescript Wizard: Matt Pocock. He's created a library called shoehorn that has some utility types. Head over to his article and read more about it.

Here's a link to his article.

Happy Typescripting :)

Typescript: Zod - Handle external api errors gracefully

Sachit — Wed, 11 Jan 2023 12:08:09 +0000

In our previous post, we discussed a very cool library called Zod and how we can use it to write user defined type guards. In this post, lets look at another use case / issue this library helps resolve easily.

Lets look at the problem first.

You have an app that consumes data from external api's for example google maps or weather api.
You are working in a micro services environment and consume api's from other teams services that are loosely bound with contracts.
You apps have background processes ( async event handlers ) that require particular data to be passed in for it to process the event.

Lets look at this problem in code: We want to get weather for a given user

interface User {
  id: number;
  name: string;
  address?: string;
}

interface Weather {
  summary: string;
  max: number;
  min: number;
  chanceOfRain: number;
}

interface UserWeatherResponse {
  user: User;
  weather: Weather;
}

interface ResponseFromGoogleApi {
  summary: string;
  max: number;
  min: number;
  chanceOfRain: number;
  humidity: number;
}

function getUserService() {
  return {
    getUserById: (id: User["id"]) => ({
      id,
      name: "John Doe",
      email: "john@doe.com",
    }),
  };
}

function getWeatherFromGoogleApi(address: string): Weather {
  const responseFromGoogle: ResponseFromGoogleApi = {
    summary: "It will be a nice sunny day",
    max: 20,
    min: 20,
    chanceOfRain: 0,
    humidity: 10,
  };

  return {
    summary: responseFromGoogle.summary,
    max: responseFromGoogle.max,
    min: responseFromGoogle.min,
    chanceOfRain: responseFromGoogle.chanceOfRain,
  };
}

function getWeatherService() {
  return {
    getWeatherForUser: (user: User) =>
      getWeatherFromGoogleApi(user.address ?? ""),
  };
}

const userService = getUserService();
const weatherService = getWeatherService();

export const getUserWeather = (
  params: { id: number },
): UserWeatherResponse => {
  const user = userService.getUserById(params.id);
  const weather = weatherService.getWeatherForUser(user);

  return {
    user,
    weather,
  };
};

So basically, the code above is simulating getting weather for a user from google api, that is an external dependency that our application needs in order to resolve weather requests from our users.

So what are the potential pitfalls:

Google api is an external dependency that we have no control over.
Google can choose to change its api response payload at any time.
Response from google api is an unknown in our application.
We have made assumptions as to what the response from google api will look like.
Google api's can have downtime and affect runtime of our application.

So while our application is typesafe at compile time, it is not immune to run time errors. For example, if goolge api does not return the required data, our application will still compile, but will break when the user is trying to access it from the browser ( runtime failure ).

Now this is where Zod excels. It can safely parse data from external api's and add runtime type safety to our application and we can gracefully handle those issue without affection the user experience. Lets take a look at how this can be done using zod:

We define our schema ( interfaces ) using zod.
We derive the type from the schema we defined.
We use zod to ensure the shape of the data we get from the external api is the same as what we expect in our application.

import z from "zod";

interface User {
  id: number;
  name: string;
  address?: string;
}

const weatherSchema = z.object({
  summary: z.string(),
  max: z.number(),
  min: z.number(),
  chanceOfRain: z.number(),
});

type Weather = z.infer<typeof weatherSchema>;

interface UserWeatherResponse {
  user: User;
  weather: Weather;
}

interface UserWeatherResponseError {
  message: string;
}

const responseFromGoogleApiSchema = z.object({
  summary: z.string(),
  max: z.number(),
  min: z.number(),
  chanceOfRain: z.number(),
  humidity: z.number(),
});

type ResponseFromGoogleApi = z.infer<typeof responseFromGoogleApiSchema>

function getUserService() {
  return {
    getUserById: (id: User["id"]) => ({
      id,
      name: "John Doe",
      email: "john@doe.com",
    }),
  };
}

function getWeatherFromGoogleApi(address: string): Weather | Error {
  const responseFromGoogle: ResponseFromGoogleApi = {
    summary: "It will be a nice sunny day",
    max: 20,
    min: 20,
    chanceOfRain: 0,
    humidity: 10,
  };

  if (!responseFromGoogleApiSchema.safeParse(responseFromGoogle).success) {
    // gracefull handler error here and return appropriate response to the user
    return new Error("Response from google is not what we expected, lets bail out here quickly")
  }

  return {
    summary: responseFromGoogle.summary,
    max: responseFromGoogle.max,
    min: responseFromGoogle.min,
    chanceOfRain: responseFromGoogle.chanceOfRain,
  };
}

function getWeatherService() {
  return {
    getWeatherForUser: (user: User) =>
      getWeatherFromGoogleApi(user.address ?? ""),
  };
}

const userService = getUserService();
const weatherService = getWeatherService();

export const getUserWeather = (
  params: { id: number },
): UserWeatherResponse | UserWeatherResponseError => {
  const user = userService.getUserById(params.id);
  const weather = weatherService.getWeatherForUser(user);

  if (!weatherSchema.safeParse(weather).success) {
    return {
      message: "Cannot find weather for the user"
    }
  }

  return {
    user,
    weather,
  };
};

In summary, zod helps us easily add runtime type safety to our application. It allows us to ensure what we expect is what we get and if we don't, we can gracefully handle those errors ( no matter the reason ) and improve our application uptime and user experience.

2023, the year of Zod.

Typescript: Type guards with zod

Sachit — Wed, 21 Dec 2022 12:26:28 +0000

In our previous post, we discussed how we can use User defined type guards and their advantages.

In this post, i'd like to show the same concept but with a popular typescript library called Zod. Zod is a very powerful library that gives runtime safety to applications written in typescript.

Lets start by looking at an example of user guard written in plain typescript.

So lets break it down as to what is happening:

We have a user interface with 3 string properties and 1 boolean.
We have a type guard that validates if an object passed is a typeof User.
The type guard is checking each mandatory fields.

So i can already think of few issues with the type guard.

We could just validate a property against its primitive type, e.g. typeof obj.email === 'string' and we can pass any value.
We can pass any valid string to the uuid but is it really a uuid ?
Same can be said about the email, we can pass any valid string and it'll satisfy the guard.
We could also add mandatory properties to the user interface later and completely forget to add them to the type guard.

Now lets rewrite the above but this time using Zod

Zod allows you to write your schemas for objects and its validations in the same place. e.g. uuid and email are defined as

uuid: z.string().uuid()
email: z.string().email()

Not only is it much cleaner, less code and more useful, it also future proofs the code as we can add more properties to the schema without needing to update the type guard.

Please checkout Zod library as to me, it is one of the must have in your codebase if you care about runtime stability and experience of your applications.

Until next time, happy Zoding!

PS: You can find the code in the Gist here

Typescript: User Defined Type guards

Sachit — Sun, 18 Dec 2022 12:56:42 +0000

In our previous post any vs unknown, we talked about type narrowing. Basically type narrowing is:

The process of refining types to more specific types than declared is called narrowing.

Source

For javascript primitives ( string, number, bigint, boolean, undefined, symbol, null) that can contain values, we can use the special typeof operator to narrow the type. For example:

// ensuring age is a number if we don't know the value
// eg. it might be an any or unknown
if ( typeof age === 'number' ) { ... }
// or
if (typeof signature === 'string' { ... }

This is all good when we have a primitive, but what if we have an object, how do we use the same technique of narrowing. But before that, why would we even need to do that ?

So here's an example:

interface Pet {
  speak: () => void;
}

interface Fish extends Pet {
  swim: () => void;
}

interface Bird extends Pet {
  fly: () => void;
}

interface Cow extends Pet {
  milk: () => void;
}

// Essentially, the subject is a union type of Cat or Dog
function flyPet(subject: Fish | Bird | Cow ) {
  subject.fly();
}

So the subject variable passed to the function flyPet, is a union type of Bird or Fish or Cow. Other than the speech, each pet have their own trait. For example, fish can swim and bird can fly.

So if we invoke the function flyPet, then we will get a compile time error:

But this is good when we know the subject type. Now to why we need this, imagine if we didn't know the type of subject, eg. it was any or unknown as the data might be coming from an external api or its legacy code that we don't know what the type is genuinely, that would result in a run time error instead of catching it at compile time.

function flyPet(subject: any ) {
  // compiler happy, but will result in a runtime error
  subject.fly();
}

We can prevent those runtime errors by using the technique of type narrowing by creating user defined type guards. e.g.

function isBird(obj: any): obj is Bird {
  if (!obj.hasOwnProperty('fly') || !(typeof obj.fly === 'function')) {
    return false;
  }
  return true;
}

Function breakdown: We assert that for an object to be a bird

It needs to have a property fly
And the property fly is an executable function

Now we can rewrite our flyPet function to be run time safe like this:

function flyPet(subject: any ): void {
  if (isBird(subject)) {
    subject.fly();
  }
}

So when we use our type guard, we have basically narrowed down the type to be a bird and anything inside the if scope, will be a bird and hence we can use our subject to fly.

In summary, User defined Type guards allows us to:

Narrow down the type for objects
Prevent runtime errors that are not caught compile time.
Practice safe programming techniques
Catch errors and not break the user application / experience.

In the next post, we will look at the concept of User defined type guards using a very popular library called Zod and how it can make it easier to write user defined type guards.

Till then, happy guarding.

Is Chat GPT going to take over our jobs ?

Sachit — Wed, 14 Dec 2022 23:47:11 +0000

Hey Guys,

Just sharing that the #2: December edition post for My Techy bites newsletter is out. It contains:

Design tokens
ChatGPT demo and thoughts
Hooked, the book that shows how to build habit forming products
Playwright - End to End testing took from Microsoft

Here's a link to the post

#3: December Edition - by Sachit Malhotra - My Tech Bytes

Design tokens, ChatGPT, Hooked and e2e testing tool

sachitm.substack.com

Like, share and subscribe to the newsletter if you like it.

Thanks

Typescript: unknown vs any

Sachit — Mon, 12 Dec 2022 06:43:03 +0000

Do you know the difference between unknown and any in typescript ? Do you know when is it useful to use unknown or any ? Do you know why using any is not recommended ? Well, here's a explanation of the differences and uses.

The type any was added to typescript to allow easy migration of the code for any javascript project. any and unknown are mostly the same with a key difference:

unknown does not allow access to any property on an object or variable or use any primitive methods. This is useful when you either don't know the shape of data you are dealing with or are migrating from legacy javascript code.

For example:

const a: any = '123';
a.toFixed(2);

Doing this will result in a runtime error:

Now lets change the any to unknown and see what happens

const a: unknown = '123';
a.toFixed(2);

Doing this with an unknown type will raise a compiler error.

To fix the above, we have to narrow the type (using truthiness narrowing) to a number using a type guard like:

const a: unknown = 123;
if (typeof a === 'number') {
  console.log(a.toFixed(2)
}

In short, benefits of using unknown are:

Leads us to use type narrowing ( article on this coming soon )
Refactoring legacy javascript code to typescript
Catch bugs early in the development cycle
Preventing runtime bugs in applications

See a short video that explains this in details.

Hope you find this useful.

We will discuss type narrowing, type assertion and type guards in the next few posts.

Until them, stay safe, stay healthy.