DEV Community: Victor Magarlamov

Simple card game with JS

Victor Magarlamov — Mon, 20 Jul 2020 12:24:51 +0000

Hi folks! I want to show you a game I made with React. It’s a popular russian card-game - Fool (or Durak). I created this project for fun and some practice with React and CSS. You can see the source code and result here.

And also I want to tell you how I organized a game logic and which design patterns I used in this.

Gameplay

In this game, the game process can be divided into several basic steps.

deal cards
choose the first attacker
discard a card (attack)
discard a card (defend)
take cards if you cannot beat
remove cards from the table if the attack is over

As you can see, each of these steps is an action - ‘to deal...’, ‘to choose...’, ‘to discard...’ And these actions are ordered. And the game process dependents on the result of this actions. Also some actions have options (for example, ‘discard a card’).

Command pattern

This pattern is ideal in this case. With this pattern we implement the logic of the actions in different classes, instead of different functions as usual. These classes will share the same "public" interface. As usually it is the ‘apply’ (or ‘execute’) method, which returns a result of the command.

For example:


class SetFirstAttackerCommand {
  errors = [];

  apply() {
     const attacker = this.setByTrump();

     return {
        success: this.errors.length === 0,
        attacker,       
     }
  }

  setByTrump() {
    // here the logic how to choose the first attacker by trump
  }
}

class TakeOpenedCardsCommand {
  errors = [];

  apply() {
     this.moveCardsToPlayer();

     return {
        success: this.errors.length === 0
     }
  }

  moveCardsToPlayer() {
    // here the logic how to move cards to the player’s hand
  }
}

Our next step will be creating instances of these command. Then we will call the apply method, which calls the ‘setByTrump’ и ‘moveCardsToPlayer’, which contain all main logic for our commands.

This is one of my favorite pattern)

Queue Data Structure

I used a queue (FIFO) as the command container. When a new command is added, a new queue node is created and a link to that node is stored in the current last node. Then at the beginning of each frame we check if there are any commands in the queue. If there are, we apply the first command. If its result has completed status, then this command will be removed.

Strategy pattern

This pattern is excellent for actions like ‘discard a card’, when behavior depends on some factor. In our case the factor is the player.

If the current player is an attacker, we need to check if there are open cards on the table and the like.

If the current player is a defender, the result of the command will depend on the rank of the card.

Here is an example strategy:

class DiscardCardStrategy {
  strategy = null;

  constructor(gambler) {
    this.gambler = gambler;
    this.strategy = gambler.isAttacker ? DiscardCardStrategy.AttackerStrategy : DiscardCardStrategy.DefenderStrategy;
  }

  discard(card, openedCards) {
    this.strategy({ card, openedCards });
  }

  static DefenderStrategy({ card, openedCards }) {
    // behavior logic
  }

  static AttackerStrategy({ card, openedCards }) {
    // behavior logic
  }
}

One of my favorite pattern too)

After all

You know, I had fun when I was making this game. I think it's important sometimes to do something just like that - for the soul. In my case, it reminds me why I decided to become a programmer )))

My eyes! or How to [get, avoid] Forced Synchronous Layouts

Victor Magarlamov — Mon, 15 Jun 2020 12:51:46 +0000

Manipulating the DOM in JavaScript allows us to do very interesting and impressive stuffs. This is a powerful ability, but, as you know, a powerful ability is often a double-edged sword. On the one hand we can have “Wow! Cosmically 🤩 cool!”. But on the other hand we can have “What's with the jank 🤢 on this page?!”

jank

choppy performance

discontinuos, surprising experience

Rash manipulating the DOM can lead to performance problems. One of them is layout thrashing or Forced Synchronous Layouts.

Each time we change the top, left, width, height and other geometric properties of the DOM element, the current layout becomes invalid and needs to be updated.

Typically, an update (or reflow) occurs at the end of the current frame. But we can force this process. If we ask for any geometric data, the browser will have to immediately update the layout.

There is one excellent example in the Google Web Fundamentals repository. Visit this page, follow all instructions and then analyze the performance record. You will see many purple rectangles labeled “Layout” and marked with a red triangle in the upper right corner. This mark is a warning that executed code leads to a forced reflow. And this significantly reduces FPS (the number of frames that the browser can draw in one second). In this case, we have much less than 60 frames per second, which is optimal for smooth animation.

Let's look at the code to understand how we can get the same effect.

for (var m = 0; m < movers.length; m++) {
   movers[m].style.left = ((Math.sin(movers[m].offsetTop + timestamp / 1000) + 1) * 500) + 'px';
   // movers[m].style.left = ((Math.sin(m + timestamp/1000)+1) * 500) + 'px';
}

