DEV Community: Jun Kaneko

Using Algebraic Data Types (ADTs) in TypeScript

Jun Kaneko — Thu, 16 Mar 2023 17:58:06 +0000

Algebraic Data Types (ADTs) are concepts originally from functional programming languages, representing composite types formed by combining other types. In TypeScript, ADTs can be achieved using union types ("|" operator), intersection types ("&" operator), and discriminated unions.



type Alien = {
  type: 'unknown';
}

type Animal = {
  species: string;
  type: 'animal';
}

type Human = Omit<Animal, 'type'> & {
  name: string;
  type: 'human';
}

type User = Animal | Human;

A discriminated union in TypeScript is a way to create a type that combines union types and has a common property that can be used to determine the specific type of the variable at runtime. In the example above, type: 'animal' or 'human' is the common property.

Algebraic Data Types (ADTs) provide several benefits:

Expressiveness and Maintainability:

ADTs allow to model complex data structures and relationships naturally by providing clear, self-documenting type definitions. They enable you to create composite types that accurately represent the domain, making the code easier to understand and reason about.

Type safety:

By using ADTs, you can explicitly define the structure of your data, making it easier for the TypeScript compiler to catch potential issues at compile time.

Pattern matching and exhaustiveness checks:

When working with ADTs, especially sum types (discriminated unions), you can leverage TypeScript's ability to perform pattern matching and exhaustiveness checks. These checks help ensure that you've handled all possible cases when working with a value, reducing the chances of bugs due to unhandled cases.

Encapsulation of logic:

ADTs can help you encapsulate the logic related to specific data structures, such as validation or transformation, making your code more modular and easier to reason about.

Utility Types

TypeScript provides several utility types to help describing the composition such like the ADTs.



type Human = Omit<Animal, 'type'> & {
  name: string;
  type: 'human';
}

Omit : This is a utility type that creates a new type by removing the specified keys from the given type. In this case, it removes the type property from the Animal type.
&: { } : The intersection type operator combines two or more types into a single type that has all the properties of the original types.

By combining the types with the intersection type operator, the Human type ends up having the properties species and name, as well as the discriminant type with the value 'human'. The Human type is essentially an extension of the Animal type with some modifications.

Finally, User is a union type that can represent any of the Animal, Human, or Adult types.

Difference between extends and & intersection

It is possible to write the similar data structure by using interface with extends.



interface Animal {
  species: string;
  type: 'animal';
}

interface Human extends Omit<Animal, 'type'> {
  name: string;
  type: 'human';
}

The interface keyword is primarily used for defining object types, while the type keyword is used for defining any type, including object types, union types, and intersection types.

One key difference between using extends and & is that extends creates a new type that has an inheritance relationship with the parent type, while & creates a new type that is a combination of two or more existing types without any inheritance relationship.

It is a personal preference, but type could be more flexible when you have to describe a lot of intersections.

How to predict unknown data

Suppose we have the following un-typed data, how can we let TypeScript compile to allocate them to the proper types?



const ghost: unknown = null;
const alien: unknown = {}

const sheep: unknown = {
  species: 'sheep',
}

const jun: unknown = {
  name: 'Jun',
  species: 'human',
}

const anomany: unknown = {
  name: 'anomany',
}

User-defined type guards

User-defined type guards are a feature in TypeScript that allows you to create custom type-checking functions that can narrow down the type of a value within a specific scope.

Takes a value as a parameter, which is usually of a more general type, such as unknown or a union type.
Returns a boolean value, which indicates whether the value matches the expected type.
Uses a special type predicate in the return type annotation, in the format "value is SpecificType". This tells TypeScript that the function can narrow down the type of the value to SpecificType when it returns true. In the following example, "someone is Animal", "someone is Human" and "data is { [key: string]: unknown }" are the type predicates



function hasProperty(data: unknown): data is { [key: string]: unknown } {
  return data != null;
}

function isAnimal(someone: unknown): someone is Animal {
  return hasProperty(someone) && typeof someone.species === 'string'
}

function isHuman(someone: unknown): someone is Human {
  return hasProperty(someone)
  && typeof someone.name === 'string'
  && someone.species === 'human';
}

hasProperty is a type guard function that checks if data is an object with string keys and unknown values.

isAnimal and isHuman are type guard functions for the Animal and Human types, respectively. These functions check whether an unknown entity has the required properties and correct types to be an Animal or Human.



