Forem: Konstantin Meiklyar

Who needs Javascript symbols?

Konstantin Meiklyar — Tue, 29 Sep 2020 04:28:52 +0000

Cover image by Alexander Fradellafra from Pixabay

Symbols are a less known primitive data type among string, number, bigint, boolean and undefined of Javascript. They were added as part of ES6 specification which was a big facelifting of Javascript language and included a lot of new features.

Why do we need Symbols?

Symbols have 2 main use cases:

Create hidden properties on objects that no other code (that has no reference to the symbol used) can access or overwrite. The convention of most built-in functions and libraries is to avoid referencing symbols declared on an object if there is no direct need to change them.
System symbols that are used to change default behaviors of object - for example, Symbol.toPrimitive that is used to define object behavior during the conversion of an object to primitive or Symbol.iterator that is used to set object behavior during the iteration.

Symbols basics

Symbols' syntax is very ~~symbol~~ simple. We can create a new symbol by writing:

// mySymbol is a new created symbol
let mySymbol = Symbol();
console.log(mySymbol) // Symbol()

Symbol() function has an optional description field and can be used in this way:

// mySymbol is a new created symbol that now has a description
let mySymbol = Symbol('decription of my symbol');
console.log(mySymbol) // Symbol(decription of my symbol)

The description field is just a text that will be attached to the symbol - it's mostly used for debugging purposes.

Every symbol returned from Symbol() function is unique, meaning that 2 symbols created using the function will never be equal (even they have same description passed to the function):

let firstSymbol = Symbol("sameDescription");
let secondSymbol = Symbol("sameDescription");
console.log(firstSymbol == secondSymbol); //false

Creating hidden properties in object

Now when we know how to create a new Symbol let's see how can use it to create a hidden property of an object.

First of all - why would we do that?

As a common use case, I can mention an example when our code is used by some third party. For example - we are writing an open-source library or a library that is going to be used by other teams of developers in our organization. We may want to add some "under-the-hood" properties to objects to be able to access them in our code - but at the same time, we want to guarantee that no other code will be able to access these properties.

If we were using regular object properties declared by a string - the developers using our library can do that accidentally by iterating over object keys or creating a property with the same name and overwriting it.

Symbols are here to help us.

For example - let's say we have an object representing a rock star:

let rockStar = {
  name: "James Hetfield",
  band: "Metallica",
  role: "Voice & Rythm guitar"
}

Now we want to add a hidden property that will represent an internal id that we want to be exposed only in our code and avoid using it outside our internal code:

let idSymbol = Symbol('id symbol used in rockStar object');

let rockStar = {
  name: "James Hetfield",
  band: "Metallica",
  role: "Voice & Rythm guitar"
  [idSymbol]: "this-id-property-is-set-by-symbol"
}

If we now want to access / change / delete the property set using the Symbol - we need to have the reference to the Symbol that was used to declare it. Without having it - we can't do that.

Also - when iterating over the keys of an object - we will not get a reference to a property set using the Symbol:

console.log(Object.keys(rockStar)); // (3) ["name", "band", "role"]

for ... in ... loop will also ignore our symbol:

for (key in rockStar) {
    console.log(key);
}

// output:
// name
// band
// role

Global symbol registry

What if in some cases we do want to add an ability to give access to properties that were defined using symbols? What if we need to share access to these properties between different modules of our application?

This is where Global symbol registry comes to help us. Think of it as a dictionary placed on a global level - accessible everywhere in our code where we can set or get Symbols by a specific key.

Symbol.for is a syntax used to get Symbols from the global registry.

Let's take the same example and re-write it using the global registry:

let idSymbol = Symbol.for('rockStarIdSymbol');

let rockStar = {
  name: "James Hetfield",
  band: "Metallica",
  role: "Voice & Rythm guitar"
  [idSymbol]: "this-id-property-is-set-by-symbol"
}

let idSymbol = Symbol.for('rockStarIdSymbol'); will do the following:

Check if the global registry has a symbol related to the key that equals rockStarIdSymbol and if there is one - return it
If not - create a new symbol, store it in the registry and return it.

This means, that if we will need to access our property in any other place in the code we can do the following:

let newSymbol = Symbol.for('rockStarIdSymbol');
console.log(rockStar[newSymbol]); // "this-id-property-is-set-by-symbol"

As a result - worth mentioning that 2 different Symbols returned by the same key in the global registry will be equal:

let symbol1 = Symbol.for('rockStarIdSymbol');
let symbol2 = Symbol.for('rockStarIdSymbol');
console.log(symbol1 === symbol2); // true