At each iteration, we ask the offsetTop property of the movers[m] element. Due to the fact that the DOM has been changed and the layout is invalid, the browser needs to recalculate the layout in order to return the current position of the element. At each iteration! Think about it.

An another example.

const el = document.getElementById(‘element’);
const container = document.getElementById(‘container’);

if (el.offsetLeft > container.offsetWidth) {
  el.style.left = 0;
}

if (el.offsetTop > container.offsetHeight) {
  el.style.top = 0;
}

First, we request offsetWidth and get the value from the current layout. Then we change the left property and invalidate the layout. And we get Forced Synchronous Layouts when we request the offsetHeight property!

But it will be much better to get the width and height of the container in the first step, and then perform a comparison and other things.

Useful links

What forces layout / reflow by Paul Irish
Web performance for the curious by Ilya Grigorik

Using Base64 encoded image

Victor Magarlamov — Thu, 11 Jun 2020 16:31:55 +0000

The window.onload event does not occur until resources are fully loaded. And often images are the biggest part of resources.

The total resource loading time consists of:

waiting for a server response,
data loading time,
byte analysis,
byte conversion to an object.

Encoding an image in Base64 format converts binary data into ASCII string format. Loosely speaking, we can convert an image to text using this process. This allows us to inline images as text on the page and get rid of the steps: "waiting for a server response" and "data loading time".

I use this technique for small images that are used as logos, icons or background images for buttons, panels and etc.

Downsides of the inline images

Converting images to base64 results in a 30% increase in size.
Size of HTML page increases.

How to convert

The easiest way is to use online converters. For example base64-image

How to use

You can set the string as the value of the src property or as css background.

Performance measuring

Victor Magarlamov — Tue, 09 Jun 2020 19:23:25 +0000

Measure first and then optimize!
-- Golden rule

You can't optimize what you can't measure.
-- Another golden rule

There are many articles on how to improve performance in JavaScript applications. Of course, it’s good to know all these tricks and tips, but it’s much better to know what I will tell in this article 😇.

Three key performance features

Navigation speed
Resources loading speed
Code execution speed

In general, web application performance depends on these characteristics — navigation, resources, and scripting. And together they are part of the Performance Timeline. Thanks to the Performance Web API, we can easily measure and read Performance Timeline metrics. Let's do it.

Navigation Timing

function getNavigationMetric () {
  const [entry] = performance.getEntriesByType("navigation");
  console.table(entry.toJSON());
}

The getEntriesByType method returns a list of the PerfomanceEntity objects, each of which is a part of the Performance Timeline. In this case, we get an object of type “navigation”. This type will be contained in the initiatorType property of the object, which we will see in the console after calling our function in the body.onload (or in the componentDidMount life cycle method in a React app).

Other interesting properties will be: responseEnd - time of the last byte received from the navigation request (startTime) and duration - equal to the difference between responseEnd and startTime, respectively.

Resource Timing

function getResourceMetric () {
  const entries = performance.getEntriesByType("resource");
  console.log(entries);
}

When we call this function in body.onload, we get PerfomanceEntity for all the resources that the page loads. If we filter these entries by initiatorType, we get metrics for images (initiatorType === “img”), scripts (initiatorType === “script”), etc.

User Timing

function getUserMetric () {
  performance.mark("do_something_start_mark");
  doSomething();
  performance.mark("do_something_end_mark");

  performance.measure("measure", "do_something_start_mark", "do_something_end_mark");

  const entries = performance.getEntriesByType("measure");
  console.log(entries);
}

In this case, we get the timeline metric from startMark to the endMark label. By the way, it’s good practice to delete the used metric using the performance.clearMeasures method.

PerfomanceObserver

Well, we have metrics, and now we can send them to the server for analysis. The best way to do this is to use the Performance Observer API.

const observer = new PerformanceObserver(list => {
  const res = list.getEntries().map(entry => ({
    name: entry.name,
    type: entry.entryType,
    start: entry.startTime,
    duration: entry.duration,
  }));

  sendMetrics(res);
});

observer.observe({entryTypes: ['resource', 'navigation', 'measure']});

More about the Perfomance Timeline API

Infinite Scrolling with IntersectionObserver

Victor Magarlamov — Sun, 07 Jun 2020 17:22:44 +0000

Infinite Scrolling is one of the technique that is used to automatically load more content when the user scrolls down the page.

