DEV Community: Patryk Andrzejewski

Better types in TypeScript with type guards and mapping types

Patryk Andrzejewski — Wed, 23 Mar 2022 12:23:17 +0000

TypeScript gains more and more popularity among the Javascript developers, becoming even a stardard when it comes to nowadays software development and replacing to some extent Javascript itself.

Desipte the main goal of this language is to provide type-safety programing in to the chaotic Javascript, many people use it just because that’s the trend. In that case the only feature they use is revealing the types of given values, and if they can’t type something, an any is being used instantly.

Well… TypeScript is so much more. It provides many features, so let’s focus on the ones that will help you with type organizing as well as bringing more security to your code.

A brief story of any

If you used TypeScript, it’s likely that you have been using any so much. This type is quite uncertain one and can mean... everything.. literally everything.

When you type something by any is same as you would say “I don’t care about what the type is here”, so you essentially ignore the typing here as if you were use plain Javascript.

For that reason any should not (almost) never been used, because you ignore the typing, the thing that TypeScript was actually built for!

You may raise a question “ok, but what if I totally don’t know what the type is?!”. Yeah, in some cases you really don’t know it, and for that is better to use unknow over the any.

The unknow type is very similar to any - also match to everything, except one thing - is type-safe. Considering an example:

let x: unknown = 5;
let y: any = 5;

// Type 'unknown' is not assignable to type 'string'.
let x1: string = x;

// fine.
let y1: string = y;

As you can see, when you use unknown in the context of string, the TypeScript doesn’t allow me to do this, because they are different types, while with any I can do whatever I want.

That’s why any is very insecure. Using any makes your code prone to even crash as you are using one data in the context of different.

Does it mean I can’t use any? No, any has its own purpose, I will show you later. In terms of typing function arguments, return values, type aliases etc. - stay with unknown.

Protection with type guards

This is really important feature of TypeScript. It allows you to check types in your code to assure that your data-flow relies on the correct data types. Many people use it, without even knowing that it’s named “type guards”. Let’s go with examples.

function product(x: number) {}
function discount(x: string) {}

function cart(x: string | number) {
 // Argument of type 'string | number' is not assignable to parameter of type 'number'.
 product(x);
 // Argument of type 'string | number' is not assignable to parameter of type 'number'.
 discount(x);
}

What’s happening here? We have function cart that takes one argument which can be either string or number. Then we call two functions, each requires also one argument, first (product) number second (discount) string. For both functions, the argument from cart has been used - why does TypeScript raise an error?

Well, TypeScript basically has no clue what you want to do. We are giving string or number then use it in a different contexts - once just number then just string. What if you pass string to the function product? Is that correct? Obviously not - it requires a different type. The same with function discount. That’s the issue here.

We must sift somehow possible types, to make sure, we have the right one in the given context. This is the goal of type guards - we make protection in given line against passing incorrect types.

typeof checking

In this particular case, a typeof guard is completely enough:

function cart(x: string | number) {
 if (typeof x === 'number') {
  product(x);
 }
 if (typeof x === 'string') {
  discount(x);
 }
}

Now, everything receives the correct types. Worth notice, if we put return statement inside of first “if” then second if is no longer needed! TypeScript will catch the only one possibility is there.

The object complexity

How about more complex types? What if we have something more sophisticated than primitives?

type Product = {
 qty: number;
 price: number;
}

type Discount = {
  amount: number;
}

function product(x: Product) {}
function discount(x: Discount) {}

function cart(x: Product | Discount) {
 // Argument of type 'Product | Discount' is not assignable to parameter of type 'Product'.
 product(x);
 // Argument of type 'Product | Discount' is not assignable to parameter of type 'Product'.
 discount(x);
}

We have here the same scenario as in the previous example, but this time we have used more complex types. How to narrow down them?

To distinguish "which is which" we can use in operator and check whether the certain fields are present in the object.

For instance, our Product has price while the Discount has amount - we can use it as differentiator.

