DEV Community: Prashanth R.

Level up your Typescript game, functionally - Part 3

Prashanth R. — Sat, 25 Nov 2023 01:11:26 +0000

Welcome back to the final post in the series "Level up your Typescript game, functionally".

In the previous post, we looked at some functional concepts (like Monads) from the Scala programming language and re-implemented those concepts in Typescript with the Option and Either types.

Now let's look at another useful type from the Rust programming language.

The `Result` type

The extremely type safe Rust language exposes a type called Result that is very similar to the Either type (from Scala/Haskell) but it is exclusively used to model the result of an operation that can either be a Success or Failure (error).

This is what it looks like [ Source ]

pub enum Result<T, E> {
    Ok(T),
    Err(E),
}

Example usage

let op: Result<i32, &str> = Ok(42);
assert_eq!(x.is_ok(), true);

let x: Result<i32, &str> = Err("Some error message");
assert_eq!(x.is_ok(), false);

We can implement the Result type in Typescript too. Let's modify our Either implementation from our previous post and give it a go!

type Ok<T> = { value: T }
type Err<E> = { error: E }
// The Result Type
type Result<T, E = Error> = Ok<T> | Err<E>

And the util functions to wrap objects

export const ok = <T>(value: T): Ok<T> => ({ value })
export const err = <E>(error: E): Err<E> => ({ error })

And finally our matchers interface and match function

interface Matchers<T, E extends Error, R1, R2> {
    ok(value: T): R1
    err(error: E): R2
}

const match =
    <T, E extends Error, R1, R2>(matchers: Matchers<T, E, R1, R2>) =>
    (result: Result<T, E>) =>
        'value' in result
            ? matchers.ok(result.value)
            : matchers.err(result.error)

As you can see this is very similar to the Either type implementation but uses Ok and Error instead of Left and Right.

And a practical example from before as follows

const getDataFromDB = 
  async (ctx: Context): Promise<Result<Data>> => {
    try {
      const result = await ctx.db.primary.getOne()
      return ok(result)
    } catch (err) {
      console.error('Error getting data from DB', err)
      return err(err)
    }
  }