The idea of the solution that I will show you in this article is quite simple. We will add an anchor to the end of the list. It can be an animated preloader, or label, or just an empty div. When the feed scrolls down, the anchor will rise. When the anchor crosses the lower boundary of the feed, we will show new data, and the anchor will lower again.

Let’s write a simple Feed component.

class NewsFeed extends Component {
  static perPage = 50;

  allNews = [];

  state = {
    page: 0,
  };

  componentDidMount() {
    fetchNews().then(res => this.allNews = res);
  }

  getVisibleNews() {
    return this.allNews.slice(0, this.state.page * NewsFeed.perPage);
  }

  render() {
    return (
      <div className=”feed”>
        {this.getVisibleItems().map(item => (
          <FeedItem key={item.id} item={item} />
        ))}
        <div>Loading</div>
      </div>
    );
  }
}

When we do this, we will see a “Loading“ label. Then the data will be downloaded and... And nothing will change. The page will only have a “Loading” label.

When does re-rendering happen in a React app? When the state has been changed. When the props have been changed. When the parent has changed. In our case none of this happened. The allNews property was changed only.

Well, it’s time to add some logic to check the position of the loader. To do this, I will add an observer to the component.

Observer is a behavior pattern, which allows us to receive notifications when a target changes. The Web APIs has the Intersection Observer API that allows us to observe how the target intersects with the parent element.

One important nuance! To asynchronously observe and it is the crucial difference between regular Event and Observer.

To add an observer to asynchronously observe the intersection of the Loader with the Feed element, we need to create an instance of IntersectionObserver. There are two parameters which we must pass to the IntersectionObserver constructor: a callback that will be fired when the intersection occurs and a config - an object with the following properties: root - the ancestor element (by default, this is a browser viewer), rootMargin - it is like the margins in CSS, threshold - a single number or an array of values which allow us to customize callback execution moments.

initIntersectionObserver() {
  const config = {
    root: document.querySelector(‘.feed’),
    rootMargin: ‘0px’,
    threshold: 0,
  };

  let observer = new IntersectionObserver(entries => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        this.setState(prevState => ({
          page: prevState.page + 1
        }));
      } 
    });
  }, config);

  observer.observe(document.querySelector(‘.loader’));
}

Let's call this function when the data is loaded.

componentDidMount() {
  fetchNews().then(res => {
    this.allNews = res;
    this.initIntersectionObserver();
  });
}

As soon as we set the target element for observation using observer.observe, the callback will be executed for the first time. At the moment, the preloader is inside the Feed element. They intersect and the entries will be contain an entry with the isIntersecting property equal to ‘true’. The state will be updated and we will see the news. When the anchor goes down the border of the Feed element, we get an object with the isIntersecting property equal to false.

When the user scrolls the news and the loader will be in the viewing area... You know what will happen next 🔥

More about the Intersection Observer API...

Caching with [Web Storage, Fetch, Redis, Nginx]

Victor Magarlamov — Fri, 05 Jun 2020 18:47:38 +0000

One of the main goals of caching is to eliminate the need to send requests in many cases. If the request just gives us a resource without any side effects (like many get requests), nothing prevents us from using the previous response.

Proper caching settings can improve performance of your project, make your project faster for user. On the other hand, neglecting caching can bury your project. Speed matters. Nobody likes to wait for the data to finally load and the site will finally come to life.

Caching with Web Storage API

Caching data in localStorage allows us to skip repeated requests to the server. In fact, I'm not a fan of this technique. This method has some disadvantages. For example, data stored in localStorage has no expiration time. But this is one of the easiest ways to cache. And this is a good solution if you do not have access to the server.

Let’s create a simple Redux middleware that will be to cache some data in a React app.

import { FETCH_ARTICLES_SUCCESS } from '../actions';

const isCached = actionType => {
  return [ FETCH_ARTICLES_SUCCESS ].includes(actionType);
};

const setToCache = action => {
  window.localStorage.setItem(
    action.key,
    JSON.stringify(action.data)
  );
};

export const getFromCache = key => {
  const data = window.localStorage.getItem(key);

  if (!data) {
    return null;
  }

  return JSON.parse(data);
};

export const conservator = store => next => action => {
  if (isCached(action.type)) {
    setToCache(action);
  }

  next(action);
};

Now we need to connect our conservative...

import { conservator } from './middleware/conservator';

const middleware = [thunk, conservator];

const store = createStore(
  rootReducer,
  initialState,
  compose(applyMiddleware(...middleware))
);

And add changes to the Article actions.

import { getFromCache } from '../middleware/conservator';
import { FETCH_ARTICLES_SUCCESS } from './';