function categorise(item: unknown): User | Alien {
  if (isHuman(item)) {
    return { ...item, type: 'human' } as Human;
  }
  if (isAnimal(item)) {
    return { ...item, type: 'animal' } as Animal;
  }
  return { type: 'unknown' } as Alien;
}

The categorise function takes an unknown item and returns a User (either Animal or Human) or an Alien. It uses the type guard functions isHuman and isAnimal to check the type of the item and adds the type property accordingly.



function parseItems(items: unknown[]): User[] {
  return items.flatMap((item) => {
    const categorised = categorise(item)
    return categorised.type === 'unknown' ? [] : [categorised];
  })
}

The parseItems function takes an array of unknown items and returns an array of User entities. It categorises each item using the categorise function and filters out any items with the type property set to 'unknown'.

Render data according to the type

Once each data is assigned to a specific type, you can safely consume the data. For example, if you want to render them differently according to the type:



function renderHuman(someone: Human) {
  return `${someone.name} is a human`;
}

function renderAnimal(someone: Animal) {
  return `It is a ${someone.species}`;
}

function renderItems(items: User[]) {
  return items.map((item) => {
    switch (item.type) {
      case 'human':
        return renderHuman(item);
      case 'animal':
        return renderAnimal(item);
      default:
        return 'unknown';
    }
  });
}

Your editor can show code suggestions and errors benefitting the type safety.

And the previous data will render the expected output.



const list = parseItems([ghost, alien, anomany, jun, sheep]);
console.log(renderItems(list))

[ 'Jun is a human', 'It is a sheep' ]

Understanding React Native Architecture

Jun Kaneko — Thu, 27 Aug 2020 11:43:59 +0000

React Native is an excellent entering point to app development for a web developer, especially with React experiences.

However, it does not mean that React Native is simple. You can write apps with your familiar language, JavaScript, but it certainly requires an overall understanding of iOS and Android platforms. This article is a summary of my learning process on the React Native architecture and the ecosystem from the web developer point of view.

The Execution Environments

React runs on the JavaScript runtime environment. For the web, it is a web browser. There is a single JavaScript thread, and it uses web APIs implemented natively in the browser.

It is important to understand how the callbacks work between the main JS thread and Web APIs, especially when using asynchronous functions. This interaction between JavaScript engine and native APIs are also vital to understand how React Native behaves in its environment.

Threads in React Native

There are three key threads in React Native execution environment, JavaScript thread, Native main thread and the background thread to handle Shadow Node.

In the current architecture, the communication between these threads happens over the library called "bridge".

The React Native team is actively working on the major architecture upgrade and this article gives a great overview of why and how the change is needed.

I don't get into the details, but the basic understanding of the current and future architecture helps to model your application, especially to separate the concerns.

React and React Native

As you can see above, React Native covers a significantly broader area than React itself.

React for the web looks rather intuitive as the key concept, the Virtual DOM, implies the browsers' HTML dom rendering. But in-fact, the Virtual DOM is not tied to the HTML DOM (Document Object Model). The Virtual DOM in React is more of a programming concept or a pattern than a specific technology.

It provides an abstraction for the declarative UI. The virtual representation of a UI is kept in memory and synced with the external UI libraries. This process is called reconciliation.

You can read a good explanation of the React Fiber Architecture here.

Reconciliation versus rendering

The DOM is just one of the rendering environments React can render to, the other major targets being native iOS and Android views via React Native. (This is why "virtual DOM" is a bit of a misnomer.)

The reason it can support so many targets is because React is designed so that reconciliation and rendering are separate phases. The reconciler does the work of computing which parts of a tree have changed; the renderer then uses that information to actually update the rendered app.
This separation means that React DOM and React Native can use their own renderers while sharing the same reconciler, provided by React core.
Fiber reimplements the reconciler. It is not principally concerned with rendering, though renderers will need to change to support (and take advantage of) the new architecture.

React Native Components and React Navigation

React Native provides its own UI abstraction layer over iOS and Android platforms. React Native core and native components invoke the native views so that you can write the smartphone app UI with JavaScript, instead of Kotlin/Java or Swift/Objective-C.

Core Components and Native Components

The native components cover comprehensive native UI elements, but you still need to write a lot of code to simulate the native user experience such as tab navigation. That's where React Navigation comes in.

