Forem: Kirill Shestakov

How does coding impact your mental health?

Kirill Shestakov — Wed, 13 Jul 2022 09:55:25 +0000

What is the best Design System or UI Component Library?

Kirill Shestakov — Sun, 08 May 2022 18:06:23 +0000

Do you tend to use one in your projects? Do you use it as inspiration for creating your own?

What makes you a productive learner?

Kirill Shestakov — Sat, 07 May 2022 18:38:35 +0000

What is your secret? What are some minor things that help?

This Microsoft proposal will prevent JavaScript from ever getting a type system

Kirill Shestakov — Sun, 24 Apr 2022 08:30:41 +0000

On Mar 9, 2022, Microsoft announced a proposal to add type syntax to the JavaScript language (originally proposal-types-as-comments; later renamed to proposal-type-annotations).

The stated intention of the proposal is to enable a large portion of TypeScript (and Flow) code to be runnable in the browsers natively, without requiring compilation or bundling. The proposed idea is for JavaScript engines to strip out the type syntax as if it were comments:

type Result = {
  a: number,
  b: number,
  sum: number
};
function sum(a: number, b: number): Result {
  const sum: number = a + b;
  return {
    a,
    b,
    sum
  };
}

In the above example, any type information such as { a: number, ... }, : number, : Result, etc, will be ignored by JavaScript engines.

Why is this important?

Proposals are a way to make changes to the JavaScript language - a way to evolve it, to keep it modern, to solve common problems for the benefit of everyone using the language. Features like async-await and optional chaining started as proposals and have since become important parts of the language.

According to State of JS survey, one of the most greatly missed features in JavaScript is the ability to define and ensure static types:

JavaScript community saw the benefits of static typing and prefers to work with statically typed code, and there are important reasons for it:

Type safety: ensuring that variables can only be used in ways that doesn't functionality
Clear intention: allowing you to express intention and code design with types
Better code cohesion: different parts of your code can communicate with each other in clearer ways
Documentation: external packages that are statically typed benefit from useful IDE suggestions

So, what's wrong?

It sounds great, right? We're going to get types in JavaScript! Well... actually, quite the opposite.

The proposal will make this code valid, even though the types are wrong:

interface User {
  id: number,
  username: string,
  email: string,
}
const user: User = { name: 'bestGuy44' };

Due to strong backwards compatibility guarantee provided by JavaScript, under this proposal, this code will always be valid JavaScript.

Because all type information is ignored as comments, that means all non-sensical code such as the following, will also become a fully proper JavaScript code:

type NonSenseType = {
  makes no sense but here we go
}
function fetchPeople(id: non sense): what ever {
  return "";
}

Because this code has to forever remain valid JavaScript and never fail, this means that any hypothetical future JavaScript type-checker cannot use this these type annotations to decide to accept or reject your code. The only possible way to introduce a type-checker to the language would be to add second type annotation syntax, which would be unreasonable if there is already syntax for that.

Why is this desirable for Microsoft?

TypeScript is led by Microsoft and is currently at an all time high in being used and loved by the community, and for good reasons. It would be a big shame, if someone came up with a great type system to rival TypeScript, proposed it and implemented it in JavaScript itself. If that were to happen, it would create quite a bit of a problem for the TypeScript project, if not rendering it useless.

Official type-checker that's incompatible with TypeScript is possibly the biggest threat to the TypeScript project. It is unclear whether getting rid of this threat is one of the intentions of the proposal, or any of its authors and champions, but it is what the proposal achieves along with the stated intention.

But TypeScript is already the best, so why not?

As someone who's been coding for many years in a variety languages, I love TypeScript, how it transformed JavaScript community and the ease of development in the language. It is also clear that TypeScript is far from being the best possible type system.

For one, it does not enforce strict typing.

// If something is declared as a string
let name: string;
// It may later be initialized as non string through "any"
name = 0 as any;
// or through a clever use of "as"
name = {} as unknown as string;

TypeScript was designed to describe the existing JavaScript, not to make it more optimized or allow you to be in a better control of your memory layout. This is why it has types such as "number" instead of more optimized types like "int", "float", "i32", "f64", etc.

const age: u8 = 20; // not a thing

TypeScript has more than one way to define types:

// 1
type Person = {
  name: string,
  age: number,
}

// 2
interface Person {
  name: string,
  age: number
}

// 3
class Person {
  name: string;
  age: number;
}

This adds more confusion when learning TypeScript, and can become a reason for unnecessary debate in a workplace along the lines of tabs VS spaces.

In addition, TypeScript has a strong emphasis on Object-Oriented features of the language, adding things such as abstract classes, public / private / protected fields, which is not a surprise given the influence of C#. There is a plenty of debate within the community around the value of OOP, and, in particular, whether inheritance or composition should be preferred. It is my experience that inheritance, that TypeScript expands with aforementioned features, more often than not, leads to less clear and overall worse code than the analogous composition-based code.