const CACHE_KEY = ‘articles’;

const fetchArticlesSuccess = articles => ({
  type: FETCH_ARTICLES_SUCCESS,
  key: CACHE_KEY,
  articles,
});

export const fetchArticles = () => {
  return (dispatch) => {
    const cachedData = getFromCache(CACHE_KEY);

    if (cachedData) {
      dispatch(fetchArticlesSuccess(cachedData));
    } else {
      ArticleApi.index().then(res => {
        dispatch(fetchArticlesSuccess(res));
      });
    }
  };
};

The idea behind this solution is pretty simple. When we first get a response from the server, the data will be cached in localStorage on the way to the Redux store. Before sending a request to the server, we check the data in localStorage by key. If there is, we return data from the cache. If there isn't, we send the the request to the server.

Сaching with Fetch API

By default, fetch uses standard HTTP caching, which is controlled using HTTP headers. We can set these headers with the cache parameter in the query request options. For example:

fetch(url, { cache: ‘no-cache’ });

You can see the full list of available values in the fetch specification. I will not describe all of them, I will focus only on some interesting points.

The Cache-Control header allows us to specify how and for how long the request should be cached. When this header is Cache-Control: private it means that the resource should be cached in the browser only. This cache is used when the user clicks the back button in the browser.

An alternative to this value is Cache-Control: public. It allows you to cache the resource for many users by any intermediate cache.

We can also set cache expiration time with Cache-Control: max-age. For example Cache-Control: max-age=3600 makes you cache valid for one hour.

Another very important header is E-Tag.
E-Tag (entity tag) - is the ID of the version of the resource. You can think of this identifier as a checksum (or “fingerprint”). Let’s see how it works.

The server sends a response with E-Tag header, which contains some value, say, “ver1”.
When the browser again requests this resource, the request will contain in the header If-None-Match: ver1. This header makes the request conditional. If there is no resource that corresponds to version “ver1”, the response will contain new data and has a status of 200. If there is, it will be a very short response with status of 304 (Not Modified).

There is a method in RubyOnRails, that allows us to set the E-Tag manually.

def show
  @article = Article.find(params[:id])

  if stale?(etag: @article, last_modified: @article.updated_at)
    render json: @article
  end
end

Caching with Redis

Pay attention to one point in the previous example. To understand what status we should respond with, we need to get the resource from the database first. When there are many requests at the same time, this can be a problem. At best, users will have to wait a bit.

But we can reduce the cost of reading from database with an in-memory data structure store. I prefer to use Redis as such a store. Let’s modify the previous example.

@article = Rails.cache.fetch(“{cache_key_with_version}”, expires_in: 12.hours) do
   Article.find(params[:id])
end

cache_key_with_version generates a string based on the model's class name, id, and updated_at attributes. As you can see, this cache will be valid for 12 hours from the moment of the first request. All this time the resource will be received without reading from the database.

I often see that this method is used to cache the results of several database queries in one object. For example, we can cache summary information about a user in a profile object. It will contain not only basic information about the user, but also the number of friends, the number of posts, balance, etc., which will be requested from several tables.

In my opinion this practice is bad. Especially if some data that will be included in a single object can be updated frequently. You will be forced to reduce the resource caching time, and you can significantly increase the resource cache formation time.

I prefer to normalize my cache according to the first normal form. Each cache entry is a separate entity. This gives me the ability to manage the cache more flexibly.

In a word, mindless caching can have a completely different effect than you expected.

Caching with Nginx

And finally, I'll tell you how to configure caching in Nginx. With a heavy load on the site, this can give an incredible result, you can reduce the load many times even when resource is cached for a short time.

Here is an example of Nginx config.

proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
…

location /api/v1/articles {
  # activate the my_cache caching zone            
  proxy_cache my_cache;
  # cache requests with these codes for 5 minutes
  proxy_cache_valid 200 301 302 304 5m;
  # set a caching key
  proxy_cache_key $scheme$proxy_host$uri$is_args$args;
  # ignore backend headers
  proxy_ignore_headers "Cache-Control" "Expires";
  # protection against identical cookies in a cached response
  proxy_hide_header "Set-Cookie";
}

In this case, we will receive an answer without request to web servers and databases. Instantly 🧚‍♀️

ES modules

Victor Magarlamov — Tue, 02 Jun 2020 17:17:32 +0000

The best definition I've ever seen about ES modules is: "modules allow us to import and export stuff". Exactly! We use modules for import/export components, classes, help methods, variables and other stuff. They help us to organize our code.

In fact Module is one of the popular design pattern that allows encapsulate the code. Let's look at the implementation of this pattern.

