Forem: Kokomi

Replace Generic Validation with Reusable Functions

Kokomi — Sun, 01 Sep 2024 23:12:37 +0000

JavaScript and TypeScript developers often find themselves writing the same conditions repeatedly. If you're a web developer, you've probably encountered code like this:

const handleSaveTextKeydown = (event: KeyboardEvent) => {
   if (event.key === 'Enter') {
    //... save text
   }
}

In this case, event.key is of type string, and it's easy to introduce bugs by accidentally including a space in 'Enter ', for example.

Why not encapsulate this condition in a function?

const handleSaveTextKeydown = (event: KeyboardEvent) => {
   if (checkIsEnterKey(event.key)) {
    //... save text
   }
}

This ensures that all checks for the Enter key are consistent and reliable.

Now, consider this validation:

type Value = null | object;

const value = {} as Value;

if (typeof value === 'object') {
  value; // value type is null | object
}

Even though TypeScript is smart, value inside the condition remains of type Value. This is because typeof null returns 'object'.

So, you need to write:

if (value !== null && typeof value === 'object') {
  value; // value type is object
}

Many developers might not encapsulate this into a function and instead write it repeatedly whenever they encounter this situation.

How many times have you written the same condition in your life?

How many times have you made the same mistake?

How many more times will you write the same condition in the future?

If it were me, I would do this:

if (checkIsObject(value)) {
  value; // value type is object
}

There are many benefits to encapsulating generic conditions in functions.

Consider the following example:

const array = [0, 1, 2, 3, 4, 5, null, undefined];

Let's create an array that excludes only nullish values.

You might prioritize brevity and write it like this:

const numbers = array.filter(Boolean);

Unfortunately, this is not ideal. 0 is also evaluated as false and gets excluded. So you need to write:

const numbers = array.filter(item => item !== null && item !== undefined);

Doesn't this feel like ugly, non-reusable code?

I can write more elegant code:

const numbers = array.filter(checkIsNullish);

Stop writing generic conditions repeatedly. It only leads to mistakes, and the code becomes less readable.

Let me introduce a library I created called checker.

This utility function library represents commonly used conditions in general web development and low-level development as functions. All functions take an input and return a boolean value.

At the time of writing this article, it provides a wealth of functions to handle data types such as strings, numbers, booleans, and nullish values. All functions are tested, documented, and easy to start using.

Let's look at some real-world examples.

The packages provided by this library are all published on JSR. They can be easily installed in NPM, PNPM, Yarn, Bun, and Deno projects.

Here, we'll take the @checker/string package as an example with NPM.

Install the package

Run the following command in your project directory:

  npx jsr add @checker/string

Using the functions

  import { checkIsNotEmptyString, checkIsIndexFound } from "@checker/string";

  const value = "Hello";

  const formatted = value.trim();

  if (checkIsNotEmptyString(formatted)) {
    // formatted !== ''
    // When formatted is not an empty string
  }

  const index = value.indexOf("el");

  if (checkIsIndexFound(index)) {
    // index !== -1
    // When "el" is found in value
  }

I am not fond of using logical negation operators like !SOME_CONDITION to reverse a boolean value. This is because it's implicit, and simply reversing the boolean value by adding or omitting it can lead to many dangerous situations.

Therefore, all functions have corresponding checkIsNot~ functions defined.

Encapsulate generic conditions in functions. This way, the code becomes more readable, and bugs become easier to spot.

Thank you for reading.

The link generator creates paths in a type-safe way

Kokomi — Sat, 31 Aug 2024 23:25:07 +0000

Next, SvelteKit, Astro, Nuxt, and common web frameworks utilize directory-based routing.

Unfortunately, directory-based routing becomes harder to maintain as routes increase and is not suitable for creating complex routes.

The LinkGenerator I created partially solves this issue by centrally managing the paths (or links) used in web applications.

Here, I'll briefly explain routing with SvelteKit.

First, let's take a look at a static route.

To create an about page, follow these steps:

Create a directory with the route's name inside the routes directory:
```
src/routes/about
```
Inside the about directory, create a +page.svelte file:
```
src/routes/about/+page.svelte
```
Write the content in the +page.svelte file:
```
<h1>About</h1>
```

This will display the About page when you access /about.

Next, let's create a dynamic page.
Here, we'll create a route like /posts/:postid.

Create the route, and make sure to enclose the directory name for path parameters in [ and ]:
```
src/routes/posts/[postid]
```
Create the page file:
```
src/routes/posts/[postid]/+page.svelte
```

This setup allows you to retrieve the value of the path parameter from the load function in the +page.ts or +page.server.ts files within the src/routes/posts/[postid] directory. Don't worry too much about the differences between these files.

// src/routes/posts/[postid]/+page.ts
export const load = (routeContext) => {
  const postid = routeContext.params.postid;
  return { postid };
};

The value returned from the load function can be retrieved in the +page.svelte file as shown below:

// src/routes/posts/[postid]/+page.svelte
<script lang="ts">
   export let data;
</script>

<h1>Postid: {data.postid}</h1>

As a result, when you access src/routes/posts/1, it will display Postid: 1.

Directory-based routing may seem simple, but we need to create many directories and files to achieve straightforward tasks.

As the number of routes increases, the directory structure becomes more complex, and it gradually becomes difficult to grasp the entire routing structure.

Every time you want to access a specific route on each page, you must check the structure of the routes directory.

How can we solve this problem elegantly?

Should we create a new router that is not directory-based? While this would be a great idea, it would take a long time to develop, and integrating the router with the framework is not easy.

Here’s the conclusion I came to:

How about creating just one function that generates links completely type-safe?

What if we represent the routes as a single object and centrally generate links based on that? While it may not guarantee that the defined object perfectly matches the directory structure, if we can centrally manage links, I no longer have to spend time opening and closing directories. Additionally, when routes are changed, TypeScript types can check the impact across the entire project.

Let me introduce how to use the LinkGenerator I created.

This package is published on JSR, a JavaScript package registry operated by Deno. It can be easily installed using Deno, NPM, PNPM, Yarn, or Bun.

Here, we'll use NPM. Open your project directory and run the following command:

npx jsr add @kokomi/link-generator

Usage is very simple. Refer to the following code:

// 1. import modules
import { type RouteConfig, flatten_route_config, create_link_generator } from "@kokomi/link-generator";

// 2. define route config
const routeConfig = {
  posts: {
    path: "/posts",
    children: {
      post: {
        path: "/:postid"
      }
    }
  }
} as const satisfies RouteConfig;

// 3. flatten route config
const flat_route_config = flatten_route_config(routeConfig);

// 4. create link function
export const link = create_link_generator(flat_route_config);

link("posts/post", { postid: "1" }); // => /posts/1

An example of usage in Svelte would look like this:

<script>
  import link from "./path_to_link_function";
</script>

<a href={link('posts/post', { postid: '1' })}>Goto post1</a>

It also strictly types the parameters and supports query parameters.

For more details, check out the link-generator repository on GitHub.

Thank you for reading.