DEV Community: Andrea Simone Costa

Cloning JavaScript objects using graph theory

Andrea Simone Costa — Sat, 01 May 2021 08:55:10 +0000

Introduction

The JavaScript slang allows us to clone objects in more than one way. We can perform a shallow clone using Object.assign or the spread syntax and a deep clone thanks to the JSON.parse(JSON.stringify()) trick.
Unfortunately, the last solution suffers from a problem: JSON.stringify cannot work on an object that has circular references, erroring out in such a case.

In this episode we'll learn a bit of graph theory to then use this knowledge to build a simple, but efficient, deep cloner.

Link to the full article 😄

Do Vue 3 refs admit a monad instance?

Andrea Simone Costa — Thu, 30 Jul 2020 13:48:44 +0000

Hi, nice to meet you 😄!
You can find this article in my personal blog here.

JavaScript Iterators and Generators: Asynchronous Generators

Andrea Simone Costa — Sun, 15 Sep 2019 07:54:13 +0000

Hi, nice to meet you 😄!
You can find this article in my personal blog here.

JavaScript Iterators and Generators: Asynchronous Iterators

Andrea Simone Costa — Sun, 08 Sep 2019 07:12:02 +0000

Hi, nice to meet you 😄!
You can find this article in my personal blog here.

JavaScript Iterators and Generators: Synchronous Generators

Andrea Simone Costa — Sun, 01 Sep 2019 06:56:50 +0000

Hi, nice to meet you 😄!
You can find this article in my personal blog here.

JavaScript Iterators and Generators: Synchronous Iterators

Andrea Simone Costa — Sun, 25 Aug 2019 16:22:42 +0000

Hi, nice to meet you 😄!
You can find this article in my personal blog here.

How to resume the flow inside a failed try block computation without algebraic effects

Andrea Simone Costa — Mon, 05 Aug 2019 17:58:59 +0000

Introduction

After reading the wonderful Dan's article about algebraic effects, one question, maybe the wrong one, stuck in my head: how far we can go trying to recover a failed try block computation?

Due to their nature, I believe the answer is inextricably linked to generators. They are an exotic function type that can be paused and resumed as many times we need, without losing the previous steps' results. This is the main point because of the stack unwinding that follows the rise of an exception.
Obviously, if an unhandled exception rises, I don't know any JS magic that could help us. But thanks to a nice trick that I'm going to explain soon, we have at least the possibility to try again the failed computation and, if it is the case, replace its value with a fallback one.

Before starting, let me stress the fact that the final result won't be powerful as would be the use of algebraic effects if they were present in the language.

Promises + generators

Let's talk about tj/co:

co(function* () {
  var result = yield Promise.resolve(true);
  return result;
})
.then(console.log); // print 'true'

The main idea behind the function co was to execute a generator that yields out Promises. When a generator yields out something, it pauses.
The co function takes care of each yielded Promise, resolving it, and inserting back into the generator its result. So the generator will be able to continue its flow with the future value that was previously contained into the Promise.

I'm sure that nowadays you don't write such type of code anymore, preferring the async/await syntax:

;(async function () {
  let result = await Promise.resolve(true);
  return result;
})()
.then(console.log); // print 'true'

Because of the possibility to write asynchronous code in a synchronous fashion, the generators + Promises pattern was so appreciated that got a dedicated syntax!

<joke>

</joke>

But, I hear you ask, how that relates to my goal?
Well, what if, instead of Promises, we yield out pieces of the computation?

The idea

I have always been fascinated by the cleverness of the generators + Promises pattern. It is not so difficult to understand nor to recreate, but I admit it's something I never would have thought.
Thinking how to solve the try block failed computation problem, it has inspired me.

I'm going to show you broadly how I've solved the problem, the main idea behind it. Then I'll argue it as much as possible.

Let's transform the following block:

let value = null;

try {
    const res1 = itMayThrow();
    const res2 = itMayThrowToo(res1);

    value = res2 / res1;
} catch {}