const Module = (function () {
  let _privateVariable;
  let publicVariable;

  function _privateMethod () {}
  function publicMethod () {}

  return {
    publicVariable,
    publicMethod,
  };
})();

We have there an anonymous closure that creates an enclosed scope with private and public methods / variables and a singleton object that get us an access to the public properties of the module.

Now let’s look at ES modules. Imagine, we have some modules...

// module A
console.log(‘a’)

// module B
console.log(‘b’)

// module C
console.log(‘c’)

Modules first!

When we import these modules into a file and execute it, the modules will be invoked first.

import * as a from ‘./a.js’
import * as b from ‘./b.js’
import * as c from ‘./c.js’

console.log(‘index’);

Output:

a
b
c
index

Modules are evaluated only once!

The module will be evaluated only once and it does not matter how many files are module dependent.

// module A
import * as c from ‘./c.js’
console.log(‘a’)

// module B
import * as c from ‘./c.js’
console.log(‘b’)

import * as a from ‘./a.js’
import * as b from ‘./b.js’

console.log(index);

Output:

c
a
b
index

It works thanks to Module Map. When a module is imported, a module record is created and placed in the Module Map. When another module try to import this module, the module loader will look up in the Module Map first. Thus we can have a single instance of each module.

Another demonstration of this idea.

// module A
import * as b from ‘./b.js’
console.log(‘a’)

// module B
import * as a from ‘./a.js’
console.log(‘b’)

import * as a from ‘./a.js’
import * as b from ‘./b.js’

console.log(index);

Output:

b
a
index

The module loading process takes several steps:

Parsing - if there are any errors in your module, you will know about it first
Loading - if there are any imports in your module, they will be recursively imported (and the module graph will be built).
Linking - creating a module scope
Run time - running a module body

So, let’s look at our previous example step by step.

-> import * as a from './a.js'
   |-> creating a module record for file './a.js' into the Module map
   |-> parsing
   |-> loading - import * as b from './b.js'
       |-> creating a module record for file './b.js' into the Module map
       |-> parsing
       |-> loading -> import * as a from './a.js'
           |-> a module record for file './a.js' already exist in the Module Map
       |-> linked
       |-> run
   |-> linked                                           
   |-> run

This case is an example of the circular module dependency. And if we try to call some variable from the A module in the B module, we will get a Reference Error in this case.

Module properties are exported by reference!

Let’s add a public variable into the A module.

// module A
export let value = 1;
export function setValue(val) {
  value = val;
}

Now let’s import the A module into the B module...

// module B
import * as a from ‘./a.js’
a.setValue(2);

...and look at the value from the C module.

// module C
import * as a from ‘./a.js’
console.log(a.value);

Output will be '2'. Pay attention to one remarkable feature of the module - we cannot directly change the value property in module B. The 'value' property is read-only, and we get a TypeError.

Play with Puppeteer: a simple SEO Spider

Victor Magarlamov — Sat, 30 May 2020 15:12:07 +0000

I will not tell you about Puppeteer. This great library needs no introduction. So without further ado, let's play with it! Create a new node.js project and edit package.json file:

"main": "src/index.js",
"type": "module",
"scripts": {
  "start": "node ."
}

Due to the fact that I will use ES6 modules I set the type parameter as "module". Notice that this works in Node 13 and above.

yarn add puppetter

Well, the goal of our application will be to visit a page and check it with some SEO rules.

SEO rules are secondary in this article. First of all, I want to show how to work with Puppeteer, parse the content of the page, and also want to give an example of working with Command pattern.

We will start by creating a class where the logic for visiting the page will be.

import puppeteer from 'puppeteer';

export default class Spider {
  browser = null;

  asyns launch() {
    this.browser = await puppeteer.launch();
  }

  async visit(url) {    
    const page = await this.browser.newPage();
    await page.goto(url);

    const content = await page.content();  
  }

  async close() {
    await this.browser.close();
  }
}

Now we can visit to a site by its url and get its content. Content as a string. Now we can parse this string with a regular expression to check, for example, the length of the description meta tag. But I'm not very good at regexp 🤯

There is one great library that allows you to convert a string to a jsdom object. Let's add it in our project

yarn add jsdom

and edit the Spider class:

import puppeteer from 'puppeteer';
import jsdom from 'jsdom';

const { JSDOM } = jsdom;
...
  const content = await page.content(); 
  return new JSDOM(content);
}
...

Now we can work with the content of the page using the querySelector and other similar methods. Let's do it and write a new class for validation the page content. Or more precisely, we will create classes - one class for one validation rule.