React Navigation is a pure JavaScript library which does not include any native code. It is built on the other native libraries such as Reanimated, Gesture Handler, and Screens to implement the common app navigation patterns.

It provides the best practice of how to structure and navigate the app screens, which is one of the most confusing parts when you come from a web development background.
My advice is to stick to the basic navigation patterns until you are confident, and you can implement your custom navigators on top of React Navigation once you have the good overviews. I would also prefer to place navigators and screens into the dedicated directories to clearly separate them from the other components.

Thinking in React

Despite the difference in the UI implementations, the thought process of building a new application stays the same as "Thinking in React" way.

Start With A Mock
Break The UI Into A Component Hierarchy
Build A Static Version in React
Identify The Minimal (but complete) Representation Of UI State
Identify Where Your State Should Live
Add Inverse Data Flow

Hooks and Functional Component

React 16.8.0 introduced Hooks in 2019, and it was a big paradigm shift. The React team expects Hooks to replace all the Class Component use cases, and the popular libraries have already migrated toward this direction, for example, React Navigation 5.0 and React Redux 7.1.0 introduced their Hook APIs.

Conceptually, React components have always been closer to functions, and "Thinking in React" way became more straight forward with Hooks.

The motivation behind Hooks explains the benefits:

Hooks let you split one component into smaller functions based on what pieces are related (such as setting up a subscription or fetching data), rather than forcing a split based on lifecycle methods. You may also opt into managing the component's local state with a reducer to make it more predictable.

Component Side Effects and Closure

Based on the prototype inheritance, JavaScript functions are said to be the first-class citizens which means that they can be:

assigned to variables
used as functional parameters
returned from a function

These are equally applied to React's Functional Component. JavaScript's Closure is also an essential element when using Hooks.

A closure is a combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function's scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time. (MDN Web docs: Closures)

Like this example in Hooks FAQ, it is very important to understand when the closure is created in the component lifecycle and use the stable function instead of unstable state variables within Hooks.

Note: Unlike the setState method found in class components, useState does not automatically merge update objects. You can replicate this behaviour by combining the function updater form with object spread syntax:

React also provides Context API to share data that can be considered "global" for a tree of React components, such as the current authenticated user, theme, or preferred language.

Referential Transparency and Static Type Checking

JavaScript is multi-paradigm, Object-Oriented Programming and Functional Programming, and React has been inherited the strength of both. But with Hooks, I feel that it is more opinionated toward the functional programming.

The key feature of React is the composition of components. Components written by different people should work well together. It is important to us that you can add functionality to a component without causing rippling changes throughout the codebase. (React Design Principles)

By extracting side effects from a React component, it becomes more predictable. You can expect the component to render the same output if the input is the same. In more specific words, it can gain referential transparency, or be idempotent.

In practice, the referential transparency should be assured by the static type checking and sufficient unit testing.
Static type checkers and linters, my preference is TypeScript and ESLint, make the development experience more confident and solid as they can identify certain types of problems before you even run your code.

Although the configuration could be a bit cumbersome when you start a new project, it helps you and your team to be much more productive. I don't see any reason not to use them in 2020.

Component Tests

A declarative component is easier to write the test as you can focus on the pure interaction and rendering of the component.

With Hooks, you can extract stateful logic from a component so it can be tested independently and reused. Hooks allow you to reuse stateful logic without changing your component hierarchy. (The motivation behind Hooks)

I believe that React Native Testing Library is now a defacto testing library for React Native. It integrates closely with Jest and provides clear testing methodologies along with the popular libraries such as React Navigation and Redux.

React Test Renderer is developed alongside React core. It renders React components to pure JavaScript objects, without depending on the DOM or a native mobile environment.

React Native Testing Library (or RNTL) is built on top of React Test Renderer. It adds useful APIs such as to render ( to getByText, queryAllByA11yRole, …), fireEvent, waitFor, and act. It is opinionated to focusing on user experience and accessibility.

React Hooks Testing Library to write test custom hooks that are not directly tied to a component or complex that is difficult to test through component interactions.

Conclusion

I understand that there has been and will be always a debate between React Native vs Native App development.

But as a JavaScript developer, React and React Native itself is a very interesting and inspiring framework to learn. It is leveraging the JavaScript's capability at the maximum level and packed with the best practices.

Through the learning process, I felt like gaining a more in-depth understanding of JavaScript language itself. I hope that this article may convey excitement.