using a generator that yields the problematic pieces of the main computation:

let value = null;

function* mainComputation() {
    const res1 = yield itMayThrow;
    const res2 = yield () => itMayThrowToo(res1);

    value = res2 / res1;
}

When the generator is executed, it yields out what could go wrong.
Who handles the generator, a simil co function, will be able to execute each yielded computation, reinserting back into the generator its result if no exception was thrown. Otherwise, it could not only try again the failed computation one or multiple times, but it could substitute it with a fallback value as well.

First attempt

You can find my first working solution here. I'm not going to spend so much time on it because, yes, it was powerful, but each try-catch block would have been transformed in a poem. The heaviness of the resulting code would have overshadowed the benefits of using the package itself.
Another mark against it was the need to stop using the try-catch syntax in favour of a dedicated API.

Second attempt

Focusing only on what is really needed, that is the possibility of retrying a failed computation or providing a fallback value, I've written a simpler package that could be used in conjunction with the well known try-catch syntax.

Here it is the result:

sync version

const { performSync, computeSync } = require("resumabletcf");

let value = null;

try {
    value = performSync(function*() {
        // computeSync(unitOfWork, howManyTimesToRetry, fallbackValue)
        const res1 = yield computeSync(itMayThrow, 5, 0);
        const res2 = yield computeSync(() => itMayThrowToo(res1), 5);

        return res2 / res1;
    });

} catch(e) {
    console.log(e);
}

async version

const { performAsync, computeAsync } = require("resumabletcf");

;(async () => {
    let value = null;

    try {
        value = await performAsync(async function*() {
            // computeAsync(unitOfWork, howManyTimesToRetry, fallbackValue)
            const res1 = yield computeAsync(itMayThrow, 5, 0);
            const res2 = yield computeAsync(() => asyncItMayThrowToo(res1), 5);

            return res2 / res1;
        });

    } catch(e) {
        console.log(e);
    }
})();

Let me explain it.

The perform functions are in this pattern what the co function is in the generators + Promises pattern.
Both the performSync and the performAsync functions take a generator, a sync and an async one respectively, and have the task to handle what they yield out. Only a particular type of function that embraces the problematic piece of computation must be yielded out, to then be properly managed by the generator runner, and we can create it thanks to the compute helpers.
If the generator reaches the end, the returned value will be given back by the perform functions, as a normal value in the performSync case or contained in a Promise in the performAsync case.

These helpers require three arguments: the unit of work to perform, how many times to retry it in case of failure (default value is 0) and a fallback value to be used if we ran out of attempts.
If you don't want to let the perform runner use a fallback value for a specific computation, preferring to rethrow the exception that has caused the unit of work to fail, simply do not pass the third parameter.
Be aware of the fact that passing undefined as the third parameter is not the same as passing only two parameters; this ensures you can use undefined as a fallback value.

Three more points to keep in mind:

performAsync always returns a Promise that will be fulfilled only if the async generator reaches the end, otherwise it will be rejected with the exception that causes its interruption as the reason
the function resulting from calling computeAsync always await the unit of work you have passed to the helper
you are not forced to return something from the generators

An example

Now we'll see an example of an async computation where two different remote API will be called into play. Each HTTP request could fail or take too time to respond, so the possibility of trying again will shine.
Moreover, the user position will be asked and, in the worst case, the Greenwich coordinates will be used as default value.

import { performAsync, computeAsync } from "resumabletcf";