export default class CheckTitleCommand {
  value = null;
  errors = [];

  constructor(document) {
    this.value = document.title;
  }

  execute() {
    if (!this.value || this.value.length === 0) {
      this.errors.push('The page title is empty');
    } else if (this.value.length > 50) {
      this.errors.push('The page title is too long');
    }   
  }

  getResult() {
    if (this.errors.length > 0) {
      return {isValid: false, message: this.errors.toString()};
    }

    return {isValid: true, message: 'Title is OK'};
  }
}

We encapsulate the logic of a validation rule in an object - Command pattern in Action. An another command.

export default class CheckDescriptionCommand {
  value = null;
  errors = [];

  constructor(document) {
    this.value = document.head.querySelector('meta[name=description]');
  }

  execute() {
    if (!this.value || this.value.length === 0) {
      this.errors.push('The page description is empty');
    }
  }

  getResult() {
    if (this.errors.length > 0) {
      return {isValid: false, message: this.errors.toString()};
    }

    return {isValid: true, message: 'Meta description is OK'};
  }
}

All commands have a common interface. Let's see how to work with it.

import CheckTitleCommand from './commands/CheckTitleCommand.js';
import CheckDescriptionCommand from './commands/CheckDescriptionCommand.js';

export default class Validator {
  document = null;

  constructor(dom) {
    this.document = dom.window.document;
  }

  validate() {
    [
      new CheckTitleCommand(this.document),
      new CheckDescriptionCommand(this.document),
    ].forEach(command => {
       command.execute();
       console.log(command.getResult().message);
    });
  }
}

Let's put it all together and see what it will come to.

import Spider from './Spider.js';
import Validator from './Validator.js';

(async () => {
  const spider = new Spider();
  await spider.launch();

  const dom = await spider.visit('http://wwwwwwww.jodi.org');
  const validator = new Validator(dom);
  validator.validate();

  spider.close();
})();

Monorepo App with Lerna

Victor Magarlamov — Fri, 29 May 2020 16:59:16 +0000

Monorepo is a way to organize an application. In this case, the application is divided into several parts, each of which is a separate package. For example, look at the React repository. You will see that the main parts of this library are separate packages: "react-reconciler", "react-dom"… In other word, monorepo is a multi-package repository.

What are the advantages of this way? In a nutshell, separation into logical parts facilitates versioned, testing and understanding of the overall project. But better than any words is practical experience.

Many years ago I made a personal website for the russian artist Gregory Maiofis. It was a monolithic Ruby On Rails application. Recently I decided to rewrite this as a single-page and monorepo application. You can see the result on github.

In this work I used Lerna and below I want to tell you (in short) how to use this multi-package application management tool.

The first command is lerna init. It creates a new lerna repo. Open the lerna.json file after executing this and add the following lines:

"useWorkspaces": true, 
"command": {
  "run": {
    "npmClient": "yarn"
  }
}

And add to the package.json file:

"workspaces": {
  "packages": [
    "packages/*"
  ]
}

These changes allow us to use yarn workspaces.

I organized my project in the following manner:

packages
  |---app   // main application with CRA
  |---admin // Admin Panel
  |---ui    // a library of common React components
  |---api   // a library for working with API

The main commands:

// bootstrap the packages in the current Lerna repo
lerna bootstrap

// Symlink together all packages
lerna link

// execute the "start" command in all packages 
// that contains this command
// in my case it will be "app" and "admin"
lerna run start

// execute the build command in the "ui" package only
lerna run --scope @project/ui build

More about working with Lerna - https://dev.to/shnydercom/monorepos-lerna-typescript-cra-and-storybook-combined-4hli
More about workspaces - https://www.smashingmagazine.com/2019/07/yarn-workspaces-organize-project-codebase-pro/
More about Lerna - https://github.com/lerna/lerna

Authentication in React App with Context

Victor Magarlamov — Wed, 27 May 2020 19:13:05 +0000

To be honest I avoided using Context for a long time. I easily began to use hooks, but I did not immediately understand Сontext. In this article I will show you one way to use Context.

const App = () => {
  <Switch>
    <Route path=”/profile” component={ProfilePage} />
    <Route path=”/login” component={LoginPage} />
    <Redirect to=”/login” />
  </Switch>
};

Let's restrict access to the ProfilePage - only authenticated users can access this page. If the user is a guest, we redirect him to the login page.