There are languages whose type systems provide many advantages that TypeScript does not. Rust, which has been considered to be the most beloved language, has a strict type system, with useful algebraic data types, allows optimized types and great control over the memory layout, is trait-based, and has no concept of classes and inheritance. It is natural for languages to get inspired by each other, and evolve to provide similar advantages to their own developers. It would be unwise to ignore languages like Rust, and not consider the advantages that stricter type systems give.

All that is to say that we can do better than TypeScript, and it is conceivable for a better type-checker to emerge and capture the hearts of developers. This proposal will make it much more difficult for such type-checker to emerge as an external tool like TypeScript and Flow, and impossible for it to emerge as a proposed standard.

Is it worth it?

Static typing provides important value that developers are yearning for. The proposal does not deliver this value and, instead, actively prevents the most desired feature developers are asking for from ever being proposed and considered as part of JavaScript standard.

The only people who will benefit from this proposal are people who both (1) are ok with using a subset of TypeScript or Flow (e.g. if you're using JSX or enums, you're not included) and (2) prefer not to compile or bundle their code. The extent of their benefit will be the ability to run code without compilation. Is it worth to receive this benefit, given that it will prevent JavaScript from ever getting a proper type system?

What makes good code good?

Kirill Shestakov — Wed, 24 Mar 2021 06:57:04 +0000

Assume that you've just become part of a team that manages a large code base for an interesting and fulfilling project. What most important aspects of the way the code is written will make the code good? What specific things are going to make your journey a complete breeze in terms of reading and understanding the code, adding new features, improving and patching it?

I'd highly appreciate it if you also indicated your experience and included an example from your past experience of encountering really good code (or bad), and what made it good (or why it wasn't).

What do you do when you can't write something in a clean way?

Kirill Shestakov — Tue, 11 Jun 2019 04:35:25 +0000

When you've been stuck trying to figure out how to write something in a clean and SOLID way, and it's been taking more time that you'd like, what do you do? Do you give up and allow yourself a bit of messiness, or do you do something else to figure it out?

You Can Create Private Properties In JS (accessor pattern)

Kirill Shestakov — Sun, 09 Apr 2017 22:44:36 +0000

It's very common for JavaScript developers to claim that it's impossible to create truly encapsulated properties and methods on an object and use them on its prototype.

In ES6, there are a few ways of easily achieving private properties without memory leaks. For example, you could use a ES6 Symbol:

// Closure
var SomeClass = function() {
    var priv_prop = Symbol();
    var SomeClass = function() {
        this[priv_prop] = 200;
    };
    SomeClass.prototype.test = function() {
        console.log(this[priv_prop]);
    };
    return SomeClass;
}();
var instance = new SomeClass();
instance.test(); // `200` logged

Alternatively, you could use a WeakMap:

// Closure
var SomeClass = function() {
    var priv_prop1 = new WeakMap();
    var priv_prop2 = new WeakMap();
    var SomeClass = function() {
        priv_prop1.set(this, 100);
        priv_prop2.set(this, 200);
    };
    SomeClass.prototype.test = function() {
        console.log(priv_prop1.get(this));
        console.log(priv_prop2.get(this));
    };
    return SomeClass;
}();
var instance = new SomeClass();
instance.test(); // `100` and `200` logged

The problem with the Symbol method is that you can still access those properties using Object.getOwnPropertySymbols. In either case, you would likely have to include bulky polyfills in production code.

Prior to ES6, there was no obvious way to create private properties usable on prototype. The claim is that you either have to abandon the idea or use a memory leaky Map (alternatively, you could use 2 arrays). But what if I told you that there is actually a way to do this that is cross-browser, needs no polyfills or ES6, and doesn't produce memory leaks?

The idea

I haven't seen this method used by anyone (EDIT: it was pointed out to me that I wasn't the first one to come up with this method. Read more here), so I'd like to call it an accessor pattern. The idea is to create a closure, create a key inside the closure and create a storage for private properties that can only be accessed if the correct key is provided. Here's how you would implement it:

/* Here's how you can create truly private
   properties in JS and use them on prototype */

// Closure
var SomeClass = function() {
    var key = {};

    var private = function() {
        var obj = {};
        return function(testkey) {
            if(key === testkey) return obj;
            // If the user of the class tries to access private
            // properties, they won't have the access to the `key`
            console.error('Cannot access private properties');
            return undefined;
        };
    };

    var SomeClass = function() {
        this._ = private(); // Creates a private object
        this._(key).priv_prop = 200; // this._(key) will return the private object
    };

    SomeClass.prototype.test = function() {
        console.log(this._(key).priv_prop); // Using property from prototype
    };

    return SomeClass;
}();

var instance = new SomeClass();
instance.test(); // `200` logged

var wrong_key = {};
instance._(wrong_key); // undefined; error logged