const httpClient = Object.freeze({
    async delay(ms, v) {
        return new Promise(ok => setTimeout(ok, ms, v));
    },
    async get(url, ms = 1000) {
       const res = await Promise.race([fetch(url), this.delay(ms)]);

       if(res === void 0) {
           throw new Error("Out of time");
       }

       // only successfully status (2XX) are allowed 
       if(res.status < 200 || res.status > 299) {
           throw new Error(res);
       }

       return res;
    },
    async post(url, { headers, body, ...otherConfigs }, ms = 1000) {
       const config = {
           ...otherConfigs,
           method: "POST",
           headers,
           body,
       }
       const res = await Promise.race([fetch(url, config), this.delay(ms)]);

       if(res === void 0) {
           throw new Error("Out of time");
       }

       // only successfully status (2XX) are allowed 
       if(res.status < 200 || res.status > 299) {
           throw new Error(res);
       }

       return res;
    },
    async toJSON(res) {
        return await res.json();
    }
});

// wrapping the getCurrentPosition API
const getPosition = function (options) {
  return new Promise(function (resolve, reject) {
    navigator.geolocation.getCurrentPosition(resolve, reject, options);
  });
}


;(async () => {

    try {
        await performAsync(async function* () {

            // ask the user for his location only one time
            // use Greenwich coordinates as default
            const position = yield computeAsync(getPosition, 0, {
               coords: { latitude: 51.47, longitude: 0 }
            });

            const lat = position.coords.latitude;
            const lon = position.coords.longitude;


            const wrappedGetRequestAboutWeather = () => httpClient.get(`
                https://api.openweathermap.org/data/2.5/weather?lat=${lat}&lon=${lon}&APPID=0a80c24ce405d5481c3c5a9c41b9d45c
            `);

            // try to get info about the weather 10 times in total
            // the fallback value is 'null'
            let weatherRes = yield computeAsync(wrappedGetRequestAboutWeather , 9, null);

            if(weatherRes === null) {
                // try to get weather info from another API
                // ...
            }


            // if the 'toJSON' method fail it means that a wrong formatted
            // JSON response was obtained by the server
            // we are not able to do anything: let the exception rise
            const { weather } = await httpClient.toJSON(weatherRes);


            const wrappedPostRequestAboutWeather = () => httpClient.post(`
                https://5d457dedd823c30014771ebb.mockapi.io/resumabletcf/weather
            `, { body: JSON.stringify(weather[0]) }, 2000);

            // try to store info about the weather 10 times in total
            // here it does not make sense to provide a fallback value
            // so if it were not possible, an exception will be thrown
            yield computeAsync(wrappedPostRequestAboutWeather , 9);

        });

    } catch(e) {
        console.log(e);
    }

})();

Epic fail

As I've already said, this solution is far away from the power of algebraic effects.
Let me show an example; I'll borrow it from Dan:

function getName(user) {
  let name = user.name;
  if (name === null) {
    throw new Error('A girl has no name');
  }
  return name;
}

function makeFriends(user1, user2) {
  user1.friendNames.add(getName(user2));
  user2.friendNames.add(getName(user1));
}

const arya = { name: null, friendNames: new Set() };
const gendry = { name: 'Gendry', friendNames: new Set() };

// here the main part
try {
  // this is going to throw because 'arya.name' is 'null'
  makeFriends(arya, gendry);
} catch (err) {
  console.log("Oops, that didn't work out: ", err);
}

It could be transformed into:

const { performSync, computeSync } = require("resumabletcf");

function getName(user) {
  let name = user.name;
  if (name === null) {
    throw new Error('A girl has no name');
  }
  return name;
}

function makeFriends(user1, user2) {
  user1.friendNames.add(getName(user2));
  user2.friendNames.add(getName(user1));
}

const arya = { name: null, friendNames: new Set() };
const gendry = { name: 'Gendry', friendNames: new Set() };

// here the main part
try {
  performSync(function*() {
    yield computeSync(() => makeFriends(arya, gendry), ...); 
  });
  ;
} catch (err) {
  console.log("Oops, that didn't work out: ", err);
}

but this isn't going to help us so much. That is because getName and makeFriends are normal functions; after raising the exception, their stack is unwound. We are still able to replace the result of calling makeFriends inside the generator, but it is pretty useless at this point.

The computeSync could be modified to take a fallback computation as well, but it seems to be a non-complete solution.
I need to think about that. What's your opinion? Do you have any idea?