const LoginPage = () => {
  const [redirectTo, setRedirectTo] = useState(null);

  const submitHandler = e => {
    e.preventDefault();

    const formData = new FormData(e.target);

    authenticate(formData).then(user => {
      if (user.authenticated) {
        this.setState({ redirectTo: ‘/profile’ });
      }
    });
  }

  if (redirectTo) {
    return (
      <Redirect to={redirectTo} />
    );
  }

  return (
     <Form omSubmit={submitHandler}>
       <Form.Input required type=”email” name=”email” label=”Email” />
       <Form.Input required type=”password” name=”password” label=”Password” />
       <Form.Button type=”submit” />
     </Form>
  );
};

The authenticate method sends user credentials to the API. When we get a response, we redirect the user to the ProfilePage. All is well, except for one trifle - everyone can access to the ProfilePage without authentication. To fix this, we need a flag - a global variable - to indicate whether the user is authenticated or not. Let's create Context that allows us to send a flag to components.

import React, { useState } from ‘react’;

export const AuthContext = React.createContext();

export const AuthProvider = ({ children }) => {
  const [authenticated, setAuthenticated] = useState(false);

  return (
    <AuthContext.Provider value={{authenticated, setAuthenticated}}>
      {children}
    </AuthContext.Provider>
  );
};

export const AuthConsumer = AuthContext.Consumer;

Go to the App.js file and wrap the Switch into the AuthProvider. AuthContext.Provider allows us to pass the context value - the authenticated flag and the setAuthenticated method - to all child components.

import { AuthProvider } from ‘./authContext’;

const App = () => {
  <AuthProvider>
    <Switch>
      <Route path=”/profile” component={ProfilePage} />
      <Route path=”/login” component={LoginPage} />
      <Redirect to=”/login” />
    </Switch>
  <AuthProvider>
};

And make changes to the LoginPage.

import React, { useState, useContext } from ‘react’;
import { AuthContext } from ‘./authContext’;