There is also a way to check which key Symbol is related to in the global registry using Symbol.keyFor function.

const symbolForRockstar = Symbol.for('rockStarIdSymbol')
console.log(Symbol.keyFor(symbolForRockstar)); //rockStarIdSymbol

Symbol.keyFor is checking the global registry and finds the key for the symbol. If the symbol is not registered in the registry - undefined will be returned.

System symbols

System symbols are symbols that can be used to customize the behavior of objects. The full list of system symbols can be found in latest language specification. Each system symbol gives access to some specification which behavior we can overwrite and customize.

As an example - let's see a usage one of the commonly used symbols - Symbol.iterator that gives us access to the iterator specification.

Let's assume we want to write a Javascript class representing a music band.
It will probably have a band's name, style, and a list of band members.

class Band {
   constructor(name, style, members) {
     this.name = name;
     this.style = style;
     this.members = members;
   }
}

And we will be able to create a new instance of the class by writing something like this:

const metallicaBand = new Band('Metallica', 'Heavy metal', 
['James', 'Lars', 'Kirk', 'Robert'];

What if we'll want our users to be able to iterate of the instance of the class like it was an array and get the names of band members? This behavior is reused in a few libraries having arrays wrapped inside objects.

Right now - if we will try to iterate over our object using a for ... of loop - we will get an error saying Uncaught TypeError: "metallicaBand" is not iterable. That's because our class definition has no instruction on how this iteration should be done. If we do want to enable iteration over it - we need to set the behavior and Symbol.iterator is a system symbol that we should use.

Let's add it to our class definition:

class Band {
   constructor(name, style, members) {
     this.name = name;
     this.style = style;
     this.members = members;
   }

  [Symbol.iterator]() { 
    return new BandIterator(this);
  }
}

class BandIterator{
  // iterator implementation
}

I will not dive into the actual implementation of the iterator - this can be a good topic for a separate post. But talking of Symbols - that's the use case we should know. Almost every native behavior can be changed and system symbols are the way to do it in javascript classes.

What else?

1) Well, technically properties on objects that are set using symbols are not 100% hidden. There are methods Object.getOwnPropertySymbols(obj), that returns all symbols set on an object and Reflect.ownKeys(obj) that lists all properties of on object, including symbols. But the common convention is not to use these methods for listing, iteration, and any other generic actions performed on objects.

2) Few times I saw code that had symbols used to declare enum values, like:

const ColorEnum = Object.freeze({
  RED: Symbol("RED"), 
  BLUE: Symbol("BLUE")
});

Not sure how good this practice is. Assuming that Symbols are not serializable and every attempt to stringify these values will just remove them from the object.

When using symbols - use serialization carefully. And overall - avoid making deep copies using JSON.parse(JSON.stringify(...)). This approach sometimes can cause hard to catch bugs that are causing sleepless nights!

3) Function used for shallow object cloning - Object.assign copies both symbols and regular string properties. This sounds like a proper design behavior.

I think that's all you need to know about symbols to have the full picture. Did I forget anything?

Happy you made it until this point!

Thanks for reading, as usual, I will appreciate any feedback.

If you love Javascript as I do - visit https://watcherapp.online/ - my side project having all javascript blog posts in one place, there is a ton of interesting stuff!

How to make your functional React components perform better (with useCallback and memo)

Konstantin Meiklyar — Sat, 02 Nov 2019 08:38:17 +0000

These days I am getting into React after 4 years of AngularJs and Angular 2+. I really like the unopinionated nature of this library and the flexibility to decide on patterns and implementation details.

With lots of choices you make - comes a big number of mistakes that can follow up these choices and more work we need to do as developers to ensure we are making our best to optimize our web applications and decide on the right patterns.

In this post, I will cover some optimization techniques I learned that may be useful for you.

This is my first React related post and I hope you'll like it.

React hooks

React hooks were a new addition in React 16.8. They give you an ability to use state without using javascript classes. These are very powerful and easy to use tools. I will not cover hooks basics here, you can learn them by yourself using official API reference, but I will use them in the demo application.

Demo application

For this post, I created a simple React application that we will change in a few ways to improve its performance. It's small and simple, but it's enough to describe the issues that we are going to solve in the next 5 minutes.

It's a number selection component and you can see it here and explore the code:

We have 2 components.
NumPad component represents a button having a number. As a props, it receives a value - a number to display, handleClick a callback function to handle clicks and isSelected - a boolean indicating if the button should get selected class or not. In case button has a positive isSelected - it will get a green color to indicate the selection.