function cart(x: Product | Discount) {
 if ('price' in x) {
  product(x);
 }

 if ('amount' in x) {
  discount(x);
 }
}

Now, again TypeScript is satisfied, however, is that clean enough?

Customized type guards

A previous solution may solve the problem and works pretty well… as long as you not emerge more complex types - having sophisticated in clause won’t be so meaningful - so what can we do?

TypeScript provides a is operator that allows you to implement special kind of function you can use as type guard.

function isProduct(x: Product | Discount): x is Product {
 return 'price' in x;
}

function isDiscount(x: Product | Discount): x is Discount {
 return 'amount' in x;
}

function cart(x: Product | Discount) {
 if (isProduct(x)) {
  product(x);
 }

 if (isDiscount(x)) {
  discount(x);
 }
}

Look at the example above. We could create a checker-functions that bring capability to confirm the input type is what we expect.

We use statement of is to define, a function which returns boolean value that holds the information if the given argument acts as our type or not.

By using customised type-guards, we can also test them separately and our code becomes more clear and readable.

The configuration is tough…

Agree. The configuration of TypeScript is also quite complex. The amount of available options in a tsconfig.json is overwhelming.

However there are bunch of them that commits to the good practices and quality of the produced code:

*strict *- strict mode, I would say that’s supposed to be oblibatory always, it forces to type everything
*noImplicitAny *- by default, if there is no value specified, the any type is assigned, This option forces you to type those places and not leave any (eg. function arguments)
*strictNullChecks *- the null and undefined are different values, you should keep that in mind, so this option strictly checks this
*strictFunctionTypes *- more accurate type checking when it comes to function typings

Obviously there are more, but I think those ones are the most important in terms of type-checking.

More types? Too complex.

Once you project grow, you can reach vast amount of types. Essentially, there is nothing bad with that, except cases when one type was created as copy of the other one just because you needed small changes.

type User = {
 username: string;
 password: string;
}

// the same type but with readonly params
type ReadOnlyUser = {
 readonly username: string;
 readonly password: string;
}

Those cases break the DRY policy as you are repeating the code you have created. So is there any different way? Yes - mapping types.

The mapping types are build for creating new types from the existing ones. They are like regular functions where you take the input argument and produce a value, but in the declarative way: a function is generic type and its param is a function param. Everything that you assign to that type is a value:

type User = {
 username: string;
 password: string;
}

// T is an "argument" here
type ReadOnly<T> = {
 readonly [K in keyof T]: T[K]
}
type ReadOnlyUser = ReadOnly<User>

In the example above, we created a mapping type ReadOnly that takes any type as argument and produces the same type, but each property becomes readonly. In the standard library of TypeScript we can find utilities which are built in exactly that way - using mapping types.

In order to better understand the mapping types, we need to define operations that you can do on types.

keyof

When you use a keyof it actually means “give me a union of types of the object key’s”. For more detailed information i refer to the official documentation, but for the matter of mapping types when we call:

[K in keyof T]

We access the “keys” in the object T, where each key stays under the parameter K - Sort of iteration, but in the declarative way as K keeps the (union) type of keys, not a single value.

As next, knowing that K has types of each parameter in a given object, accessing it by T[K] seems to be correct as we access the “value” that lives under the given key, where this key also comes from the same object. Connecting those statements together:

[K in keyof T]: T[K]

We can define it: “go over the parameters of the given object T, access and return the value that type T holds under given key”. Now we can do anything we want with it - add readonly, remove readonly, add optional, remove optional and more.

The “if” statements

Let’s assume other example:

type Product = {
 name: string;
 price: number;
 version: number; // make string
 versionType: number; // make string
 qty: number;
}

// ???
type VersioningString<T> = T;
type X = VersioningString<Product>

We have type Product and we want to create another type that will change some properties to string, let's say the ones related to version: version and versionType.

We know how to “iterate” but we don’t know how to “make a if”.

type VersioningString<T> = {
 [K in keyof T]: K extends "version" | "versionType" ? string : T[K]
};