Conclusion

I have to admit that I'm not completely satisfied with resumabletcf.
I think it could find its place in the JavaScript world, but it seems a bit limited and limiting. The fight against the stack unwinding is hard; maybe generators are not the right answer.
How far we can go with a dedicated API before the cost-benefit grows too much?
Or maybe the solution is here somewhere, but I'm not able to see it.

Reactive primitives in JavaScript (and other cool stuff with OxJS)

Andrea Simone Costa — Wed, 03 Jul 2019 17:52:08 +0000

Ok ok, I know what you are thinking: this is impossible!

And the delirium began

Some time ago I was wondering if it were possible to create direct reactive relationships between entities in JavaScript.
In other words I would have liked to be able to write code conceptually represented by the following pseudo one:



// create a source
const $source = { foo: 42 };

// create a reactive primitive that will be updated
// when the 'foo' field of the source changes
rx primitive = $source.foo;
primitive; // 42

// create a reactive object that will be updated
// when changes happen into the source
rx object = $source;
object; // { foo: 42 };

// change the 'foo' field source
$source.foo = 'hi';

// the reactive primitive was updated
primitive; // 'hi'
// the reactive object as well
object; // { foo: 'hi' }

// change the whole source
$source = { foo: { bar: 'baz' } };

// the reactive object was updated
object; // { foo: { bar: 'baz' } }
// the reactive primitive too, but unfortunately is no more a primitive
primitive; // { bar: 'baz' }

What's the point of such type of reactivity, that I like to define encapsulated reactivity or low-level reactivity?
It helps to observe changes inside a structure that could easily become the source of truth in event-driven applications.

Let's talk about VueJS computed properties, from which I've took inspiration to build the raw reactivity system of OxJS. I'm not going to explain VueJS reactivity system here, but I can link this interesting video series that contains lot of useful information.
For each Vue component, we can consider the union of the internal data object and the props that the component's parent has passed to it as the source of truth:



export default {
    data() {
        // the internal data object
        return {
            age: 22
        }
    },

    props: {
        // a numerical multiplier prop
        multiplier: {
            type: Number,
            default: 1,
        }
    },

    // here the magic
    computed: {
        result() {
            return this.multiplier * this.age + 1;
        }
    }
}

Computed properties are a special type of properties that result from combining other properties of the component with some custom logic. In our example the result computed property will become the result of a mathematical operations that uses the multiplier prop and the age data property.
Every time one of those changes, the result property will be recomputed, hence the name, updating properly.

For VueJS developers computed properties are very useful and irreplaceable; the lifeblood of each VueJS component, because they make reactivity a breeze.

So I've asked myself: why not try to extract, broadly, this type of reactivity from VueJS? A few days later OxJS was born.

Epic music

OxJS is a proof of concept library written in TS that enable encapsulated reactivity.

Let's try it to create an observable and a reactive object:



const { ox } = require('oxjs');

// it creates an observable source
const $source = ox.observable({
    years: 32,
});

// it creates a reactive object
const reactiveObject = ox.observer(() => {
    // we are referencing the observable here
    const years = $source.years;

    // an object is returned
    // so we are creating a reactive object
    return {
        age: years,
    }
});

// initial evaluation
console.log(reactiveObject); // { age: 32 }

// we change the stored 'years' inside $source
$source.years = 28;

// the 'reactiveObject' is updated
console.log(reactiveObject); // { age: 28 }

As you can see the creation of both an observable and an observer is pretty straightforward; moreover the latter one is notified as soon as possible.
Obviously we are not limited to one observer for one observable at time: an observable can be used by any number of observers and an observer can use how many observable it needs.

What about reactive primitives?

Here it is:



const { ox } = require('oxjs');

// it creates two observable sources
const $source1 = ox.observable({
    years: 32,
});

const $source2 = ox.observable({
    name: 'Mario',
});

