DEV Community: Mike Skoe

Opaque TypeScript

Mike Skoe — Sat, 02 Mar 2024 21:50:10 +0000

Let us begin straight with the example after which we will discuss the what, why and how.

You don't need to understand everything in the code.
But note that we have two values: fahrenheit and celsius.
Both of them have the Fahrenheit and Celsius types respectively.
But even though TypeScript is a structural language and both of the types are essentially numbers, they are not interchangeable. On top of that we can't even write F.add(fahrenheit, celsius as F.Fahrenheit);.
✨ Pure miracle ✨

The what

An opaque data type is a data type whose concrete data structure is not defined in an interface. This enforces information hiding since its values can only be manipulated by calling subroutines that have access to the missing information.

Wikipedia

Translating it from the Wikipedian, the opaque type is an encapsulation (hiding internal structure) that is not limited to OOP (classes).

The idiomatic alternative using classes would look like this
This version is more readable and less cryptic, but we are not always able/want to use classes.

Thy why

A typical example of a classless circumstance could be a Flux architecture (like Redux), where behavior is separated from data.
But there are some other a bit less obvious reasons to give the opaque type a try:

True guard

Imagine that we need to model a domino type.
Usually, we go ahead and do something like:

type Domino = [DominoValue, DominoValue];
type DominoValue = 1 | 2 | 3 | 4 | 5 | 6;

This is a good example of using TypeScript types, but it does not always make sense or save us from a wrong structure.
Because such type is safe as long as we are responsible for making the instances.
As an example, take a look at the following express router:

    Router()
        .post<unknown, unknown, Domino>("/add", (req, res) => ...)

We promise to the compiler that the req.body has the Domino type, while it can be wrong.
Typically to guard the type we make some validation function, like function isValid(domino: Domino): boolean { ... }, but we can forget to call the guard and all typing is just a nice description, not an actual validation.
Opaque type can help us to apply the type-level programming, where the result of a validation is another type.

So that the only way to create the domino type is a specific validation function so that the request body is just a raw input

// domino.ts
declare const domino: unique symbol;
export type Domino = [number, number] & { [domino]: "Domino" };

export function createDomino(rawData: [number, number]): Domino | false {
    for (const value of rawData) {
        if (value < 1 || value > 6) {
            return false;
        }
    }
    return rawData as Domino;
}

console.log(createDomino([1, 2]))  // [1, 2]
console.log(createDomino([-1, 2])) // false
console.log(createDomino([5, 29])) // false

Phantom type

Phantom type is a way to differentiate types using unused generic parameters.
The most typical example is making an Id type that is attached to a specific entity so that it can not be mixed up with another type's id.
Here is the example.
Note that even though both of the ids are strings, we can not use the post's id in place of the user's id and vice versa.

The how

As you may have noticed, the key part is the unique symbol.
We declare a file local symbol, that serves as a specific key in an object.

Technically it is not a pure opaque type, because we still se the actual internal structure from outside.
Still, since symbols are unique, only the local symbol can be used while creating opaque types instance.

Even though we never actually initialise the symbol, we can do that, but in this case, we affect the resulting JS object's structure, which is not always desirable.

Reactive around reducer

Mike Skoe — Tue, 24 Oct 2023 21:29:33 +0000

Recently, I've been experimenting with an implementation of my library that provides reactivity to ReScript, called ReX. The goal of this project is to implement a low-level reactive library for ReScript and explore a combination of reducers and observables to achieve scalability. Additionally, I want to experiment with OCaml's React-like API and have some fun along the way. You can check an example usage of the library in a React application here

A taste of ReX

Before diving into my thoughts, let me quickly show you an example of how to use the ReX library

let intString = ReX.make(Belt.Int.toString);
let floatString = ReX.make(Belt.Float.toString);

let numbers = ReX.both(intString, floatString, ("0", "0.0"))
    ->ReX.map(((left, right)) => `${left}:${right}`)
    ->ReX.debounce(100);