We can put the “if” statements in that way by using extend keyword. Since that’s declarative programming, we operate on the types we are checking if our K type extends… the union type of “version” and “versionType” - makes sense? In this meaning we check the inheritance of given type, just like among the classes in oriented programming.

Type inferencing

TypeScript always tries to reveal the types automatically and we can access it and take advantage of revealed type.

It’s quite handy when when it comes to matching something by extend keyword and obtain the inferenced type at the same time.


type ReturnValue<X> = X extends (...args: any) => infer X ? X : never;

type X1 = ReturnValue<(a: number, b: string) => string> // string

This is classical example of obtaining the return type of given function. As you can see, by using extend we can check whether input arg (generic) is a function by its signature, but in that signature we also use infer keyword to obtain of what return type is, then save it under the X field.

Connecting all of pieces together - A real world scenario

Using those mechanics, let’s now break down the following type:

type CartModel = {
 priceTotal: number;
 addToCart: (id: number) => void
 removeFromCart: (id: number) => void
 version: number;
 versionType: number;
}

Our goal is to create a new type that, skips fields related to versioning and adds quantity argument to both addToCart and removeFromCart methods. How?

Since there is no simple declarative operations of skipping fields, we need to implement it in the other way. We know that it's feasible to create a new type from existing one by going over the fields of it, however we exactly want to limit those fields.

type SingleCart <T> = {
  // keyof T ??
  [K in keyof T]: T[K]
}

// prints all fields as normal
type Result = SingleCart<CartModel>

// goal:
type SingleCart <T> = {
  [K in <LIMITED VERSION OF FIELDS OF T>]: T[K]
}

How can we achieve that? Normally to access all of the fields we use keyof T but we our goal is to limit te list of possible keys of T.

Since the keyof T gives us a union of the fields, we can limit this by using extend keyword:

// access all of the fields
type R1 = keyof CartModel

type SkipVersioning <T> = T extends "version" | "versionType" ? never : T

// gives union of "priceTotal" | "addToCart" | "removeFromCart"
type R2 = SkipVersioning<keyof CartModel>

So now we can use that type:

type SkipVersioning <T> = T extends "version" | "versionType" ? never : T

type SingleCart <T> = {
  [K in SkipVersioning<keyof T>]: T[K]
}

/*
it gives a type: 
type ResultType = {
   priceTotal: number;
   addToCart: (id: number) => void;
   removeFromCart: (id: number) => void;
}
*/
type Result = SingleCart<CartModel>

We have just removed fields related to the version!

The next part is adding a quantity argument to functions in the type. As we already have access to the type of given field (T[K]), we need to introduce another one for transforming if given type is function:

type AddQuantityToFn<T> = ... // ??

type SingleCart <T> = {
  [K in SkipVersioning<keyof T>]: AddQuantityToFn<T[K]>
}

The T[K] is being wrapped by a new type AddQuantityToFn. This type needs to check whether given type is a function and if that's true, add to this function a new argument quantity if not, don't do anything. The implementation may look as follows:

type AddQuantityToFn <T> = T extends (...args: infer A) => void ?
  (quantity: number, ...args: A) => void
  :
    T

If the type is a function (extends (...args: infer A) => void), add a new argument quantity: number (returns a type of (quantity: number, ...args: A) => void) if not, keep the old type T. Please notice we are using also type inferencing (infer A) to grab the old argument's types.

Below, full implementation of it:

// Skips properties by given union
type SkipVersioning <T> = T extends "version" | "versionType" ? never : T

// Adds new argument to the function
type AddQuantityToFn <T> = T extends (...args: infer A) => void ?
 (quantity: number, ...args: A) => void
 : T

// Goes over the keys (without versioning ones) and adds arguments of quantity if that's method.
type SingleCart <T> = {
 [K in SkipVersioning<keyof T>]: AddQuantityToFn<T[K]>
}

type ResultType = SingleCart<CartModel>