The second and the bigger component is NumberSelection. This component has stateful logic and handles the selectedValue variable using useState hook. NumberSelection renders 10 buttons in the loop and one of them that is equal to selectedValue is getting isSelected class. It also represents the selected value inside the header element. Initial selectedValue equals 5.

Easy until now?

Now let's dive into the problems this code has.

Functional components

In 2019 functional components are considered a better practice than class components. With the help of hooks, they now allow creating stateful logic.

There is 1 important thing that we need to remember about functional components - they are functions that run on each render, meaning that every single thing inside them is invoked and every variable or function is declared again.

Inside NumberSelection we have a function called changeSelection. Every time the state of the component is changed - component is rendered and the function is declared again and again. To show this in a more visual way, I changed our original code and added a set called functionsSet. I will add our changeSelection to that set every time the component is rendered.

As you see, every time we change the selection - a new function reference is created and added to the set. This is definitely not so good for our memory and in some cases can cause memory leaks. But even a bigger problem - this function is passed to child components using props. This means that they will be rerendered too because of the change in the props passed inside.

What can help us here as a hook called useCallback. It will create a memoized version of the function that will be reused when the component will be rerendered.

Let's rewrite changeSelection declaration using useCallback hook:
See updated codepen example:

We are not redeclaring them anymore. Great success!

One more thing to remember here - in many cases there is no need to keep stateless functions inside functional components. If your function is completely static - consider placing it outside, move it to utils library or just before the component is declared. This will keep it from being redeclared even without the usage of useCallback.

What are we really rendering?

There is a big number of great articles explaining in-depth how rendering works overall and in React applications. I will not dive into it here as it will take too much time. I assume that you know what React Virtual Dom is and how it works.

How our application is rendered? What happens when we change the selection and the state of NumberSelection is updated?

The whole application is rendered for the first time.
We click the button represented by NumPad component.
This calls the callback function received from NumberSelection component.
State of NumberSelection component is changed as a result of the callback.
Once the state is changed - the component that was using the state and the tree of the child components are rebuilt in virtual DOM.
Once the virtual DOM is ready - the diffing algorithm decides which parts of real DOM should be updated. Assuming we changed the selection - it updates 2 NumPad components - one is deselected and one is now selected.

That is nice to understand.
I added a new log written when NumPad is rendered.

As you see - NumPad is rerendered on each state change of parent component - meaning that on every click we are rendering all 10 buttons again. This is a rendering done for the virtual DOM - the component is not really updated in the real DOM, but we still invoke the whole render process. This is a lot of code running. Do we really need this? What if we have 100 buttons, 1000 buttons?

On every selection change, we have only 2 NumPad components that are actually changed - the one that was selected - it will get the selection now, and the old one that is now deselected. We don't really need to render all 10 NumPads again.

How can we know if a component should be rendered or not? Assuming that components are pure functions - we can just look at the props passed into. If they are changed - that's the sign we need to render the component. If not - we don't need to render them.

This is a place we should consider using React.memo. It does exactly what we need.

React API says:
If your function component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result.

Sounds like our case! Let's wrap our NumPad in React.memo:

Now we see that only the 2 relevant components are rendered. Great success again!

One thing that worth mentioning here - without using useCallback hook from the previous example - this optimization was not working. Because without useCallback hook new function is generated every time and is passed to all components, meaning the React.memo will detect change prop value and render the component.

If React.memo is so useful for us, why can't React just wrap all components by default?

Remember that using memo and useCallback should not be done by default by you. Check the exact reference and think of each case separately as a misunderstanding of the way they should be used can cause side effects and bugs in your code.

Hope you had fun!
Will be happy to get your feedback on my post.

Check out my previous post talking about interesting features in HTML5.

Follow me on Twitter to get my latest updates!

See you

10 superpowers HTML5 gives you (and you are not using)

Konstantin Meiklyar — Sat, 19 Oct 2019 05:14:37 +0000

The latest HTML spec has a big number of new features and the plans for future additions are constantly growing.

I have a feeling that the lack of awareness and cross-browser support are causing developers to be less curious about the updates and the new specs. But I definitely agree that overcoming the compatibility issues to use some new feature natively can be overwhelming.

In this post, I will list some nice features that may be out of your radar and can probably help you be more productive when writing your web applications. Some of them are widely supported by all browsers, some of them have very limited support.

1. details and summary tags

How many times did you create flags in your React and Angular code to keep the state of toggles, accordions, sliders in your components? Using details and summary tags you can handle this without writing a single line of javascript code.

Check this codepen for the full example