let unsub = numbers->ReX.sub(Js.log);

intString->ReX.call(3);
floatString->ReX.call(2.2);

React Architecture

Sometimes I meditate about Elm-ish (like Redux) vs reactive (like MobX, Jotai, etc). On the one hand, the Elm-ish way provides robust global state management that is easy to test and debug. On the other hand, reactive options let you write a boilerplate code with declarative time-spaced operators. Ultimately I concluded that the best option is a proper combination.

How I see it

[Domain] <- [Reducer] <- [Observable] <- [UI]

When it comes to designing an architecture, I imagine it as a system with multiple layers, each with its own specific purpose.

At the very core, we have the domain of our application, which contains the business logic with no dependencies. Surrounding the domain is a reducer, which is a thin layer that exposes the domain in the form of (action, prevState) => newState.

Languages that support Algebraic Data Types (ADT) are particularly useful here because they eliminate the need to write any boilerplate code to make actions.

The reducer is then covered with observables, which provide a reactivity part to the architecture. Wrapping our reducers with observables gives us a lot of opportunities to declaratively handle effects like throttling actions, implementing selectors, combining the observables, and more.

As an example, let's imagine a todo application.

Domain

A type of the domain-level modules could look like this:

module Tasks: {
    type task = Todo(string) | Done(string, float)
    type t = list<task>

    let empty: t
    let addTask: (t, string) => t
    let doneTask: (t, task, float) => t
    let filterTasks: (t, task => bool) => t
    let isDone: task => bool
    let isTodo: task => bool
}

module Filter: {
    type t = All | TodoOnly | DoneOnly

    let filterTasks: (Tasks.t, t) => Tasks.t
}

Reducer (State)

Next we represents the functionality in the form of actions and a state

module State = {
    type action =
        | AddTask(string)
        | DoneTask(Tasks.task, float)

    type state = Tasks.t;

    let initialState: state = Tasks.empty;

    let reducer = (state: state, action: action): state =>
        switch action {
            | AddTask(content) => state->Tasks.addTask(content)
            | DoneTask(task, timestamp) => state->Tasks.doneTask(task, timestamp)
        }
}

Observable (Store)

And now we can use the state in our observables

module Store = {
    let { make, id, thunk, either, reduce, sub, both, map, delay } = module(ReX);

    // inputs
    let addTask = make(str => State.AddTask(str));
    let doneTask = make(task => State.DoneTask(task, Js.Date.now()));
    let fetchNewTask = make(id)
        ->thunk((source, dispatch) => {
            fetchFrom(source)
                ->Js.Promise2.then(async response => {
                    dispatch(State.AddTask(response))
                })
                ->ignore;
        });
    let taskFilter = make(id);

    // global state
    let tasks =
        addTask
        ->either(doneTask->delay(500))
        ->either(fetchNewTask)
        ->reduce(State.initialState, State.reducer)

    // effects (middleware)
    let unsubLogFilter = taskFilter->sub(log)

    // outputs
    let filteredTasks =
        tasks
        ->both(taskFilter, (Tasks.empty, Filter.All))
        ->map(((tasks, filter)) => Filter.filterTasks(tasks, filter))
}

In terms of Redux, we have:

Store.addTask, Store.fetchNewTask, etc. as actions. So adding a new task from a React component is as simple as Store.addTask(contentString) instead of dispatch(createAddTaskAction(contentString))
Store.tasks as a reducer that contains the most critical logic
Store.unsubLogFilter as a middleware
Store.filteredTasks as a selector. So that we can expose only the selected slices of states, instead of only the main state, delegating the selection to components

Presentation (View)

In order to be able to use observables in React components, we need to sync them with Component's lifecycle. Here is a usefull hook that takes an observable and a selector and provides a local slice of obsevable's stream