// using pipe and andThen from the NodeJS 'ramda' package
const app = async () => {
   return pipe(
     getDataFromDB(ctx)
     andThen(
       match({
         err: (err) => throw err,
         ok: (value) => return value
       })
   )
}

Summary

Through this entire series of posts, we saw that we can use pure functional concepts to re-write our Typescript application flows using appropriate types and make our code functionally aware thereby improving dev efficiency and utility especially when it comes to handling domain errors instead of throwing exceptions everywhere.

Takeaways and Resources

We learned 4 new functional types to help optimize our code and flows. They are namely ResultTuple, Option, Either and Result.

If you want to use any of these types mentioned in this series, check out this handy ts-utils NodeJS package that I created that encompasses these types as exports so you can use whatever variation makes sense for your use case. To install it simply run this command

npm i -S @universal-apps/ts-utils

The advantage of the types we have discussed in detail in this series is that you can use as much or as little as your want and swap out portions of your codebase without affecting others.

However if you want to use a full fledged functional library with lots of utilities, I recommend checking out fp-ts and this handy cookbook that teaches you how to use it with examples. A newer library called EffectTS that also uses similar concepts and patterns has also been recently gaining popularity if you want to check that out.

Other libraries to check out are pratica and ramda

Last but not least if you want a good learning resource on Functional Programming, check out this series on Youtube.

Acknowledgements

I was heavily inspired by this post from Dan Imhoff on using Results in Typescript for this entire series of posts and extending the concepts.

Conclusion

Congrats on making it to the end of this final post in the series! You have leveled up once more 🍄🍄🍄 and completed your quest. Thanks for going on this journey with me.

If you found this post and/or series helpful, please upvote/react to it and share your thoughts and feedback in the comments.

Onwards and upwards 🚀

Level up your Typescript game, functionally - Part 2

Prashanth R. — Sat, 25 Nov 2023 01:11:03 +0000

Welcome back to another post in the series "Level up your Typescript game". This is the second post in the series.

In the earlier post, we looked at some Typescript trends, some challenges in handling complex apps and a better pattern to model errors to avoid the try/catch hellscape. In this post, let's look at some new concepts and take some learnings from other languages and apply it to Typescript.

There are a few different types of programming languages:
(Source 1 | Source 2)

Procedural - A procedural language follows a sequence of statements or commands in order to achieve a desired output. Examples: C, C++, Java, Pascal, BASIC etc.
Object Oriented - An Object Oriented language treats a program as a group of objects composed of data and program elements, known as attributes and methods. Objects can be reused within a program or in other programs. Examples: Java, C++, PHP, Ruby etc.
Functional - Functional programming languages are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values. Examples: Scala, F#, Erlang, Haskell, Elixir etc.
Scripting - Scripting languages are used to automate repetitive tasks, manage dynamic web content, or support processes in larger application. Examples: Javascript, Node.JS, Python, Bash, Perl etc.
Logical - A logic programming language expresses a series of facts and rules to instruct the computer on how to make decisions. Examples: Prolog, Absys, Datalog, Alma-0

All these different types of languages have their own pros and cons, design trade offs and respective use cases.

Typescript and Javascript are scripting languages by nature and we only have access to features that are part of the ECMAScript standard; which is evolving constantly and new features are added all the time. However can we take a few concepts and advanced features from other languages and apply them to Typescript now? Let's explore below.

For the remainder of this post, I want to focus on functional programming concepts because those ideas seem to have the most benefit for building modern complex applications. We'll consider languages like Scala and Rust and look at how they do things to achieve maximum productivity and effectiveness.

In many functional programming languages like Scala and Haskell, there is a concept called Monad. For the rest of this post we'll focus on features of the Scala programming language in particular.

Monads are nothing more than a mechanism to sequence computations around values augmented with some additional feature. Such features are called effects. A monad adds an effect to a value wrapping it around a context. In Scala, one way to implement a monad is to use a parametric class on the type.

class Lazy[+A](value: => A) {
  private lazy val internal: A = value
}

The Lazy type wraps a value of type A, provided by a “call-by-name” parameter to the class constructor to avoid eager evaluation.

But how do we sequence computations over a value wrapped inside a monad?

Since it is cumbersome to extract the monad’s wrapped value to apply operations, we need another function that can handle this for us. In Scala this is called the flatMap function. A flatMap function takes as input another function from the value of the type wrapped by the monad to the same monad applied to another type. A monad must provide a flatMap function to be considered one.

def flatMap[B](f: (=> A) => Lazy[B]): Lazy[B] = f(internal)
// Using our earlier example
val lazyString42: Lazy[String] = lazyInt.flatMap { intValue =>
  Lazy(intValue.toString)
}

We changed the value inside the monad without extracting it. So, any chain of flatMap invocation lets us make any sequence of transformations to the wrapped value.

Monads by nature also must also follow three laws

Left identity

Applying a function f using the flatMap function to a value x lifted by the unit function is equivalent to applying the function f directly to the value x.

Monad.unit(x).flatMap(f) = f(x)
// With the earlier example
Lazy(x).flatMap(f) == f(x)

Right identity

Application of the flatMap function using the unit function as the function f results in the original monadic value

x.flatMap(y => Monad.unit(y)) = x
// With the earlier example
Lazy(x).flatMap(y => Lazy(y)) == Lazy(x)

Associativity

Applying two functions f and g to a monad value using a sequence of flatMap calls is equivalent to applying g to the result of the application of the flatMap function using f as the parameter.

x.flatMap(f).flatMap(g) = o.flatMap(x => f(x).flapMap(g))
// With the earlier example
Lazy(x).flatMap(f).flatMap(g) == f(x).flatMap(g)

If a monad satisfies the three laws, then we guarantee that any sequence of applications of the unit and the flatMap functions leads to a valid monad — in other words, the monad’s effect to a value still holds. Monads and their laws define a design pattern from a programming perspective, a truly reusable code resolving a generic problem.

[ Scala Monads By baeldung ]

Now that we've understood Monads, let's take a look at some example Monads in Scala.

Option - An option type represents an optional value aka a value that is either defined or not. This provides type safety and also ensures that if the optional value is used anywhere in the code; it is functionally aware using it's monad properties.

val maybeInt: Option[Int] = Some(42) // Value defined
val maybeInt2: Option[Int] = None // No value defined

Either - An Either type models a disjoint union that represents a value that is exactly one of two types.

val eitherValue: Either[String, Int] = Right(42) // Right type
val eitherValue2: Either[String, Int] = Left("42") // Left type

It is most commonly used to model Errors as opposed to throwing exceptions

val eitherSuccessOrError: Either[Error, Int] = Right(42)
val eitherSuccessOrError: Either[Error, Int] = Left(Error("no 42"))

// instead of 
if (someCondition) 42 else throw new Error("no 42") else

Note: This type of composition for modeling errors of operations very similar to what we saw in our previous post with the tuple type.

Now let's try to implement these monads in Typescript so we can use these functional concepts.

The `Option` type

// We wrap the value inside an object
type Some<T> = { value: T }

// We want something better than null or undefined 
type None = Record<string, never>

// The Option type
type Option<T> = Some<T> | None

It's going to get cumbersome to keep wrapping our values to represent Some<T> and None so let's create some helper methods.

// Wrapper to create a Some<T> value
const some = <T>(value: T): Some<T> => ({ value })
// Wrapper to create a None value
const none = (): None => ({})

Now let's use our new types!

const someValue: Option<number> = some(1) // { value: 1 }
const noValue: Option<number> = none() // {}

That's really cool! Now how do we use this in a functional way?

If I want to know whether a value is defined (Some(value)) or not (None), I have to inspect my Option type

const isDefined = <T>(option: Option<T>) => !!option?.value

This works but it's not really scaleable enough to use everywhere.

What would be cool is if we can pattern match on the type. This is implemented in a lot of functional languages. For example in Scala, this is how we can match on the Option type.

val option: Option[Int] = Some(42)

option match {
 case Some(value) => println(s"Value is defined: $value")
 case None => println("Value is not defined")
}

Pattern matching is great! It allows you to functionally determine intent from the type and perform operations based on the tree.

Unfortunately Javascript doesn't support pattern matching...yet!

There's an ECMAScript proposal that is in the works to add this feature to the language! It's going to look something like this.

match (res) {
  when ({ status: 200, body, ...rest }): handleData(body, rest)
  when ({ status, destination: url }) if (300 <= status && status < 400):
    handleRedirect(url)
  when ({ status: 500 }) if (!this.hasRetried): do {
    retry(req);
    this.hasRetried = true;
  }
  default: throwSomething();
}

Well it's still a work in progress and might take some time to be added to the language. In the meantime however, let's build our own pattern matching mechanism.

To mirror the case match, let's create an interface to support the tree paths.

// Option Matchers 
interface Matchers<T, R1, R2> {
    none(): R1
    some(value: T): R2
}

The Matchers interface takes in a type T for the exists path of the Option, a type R1 for the response type of the none() path and a type R2 for the response type of the some(v) path.

Next, let's build a function to actually do the matching

// Option match function
const match =
    <T, R1, R2>(matchers: Matchers<T, R1, R2>) =>
    (option: Option<T>) =>
        'value' in option ? matchers.some(option.value) : matchers.none()

The above match function takes in the matchers interface object and applies it to the actual Option<T> value. Internally it checks the signature of the Some<T> type and if it exists, it calls the matchers.some(..) fn and if not the matchers.none() fn to satisfy both tree paths.

Now let's see this in action

const someValue: Option<number> = some(42) // { value: 42 }
const noValue: Option<number> = none() // {}

const result = match({
   some: (value) => value
   none: () => undefined
})(someValue) // 42

const result2 = match({
   some: (value) => value
   none: () => 'default'
})(noValue) // 'default'

This seems to work really nicely! Now let's compose this in a pipeline flow. Due to the match functions functional nature, we can apply it easily. A pipeline pipes the result of each operation as an input to the next operation in a sequence.

op1 => op2(op1_result) => op3(op2_result) => ...

To create our pipeline, I'm going to use the pipe function from the NodeJS ramda library instead of building my own.

const optionPipeline = pipe(
    () => some(42),
    match({
        some: (value) => value + 1,
        none: () => undefined,
    }),
    (input) => input.toString()
) // { value: 42 } => 42 + 1 => 42.toString() => '42'

Notice how this flows really nicely! We created an Option<Int>, passed it through our custom match function which added 1 to our Option if it exists and then converted the result to a string.

Imagine using this to build complex pipelines in your apps; with the functional type safety you don't have to worry about those pesky "what if this is undefined?" checks!

Next let's look at the Either type and define that in Typescript

The `Either` Type

type Right<T> = { value: T }
// We are using the Left type to model errors
type Left<E = Error> = { error: E }

// The Either Type
type Either<E = Error, T> = Right<T> | Left<E>

With the new Either<E, T> type, we are primarily modeling a union that can be either a Left type or Error and a Right type that can be a success value type.

Just like we did with the Option type, let's create some utilities and match functions to make the type practical.

Wrappers for the Either type can be done this way

const right = <T>(value: T): Right<T> => ({ value })
const left = <E>(error: E): Left<E> => ({ error })

Next let's create our matchers interface

interface Matchers<E extends Error, T, R1, R2> {
    left(error: E): R1
    right(value: T): R2
}

Similar to the Option case, the matchers for the Either type now takes in an extra argument for the Error type since Either consists of 2 generic types (left error type and right value) as opposed to the Option that only had 1 generic Type (the value)

And our match function now looks like this

const match =
    <E extends Error, T, R1, R2>(matchers: Matchers<E, T, R1, R2>) =>
    (either: Either<E, T>) =>
        'value' in either
            ? matchers.right(either.value)
            : matchers.left(either.error)

We are using a similar implementation for the match function as we did in the Option case by inspecting the either object and looking for a property (value) that is in the Right case ({ value }) but not in the left case ({ error }).

Note that this is just one implementation but you can also have your left and right types take any shape or form and update the match function to match your signatures. Another common option to do this is to use a discriminator type as follows.

type Right<T> = { typename: 'right', value: T }
type Left<E> = { typename: 'left', error: E }

And your match function can inspect the typename property instead.

But circling back, let's use our new types in a practical pipeline flow

const right: Either<Error, number> = right(42) // { value: 42 }
const left: Either<Error, number> = left(new Error('error')) // { error: Error('error') }


const eitherPipeline = pipe(
    () => right,
    match({
        right: (value) => value + 1,
        left: () => undefined,
    }),
    (input) => input.toString()
) // { value: 42 } => 42 + 1 => 42.toString() => '42'

And there you have it, we implemented a functional type for Either that is practical and can scale.

Here's another functional use case. Let's redo our tuple implementation from Part 1 using the Either type instead of the Tuple type.

const getDataFromDB = 
  async (ctx: Context): Promise<Either<Error, Data>> => {
    try {
      const result = await ctx.db.primary.getOne()
      return right(result)
    } catch (err) {
      console.error('Error getting data from DB', err)
      return left(err)
    }
  }

const app = async () => {
   const eitherData = await getDataFromDB(ctx)
   match({
     left: (err) => throw err,
     right: (value) => value
   })(eitherData)
}

In my opinion, this looks like a very pragmatic way to compose results of operations.

In the next and final post, let's look at an alternative type to the Either type that takes inspiration from the Rust programming language. We will also summarize what we have learned along with a handy library that encompasses all these concepts.

Bonus: If you like the idea of pattern matching, also check out this library that can help you with pattern matching use cases until the ECMAScript pattern matching standard is added to Javascript.

Congrats on making it to the end of this post! You have leveled up 🍄🍄

If you found this post helpful, please upvote/react to it and share your thoughts and feedback in the comments.

Onwards and upwards 🚀

Level up your Typescript game, functionally - Part 1

Prashanth R. — Sat, 25 Nov 2023 01:10:18 +0000

Welcome to the first post in the series "Level up your Typescript game, functionally".

Typescript is awesome. It is basically Javascript with superpowers. I can't imagine writing Javascript code today without types.

Statistics

Let's take a look at the state of programming languages. When we compare 2020 to 2023, we can see that there is rise in the popularity of Typescript, Python and GO.

Language	% of coders	% of coders	% change
	2020	2023
Javascript	`67.70`	`63.61`	🔻 `4.09`
Typescript	`25.40`	`38.87`	🔺 `13.47`
HTML/CSS	`63.10`	`52.97`	🔻 `10.3`
Python	`44.10`	`49.28`	🔺 `5.18`
SQL	`54.70`	`48.66`	🔻 `6.04`
Java	`40.20`	`30.55`	🔻 `9.65`
Shell (Bash etc.)	`33.10`	`32.37`	🔻 `0.73`
C#	`31.40`	`27.62`	🔻 `3.78`
PHP	`26.20`	`18.58`	🔻 `7.62`
C++	`23.90`	`22.42`	🔻 `1.48`
Go	`8.80`	`13.24`	🔺 `4.44`

Source: Stack Overflow Survey 2020 & 2023

Let's take a look at the rising popularity of Typescript when compared to Javascript in the web ecosystem.

Source: 2022 State of JS

We can certainly infer that Typescript adoption has grown and is steadily on the rise.

By the way, here's a fun documentary video about the history of typescript. It has a lot of interesting tidbits about timing and decisions that were made in the early days.

State of the union

Today there's tonnes of information and communities around typescript.

Note: If you are new to typescript, I highly recommend heading over to TotalTypescript and checking out the professional tutorials by the experienced Matt Pocock

Here's some sample type safe JavaScript code using Typescript.

type User = {
  id: number,
  name: string
}

const getUser = (): User => {
  return {
    id: 1,
    name: 'John'
  }
}

The above code ensures that at compile time we have checked our types and are operating on safe code.

What about asynchronous code involving I/O?

Well...this is what it looked like before 2017.

const aPromise = (): Promise<Data> => {
  // Some API call / IO 
  return Promise.resolve(data)
}

const main = () => {
  aPromise().then(data => {
      // Do something with result
  })
}

main().then(...)

It doesn't look great but it got better after the addition of async/await which was introduced as part of the ECMAScript 2017 standard.

const aPromise = async () => {
  // Some API call / IO 
  return Promise.resolve(data)
}

const main = async () => {
  const result = await aPromise()
  // Do something with result
}

But what about errors? Well...we can use try/catch

const main = async () => {
  try {
     const result = await aPromise()
    // Do something with result
  } catch (err) {
    // Do something with error
  } finally { // optional block
    // No matter what happens run this code
  }
}

This definitely works and does a much better job handling errors and unexpected things with I/O. But to be honest, it's not the cleanest code to look at.

Also what happens when you have to write a lot of I/O code that can potentially fail?

You get into try/catch hellscape of course.


// This promise will succeed
const promise1 = async () => { return Promise.resolve(1) }

// This promise will return an error
const promise2 = async () => { return Promise.reject(new Error('boom') }

// This promise could return an error or succeed
const promise3 = async () => { 
  const promiseResults = [
    Promise.resolve(1), 
    Promise.reject(new Error('boom')
  ]

 // Randomly pick the success or error promise
 return promiseResults[
   Math.floor(
     Math.random() * promiseResults.length
   )
 ]
}

const getRequiredData = async () => Promise.all(
  promise1, 
  promise2
)

const getResult = async (data) => promise3(data)

// Catch and throw
const app1 = async () => {
   try {
     const data = await getRequiredData()
     const result = await getResult(data)
     return result
   } catch(err) {
      // Note that we can't tell what promise failed from the try block
      console.error(`Something failed in the promise block`, err)
      throw err
   }
}

// OR don't catch anything and let it bubble up. 
// Looks nicer but no utility
const app2 = async () => {
  const result = await getResult(await getRequiredData())
  return result
}

Notice the difference between app1 and app2 above.

In the app1 case, we catch everything in the chain and can handle it but we have no information on what caused the error or what the source was, we simply know that something failed in the higher order operation. Furthermore, writing try/catch blocks for every async call in our entire app flow is going to get pretty messy, pretty fast.

In the case of app2, we don't do any error handling and let everything bubble up to the caller. If this was the root call, our app would have crashed with no handling; and even worse, if we didn't have a process monitor to reboot our app when it fails, we're out of luck unless we manually intervene.

Both of the above cases are not ideal. We can do better. We must do better.

Why are exceptions bad?

Here's a good breakdown from Dan Imhoff's post

Exceptions are not type-safe. TypeScript cannot model the behavior of exceptions. Checked exceptions (like in Java) will likely never be added to TypeScript. Not all JavaScript exceptions are Error objects (you can throw any value). JavaScript exceptions have always been and will always be type-unsafe.

Exceptions are often difficult to understand. It is unclear whether or not a function throws exceptions unless it is explicitly documented. Even source code inspection makes it difficult to know if exceptions might be thrown because of how exceptions propagate. On the other hand, if a Result-returning function is inspected, the error cases become immediately clear because errors must be returned.

Exceptions (may) have performance concerns. This isn’t hard science and likely completely negligible, but JavaScript engines in the past have struggled to optimize functions that use exceptions because pathways become unpredictable when the call stack can be interrupted at any time from anywhere.

So in summary, exceptions are pretty bad and unreliable to code against.

Now let's take a look at a solution to model our operations without using exceptions by creating custom functional types in Typescript.

The `ResultTuple` type

First let's represent our success and error using unit types

// An operation result can be anything
type OpResult<T> = T

// An operation error can be any custom error type or the Error type itself (default)
type OpError<E = Error> = E

Next, let's create a common type to represent the result and/or error of an operation.

// A unified type to represent the operation 
// result with both the success and error types.
// Either one or both can be defined
type ResultTuple<T, E = Error> = [ OpResult<T>?, OpError<E>? ]

Let's say we have a function that takes in a list of numbers and sums them. This is what the signature would look like

const add = (nums: number[]): number => {
  return nums.reduce((acc, c) => acc + c, 0)
}

To be more declarative, using the newly created ResultTuple type we can now represent the same function as follows.

// Return type with explicit result and implicit Error type
const add = (nums: number[]): ResultTuple<number> => {
  // first argument is the success type
  // second argument is undefined; same as [result, undefined]
  return [
    nums.reduce((acc, c) => acc + c, 0)
  ]
}
// OR Return type with explicit Error type
const add = (nums: number[]): ResultTuple<number, Error> => {
  return [
    nums.reduce((acc, c) => acc + c, 0)
  ]
}

We have created an explicit definition for the function that has both a success type and the error type. So callers can infer more from the result via ResultTuple.

const app = () => {
  // We can easily infer error or result from the operation
   const [result, error] = add([1,2,3])

   // If error is defined, do something with it
   if (error) { throw error }

   // If result is defined, do something with it
   if (result) { return result }
}

With this approach to the add function, we can de-structure both the result and error from the function call and act appropriately. This makes so much more sense because it's declarative and explicit and you know what you're getting when you call the add function.

Now, let's look at an error handling case

const divide = (dividend: number, divisor: number): number => {
  if (divisor === 0) throw new Error('Cannot divide by zero')
  return dividend/divisor 
}

// Rewrite the same function using our ResultTuple type

const divide = (
  dividend: number, 
  divisor: number
): ResultTuple<number> => {
  if (divisor === 0) {
    return [
      undefined,
      new Error('cannot divide by zero')
    ]
  }
  return [dividend/divisor]
}

const app = () => {
  const [result, error] = divide(1, 0)
  if (error) { throw error }
  if (result) { return result }
}

This works really well, doesn't it?

Now let's take a look at an asynchronous example. As we've seen before; this is how we would do it if we only used try/catch to handle our exceptions everywhere.

// A sample result data type
type Data = { id: string, value: string }

const getDataFromDB = 
  async (ctx: Context): Promise<Data> => {
    try {
      const result = await ctx.db.primary.getOne()
      return result
    } catch (err) {
      console.error('Error getting data from DB', err)
      throw err
    }
  }

// We have to catch here too and throw
const app = async () => {
  try {
   const data = await getDataFromDB(ctx)
  } catch (err) {
    throw err
  } 
}

Now let's add in the new paradigm of ResultTuple and this is what we would get

const getDataFromDB = 
  async (ctx: Context): Promise<ResultTuple<Data>> => {
    try {
      const result = await ctx.db.primary.getOne()
      return [result]
    } catch (err) {
      console.error('Error getting data from DB', err)
      return [undefined, err]
    }
  }

// The wrapper call becomes really simple
const app = async () => {
   const [result, error] = await getDataFromDB(ctx)
   if (error) { throw error }
   if (result) { return result } 
}

Using this pattern, our operations become more explicit and are super easy to reason about.

Note that we only used try/catch around the fn ctx.db.primary.getOne() to get data from the DB assuming we don't control this operation and it's behavior. We could also easily create a wrapper for the DB so we can catch errors internally and expose the the ResultTuple to callers.

You can also get really loose or strict with the types. For example, what if you wanted to define your own error type, you can do it this way.

// Custom error class that extends the JS Error interface
class AppError implements Error {
   name: string
   message: string
   constructor(message: string) {
    this.name = 'AppError',
    this.message = message
   }
}

// We create a new ResultTuple which overloads our Error type
// to be our base AppError instead of the default Error interface
type CustomResult<T, E = AppError> = ResultTuple<T, E>

Then you can use CustomResult<T, AppError> or CustomResult<T> everywhere instead of ResultTuple<T, E>.

const mySuccessFn = (): CustomResult<string> => { 
  return ["hello world"]
}
// OR
const myErrorFn = (): CustomResult<string> => {
  return [undefined, new AppError('boom')]
}

Using this pattern you can get more advanced with your error handling too

class AppError implements Error { ... } // see above
class DBError extends AppError { ... }
class OtherError extends AppError { ... }

// We can use the same custom result type
type CustomResult<T, E = AppError> = ResultTuple<T, E>

// Example use case where op fails when fetching data from DB
// Note that CustomResult already has AppError as the default
// Error type which means any class that inherits AppError 
// such as DBError can be safely returned
const getFromDB = (): Promise<CustomResult<Data>> => {
  try {
    ...
  } catch (err) {
    return [undefined, new DBError(...)] // works!
  }
}

The original definition of ResultTuple was designed in a way where either argument was optional. In order to tighten the type and usage, we can re-write it so that at most one argument should be specified that way each operation can only return a result or error but not both.

// Original definition where either argument can be present or undefined
type ResultTuple<T, E = Error> = [ OpResult<T>?, OpError<E>? ]

// New definition where only one argument can be defined
type ResultTuple<T, E = Error> = 
  [ OpResult<T>, undefined ] | [ undefined, OpError<E> ]

The new definition ensures that either the result or error is defined but not both at the same time. This is even better because this makes all operations that return this type choose one or the other and return data correctly. This is probably the safer pattern but it depends on your use case. What if you have operations that return partial results and errors? In that case, you are better off using the original definition so you can return both partial results and errors so callers can do as they please with that information. For example return [partialResults, partialErrors]

So we went through a lot of stuff in this article but in summary we saw how we went from traditional typescript programming to a pattern of functionally representing the results of operations using the ResultTuple type which is more declarative and scales based on practical use cases and avoids the Exception handling nightmare.

What if we wanted to make this even better? Typescript is so powerful and packed with so many features that we could use it to our advantage to boost our productivity and be declarative for complex use cases and flows.

In the next post, we will take a deeper look at functional programming and how we can apply it to Typescript to truly level up your code!

Congrats on making it to the end of this post. You have leveled up 🍄

If you found this post helpful, please upvote/react to it and share your thoughts and feedback in the comments.

Onwards and upwards 🚀

Be water, my friend

Prashanth R. — Tue, 16 Feb 2021 17:54:45 +0000

I've been reading a lot of Bruce Lee's philosophies lately. He was a great man who faced his fair share of challenges and was treated like an outsider even after he made it to Hollywood and became famous ^[1].

Transcript

Empty your mind. Be formless, shapeless, like water. You put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it into a teapot, it becomes the teapot. Now water can flow or it can crash. Be water, my friend. - Bruce Lee [1971]

What really amazes me is that even at the age of 26, he was immensely disciplined and kept a nice little pocket journal with thoughts, lessons and teachings that he could read and reflect on whenever he needed it.
(Notebook Image Source ^[1])

Here are some of his famous philosophies. I picked the ones that I can relate to and I'm going to attempt to explain the meaning behind them and how one can apply it to their daily life to become a better developer/programmer.

Bruce Lee's Philosophies 🥋

Always be yourself; express yourself; have faith in yourself

My interpretation: I believe Bruce lee says this in light of the many obstacles he faced in his career and his path to fame. People didn't respect him enough because he was an outsider didn't think he deserved worthy casting roles. He frames this idea to remind himself to be true to himself and keep persevering.

Application: In the programming world, everyone is unique in terms of what they can bring to the table. Always be yourself, add your own flair to your craft and believe in yourself for you have the ability to accomplish wonders.

Be a practical dreamer backed by action

My interpretation: Bruce was a firm believer that philosophies are meant to be applied and not just pondered ^[2]. He wholeheartedly tried to apply all of his philosophies to his way of life. They were a part of his core outlook and he practiced them religiously.

Application: While this particular idea is more philosophical than anything else, we can still apply it to a developer's life. Nothing is impossible if you put your mind to it. When faced with a size-able technical problem, dream and dream big without limitations. Then shrink it based on practical considerations like time, effort, resources and constraints. Finally, be sure to see it to completion.

Under the sky, under the heavens, there is but one family

My interpretation: This was in response to the question posed by Pierre Berton in his interview. Pierce asked Bruce if he considers himself Chinese or North American? (Fun fact: Bruce Lee was born in San Francisco ^[3]). He replied that he never considered himself to be from either place but he believed that he was just a human being, one among others on this planet.

Application: I personally think Bruce couldn't have said it better. Everyone has their own origin stories but in a professional world, we're all just human beings. We need to learn to treat each other with respect and dignity and there is no room for hate or any form of discrimination.

Walk on!

My interpretation: During the time between his first Hollywood debut series, The Green Hornet and his simultaneous acting career in Hong Kong, Bruce faced many challenges. He wasn’t getting the roles he felt he deserved, his financials struggled and he also had medical problems which affected his acting career which was primarily martial arts based. This was a key turning point for him where he turned to many self-help books for inspiration. He wrote "Walk On!" on the back of one of his business cards and placed it in line of sight. It became a constant reminder for him to always keep moving forward ^[2].

Application: During your professional career as a developer, there will often be times when you will be faced with adversity or difficult situations that are simply out of your control. This philosophy can serve as a reminder to find the strength to persevere and move on. As an unknown saying goes, it may be stormy now, but it never rains forever. Keep walking on...

Be Water, My Friend

This is by far my favorite philosophy from Bruce. He explains it quite well in the interview segment at the beginning of this post.

My interpretation: What Bruce Lee is aiming at is that in order to survive in this world, you have to learn to be adaptable to changing situations so you can always be ready to face and overcome any challenges. If you choose to become like water, you are shapeless and formless and can survive anything you're up against.

Application: In a developer's world we are often faced with with various challenges and problems. Plans change, designs change, requirements change and people change. We can apply this idea here by learning to be adaptable to changing situations by always expecting change and thereby applying an adaptable form or layer to several facets of your work i.e. your code, architecture, systems, process etc. When the world around you changes, you'll be ready for it.

Be Water, My Friend. 🌊

Bonus ☮️

Jeet Kune Do - Way of the intercepted Fist
Bruce Lee on the Pierre Berton Show, 1971
Bruce Lee Podcast
Things you didn't know about Bruce Lee
Best of Bruce Lee's Fights

References & Credits

Bruce Lee's Writings
Bruce Lee's Philosophies
Bruce Lee on Wikipedia
Cover Image: Photo by Yaopey Yong on Unsplash

Q: What do you think of these interpretations? Do you have your own versions of these ideas? I'd love to hear from you in the comments.

Hello, world 👋 (with GitHub Readmes)

Prashanth R. — Tue, 22 Dec 2020 00:47:25 +0000

Hi there. I'm Prashanth.

I'm an experienced full stack developer with a passion for technology and building scalable distributed systems.

This is my first Dev blog post. I joined Dev back in September 2018 and I've been meaning to write technical posts for a long time but have just not been able to do so. I've gathered a wealth of information over the years and I think I'm ready (or in the mood?) to finally start sharing bits and pieces (just the interesting ones) of my technical journey.

First of all, it's 2020 and everything is fine. REALLY.

On that note, I've just launched my GitHub profile readme.

The world of GitHub Readmes

I've seen many creative github profile readmes and drove my inspiration from many of them. What I initially wanted to do was to create a readme with some fancy html and css. Then I got shot down when I learned that Github uses this tool to sanitize the html and so it won't really work the way you think it would.

After launching a simple readme, I came across this really creative way with an explanation to actually use HTML inside of readme and I'm impressed. Last but not least, there's this popular project that helps add some cool looking github stats to your profile. It's really well done.

Anyway, I just wanted to write an intro post and say hi to the community. There's more to come and we have lots of work to do.

See you soon.

DEV Community: Prashanth R.

Level up your Typescript game, functionally - Part 3

The Result type

Summary

Takeaways and Resources

Acknowledgements

Conclusion

Level up your Typescript game, functionally - Part 2

The Option type

The Either Type

Level up your Typescript game, functionally - Part 1

Statistics

State of the union

Why are exceptions bad?

The ResultTuple type

Be water, my friend

Bruce Lee's Philosophies 🥋

Always be yourself; express yourself; have faith in yourself

Be a practical dreamer backed by action

Under the sky, under the heavens, there is but one family

Walk on!

Be Water, My Friend

Bonus ☮️

References & Credits

Hello, world 👋 (with GitHub Readmes)

The world of GitHub Readmes

The `Result` type

The `Option` type

The `Either` Type

The `ResultTuple` type