const LoginPage = () => {
  const context = useContext(AuthContext);
  const [redirectTo, setRedirectTo] = useState(null);

  const submitHandler = e => {
    e.preventDefault();

    const formData = new FormData(e.target);

    authenticate(formData).then(user => {
      context.setAuthenticated(true);

Now we just have to subscribe to the changes and send off a guest.

import { AuthConsumer } from ‘./authContext’;

const ProtectedRoute = ({ component: Component, ...rest }) => (
  <Route {...rest} render={matchProps => (
    <AuthConsumer>
      {value => (
         <Fragment>
           {value.authenticated || (
             <Redirect to=”/login” />
           )}
           <Component {...matchProps} />
         </Fragment>
      )}
    </AuthConsumer>
 )} />
);

Consumer is a React component, that subscribes to Context changes. It takes the function as a child and passes the current Context value to it.
Finishing touch.

import { AuthProvider } from ‘./authContext’;
import { ProtectedRoute } from’./ProtectedRoute’;

const App = () => {
  <AuthProvider>
    <Switch>
      <ProtectedRoute path=”/profile” component={ProfilePage} />
      <Route path=”/login” component={LoginPage} />
      <Redirect to=”/login” />
    </Switch>
  <AuthProvider>
};

Testing a request with Cypress

Victor Magarlamov — Tue, 26 May 2020 18:58:59 +0000

Well, we need to test API. With Cypress we can do it easily. But before we start we need to dance.

Dance with a tambourine

There is one flaw in Cypress. Cypress can track XMLHttpRequests only. Requests with fetch type are invisible to Cypress. We cannot intercept or stub them. But there are some recipes how to solve this small flaw. Let's use one of them - "removes window.fetch method and replaces it with a polyfill based on XMLHttpRequest". Go to the cypress/support directory and download the polifil. Now create a "hooks.js" file.

enableFetchWorkaround();

function enableFetchWorkaround() {
  let polyfill;

  before(() => {
    cy.readFile("./cypress/support/unfetch.umd.js").then(content => {
      polyfill = content;
    })
  });

  Cypress.on("window:before:load", win => {
    delete win.fetch;
    win.eval(polyfill);
    win.fetch = win.unfetch;
  });
}

And add import "./hooks" to the index.js file.

Requests Testing

In order to test a request, we need to send the one

cy.request("/posts").as("postsFetch");

or we need to wait until the request is sent.

cy.route({method: "GET", url: "/posts"}).as("postsFetch");

cy.visit("/posts");

cy.wait("@postsFetch")

Time to test what we have.

it("has the right status code", () => {
  cy.get("@postsFetch")
    .its("status")
    .should("equal", 200);
});

it("has the right content-type", () => {
  cy.get("@postsFetch")
    .its("headers")
    .its("content-type")
    .should("include", "application/json");
});

it("has the right number of items", () => {
  cy.get("@postsFetch")
    .its("responseBody")
    .should("have.length", 20);
});

it("has the right item structure", () => {
  cy.get("@postsFetch")
    .its("responseBody")
    .each(item => {
      expect(item).to.have.all.keys("id", "title", "createdAt");    
    });
});

A Linked List with Map, Filter and Reduce methods

Victor Magarlamov — Sat, 23 May 2020 16:45:54 +0000

In this article I will implement a simple Linked List with support of the map, filter and reduce methods. If you are new to JavaScript, I hope this helps you better understand these methods. I will also tell you some basic JavaScript stuff.

A Linked List

A Linked List is a data structure that consists of nodes. Each of the nodes contains a value and two references to the previous and next nodes.

function Node (value, prev) {
  this.value = value;
  this.prev = prev;
  this.next = null;
}

Here we declared a function with a function declaration statement. The name of the function with the first capital letter is the convention for the object constructor.

When we call this function with the new keyword, will happen next steps:

this = {}; // a new object will be created
this.value = value; // properties were be added to the object
return this; // the object will be returned

Now let's write a Linked List function.

function List () {
  this.root = null;

  this.add = function (value) {
    const lastNode = this.getLastNode();
    const newNode = new Node(value, lastNode);

    if (!lastNode) {
      this.root = newNode;
    } else {
      lastNode.next = newNode;
    }

    return newNode;
  }
}

The logic of adding a new node is implemented in an anonymous function, which is created during the assignment expression. A function expression in action)

Ok, it's time to add the node to the list.

const list = new List();
list.add(1);
list.add(2);
list.add(3);

But we got an error with the type "TypeError" and with the message "this.findLast is not a function". Let's fix it. To add a new property to a object constructor, we need to edit its body or edit its prototype object.

List.prototype.findLast = function() {
  let cursor = this.root;

  while (cursor && cursor.next) {
    cursor = cursor.next;    
  }

  return cursor;
}

When we call the property of an object, it is first searched in the same object. In our case we get this:

Object.getOwnPropertyNames(list); // ["root", "add"]

If there is no property, the search will continue in the prototype.

сonst proto = Object.getPrototypeOf(list);
Object.getOwnPropertyNames(proto); // ["constructor", "findLast"]

Let's see what happens when the property is found in the prototype.

List.prototype.name = "name";
console.log(list.name); // name

Object.getOwnPropertyNames(list); // ["root", "add"]
Object.getOwnPropertyNames(proto); // ["constructor", "findLast", "name"]

list.name = "new name";

Object.getOwnPropertyNames(list); // ["root", "add", "name"]
Object.getOwnPropertyNames(proto); // ["constructor", "findLast", "name"]

console.log(list.name); // new name
console.log(proto.name); // name

Easy) But when a method of the prototype is called, it doesn't copied to the object. This works due to the this property refers to the object that calls the method, but not to the prototype.

Map, Filter, Reduce

Each of these methods is a Higher Order Function. In other words, a function that takes functions in parameters. We can do this because a function is actually an object in JavaScript (or a first-class citizen).

In an array the map method creates a new array populated with the results of calling a provided function on every element in the calling array.

List.prototype.map = function(fn) {
  const res = new List();

  let cursor = this.root;
  while (cursor) {
    res.add(fn(cursor.value));
    cursor = cursor.next;
  }

  return res;
}

const res = list.map(i => i * 2);

Well, there is one thing that I don't like in our map function. That is how we iterate over list nodes. Let's make our list a truly repeatable object. We need to add a method with name [Symbol.iterator]. This method should return an iterator - an object with the next method.

function List() {
  this.root = null;

  this.add = function (value) {
    ...
  }

  this[Symbol.iterator] = function () {
    let current = this.root;

    return {
      next: function () {
        if (current) {
          res = { value: current.value, done: false};
          current = current.next;
        } else {
          res = {done: true};
        }

        return res;
      }
    }
  }  
}

The filter method creates a new array with all elements that pass the test implemented by the provided function.

List.prototype.filter = function(fn) {
  const res = new List();

  for (let node of this) {
    if (fn(node)) {
      res.add(node);
    }    
  }

  return res;
}

const res = list.filter(i => i >= 2);

The reduce method executes a reducer function on each element of the array, resulting in single output value.

List.prototype.reduce = function(fn, acc) {
  for (let i of this) {
    acc = fn(acc, i);
  }

  return acc;
}

const res = list.reduce((acc, i) => {
  acc += i;
  return acc;
}, 0);