Quick summary: First of, we have defined a type that generates for us a union of property names besides ones related to versioning. Secondly, type for creating a new argument - if the type if function - if not, return given type. Lastly, our final type that goes over the keys (filtered) of an object, and adds arguments to the method (if needed).

Recap

TypeScript might be difficult and helpful at the same time. The most important thing is to start using types in a wise way with an understanding of how they work and with a right configuration that will lead you to produce properly typed code.

If that's something overwhelming for newcomers, would be nice to introduce it gradually and carefully and in each iteration provide better and better typings as well as type guarding of your conditional statements.

Using command pattern with vue composition-API

Patryk Andrzejewski — Wed, 05 Aug 2020 16:59:08 +0000

"Design patterns" is one of the topics that everyone has heard about, but usually, no one uses it. Sometimes it's just better to take a step back and think twice about the problems we come across in our software development adventure - it's likely that someone faced it before we did, and solved it before we did.

I've been considering a command pattern recently and it's a certainly powerful concept. It let you encapsulate the action logic and all corresponding information to perform or undo it.

The overall idea is to implement actions as separate objects (commands) that can be invoked by a sort of manager (invoker).

Imagine a cart object. The cart has functions to operate on it, such as addToCart, removeFromCart, applyDiscunt, cleanCart, and so on. Each time you want to add a new operation, you have to modify the original object of the cart (adding a new function).

Using a command pattern the cart object becomes an invoker and it has only one function that triggers given commands. When you want to add a new operation, create a new command, you don't have to touch the cart at all.

Let's jump to the Vue world and try to define cart as a composition API - useCart

Using command pattern

The essential unit of this approach is a command. It must implement two functions, the first one to invoke action and the second one to undo it. We can define this as a pure function that just returns the mentioned requirements:

const AddToCart = product => ({
  invoke: cart => ({
    ...cart,
    products: [...cart.products, product],
    totalPrice: cart.totalPrice + product.price
  }),
  undo: cart => ({
    ...cart,
    products: cart.products.filter(p => p.id != product.id),
    totalPrice: cart.totalPrice - product.price
  })
});

As the argument of this action, we take a product that we want to add to a cart. Secondly, we are returning the following functions:

invoke - which performs some action on the given state and returns the new one. In this case, it just adds a product to the cart and updates the total price.
undo - which allows us to move backward, it is undoing an action that we executed.

Once we have defined our first command, let's move to the invoker. Apparently, our invoker is useCart function and its implementation may look like this:

const useCart = () => {
  const history = [];
  const cart = ref({
    products: [],
    discount: null,
    totalPrice: 0
  });

  const invoke = command => {
    cart.value = command.invoke(cart.value);
    history.push(command);
  };

  const undo = () => {
    cart.value = history.pop().undo(cart.value);
  };

  return { invoke, undo, cart };
};

Considering that example, useCart has to implement just two functions (to modify the state) even if we have many operations related to the cart.

const { invoke, undo, cart } = useCart();

invoke(AddToCart({ id: 1, name: "Beer", price: 4 }));
// Beer in cart, total price is 4

invoke(AddToCart({ id: 2, name: "Pizza", price: 10 }));
// Beer and Pizza in cart, total price is 14

undo();
// Beer in cart, total price is 4

That leads to the following conclusion:

useCart keeps only the state and share it along with invoke and undo functions
implementing a new feature comes with creating a new command, nothing else (we don't have to update useCart itself)
it's super testable - each command has dedicated unit test, arguments are easy to mock
we can track the history of changes and we can move backward

Summary

It might look amazing for first sight how simple we can implement new functionality in the system, but it raises a question whether should we use that everywhere? - of course not, it totally depends on the problem, so when should we use it then?

The command pattern is pretty useful when it's likely that part of the system will be extended in the future or we want to leave the ability to implement any action for the developer. Additionally, because of having a history - we can use that pattern if there is a need to undo some actions (eg. text editors).

However, if a given feature is pretty simple, it has a fixed set of actions/operations, using a command pattern could be overhead.

Original source: https://andrzejewsky.com/using-command-pattern-with-vue-composition-api/

How to get rid of unnecessary props in React.js

Patryk Andrzejewski — Sat, 16 May 2020 19:25:00 +0000

Many times when you write something in React, you have to face an eternal problem - passing props down, sometimes over the long components tree, just to cover one certain case. I think you are familiar with that, and... bad news for you - in most of these cases it means there is something wrong with an app architecture, but let's see how to solve it.

Example

Let's look at the following example:

import React, { useState } from "react";

const Todo = ({ text, onDelete }) => <div>
  <div>{text}</div>
  <button onClick={() => onDelete(text)}>X</button>
</div>;

const TodoStats = ({ items }) => {
  const totalCount = items.length;

  if (!totalCount) return null;

  return <div>Total items: {totalCount}</div>;
};

const TodoList = ({ items, onDelete }) => (
  <div>
    {items.map(item => (
      <Todo text={item} key={item} onDelete={onDelete} />
    ))}
  </div>
);


const TodoHeader = ({ items, onAddClick }) => {
  const [text, setText] = useState("");

  const handleTodoAdd = () => {
    onAddClick(text);
    setText("");
  };

  return (
    <div>
      <TodoStats items={items} />
      <input
        type="text"
        value={text}
        onChange={evt => setText(evt.target.value)}
      />
      <button onClick={handleTodoAdd}>ADD</button>
    </div>
  );
};

const TodoListApp = () => {
  const [todos, setTodos] = useState([]);

  const addTodo = todo => {
    setTodos([...todos, todo]);
  };

  const handleDelete = todo => {
    setTodos(todos.filter(t => t !== todo));
  };

  return (
    <div>
      <TodoHeader onAddClick={addTodo} items={todos} />
      <TodoList items={todos} onDelete={handleDelete} />
    </div>
  );
};

const App = () => {
  return (
    <div className="App">
      <TodoListApp />
    </div>
  );
};

export default App;

That's the basic implementation of the todo list app. Let's think about it as some feature in the whole application that can have its own state, components, or even styles.

Now, what's wrong with this piece of code? Well... in some places, we don't use the props but we have to pass it just because of children's components need them. For instance:

TodoHeader requires items only for TodoStats
TodoList requires onDelete only for Todo

So what we can do with this? Share mandatory state and functions across the entire app/feature.

Sharing state with the context API

If you need to share something between components, context API is really the best way to achieve it. So how our code was changed? Please look below:

import React, { useState, useContext } from "react";

const TodoContext = React.createContext();

const Todo = ({ text, onDelete }) => <div>
  <div>{text}</div>
  <button onClick={() => onDelete(text)}>X</button>
</div>;

const TodoStats = () => {
  const context = useContext(TodoContext);
  const totalCount = context.todos.length;

  if (!totalCount) return null;

  return <div>Total items: {totalCount}</div>;
};

const TodoList = () => {
  const context = useContext(TodoContext);

  return (
    <div>
      {context.todos.map(item => (
        <Todo text={item} key={item} onDelete={context.handleDelete} />
      ))}
    </div>
  );
  }


const TodoHeader = () => {
  const context = useContext(TodoContext);
  const [text, setText] = useState("");

  const handleTodoAdd = () => {
    context.addTodo(text);
    setText("");
  };

  return (
    <div>
      <TodoStats />
      <input
        type="text"
        value={text}
        onChange={evt => setText(evt.target.value)}
      />
      <button onClick={handleTodoAdd}>ADD</button>
    </div>
  );
};

const TodoListApp = () => {
  const [todos, setTodos] = useState([]);

  const addTodo = todo => {
    setTodos([...todos, todo]);
  };

  const handleDelete = todo => {
    setTodos(todos.filter(t => t !== todo));
  };

  const contextValue = {
    todos,
    addTodo,
    handleDelete
  };

  return (
    <div>
      <TodoContext.Provider value={contextValue}>
        <TodoHeader />
        <TodoList />
      </TodoContext.Provider>
    </div>
  );
};

const App = () => {
  return (
    <div className="App">
      <TodoListApp />
    </div>
  );
};

export default App;

Have you spotted a difference? Now, most of the components are independent - they don't have props as they read the state from a shared context. The only props they could have needed are UI-related ones rather than state-related.

But there is one more thing. In the component TodoListApp we have two responsibilities. The first one is displaying the data based on state, and the second one is state management (operations using setState). It's not that bad, however we are able to refactor it and achieve better code separation with one responsibility.

State management with useReducer

Do you remember redux? It does one important thing - manages the state in the whole app, so the components can focus only on reading it and notice some changes by dispatching an action. Nowadays, using useReducer we can implement something like local-based redux, focussed only on our feature. Let's introduce it:

import React, { useState, useContext, useReducer } from "react";

const TodoContext = React.createContext();
const initialState = [];

const todoReducer = (state, action) => {

  switch (action.type) {
    case 'ADD_TODO':
      return [...state, action.todo];
    case 'DELETE_TODO':
      return state.filter(t => t !== action.todo);
    default:
      return state;
  }
}

const Todo = ({ text, onDelete }) => <div>
  <div>{text}</div>
  <button onClick={() => onDelete(text)}>X</button>
</div>;

const TodoStats = () => {
  const context = useContext(TodoContext);
  const totalCount = context.todos.length;

  if (!totalCount) return null;

  return <div>Total items: {totalCount}</div>;
};

const TodoList = () => {
  const context = useContext(TodoContext);

  return (
    <div>
      {context.todos.map(item => (
        <Todo
          text={item}
          key={item}
          onDelete={todo => context.dispatch({ type: 'DELETE_TODO', todo })}
        />
      ))}
    </div>
  );
  }


const TodoHeader = () => {
  const context = useContext(TodoContext);
  const [text, setText] = useState("");

  const handleTodoAdd = () => {
    context.dispatch({ type: 'ADD_TODO', todo: text });
    setText("");
  };

  return (
    <div>
      <TodoStats />
      <input
        type="text"
        value={text}
        onChange={evt => setText(evt.target.value)}
      />
      <button onClick={handleTodoAdd}>ADD</button>
    </div>
  );
};

const TodoListApp = () => {
  const [todos, dispatch] = useReducer(todoReducer, initialState);

  const contextValue = { todos, dispatch };

  return (
    <div>
      <TodoContext.Provider value={contextValue}>
        <TodoHeader />
        <TodoList />
      </TodoContext.Provider>
    </div>
  );
};

const App = () => {
  return (
    <div className="App">
      <TodoListApp />
    </div>
  );
};

export default App;

What we did actually? We separated the state management layer from the UI layer. It may look like more code, but please think about it in the context of testing or logic separation. Using this approach, you are able to test state-related logic independently from components, while in the previous version of TodoListApp you had to do it simultaneously (test adding and removing todos along with rendering stuff).

When to use useContext and useReducer?

It depends. Everything is always related to the feature you want to implement. If you want to share something across the code - contexts are the best choice, but if your code is really easy, passing one prop down would be more reasonable. What about reducers? If your state is really complicated it's nice to separate it - that will be easier to maintain in the future as you can see exactly what is the state-flow, otherwise when your app has just one or two fields to obtain, keep that in the component.

Thanks for reading!

Reference to my blog: https://andrzejewsky.com/how-to-get-rid-of-unnecessary-props-in-react

Vue 3 reactivity in depth

Patryk Andrzejewski — Tue, 28 Apr 2020 19:55:23 +0000

As Vue 3 is introducing composition API and its own reactivity system, I was curious how it works underneath. I spent some time researching it and analyzing its implementation and I think I understood how it works. Of course today there are tons of explanations, but I decided to go over this on my own, and here I'm sharing what I found.

In this article I used simple arrays and objects instead of Map or Set just for simplicity and for paying more attention to the topic rather than javascript API

What is new in Vue 3?

Let's consider the following piece of code using plain javascript:

const person = { firstName: "John", lastName: "Doe" };
const fullName = `${person.firstName} ${person.lastName}`;
person.firstName = "David";

console.log(`You are logged as: ${fullName}`); // You are logged as: John Doe

Obviously, you can see John Doe in the console even though you have changed the firstName to David - it's because that evaluation is imperative which means the execution goes line by line. Firstly you create a person object, secondly fullName and assigning new firstName at the end.

Now please look at the similar code using Vue 3 reactivity system:

const person = reactive({ firstName: "John", lastName: "Doe" });  // reactive field
const fullName = computed(() => `${person.firstName} ${person.lastName}`); // effect
person.firstName = "David";

console.log(`You are logged as: ${fullName}`); // You are logged as: David Doe

We can notice a different result. In our console David Doe has been displayed. What sort of magic really happened there? Well... we defined a reactive property using reactive function, secondly, with computed we created an effect that will combine two fields of person object: firstName and lastName into one string. Whenever used properties change, the effect will be fired, hence fullName receives a new value.

What's inside of reactive function that adds such super abilities to the object? There is a sort of tracking system that reacts to the changes by calling linked effects. Whenever you access some property (eg. person.firstName call), it begins to be tracked and if you modify it (person.firstName = "David") - the assigned effect (computed) is being triggered. That's the basic idea. Let's try to implement it then!

Detecting access to the object

First of all, we need to somehow detect what properties we access in the object. To do this we can use Proxy:

const reactive = obj =>
  new Proxy(obj, {
    get(target, key, receiver) {
      const res = Reflect.get(target, key, receiver);
      console.log("get", key);
      return res;
    },
    set(target, key, value, receiver) {
      const res = Reflect.set(target, key, value, receiver);
      console.log("set", key);
      return res;
    }
  });

const person = reactive({ firstName: "John", lastName: "Doe" });
person.firstName = "David"; // displays 'set firstName David'
console.log(person.firstName); // displays 'get firstName David' and 'David'

The first argument of a Proxy constructor is an object that we want to use and the second one is a handler, that gives as a possibility to react whenever we change a property (set method) of an object or we access it (get method).

Traceability of fields and the effect

Here the all fun comes. We know how to inject into the setting and getting process, but how to use that? Let's think about it for a while. Based on my previous explanation we can think of two facts:

each time you set a property it causes an effect (callEffects())
each time you access the property you should save its effects (track()) and trigger it in the future

const reactive = obj =>
  new Proxy(obj, {
    get(target, key, receiver) {
      const res = Reflect.get(target, key, receiver);
      track();
      return res;
    },
    set(target, key, value, receiver) {
      const res = Reflect.set(target, key, value, receiver);
      callEffects();
      return res;
    }
  });

Ok let's focus on track and callEffects. I mentioned that track should save effects and callEffects triggers them all once some property in the object was set.

const effects = []; // effects collection

const track = () => {
  effects.push(effect); // we save effect for latter
};

const callEffects = () => {
  effects.forEach(effect => effect()); // change detected, fire all related effects
};

And of course we have to define our effect:

let fullName = "";

const effect = () => {
  fullName = `${person.firstName} ${person.lastName}`;
};

effect();

Full code:

const effects = [];

const track = () => {
  effects.push(effect);
};

const callEffects = () => {
  effects.forEach(effect => effect());
};

const reactive = obj =>
  new Proxy(obj, {
    get(target, key, receiver) {
      const res = Reflect.get(target, key, receiver);
      track();
      return res;
    },
    set(target, key, value, receiver) {
      const res = Reflect.set(target, key, value, receiver);
      callEffects();
      return res;
    }
  });

const person = reactive({ firstName: "John", lastName: "Doe" });
let fullName = "";

const effect = () => {
  fullName = `${person.firstName} ${person.lastName}`;
};

effect();

console.log(`You are logged as: ${fullName}`); // You are logged as: John Doe
person.firstName = "David";
console.log(`You are logged as: ${fullName}`); // You are logged as: David Doe

As you can see, the result is more similar to the Vue-based one, but keep reading, there is more work to do!

Introduce current effect

Our basic reactivity works pretty well. But we have to call our effect manually in the beginning and also track function adds that effect multiple times. Let's improve!

I defined currentEffect to store the current effect that should be added to the collection, but only when it's assigned, otherwise, there is no sense to call effects.push - that would add the same effect again. Furthermore, there is effect function that assigns given effect as a current one, and fires effect immediately (that was our initial call we had to call manually, remember?).

let currentEffect = null;

const effects = [];

const track = () => {
  if (!currentEffect) return;
  effects.push(currentEffect);
};

const callEffects = () => {
  effects.forEach(effect => effect());
};

const effect = fn => {
  currentEffect = fn;
  currentEffect();
  currentEffect = null;
};

// ...

let fullName = "";

effect(() => {
  fullName = `${person.firstName} ${person.lastName}`;
});

console.log(`You are logged as: ${fullName}`); //  You are logged as: John Doe
person.firstName = "David";
console.log(`You are logged as: ${fullName}`); // You are logged as: David Doe

Property dependencies

We are able to track properties but we have no clue which ones. As a result of that, our track function will store effects for every single property access, although the effect depends only on certain ones.

let fullName = "";
let welcome = "";

effect(() => {
  fullName = `${person.firstName} ${person.lastName}`; // dependencies: firstName and lastName
});

effect(() => {
  welcome = `Mr. ${person.lastName}`; // this depends only on lastName!
});

How to solve that? Use a map of effects where the keys are tracked field names and values are related effects.

let currentEffect = null;
const deps = {}; // map of properties and their effects
const track = key => {
  if (!currentEffect) return

  if (!deps[key]) { // if property doesn't have collection, create it
    deps[key] = [];
  }

  deps[key].push(currentEffect); // add effect
};

const callEffects = key => {
  if (!deps[key]) return;

  deps[key].forEach(effect => effect());
};

// ...

Close object reactivity

Unfortunately, there is still a problem that needs to be solved. What if we define two reactive variables? Look at example below:

const person1 = reactive({ firstName: "John", lastName: "Doe" });
const person2 = reactive({ firstName: "David", lastName: "Doe" });

let fullName1 = "";
let fullName2 = "";

effect(() => {
  console.log("trigger 1");
  fullName1 = `${person1.firstName} ${person1.lastName}`;
});

effect(() => {
  console.log("trigger 2");
  fullName2 = `${person2.firstName} ${person2.lastName}`;
});

person1.firstName = "David"; // 'trigger 1' and 'trigger 2' in the console!

I changed the firstName for person1 but both effects were triggered! It's not an expected result, we suppose to call effects that are related to its object, let's do it.

Actually we need to do something very similar to the previous step but for the target object. We've been storing a map of properties and their effects, now we have to go a level below and start storing a target object, its properties, and all related effects in each property.

// ...
const deps = new WeakMap();
const track = (target, key) => {
  if (!currentEffect) return;

  let objMap = deps.get(target);

  if (!objMap) { // if there is no such a target, create it
    objMap = {}; // define map of properties and their effect collections
    deps.set(target, objMap); // set it
  }

  let dep = objMap[key];

  if (!dep) { // if there is no given property in that target, create it
    dep = []; // create effects collection
    objMap[key] = dep; // set it
  }

  dep.push(currentEffect); // add effect
};

const callEffects = (target, key) => {
  let objMap = deps.get(target);

  if (!objMap) return;

  const dep = objMap[key];

  if (!dep) return;

  dep.forEach(effect => effect());
};

//...

I used here a WeekMap which gives a possibility to store something under the given object as a key.

That's it! We achieved quite similar implementation to the one prepared by Vue team. Original Vue source code references:

Summary

The original implementation is undoubtedly more complicated and we haven't covered other features and edge cases, but I wanted to show only the general idea behind it.

Thanks for reading!