details and summary tags are supported by most major browsers excepting Edge and IE but have a polyfill.

2. Native modals

Everyone knows the headache of creating dialog and modal components that are responsive enough and flexible enough to be used across large systems. Actually we do have a native solution for this.

In this codepen you can see a simple example of how the dialog component of HTML 5.2 can be used.
Warning: the example is not including polyfills and is working only on desktop or android Chrome

dialog has some nice capabilities like backdrop pseudo-class. Check this blog post that is showing really nice example of using it.

Dialog element is supported by modern desktop and Android versions of Chrome. That's all. But you can use the polyfill that Google created to use in other browsers and prepare your code for the day it will be supported natively by all browsers.

3. calc()

calc() is a CSS way to do any math and you can replace any numeric value by using this function. Modern preprocessors have capabilities that allow using math functions but the superpower of calc() is the ability to mix units - for example percents and pixels.
calc() can be very useful in places you used javascript to calculate container height or width in a dynamic way.

If you write HTML and CSS you'll definitely need this function, don't skip learning it. Check this post for a bunch of nice examples.

4. contenteditable attrubute

contenteditable attribute turns any element to editable in a magic way. This can be very useful when creating some custom user inputs like text processors, blog engines or anything else working with the text. Check this codepen to show a basic feature of this attribute.

The big suprise - contenteditable is supported by all major browsers, even by IE 6.

5. mark tag

mark is a very simple and useful native tag. Since dev.io supports native markup I can just show it here. It just marks things.

The syntax is very simple:

mark element is supported by major browsers, IE support is starting from IE 9+.

6. @supports()

Feature support in web development is a real pain point. CSS3 gave us a lot of nice tools to work with but we can never be sure that the cool new feature we are using is natively supported by different versions of different browsers on different operations systems on different devices. @supports function was created to make things easier. Overall - CSS supports natural fallback mechanisms - if something is not recognized - it will just be ignored by the browser. I think this function can make code cleaner and make it easier to build those logical blocks.

Example of such CSS block can look like this:

It's important to say that this example is a bit utopic as @supports itself is not supported by all browsers. So, in real life our code will look this way:

@supports() is supported by the modern version of all major browsers and not supported by IE.

7. meter and progress tags

meter and progress tags are the native way to build progress bars and measurement visualizations:

Excepting the way they look, the difference between these 2 tags is only in semantics. The spec says:
The progress element represents the completion progress of a task.
The meter element represents a scalar measurement within a known range or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate.

Needless to say that there is an post doing amazing things with meter on CSS-tricks.
This tag is supported by all major browsers including IE10+ and also have a polyfil if needed.

8. Multicolumn elements

Multicolumn is a set of CSS attributes giving an easy way to split every HTML element to columns, very similar to what modern UI frameworks like Bootstrap offer.
Check this example:

Without changing any display or sizing attributes we can easily split everything by using 1 attribute. The spec has some additional nice features that are worth checking. Multicolumn is a codename for a variety of CSS-attributes and their support depends on the exact subset. Check can-i-use and query attributes you need.

9. picture tag

picture tag comes to solve the lack of ability to set different image sources and sizes for different media sources. It's a more flexible way to handle different versions of images for different resolutions. Check this example (this is a fork of original codepen by CharlesKiarie and a credit goes to him).

The image source is responsive to the media query as you can see if you will resize the screen to mobile dimensions.
picture tag is supported by all major browsers and has a polyfill for older versions of IE.

10. Web Components

Taking the whole web and mobile applications development stack - HTML and JS are parts of it that were very innovated in the last 5 years. The number and the frequency of newborn frameworks are growing. Web Components are the attempt to establish common conventions and patterns and it looks like they are here to stay, backed by top companies in the industry.
If you missed it - you should definitely check and play with them.

These were 10 HTML5 features that I found useful and worth sharing. I hope you're able to find something that was new to you and something that can be useful in your work.

You still need to remember that you'll need to use them carefully as not all of them are supported by all browsers in a native way.

Hope you had fun.
Will be happy to get your feedback.

Follow me on Twitter to get my latest updates!

Understanding Javascript Scope

Konstantin Meiklyar — Mon, 14 Oct 2019 04:38:14 +0000

In the last 4 years, I interviewed around 100 javascript developers, experienced and not, for senior and junior positions. Many of them were good at what they are doing but were still missing knowledge of some very basic concepts that the language has. I can explain this by the fact, that many developers come and stay in javascript from other languages without taking time to learn some basics.

I did this mistake by myself several times when switching between languages and frameworks. It took me almost 10 years to realize how important is to learn the basics before diving into code.

