Forem: Todsapon Boontap

Enhancing Error Handling in TypeScript: Leveraging Functional Concepts for Better Practices

Todsapon Boontap — Fri, 08 Dec 2023 22:49:26 +0000

Introduction

As someone who tends to prioritize addressing errors upfront, encountering an error that can arise without our code being ready to catch it makes me feel uneasy.
I believe error handling is a crucial topic that doesn't receive as much attention as it deserves, especially when working with JavaScript and TypeScript. There are gaps that need to be filled in these languages, and I personally believe we should put in more effort to handle errors effectively, rather than solely relying on native features.

OK, today I'll begin with:

The native approach in TypeScript/JavaScript.
A common approach that is widely used and can be found in many projects.
Then, a more preferable and better way.

Starting with what TypeScript/JavaScript natively provides for error handling: try and catch.

try {
    op1()
    op2()
} catch(e) { handle(e) }

Here, all the operations within the try block are executed, and if an error occurs, the catch block is triggered.

A common approach

Let's assume we're working on the backend side. We've structured our operations into different layers such as Validation and Database layers.

For the purpose of this example, let's create two types of errors and simulate fake operations. One operation will result in a promise rejection or error, while the other will simulate success. This might look something like this:

type ErrorFromDBLayer = { msg: string };
type ErrorFromValidationLayer = { errors: { field: string; reason: string }[] };

let validationOp = Promise.reject({
  errors: [{ field: "x", reason: "number only" }],
} as ErrorFromValidationLayer);
let dbOp = Promise.resolve({} as ErrorFromDBLayer);

Now, let's imagine that we're working on a route handling function. This function will execute the previously created fake operations.