let useSync: (ReX.t<BattleState.action, BattleState.state>, 'a, BattleState.state => 'a) => 'a
    =
    (t, initial, selector) => {
        let snapshot = React.useRef(initial);

        React.useSyncExternalStore(
            ~subscribe = sub => {
                let unsub = t->ReX.sub(value => {
                    snapshot.current = selector(value);
                    sub();
                });
                (.) => unsub();
            },
            ~getSnapshot = () => snapshot.current,
        );
    }

So now we can use observables like:

let choice = app->useSync(None, getChoice); // app is an observable; getChoice is a pure state's selector

The full example of useing the observables together with React can be found here

In conclusion

My thoughts about the layered architecture for reactive programming combined with an immutable global state led me to create the ReX library, which provides reactivity to ReScript. However, if you need to follow a similar approach in production (specifically with TypeScript), I highly recommend trying to connect RxJS to Redux manually and with tools like redux-observable

Depth of composition

Mike Skoe — Sun, 20 Aug 2023 21:58:37 +0000

When developing applications, it is common to split a large amount of code into smaller units. However, one of the difficulties is how to compose these parts together. In this post, we will emphasize the "depth" of a composition. This refers to how nested composition differs from flat composition in different contexts.

Class

// -- nested --
class Low {}

class Middle {
    private low = new Low();
}

class High {
    private middle = new Middle();
}

// usage
const high = new High();

// -- flat --
class Low {}

class Middle {
    constructor(
        private low: Low,
    ) { }
}

class High {
    constructor(
        private middle: Middle,
    ) { }
}

// usage
const high = new High(new Middle(new Low()));

React component

// -- nested --
const Low = () => <low />;

const Middle = () => <middle><Low /></middle>;

const High = () => <high><Middle /></high>;

// usage
<High />

// -- flat --
const Low = () => <low />;

const Middle = ({ children }) => <middle>{children}</middle>;

const High = ({ children }) => <high>{children}</high>;

// usage
<High>
  <Middle>
    <Low />
  </Middle>
</High>

Function

// -- nested --
function low() {}

function middle() {
  low();
}

function high() {
  middle();
}

// usage
high();

// -- flat --
function low() {}

function middle(low: () => void): () => void {
  return () => {
    low();
  }
}

function high(middle: () => void): () => void {
  return () => {
    middle();
  }
}

// usage
high(middle(low))();

Interface

// -- nested --
interface Low { }

interface Middle extends Low { }

interface High extends Middle { }

// -- flat --
interface Low { }

interface Middle { }

interface High extends Middle, Low { }

Why flat?

Easier to navigate between layers
More control over each layer of the code
Easier to manage and modify
It facilitates mocking
It encourages reliance on interfaces

Why nested?

More intuitive structure
Easier to implement and use
It hides inner details from the API
It provides a simpler interface for users

By considering these factors, developers can choose the most suitable approach for their specific needs and context.

Reselect, but in OCaml

Mike Skoe — Tue, 19 Oct 2021 18:42:44 +0000

The post was originally written here, so you can go there to play with the code

In this post, I'd like to share with you my implementation of reselect library and few related reflections.

Reselect is a library to make reusable and memoized selectors. Which allows you to put minimal data inside your state. I like the simplicity and the power of that concept, so I decided to build something similar myself.

Let me first put the working implementation. Then we will use it.

let memo ?eq:(eq=(=)) fn =
    let last_arg_res = ref None in
    (fun arg ->
        match !last_arg_res with
        | Some (last_arg, last_res) when eq last_arg arg -> last_res
        | _ ->
            let new_res = fn arg in
            last_arg_res := Some (arg, new_res);
            new_res
    )

type ('a, 'b) t = ('a -> 'b)

let return res = (fun _ -> res)

let id a = a

let (>>=) fn bind_fn =
    fun arg -> arg |> bind_fn @@ fn arg

To make our code a little more elegant, we will prepare some utils.

let (>>) f1 f2 arg = f2 (f1 arg)
let percent all part =
  let part = float_of_int part in
  let all = float_of_int all in
  part /. all *. 100.
  |> int_of_float