Pretty simple, huh? private function creates the private storage and returns a private access function that will only return the storage if the correct key is provided. Then, in constructor, we assign this private access function to this._ which can be easily used on the prototype, provided that the prototype properties also have access to the key. Basically, there is no way to access the private storage without having the correct key. Hence, if the user tries to call this._ with any argument, maybe with a wrong_key, then the attempt will fail, error will be logged, and all the user will get is undefined.

Advantages of this method:

It's quite simple. All you need is to create a private storage, and you can access all private properties inline within a constructor / prototype.
It lets you create truly private properties that can be accessed from the prototype. The user of the class will not be able to access them.

Disadvantage of this method:

It slightly pollutes the namespace, because you have to assign the private storage to this._ or alike, but there's probably no other way to do this.

A problem

A minor problem with this method is that, in case of prototypal inheritance, if both child and parent use the same property name for the private access function (in this example, this._), then the parent's private properties cannot be accessed within parent's prototype, because this._ will refer to child's private access function. Here's what I mean,

// Note: this Gist is to show a problem with accessor pattern
// and inheritance. Do not use!

var private = function(key) {
    var obj = {};
    return function(testkey) {
        if(key === testkey) return obj;
        console.error('Cannot access private properties');
        return undefined;
    };
};

var ParentClass = function() {
    var key = {};
    var ParentClass = function() {
        this._ = private(key);
        this._(key).priv_prop = 100;
    };
    ParentClass.prototype.parent_test = function() {
        console.log(this._(key).priv_prop);
    };
    return ParentClass;
}();

var ChildClass = function() {
    var key = {};
    var ChildClass = function() {
        ParentClass.call(this);
        this._ = private(key);
        this._(key).priv_prop = 200;
    };
    ChildClass.prototype = Object.create(
        ParentClass.prototype
    );
    ChildClass.prototype.test = function() {
        console.log(this._(key).priv_prop);
    };
    return ChildClass;
}();

var instance = new ChildClass();
instance.test(); // `200` is correctly logged
instance.parent_test(); // ERROR! (expected result: `100`)

When instance.parent_test is called, this._ inside it will refer to the child's private access function, hence, the key will mismatch and the error will be logged. However, this problem can be quite easily solved.

The final solution

The best solution is to namespace and make sure that parent and child have different property names for their private access functions. Here's the final solution:

/* Here's how you can create truly private
   properties in JS and use them on prototype */

// Creates private storage, secures with a key, and
// returns a private access function
var private = function(key) {
    var obj = {};
    return function(testkey) {
        if(key === testkey) return obj;
        console.error('Cannot access private properties');
        return undefined;
    };
};

// Create closure
var ParentClass = function() {
    var priv = '_ParentClass' + Math.random(); // Namespace
    var key = {}; // Create key withing closure
    var ParentClass = function() {
        this[priv] = private(key); // Create private storage
        this[priv](key).priv_prop = 100; // Modify any private data
    };
    ParentClass.prototype.parent_test = function() {
        console.log(this[priv](key).priv_prop); // Access private data
    };
    return ParentClass;
}();

var ChildClass = function() {
    var priv = '_ChildClass' + Math.random();
    var key = {};
    var ChildClass = function() {
        ParentClass.call(this);
        this[priv] = private(key);
        this[priv](key).priv_prop = 200;
    };
    ChildClass.prototype = Object.create(
        ParentClass.prototype
    );
    ChildClass.prototype.test = function() {
        console.log(this[priv](key).priv_prop);
    };
    return ChildClass;
}();

var instance = new ChildClass();
instance.test(); // `200` logged, as expected
instance.parent_test(); // `100` logged, as expected

// Yet, there's no way to access the property from outside of the closure

Pretty much the only difference from the previous code snippet is that we replaced this._ for both child and parent classes with this[priv], where priv is namespaced and randomly generated to ensure that private access function is stored under a different property name for child and parent.

Another recommendation I can make is that you should probably secure this[priv] by making it non-configurable, non-enumerable and read-only:

    Object.defineProperty(this, priv, {
        value: private(key)
    })

Instead of just

    this[priv] = private(key)

This will make sure that user will not be able to remove or modify this[priv], which is crucial for correct private storage functioning.

Conclusion

Go ahead and use accessor pattern! It allows you to create truly encapsulated properties and use them on a prototype. Let others know about this method so we don't continue the misconception that privacy is impossible to achieve in JavaScript. Sharing this article will also help ðŸ˜Š

Hi, I'm Kirill Shestakov

Kirill Shestakov — Sun, 09 Apr 2017 22:41:24 +0000

I have been coding for 10 years.

You can find me on GitHub as guitarino

I live in Vancouver, Canada.

I mostly program in these languages: HTML, CSS and JavaScript.

I am currently learning more about ES6, Web Components.

Nice to meet you.