// it creates an observer that will behave as a string
const stringObserver = ox.observer(() => `My name is ${$source2.name} and I'm ${$source1.years} years old`);

// initial evaluation
console.log(`${stringObserver}`); // My name is Mario and I'm 32 years old

// we change the stored 'years' inside $source1
$source1.years = 28;

// the 'stringObserver' is updated
console.log(`${stringObserver}`); // My name is Mario and I'm 28 years old

// we change the stored 'name' inside $source2
$source2.name = 'Luigi';

// the 'stringObserver' is updated
console.log(`${stringObserver}`); // My name is Luigi and I'm 28 years old

As you will see my reactive primitives are not perfect, because they are not real primitives. Otherwise my API would not have been able to change the value referenced by them. In fact they are based on primitives wrappers and a weird ES6 Proxies hack that has got some limitations, due to the JS lang itself.

But they are suitable for a wide range of cases if you pay a little attention. Most times you will not feel the difference. I hope.

What's going on under the hood?

I'm not able to explain all the reactive hackish that I've proudly written, but I can try to describe the magic that happens when a reactive entity needs to be updated.

Let's suppose this is our source of truth:



const $source = ox.observable({
    city: 'Carrara',
    country: 'Italy',
});

We call into question the following weird observer that could be either a string or an object:



let weirdObserver = ox.observer(() => {
    const city = $source.city;
    const country = $source.country;

    if (city && city.length > 5) {
        return `${city} is located in ${country}`;
    } else {
        return {
            city,
            country
        }
    }
});

// initial evaluation
console.log(`${weirdObserver}`); // "Carrara is located in Italy"

Knowing that each time one of the used $source fields changes, the arrow function passed to ox.observe is called, the main problem was: how to change on what the weirdObserver identifier is pointing to?
Without relying on a closure, which would have led to a change in the way ox.observe and OxJS were thought to be used, there is no way in JS.

Therefore, if we cannot move the weirdObserver identifier, we can't even set it to a primitive, because in JS two different identifiers cannot point to the same memory area if in it a primitive value is stored.

Wait a moment, why we need another reference?

Because if weirdObserver is immovable, we need another reference to the same thing pointed by it - reference that will be stored somehow by OxJS - to perform the changes, so that weirdObserver "sees them" as well, so to speak.

To summarize what has been said so far:

no primitives are allowed (here's why I do use primitive wrappers)
weirdObserver is immovable and will always point to the same object
there is another reference to the same object pointed by weirdObserver that is used to perform changes

Now another another problem comes up: that object should be able to completely change its nature. What if it should be transformed from an Array to a Number wrapper, to be then changed into a Promise, passing from a Map?
Yes I'm exaggerating, but I believe you have now grasped the point: there is no merge strategy nor prototypes hack which could help us.

So what? ES6 Proxies!

The solution I found is to return an almost fully transparent Proxy on which the target is dynamically changed at runtime. As a rule this is not possible, unless all traps are redirected.
I know, this is a big, ugly workaround. But I was able to made the hack resilient for the most use cases.

Returning to our example, the proxy referenced by weirdObserver will have a String wrapper as a target initially. Each time the source changes, even if the length limit is not exceeded, the target of the proxy will change.

If length of the new $source.city value is greater than 5, the new target will be a new String wrapper, otherwise will be a new { city, country } object. Due to the nature of Proxies, the client, that is who use the weirdObserver identifier, will be able to use all the String.prototype's methods in the former case and to perform almost all the operations which are allowed on an object in the latter.

Other things that OxJS can do

I'm too lazy to create a clone of the README. Please check it out here.

Conclusion

As I said this library is only a proof of concept, IDK if this sort of reactivity could be suitable in real applications without having a framework that protect us. Maybe its "implicit" nature could quickly generate problems if misused.
I'd like to hear your opinion on that.

Moreover sometimes I like to develop only for the pleasure of it, without worrying too much on clean and efficient code nor wondering on real use cases of what I'm creating. This is one of those cases; I've focused more on trying to upgrade my TS skills (apparently with little success seeing how much I had to fight 😂) and on reaching my main goal: take reactivity to a greater level of mess.

The shortest way to conditional insert properties into an object literal

Andrea Simone Costa — Wed, 27 Mar 2019 20:25:39 +0000

Hi, nice to meet you 😄!
You can find this article in my personal blog here.

Customize objects coercion in JavaScript

Andrea Simone Costa — Sun, 24 Mar 2019 10:53:33 +0000

Introduction

JavaScript, unlike other programming languages, doesn't allow operators overloading. What it allows us to do is to modify the primitive value in which an object is transformed. This is because when an object is coerced, the result is, and must be, a primitive value.

Unfortunately we can consider this opportunity only a paltry consolation prize, because the control we can obtain is quite limited. In any case it could always be useful to know what possibilities the language offers to us, considering that ES6 has brought a solution of considerable value.

The whole article is based on a good number of concepts related to coercion. In fact, what we can do is modify the result of the coercion performed on our objects.

Customization before ES6

Since coercion of objects is strongly based on toString and valueOf methods, which are callable by default on any object, what we could do before ES6 was simply redefine those methods on our objects.

Why did I use the word redefine? Why are the two methods callable by default? In Javascript all objects are automatically linked to the Object.prototype object thanks to what is called the prototype chain.
This object defines a fair number of methods which are therefore invocable directly from the all the objects connected to it. Learn more here.

Before to redefine their behaviour, let's see the default one:

    var object = {
        prop: "value",
    };

    object.valueOf(); // object
    object.toString(); // "[object Object]"

As you can see, valueOf simply returns the object itself (a reference to). Instead the other method, toString, reads the value of the [[Class]] internal property and constructs the well know "[object Object]" string.

Also arrays are objects, but for them the behaviour of the toString method was already redefined by default:

    var array = [1, 2, 3];

    array.valueOf(); // array
    array.toString(); // "1,2,3"

When any object is coerced, depending on the initial conditions, a method between toString and valueOf will take precedence. Only if it does not return a primitive value, such as the valueOf method of Object.prototype, the other method will be invoked as fallback. If even it doesn't return a primitive value, a TypeError will be raised.

Warning! We could decide to return null or undefined when we redefine these methods because they are valid primitive values. However, Javascript never leads to this result for the objects it makes available to us and we should follow its example, returning one of string, number and boolean.

Numerical operations like Number(obj), +obj (unary +), unary -, binary -, *, **, /, % will clearly prioritize the valueOf method, while an explicit coercion operation like String(obj) will give priority to the toString method.
Doubts arise when facing the binary + and the == loose equality operator, which give priority to valueOf.

Let's see, in practice, how this stuff can help us to reach our goal:

    var myObj = {
        toString: function() {
            return "myObj";
        },
        valueOf: function() {
            return 10;
        }
    }

    // valueOf precedence
    Number(myObj); // 10
    +myObj; // 10
    myObj - 7; // 3
    myObj % 3; // 1
    myObj + 15; // 25
    "this is " + myObj; // "this is 10"
    myObj == 10; // true

    // toString precedence
    String(myObj); // "myObj"

We have therefore redefined the behaviour of our object.

We may however not be satisfied with the result of "this is" + myObj;, preferring "this is myObj" to it. Unfortunately, apart from explicit coercion using the String function, the only way to do this, in ES5, is to impose the return of the string "myObj" to the valueOf method as well, sacrificing the possibility of using the object in arithmetic operations, penalty an infinite series of NaN deriving from the coercion attempt of the "myObj" string in a number.

Customization with ES6

Let me introduce a new concept: the hint. When any object is coerced into a primitive, the decision to give priority to one of the two method of which we spoke earlier is done thanks to an hint.
Possible values for the hint are: number, string, default.
When the hint value is string will be given precedence to the toString method, when it is number or default is the valueOf method which has priority. The only exception to this logic is the Date "type", for which the default hint value will give priority to the toString method.

Let's see what hints are forwarded by the main operations seen so far:

Hint	Operations
string	String(), interpolation [ES6]
number	Number(), unary +, unary and binary -, , *, /, %
default	binary +, ==

It may seem the opposite, but ES5 is also based on the same concepts. The difference lies in the possibility, offered by ES6, to interact directly with this mechanism.

It is necessary to provide to the object a method with a special name, which takes a string with the value of the hint. Based on it we can decide what to do, like manually call the valueOf and toString methods if it is our wish, or invoke other methods. The important thing is to produce a primitive value as the end result, to avoid running into a TypeError.

What is the special name of this method? It's Symbol.toPrimitive. This article will not talk about symbols, because it is not necessary to have confidence with them to reach our goal.

Let's see a possible implementation of it, which allows us to obtain the same behavior defined by ES5:

    let obj = {
        [Symbol.toPrimitive](hint) {
            // it checks if a value is an object
            const isObject = (value) => value !== null 
                                        && typeof value === 'object' 
                                        || typeof value === 'function';

            switch(hint) {
                case "default": 
                case "number": 
                    // precedence to valueOf if the hint is "number" or "default"
                    const value = this.valueOf();

                    // if the result is a primitive, it can be returned
                    if(!isObject(value)) return value;

                    // otherwise the toString method is used as fallback
                    else return this.toString();

                case "string": 
                    // precedence to toString if the hint is "string"
                    const string = this.toString();

                    // if the result is a primitive, it can be returned
                    if(!isObject(string)) return string;

                    // otherwise the valueOf method is used as fallback
                    else return this.valueOf() 
             }
        }
    }

What could we do if toString and valueOf methods are not trustable and could lead to a TypeError?
Let's see a possible workaround:

    let obj = {
        [Symbol.toPrimitive](hint) {
            // it checks if a value is an object
            const isObject = (value) => value !== null 
                                        && typeof value === 'object' 
                                        || typeof value === 'function';

            switch(hint) {
                case "default": 
                case "number": 
                    // precedence to valueOf if the hint is "number" or "default"
                    let res = this.valueOf();

                    // if the result is a primitive, it can be returned
                    if(!isObject(res)) return res;

                    // otherwise the toString method is used as fallback
                    res = this.toString();

                    // if the result is a primitive, it can be returned
                    if(!isObject(res)) return res;

                    // otherwise returns an appropriate primitive value
                    return NaN;


                case "string": 
                    // precedence to toString if the hint is "string"
                    let res = this.toString();

                    // if the result is a primitive, it can be returned
                    if(!isObject(string)) return string;

                    // otherwise the valueOf method is used as fallback
                    res =  this.valueOf();

                    // if the result is a primitive, it can be returned
                    if(!isObject(res)) return res;

                    // otherwise returns an appropriate primitive value
                    return "";
             }
        }
    }

We can easily add more substantial changes to the mechanism, bearing in mind the table shown above. As a practical example, I take the previously defined myObj object, where I wanted the object to be transformed into a string value instead of a numeric one when the binary + operator comes to action. As the table illustrates, the == operator will also be affected by my change.

    let myObj = {
        toString() {
            return "myObj";
        },
        valueOf() {
            return 10;
        },
        [Symbol.toPrimitive](hint) {
            switch(hint) {
                case "number": 
                    return this.valueOf();

                case "default":     
                case "string": 
                    return this.toString();
             }
        }
    }

It is worth noting that we could still use the numeric value of myObj in a binary + operation or with the == operator if necessary, thanks to the unary +.
The table confirms this statement: unary + suggests "number".

    "this is " + myObj; // "this is myObj"
    `greetings from ${myObj}`; // "greetings from myObj"
    "myObj" == myObj; // true

    32 + +myObj; // 42
    `greetings from ${+myObj}`; // "greetings from 10"
    10 == +myObj; // true