Now we are ready to play. Imagine an app to learn words.

module Word = struct
  type t = {
    language: string;
    spelling: string;
    translation: string;
    learned: bool;
  }

  module Get = struct
    let lang {language; _} = language
    let spell {spelling; _} = spelling
    let transl {translation; _} = translation
    let learned {learned; _} = learned
  end
end

module State = struct
  type t = {
    current_language: string;
    words: Word.t list;
  }

  module Get = struct
    let cur_lang {current_language; _} = current_language
    let words {words; _} = words

    let cur_words t = 
      let lang = cur_lang t in
      let words = words t in
      words
      |> List.filter (Word.Get.lang >> (=) lang)

    let learned_cur_words t =
      let words = cur_words t in
      words
      |> List.filter (Word.Get.learned)

    let progress t =
      let words_len = cur_words t |> List.length in
      let learned_words_len = learned_cur_words t |> List.length in
      percent words_len learned_words_len
  end
end

let sample: State.t = {
  current_language="nl";
  words=[
    { language="nl"; spelling="banana"; translation="banaan"; learned=true; };
    { language="eo"; spelling="winter"; translation="vintro"; learned=true; };
    { language="nl"; spelling="kindness"; translation="vriendelijkheid"; learned=false; };
    { language="nl"; spelling="rainbow"; translation="regenboog"; learned=false; };
  ]
}

let progress = State.Get.progress sample

The state data is exposed through getters, which help us to easily get/calculate required data. It is extremely useful. But what if our progress getter could perform some heavy calculations? Performing the calculations every time is not the most efficient decision. Especially if state changes do not relate to data used inside progress getter. But we can rewrite the getter.

let (>>=) fn bind_fn = fn >>= (memo bind_fn) (* Without this line the ">>=" performs only a function composition, which is also nice *)

let progress =
  State.Get.cur_words >> List.length >>= fun words_len ->
  State.Get.learned_cur_words >> List.length >>= fun learned_words_len ->
  return (percent words_len learned_words_len)

This way the getter looks a bit different, but now the body of progress getter will trigger only if words_len or learned_words_len will change. Great!

This concept lies in between things like reactive programming, incremental and lenses, but it focuses only on getting data, it can perform calculations along the way, and it does nothing, unless you ask for it.

Interesting points

Since composition is performed using function monad, we have no limits in the number of arguments
Memo can accept the optional argument, to customize memoization strategy
By default bind (>>=) function does not perform memoization, so we can apply different features to binding functions. Memoization is only an option

Things I've learned in the latest app

Hide types and expose setters/getters. It will help you to reason about your structure consistency and will allow you to compose multiple getters or setters
Try to fill your state only with the data you need right now. OCaml has variant types, it can help you to describe all possible scenarios and what data they will need
Cyclic dependencies can hurt your architecture OCaml and dune will warn you if you have cyclic dependencies. Sometimes it is so easy to fix, but tree-like dependencies will make your code more reusable, testable, and pure.

I've done TUI (Terminal User Interface) app. This is what it looks like

Mike Skoe — Fri, 16 Apr 2021 06:36:19 +0000

For the last few months, I was learning OCaml in my free time. To improve the skills I decided to make a little minimalist app, for listing all things you have and reasoning about their necessities. The idea is to make an app with a terminal user interface using sqlite3 as persistent storage. Here is the link to GitHub

In this post, I would like to shallowly sketch the code and the main architecture.

Since the app not performs any heavy computations and has no timers - the main loop will be synchronous, which simplifies implementations quite a bit.