In this post, I will cover a very basic JS concept called Scope. I will try to include everything you need to know about it in 5 minutes of reading.

This is my first tech blog post ever. I hope you'll have fun reading it and will be happy for any feedback.

Compilation and interpretation

One popular mistake about Javascript is thinking of Javascript as an "Interpreted language", that is not compiled. It's not exactly working this way. Javascript is not compiled to some "byte-code" similar to other languages, but there are definitely some processes happening before the execution of the code.

Most of major javascript engines (for example V8 used by in NodeJS and Chrome browser) are using JIT (Just-in-time) compilers. This is a very interesting topic and can require an additional blog post. I recommend reading this good old thread to get some understanding of it.

This article has a good overview of the compiler/interpreter relationship in Javascript.

I also recommend reading this article explaining what V8 is and how it works.

So, for making things easier for now - let's say that when running JS code we have 2 phases - compilation phase and execution phase.

Scope basics

JS Scope is born during the compilation phase. Scope - is just something that tells the running code where to look for things. During that phase variables and functions are added to the scope for every function/block or on the global level. They still don't have any values. Values are something that comes to the scene only during the execution phase. Let's take a look on a piece of code:

Here we have 3 scopes: global scope and 2 function scopes - a scope of go and scope of go_again. Lets run this code and explore the scope using Chrome dev tools.

1) Global scope has a variable called bar and a function called go. If we will stop during the execution process on the first line we can see the scope in Sources tab in Google Chrome:

This is one more evidence that right now we are in the global scope and on the right side we have a long list of functions and variables that exist there. You can find bar variable there in the list. It's in the scope and it's still undefined.

2) Scope of go function.

Here we can see that actual scope that is different from the global scope. It has 2 declarations inside: a variable called foo and a function called go_again. We also have this inside this scope, I will ignore it for now as it's a topic for a whole separate post and I hope I will cover it there later.

The important thing here is goo variable that we see in the code but don't see in the scope of the function. The reason for that is the way it was declared. It has no initial declaration using var (or let and const that we will review later) keyword. In this case - during the compilation - it was not added to any scope.

The following will happen during the execution phase: The interpreter will look for the variable in local (function) scope - as we can see - it's not there, after that it will try to find it in parent/grandparent scope until it will get to the global scope. Global scope in default conditions will declare this variable and add it to the list of other variables declared on it.

3) Scope of go_again function

The thing worth mentioning here is that the value passed from parent function to go_again is declared in the local scope as well. Simple variables in JS are passed by value - so in this case - the local variable foo will be assigned to "xyz" while the original variable foo inside go function will keep the value of "def".

let vs. var

Since ES6 we have a new (well, not so new already) way to declare variables using let and const keywords. Declaring variables with let keyword has also effect on the scope - it creates a new type of scope - Block scope. Let's review a short piece of code using let and const in variables declaration.

As in the previous example - let's stop in debug mode during the execution and see how our scope looks like. Let's start with line #2:

We are now inside foo function and as we see inside our scope we don't have any variable excepting a and z variables. This is because rest of the variables here are declared using let keyword and exist only inside block scope of the block they appear in. Let's take a few more steps in the program and stop inside for loop:

So here, we see 3 new scopes added inside our function scopes. These are scopes of 3 blocks that we have inside our code.

One thing about the difference between var and let declarations are the way they are hoisted and initialized. You can learn more details from this post

Classic block scope problem

Since the release of ES6, there are few technical questions asked during the interviews that became classic problems related to function/block scope in JS. Let's review one of them briefly.

Having this code - what is the output of it? And how can we fix it to print the array in the right way?

So, the output of this loop will be 5 5 5 5 5. At the point where we will print the variable i that is set on the global level and not on block-level it will be changed to 5 globally.
You definetely understand at this point - that changing var count to let count inside the definition of for loop will change the scope of the variable to block level and will cause the loop to be printed in a way it was supposed to be - 0 1 2 3 4.

So, what we've learned?

Scope in JS is a place where declared variables and functions live.
The scope can be easily examined using Google Chrome dev tools.
Global variables are attached to the global scope and are accessible everywhere in the code. This is a bad practice and should be avoided, excepting some specific cases - mostly because for these variables the garbage collection is never done and can cause collisions with locally declared variables with the same names.
Variables declared as var are added to function scope and are accessible everywhere inside that function.
Variables declared as let and const are added to block scope and are accessible everywhere inside that block.

That's all for now!
Like and share if this post was useful for you.
Leave feedback if you have any.

And never lose your scope! :)