DEV Community: Ski

Your code probably does not need TypeScript's Omit<>

Ski — Tue, 21 Feb 2023 00:06:49 +0000

What are you optimising your code for? Would it be readability or rather least amount of meaningful words used? If trying to optimize code for later then Omit<> might be the tool for the job. If however readability is is a concern then Omit<> might be making your code worse.

Take this example, a seemingly straight forward case for applying Omit<>

type HigherLevelProps = Omit<LowerLevelProps, 'something'>

const HigherLevelCode = (props: HigherLevelProps ) => {
   ...

   return LowerLevelCode({
     something: "...",
     ...props
   })
}

When I am reading this code trying to understand how it works or what it needs to work, what would help me my understanding? Knowing what properties it needs - would be very helpful. Knowing what properties it doesn't need? Not really helpful at all. I cannot understand this code unless I dig deeper into LowerLevelCode - digging deeper will occupy more of my short term memory and/or will require me to manage more vertical code split windows before I can begin to understanding what the code is doing and how I could use it.

Let's check what Law of Demeter tells us. Principle talks about building code in a way that it can be successfully used and understood with least amount of knowledge. If I would try to apply it to my example above - I should be able to use HigherLevelCode without having to learn a lot about the LowerLevelCode. Yet applying Omit<> and spread operator (...props) achieves the exact opposite: my code needs to be coupled not just with HigherLevelCode but also with LowerLevelCode thus if I ever need to refactor LowerLevelCode it will not be enough to only change HigherLevelCode but also all the usage of it.

Let's try to improve the example to fix the problems we talked about:

type HigherLevelProps = {
   propA: ...,
   propB: ...
}

const HigherLevelCode = (props: HigherLevelProps) => {
   const {propA, propB} = props
   ...

   LowerLevelCode({
      something: "...",
      propA,
      propB,
   })
}

It may not be the shortest possible way to write code. But it results in code that I can read and understand faster as I no longer have to jump into implementation of LowerLevelCode to learn about necessary properties. It also makes refactoring easier to do in smaller iterative chunks thanks to code being less coupled (code that uses HighLevelCode now knows nothing about LowLevelCode and so each piece can be easily changed independently in smaller pull requests).

This may look like going against 'DRY' (Do not repeat yourself) concept creating repetition. Yet this is not necessary a situation where some amount of repetition is bad. In a situations where it is hard to maintain consistency between the repeated concepts for example if implementation of an algorithm is repeated in a few places - that's a big problem. However repeating attribute names is not necessary a problem: it helps to communicate meaning as opposed to stuffing type algebra that may be meaningful to TypeScript but fora human it requires additional mental power to process it and to understand it.

Surely if TypeScript added Omit<> it must be useful somewhere? Yes in some situations it is useful or even necessary. Typically that would be framework or library level code - code that is designed to be very generic. For example, if I want to implement a function that allows to bind a single property key of a function input parameter, Omit<> can be helpful to create type declaration for such function:

/**
 * Usage example:
 *   const xy = ({x, y}) => { ... } 
 *   const y = bindProp(xy, 'x', 0)
 */
const bindProp = <Props, ReturnType, Key extends keyof Props>
  (
    f: (props: Props) => ReturnType,
    key: Key, 
    value: Props[Key]
): (props: Omit<Props, Key>) => Return => {
   return (props) => f({...props, [key]: value})
}

notice how complicated TypeScript type declaration is, compared to the simple javascript function? When implementing libraries or frameworks and the code can simplify business logic in application's code it may be worthwhile to pay the price of complexity implementing very generic types.
If however code is in application level as opposed to a generic library - aiming for simplicity and avoiding cleverness is usually better bet. We can assume that library's code will seldom need to change and we can assume that if it needs to change it would be done by specialists who know TypeScript down to every details. On other hand when writing high level application code we should assume that it may be written and read by developers who are either less experienced (entry level roles) or might be coming from different background (a backend engineer trying to fix a simple UI bug).

I wish I had a lib that...

Ski — Sat, 18 Feb 2023 17:38:52 +0000

What kind of api/library you wish that you had that would make your work easier?

Writing fashionable functional code

Ski — Fri, 18 Feb 2022 16:15:38 +0000

Old and boring code:

interface Authenticated {
  isAuthenticated: true
  username: string
  firstName?: string
}

interface Anonymous {
  isAuthenticated: false
}

type User = Authenticated | Anonymous 

function greet(user: User) {
   if(user.isAuthenticated) {
      return 'Hello ' + (user.firstName || user.username)
   } else {
      return "I don't talk to strangers, bye"
   }
}

It's functional, it's not bad, but it lacks in style. We need more swag! Monads are all the rage nowadays. Functional code without monads ain't no functional code. Let's throw in some to make code look more hip

interface Authenticated {
   username: string
   firstName: Option<string>
}

interface Anonymous {
}

function greet(someone: Either<Authenticated, Anonymous>) {
   return someone
       .mapLeft((user) => 
         'Hello ' + user.firstName
               .getOrElse(user.username))
       .orElse(() => "I don't talk to stranges, bye")
}

How much better is this? Infinitely better!

And did you also noticed, we didn't just add swag, we removed the unnecessary boolean isAuthorized! We can identify users from anonymous by their political leaning left or right*. Less business specific jargon, more generalizations, better code!

Which style do you prefer more? Leave comment.

*Monad inspired APIs, for example fp-ts, frequently refer to one of two possible types of values either as 'left' or 'right'

Classes are still useful even in largely functional style code

Ski — Tue, 15 Feb 2022 12:14:36 +0000

It’s became a fashion to rid code of classes even when it doesn’t help produce better code. The popular web UI framework React is likely a culprit — so many developers are familiar with React and so any trends started by React developers inevitably spread even if outside React same concepts don’t work at all.

While classes are mostly associated with object oriented programming they can also be just as useful tool in functional programming as they are in OOP. Functional programming while containing useful ideas and goals badly lacks down to earth vocabulary.

The use case that classes solve is same that of “Higher-order functions”. This functional term is a bit broad — it’s good to describe a general approach but not good to name the individual bits in code. It’s not immediately clear if higher-order function refers to function that returns a function, or a function that takes a function as a parameter or a function that has been returned by a function and in this sentence the word function was used so many times that it should be pretty clear that we need better vocabulary.

Classes provide more structure and very useful vocabulary:

Class
Constructor
Instance
Property
Method

Now it’s easy to identify what is what — instead of “function that returns a function” — we got a “class" and "constructor”. Instead of “function that has been created inside a function” — we have a method. And it has became explicit that methods don’t exist without instances, just like returned functions don’t exist without hidden closures attached to them.

What also very helpful is that it's more natural to name classes using nouns. This makes code look more like a human language - we typically don't use verbs to describe gifts that we get on birthdays. Meanwhile typically verbs are frequently used to name functions/methods thus it often becomes awkward to give a name to variables that hold on to a function that's bound to closure. On one hand it makes sense that function is verb on other hand when function is passed around like a gift it's awkward if it's name is a verb.

What classes help to achieve — a code written in such a manner that all functions are always verbs, and all things that can be passed around are always nouns. It helps to achieve consistency. It helps to talk about code. And yes it’s sometimes takes more time to give meaningful naming — but this is a good problem to have — after it’s solved it creates a code that is more easy to understand and has more clearly defined structural shape.

It doesn’t matter if you’re fan of functional programming or not — if your programming language has classes — use them instead of just plain functions — it’s good for your code.