let rec loop (state, msgs) =
      let open State in
      match msgs with
      | [`Navigation Navigation.Quit] -> ()
      | msgs ->
      (state, msgs)
            |> MyState.reducer
            |> Ui.reducer
            |> loop

As we can see, the main loop is implemented as a recursive function that takes a tuple of state and message list, modifies the tuple until any quit message, and return the unit as a result, to stop execution. The message is represented as a list because it allows batch actions.

To see how the tuple is changing, info is drawing and an event is handling we should zoom into the loop a bit

UI - is the module responsible for, you know, UI and event handling. It takes our tuple and returns a tuple with modified messages.
Reducer (in code it is called State, but here I’ve changed the name to prevent name collisions) - is the module responsible for changing state, depending on messages.

Let's again zoom into the modules, but first, familiarize ourselves a bit better with state and message.

Since the app has only two "pages", it is represented as a variant with two options. Every page has its own variant of messages and its own logic to modify the state via the messages. The only "high level" message type is navigation, which allows switching between pages. The main message type has a shape of polymorphic variant because this way there is no cyclic dependency.

As some can guess, the architecture was heavily inspired by Elm and Elmish parent-child patterns.
Notty - is a cool library, which is a perfect choice for a simple terminal draw. But keep in mind, that you will be responsible for focus management and isolation of all event handlings.
Sqlite3-OCaml - is totally imperative library, because it is just bindings on C library. But you get all the essential functionality with which you can build yourself the needed level of abstraction.

I have an assumption, that functional programming is a perfect tool for safe and reliable GUI and I always wanted to make TUI, so I believe, with this project and the tools I have achieved what I wanted.

If you like to get a more in-depth overview of OCaml/code/tools, let me know.

Algebraic Data Type(ADT) with TypeScript

Mike Skoe — Sat, 06 Feb 2021 17:15:39 +0000

Functional programming languages are awesome. They have a lot of brilliant design decisions, the most mainstream ones are Algebraic Data Type (ADT) and pattern matching.

Simple ReasonML example:

/* Algebraic Data Type */
type coolString = 
  | Uppercase(string)
  | Concat(string, string)
  | Empty;

/* pattern matching */
let string_of_cool_string = fun
  | Uppercase(str) => String.uppercase_ascii(str)
  | Concat(str1, str2) => str1 ++ str2
  | Empty => ""

You can think of ADT as enum with additional data/payload and pattern matching as switch by the payloadfull enums.

Naive TypeScript implementation would be:

type UpperCase = {
  key: 'UPPERCASE',
  value: string,
}

type Concat = {
  key: 'CONCAT',
  value: [string, string],
}

type Empty = {
  key: 'EMPTY',
}

const makeUpperCase = (value: string): UpperCase => ({
  key: 'UPPERCASE',
  value,
});

const makeConcat = (value: [string, string]): Concat => ({
  key: 'CONCAT',
  value,
});

const makeEmpty = (value: string): Empty => ({
  key: 'EMPTY',
});

type CoolString = UpperCase | Concat | Empty;

const match = (action: CoolString): string => {
  switch (action.key) {
    case 'UPPERCASE':
      return action.value.toUpperCase();
    case 'CONCAT':
      return action.value.join('');
    case 'EMPTY':
      return '';
  }
}

As you can see, the TypeScript version is very verbose. The goal of this article is to present one of the possible solutions for lowering the number of lines of code while keeping everything simple and having all static type features.

First, we will write simple type that will represent ADT option and function to create options

type Option<Key extends string, Value = undefined> = {
  key: Key,
  value: Value,
};

const makeOption = <Key extends string, Value = undefined>(
  key: Key,
) => (
  value: Value,
): Option<Key, Value> => ({
  key,
  value,
});

Having code above usage will be:

const Upper = makeOption<'upper', string>('upper')
const Concat = makeOption<'concat', [string, string]>('concat');
const Empty = makeOption<'empty'>('empty');

type CoolString
  = ReturnType<typeof Upper>
  | ReturnType<typeof Concat>
  | ReturnType<typeof Empty>

const match = (coolString: CoolString): string => {
  switch (coolString.key) {
    case 'upper':
      return coolString.value.toUpperCase();
    case 'concat':
      return coolString.value.join('');
    case 'empty':
      return '';
  }
}

This way we have extracted boilerplate, so ADT pattern became much cleaner.

Making Vanilly App

Mike Skoe — Mon, 05 Aug 2019 15:52:28 +0000

It is great to be able to make app using Reaction, View, Angler. But it is cooler better if you can do even a small app with pure JS.

Today I will show you the way I did my vanilla app.

...

I call it "property-oriented pub-sub pattern". But before I will explain the idea, let's look at some essentials.

Every app has three fundamental parts: State, Actions and Presentation layer.
State is an object with all changeable information. Usually, every app has one global state and optionally little states for small parts of an app.
Actions are functions, that change state. Usually triggered on some button press or on any other update.
Presentation layer or "view", is a way to beautifully present the state to users.

React+Redux cycle looks like this:

trigger update of a state by pressing button (for example).
basing on the new state we make new VDOM (JS-object as a representation of a future DOM).
new VDOM compares with old one.
basing on parts that was really changed, React updates only needed DOM elements.

propertyorientedpubsubpattern has much simpler flow. Action change a state and list all changed properties. Basing on changed state keys subscribed functions are triggered.

To make everything clear, let's first learn how to use it, then we will make it.

For example, we have a state "Character".

const initialState = {
   name: 'Jake',
   age: 32,
   about: 'hi, im jake, yo',
}

We put it into some 'init' function, that gives us 'pub' and 'sub', to deal with.

const {pub, sub} = init(initialState);

Then we make several components.

const c = document.createElement.bind(document); // alias for createElement
const q = document.querySelector.bind(document); // alias for querySelector
const Name = c('div');
const Age = c('div');
const MakeOlder = c('button');
MakeOlder.innerText = 'Make a person older!';
const App = c('div');
App.append(Name, Age, MakeOlder);

then use those pub-sub stuffs.

sub(
   ['age'],
   age => Age.innerText = `age: ${age}`,
);
sub(
   ['name'],
   name => Name.innerText = `name: ${name}`,
);
const OLDER = pub(
   ['age'],
   state => ({...state, age: state.age + 1}),
);

MakeOlder.onclick = OLDER;

Now we have a little counter, masked as an account app.
As you can see, we explicitly list all properties public and subscribe to. When certain properties are updated, certain functions are triggered. Easy-Peasy.

So let's build this 'init' peace of function.

const init = state => { // 1.
   const callbacks = {}; // 2.
   return {
      sub: (keys, fn) => { // 3.
         fn.args = keys; // 4.
         keys.forEach(key => {
            callback[key] = callback[key] || []; // 5.
            callbacks[key].push(fn);
         };
         fn(...fn.args.map(arg => state[arg])); // 6.
      },
      pub: (keys, update) => () => {
         initialState = update(initialState); // 7.
         keys.forEach(key => { // 8.
            (callback[key] || []).forEach(cb => { // 9.
               cb(...(cb.args || []).map(arg => state[arg]) // 10.
            });
         });
      }
   }
}

Now let me explain everything line by line.

state is kept in the closure.
'callbacks' is an object, that holds all subscribed functions. Key is state property string, value - function, that depends on that key.
'sub' takes keys of state, as you already know, and a function to trigger.
when function is subscribed on several keys, the function is listed in different arrays on several keys of 'callbacks' object. To save all keys associated with a function, we put them in 'args' property, cuz' functions are objects in JS.
if callbacks objects already has that key = we do nothing, otherwise we create empty array.
immediately call with arguments taken as keys from the state.
append the function to callbacks object.
we update the state by reassigning 'initialState' from closure.
for safety, if the are no array on that key, we use empty array(to do nothing).
same as at line (6.), trigger needed functions.

This code has list of defects, because i whated to make it as easy as possible, but it is already usable tool to make small apps!

If you what to play with this, here is codesandbox example:

Everything is great, but:

some functions are can be called twice
creating and updating elements via 'document' object directly is not cool
we have no way to unsubscribe functions
nature cataclysms are still happening

In the next episode we will fix some of those problems, so until next time!

lib: repo;
app: repo
gh-pages version