async function routeHandler() {
  try {
    await validationOp;
    await dbOp;
  } catch (e: unknown) { // handle errors }
}

To me, this approach seems prevalent, present in about 3/4 of projects. It appears quite normal and understandable, right?

However, let's take a step back, calm down, and analyze this pattern.

One concern that comes to mind is within the try block: how can we distinguish which operation fails and what type of error it encounters? TypeScript lacks a native way to specify Promise reject function return types, leading all errors to fall into the catch block. In such cases, what is typically done is creating a function to handle all operation errors. Let's start by implementing the handleErrors function.

Firstly, I'll create a type guard utility function for error types.

// define type gard util funcs
function isErrorFromDBLayer(t: object): t is ErrorFromDBLayer {
  return "msg" in t;
}
function isErrorFromValidationLayer(
  t: object,
): t is ErrorFromValidationLayer {
  return "errors" in t;
}

Then the handle errors function and update our catch block. Like this

try { ... } catch(e: unknown) { handleErrorsByTypeNarrowing(e) }

function handlerErrorByTypeNarrowing(e: unknown) {
  if (typeof e === "object") {
    let errObj = e as object;
    switch (true) {
      case isErrorFromDBLayer(errObj):
        console.log("error msg from db layer", errObj.msg);
        break;
      case isErrorFromValidationLayer(errObj):
        console.log("error msg from validation layer", errObj.errors);
        break;
      default:
        console.log("unknown error");
    }
  } else {
    console.log("unknown error");
  }
}

As observed, this function effectively manages errors through type narrowing with a type guard function.

So what's wrong with this approach?

Here are a few concerns that come to mind:

When dealing with more than just two operations, or when working with code we haven't authored ourselves, we're forced to delve into all interacting functions to identify error types. This can become quite cumbersome and time-consuming for developers, as it requires loading a lot of context beforehand to proceed.
As developers, we aim to avoid writing code that requires readers or our future selves to invest a significant amount of time understanding context just to continue working. This can slow down development and productivity.
Due to the lack of error typing support in Promises, manual detection of error types and handling becomes necessary. Consequently, when introducing more operations, the handle function needs frequent updates. This lack of scalability may lead to error-prone code.

A Better approach

In this approach, we'll explore a type commonly used in functional programming known as the Result type. This generic type can represent either an Ok or Error state. Let's gain a better understanding by examining its type definition.

type Err<F> = { identifier: "fails"; reason: F };
type Ok<T> = { identifier: "success"; value: T };
type Result<T, F> = Ok<T> | Err<F>;

We can examine languages like Rust, where the type definition appears quite similar. Since TypeScript enums don't allow embedding associated values, we can implement a similar concept using discriminated unions.

Let's proceed by updating our operation functions.

const validationOp: Promise<Result<{}, ErrorFromValidationLayer>> =
  Promise.reject({
    identifier: "fails",
    reason: { errors: [{ field: "x", reason: "number only" }] },
  });

let dbOp: Promise<Result<{}, ErrorFromDBLayer>> = Promise.resolve({
  identifier: "success",
  value: {},
});

As observed, our Promise now has a specified result type that supports Ok and Err types, effectively enhancing the Promise's capabilities.

Now, let's examine our updated implementation of the routeHandler function.

async function routeHandler() {
  const validationOp_result = await validationOp;
  if (validationOp_result.identifier === "fails") {
    // log error, write an error response

    // also get benefit of auto intellisence, by discriminated union!
    // processValidation_result.reason.errors
    return;
  }

  const dbOp_result = await dbOp;
  if (dbOp_result.identifier === "fails") {
    // log error, write an error response
    return;
  }

  // return success response, etc..
}

After this lengthy journey, let's reflect on what improvements we've achieved.

The primary enhancement is the complete removal of the handleError function, rendering it unnecessary.

Why?

As evident in our updated routeHandler function:

We now possess the capability to catch errors early and exit the operation flow, granting more control.
The power of discriminated types becomes apparent within the if true block, where our editor or IDE offers auto-completion for error types.
Due to our knowledge of the error type, we can handle it with type safety, eliminating the need for implementing type narrowing functions to detect errors.
With the Result type in place, we can seamlessly add numerous operations without the necessity to navigate to the function source for its definition. This scalability is achieved without requiring modifications.

Conclusion

Although TypeScript lacks direct support for error typing, we can draw upon concepts from functional programming to enhance our approach. The Result type, found in various functional languages, provides a foundation for further exploration. For instance, implementing traditional functional-style mapping functions to map Ok or Err values and enable type chaining is a potential avenue to explore, albeit beyond the scope of this discussion.

I hope this idea proves helpful for better error handling!

Enjoy the enhancements!

Solving zustand persisted store re-hydration merging state issue

Todsapon Boontap — Sun, 19 Nov 2023 20:53:43 +0000

Introduction

After spending about four months working in the Vue.js environment, I didn't choose it; the existing team was already using it. Now, I've transitioned back to React with Next.js.

The reason I chose Next.js over just React or React with Vite is because I'm intrigued by the concept of server components—a relatively new paradigm in server-side rendering that caught my interest.

Having been away from React for a while, I've noticed a significant expansion in the ecosystem of state management libraries. The last library I used for state management was Jotai. Now, there are new ones like xstate and zustand. After quickly exploring their documentation, I opted for zustand. It seems to offer an improved, less verbose version of Redux, which I believe early React developers are familiar with. Plus, I still appreciate the idea of time-traveling state.

Alright, that's enough for the introduction. Let's get started!

Usecase and issues

I've begun setting up a Zustand store following consultation with the official documentation. My goal is to partially persist certain parts of the state. Here's how I've set up the store:

I employ the slices pattern to construct and divide the main store into smaller parts, adhering to this good practice. As evident, I utilize devtools to encapsulate all state slices, but intentionally choose to persist the UserSlice.

This is how I've set up the app-user-slice. As you can see, I utilize the persist middleware from the



zustand/middleware

package to handle this process. The expected behavior should be that upon refreshing or reloading the website, all persisted state should properly rehydrate to the state shape without any complexity.

However, a remarkable aspect that simplifies Zustand is its allowance to directly attach any side effect action to the state shape, exemplified by the login function.

This feature enables us to access the store's associated function and use it within a component, like so:

So, what are the issues here?

Upon pre-validating this code, we've realized that this component relies on the login function derived from the store to function correctly. However, as previously mentioned, this slice is a persisted slice. The problem arises when I attempt to reload the page for the first time. After the complete reload, the error surfaced, stating that the login function is undefined, although the other state properties exist.

as you can see, login function is disappear!

This error drive me an hours try figure this out, Here is what I understand and how to solve.

Initially, I questioned whether I set up the store and the slice correctly or if there was any relation to SSR hydration. Upon investigation, I discovered that the issue wasn't related to the hydration flow. Rather, it stemmed from the process of persisting the state shape to localStorage (the default setting), which involves serializing the current state behind the scenes.

The critical point here is the process of serialization.

As we're aware, JSON.stringify supports only primitive types and not object or reference types. However, because Zustand allows attaching side-effect functionalities directly to the store's state shape, this limitation becomes apparent. This is precisely why the login function disappears.

Solving & Solution

I consulted the official documentation and examined the persist middleware API specification. I came across the "merge" option, which stated:

The default implementation explain it all and this is what I need.
So I add it to my slice like this:

Why it work

Because every time the page reloads, the hydration is triggered, Zustand recreates the store with the initial state, which includes side-effect functions. Then, it loads the persisted state and attempts to merge them. So, we override the default behavior of the merge function and reassign the sideEffectFunction to currentState.sideEffectFunction (initial state).

This is the normal and simplest approach because I only have one function in this slice. However, when dealing with more functions or nested state, a more advanced approach, such as using deepMerge or Immer, can be employed to assist in merging the state shape.

Conclusion

For me, this kind of issue seems basic, something I didn't expect with such a popular library. But when it arises, it's a good reminder to revisit fundamental concepts, such as serialization and its limitations.

In terms of Zustand's intention to allow us to include functionality in the state, it's somewhat predictable that this type of issue might surface. I wonder why Zustand doesn't handle this case for us. Just imagine having to override the merge option behavior for every persisting slice—this could impact the Developer Experience (DX), right?

As users, we encounter limitations and then resolve them.

Hopefully, this insight is helpful.

References:
persist middleware merge option

Dark mode เหมาะกับสายตา Dev อย่างเราจริงๆ หรอ, นอกจากความชอบ มีผลเสียอะไรไหม

Todsapon Boontap — Mon, 19 Apr 2021 07:42:25 +0000

เดี๋ยวนี้ หันไปทางไหน Developer 99% ใช้ dark theme ในการ coding กันหมดเลย แต่ด้วยส่วนตัวผมเอง ตอนนี้เปลี่ยนมาใช้ light theme มาสักพักใหญ่และ (เกิน 6 เดือน) เปลี่ยนโดยที่ไม่ได้มีความรู้อะไร นอกจากความรู้สึกว่า มองๆ code ไปมันสบายตาดีกว่านี่หว่า

วันนี้ รู้สึกสงสัยเพิ่ม ฮ่าๆ ว่าทำไมว้า เลยไปหาคำตอบมา ซึ่งพอไปอ่าน รู้สึกมีประโยชน์ดีครับ

Dark mode เป็นสิ่งที่เพิ่งมีมาหรอ

ย้อนไป ในยุคสมัยก่อน computer ใช้จอ CRT ซึ่งแสดงตัวหนังสือเป็นสีเขียว และพื้นหลังเป็นสีดำ หรือ มีเครื่องที่เอาใว้ใช้ทำ words procesing ก็แสดงตัวหนังสือสีขาว บนพิ้นหลังสีดำ

มาเปลี่ยนกลายเป็น พื้นหลังสีขาว ตัวหนังสือสีดำ ก็ช่วงยุค 80s โดยบริษัทส่ง fax ในยุคนั้น ซึ่งทำมาจากเหตุผลว่าอยากเลียนแบบให้เหมือนอยู่บนกระดาษ แล้วเราเขียนหรืออ่านหนังสือ
ตรงนี้เราจะเห็นว่า dark mode ไม่ใช่ innovation อะไรใหม่เลย

ทำไมเราควรใช้

ในเชิงพลังงาน คือการใช้ dark mode มีส่วนช่วยลดการใช้พลังงาน กล่าวคือเวลาที่เราใช้ dark mode พื้นหลังเป็นสี ดำ หรือ เทา ทำให้ตัว pixel dot บนหน้าจอของเราไม่ได้เปิดทำงานทุก dot ที่มี ต่างจาก light mode ที่ส่วนนี้ทำงานเต็มที่เพื่อแสดงพื้นหละงสีขาวให้เรา
ในเชิงของสุขภาพ คือ light mode จะปล่อย blue light ออกมาเยอะมากกว่า ซึ่ง blue light ก็ไม่ใช่อะไรใหม่ แต่ว่ามันมีอยู่ตามธรรมชาติอยู่แล้ว เช่นแสงแดดเป็นต้น ผลของมันก็คือ การสร้าง melatonin บนผิวเราจะเพิ่มขึ้น พูดง่ายๆ คือ พวกขี้แมลงวัน ที่ขึ้นบนหน้าเรา เมื่อเราเริ่มอายุเพิ่มขึ้นเรื่อยๆ นั้นเอง และ blue light ยังมีผลต่อ hormone ที่เกี่ยวข้องกับการนอนหลับด้วยครับ

แล้วทำไมไม่ควรใช้

มนุษย์เรา สายตาเรานั้นมองได้ชัด ในเวลากลางวัน มากกว่า กลางคืน เพราะสายตาเราถูกพัฒนามา ให้ เห็นสีดำ บน สีขาว โดยไม่สนว่า สีดำจะเป็นอะไร สิ่งของ หรือตัวหนังสือ ถ้า พื้นหลังเป็นสีขาว เราโอเคหมด

จากที่กล่าวไปข้างต้นว่า เวลาเราใช้ dark mode นั้น เจ้า pixel dot ไม่จำเป็นต้องทำงานเต็มที่ (ไม่ได้ activate pixel dot ทั้งหมดที่มี) ทำให้เวลาเราอ่านเขียน ด้วย dark mode รูม่านตาเราจะขยายมากขึ้นเพื่อรับแสง (ก็แสงมันน้อย) และ การกระพริบตาของเราก็จะน้อยลงตาม ซึ่งเป็นการปรับตัวของกล้ามเนื้อตา เพื่อช่วยให้เรา focus สิ่งที่มองได้ง่ายขึ้น
แน่นอนว่าเมื่อเรากระพริบตาน้อยลง ส่งผลให้ตาแห้ง ซึ่งเป็นสาเหตุของความเสียหายของกระจกตา ซึ่งถ้าปล่อยผ่านไป มีผลให้สายตาของเรา แย่ลงในที่สุดครับ
ในทางกลับกัน Light mode สายตาเราไม่ต้องพยายามมากนักที่จะ focus ครับ
สายตาเราถ้าเราอยู่กับ dark mode (แสงน้อย) เป็นเวลานานมากพอ เขาจะเกิดการปรับตัวให้ชินครับ ทีนี้ สมมุติเราต้องขับรถกลางวันเราจะรู้สึกว่าตาเรามันไม่ค่อยสู้แสง รู้สึกว่าใช้พลังเยอะในการเพ่ง ซึ่งเป็นส่วนของสาเหตุ ของการง่ายขณะขับรถครับ

สรุปก็คือ รู้ใว้ว่า สายตาเราประกอบไปด้วยกล้ามเนื้อด้วย ถ้าเกิดเรารู้สึกว่า ต้องพยายามในการ focus เราอย่าไปฝืนมันครับ

ส่วนตัวตอนนี้ ผมใช้ light theme ครับ เริ่มจาก เวลา coding ตัว code editor ของเรามืดเพราะเรา set dark theme ใช่ไหมครับ แต่เวลาที่เราทำงานอยู่ เราก็ต้องเปิด Website หรือ อื่นๆ ไปด้วย แล้วต้องสลับไปมา ขาวๆ ดำๆ พอนานผมรู้สึกไม่สบายตา ก็เลยลองเปลี่ยนครับ
ตัวผมเองไม่ได้แคร์เรื่อง blue light มากเพราะมันยังไม่มีข้อมูลยืนยันว่ามีผลเสียต่อสายตา (ถ้ามีบอกด้วยยย) นอกจากผิวเรา ก็ทากันแดดกันได้ครับ หรือการนอน ก็ไม่ใช้คอมสัก 1 ชมก่อนนอน ก็แก้ได้ แต่ผมต้องอยู่หน้าคอม หลายชั่วโมงต่อวัน light theme สำหรับ code editor จึงเหมาะกับผมมากกว่าครับ

สุดท้าย จะเห็นว่าจริงๆ ก็มีทั้งข้อดี ข้อเสีย ของทั้งสอง mode ซึ่งก็ขึ้นอยู่กับวิธีใช้งานของเรา และว่าเราให้น้ำหนักที่อะไร ครับ

Builder: design pattern

Todsapon Boontap — Thu, 07 May 2020 04:59:28 +0000

สวัสดีครับ Devs ถ้าเรื่อง code quality สำคัญสำหรับคุณ เราคือเพื่อนกัน

Devs เรา code กันมา เราน่าจะเคยเห็น class ที่การจะสร้าง instance ของพี่เขาเนี่ย
require parameters เยอะ หรือบาง instance ต้องการการ set runtime config ค่าบางอย่างเพื่อให้เขาทำงานได้ถูกต้อง ดังตัวอย่างง่ายๆ ดังนี้

ClassGenerator มีหน้าที่ gen code ออกมาเป็น string ธรรมดา
ตาม config ที่มีให้อย่างในภาพด้านล่าง

จากภาพสังเกตุว่าใน function generate จะมีส่วนที่มีปัญหานิดหน่อย

ตรงนี้
ถ้าเกิดเรา config parentClass แต่ไม่กำหนด isExtends เป็น true
code ที่ gen ออกมาก็จะไม่ มีสวน extends parent class ให้
ซึ่งมันไม่ใช่ expected behavior

ซึ่งสิ่งที่อาจเป็นปัญหาคร่าวๆ คือ

Devs คนอื่นๆ หรือ ตัวเราเอง ที่ใช้ object นี้ต่ออาจลืม setter บางตัวได้
จากข้อบน อาจทำให้เกิด unexpected behavior ได้

ทีนี้ Builder pattern จะมาช่วยเราอย่างไรบ้าง
โดยตาม theory บอกว่า

builder ทำให้การสร้าง หรือ config object ที่มีความ complex ให้ง่ายขึ้น
builder นั้นเป็นอิสระจาก object อื่นๆด้วยครับ

Welcome Builder class

สังเกตุว่า class Builder นี้ใน function parentClass
ผมกำหนดให้ไปเลยว่า ถ้ามีการ set parent class เข้ามา
isExtends ต้องเป็น true เลย ซึ่งก็จะลดความซับซ้อน ไปได้ครับ

ซึ่งวิธีการเรียกใช้เป็นแบบนี้

code เราที่เขียน เพื่อนมาดูต่อก็ จะรู้สึก มีอารยธรรมครับผม

ทีนี้ด้วยความเป็นคนจุกจิก ไม่พอใจอะไรง่ายๆ ครับ ฮ่าๆ
แล้วมันทำได้ดีกว่านี้อีกไหม ?
คำตอบคือได้ครับ

ขอแนะนำให้รู้จักสิ่งที่เรียกว่า Fluent Builder pattern
ซึ่งเขาก็คือ builder แหละ แต่เป็น style ที่สวยขึ้น useful มากกว่า
โดยเราจะ implement ได้ดังนี้

ซึ่งสิ่งที่เราเพิ่มเติมขึ้น เราให้ class builder นี้ return ตัวเขาเองออกมาทุกครั้ง
เพื่อให้เราสามารถ ทำ chain configuration ได้ เพื่อให้เราเรียกใช้ แบบนี้ได้ครับ

เป็นงัยบ้างครับ สำหรับ Builder pattern
ทีนี้เรารู้จักการเขียนแบบนี้ Team เรา หรือเราจาก อนาคต
จะรู้สึกว่าได้ร่วมงานกับ คนที่มีอารธรรมที่สูงส่งกว่าครับ

หวังว่าเพื่อนๆ Devs จะลองเอาไป implement กันดูนะครับ