DEV Community: Erick Sosa Garcia

values and references in javascript

Erick Sosa Garcia — Sat, 07 Nov 2020 17:40:40 +0000

a very important concept that every javascript developer should know is values and value references, If you are a javascript developer, here is this question for you: If I declare a variable named name1 and assign the value jhon and then create another variable with name name2 and assign it the value of name1, is a link created between these two variables? Or what happens if I then change the value of name1, will it affect name2?
example

let name1 = "jhon";
let name2 = name1; // "jhon"
let name1 = "jhon doe";
name2 // ??

the first thing where we must start knowing the two groups in which we can divide the data in javascript: primitive values and objects.

within the primitive values we have:

string: to represent text strings

const dog = "woff";

number: to represent both integer values as well as decimal or floating point values and other data that are considered of type number.

const intValue = 10;
const floatValue = 3.14;
// others that are evaluated as type number
NaN
Infinity+, Infinity-

booleans: this represent two value true or false

const on = true;
const off = false;

null: is used to represent that a variable is empty or has no value.

const myNull = null;

undefined: undefined is a special data that represents a non-existent data, and it is the value that is assigned to a variable when we define it and we do not add a value to it and it is also the data that returns a function that does not return anything.

let name;

name // undefined

symbol: symbols allow us to create unique, immutable and unrepeatable values.

const symb1 = Symbol("foo");
const symb2 = Symbol("foo");

symb1 === symb2 // false

bigInt: and in the latest versions of the language, the bigInt data type is incorporated to represent integer values as large as we want.

const big = 10n;
const normal = 10;

big === normal // false

within the object values we have:

literal object: this represents a data set in key and value.

const car = {
 color: "red",
 model: "tesla",
 year: 2020
}

arrays: These represent a set of data organized according to its position

const arr = [true, 10, "hello", [], { name: "jhon" }];

arr[0] // true

functions: functions in javascript are objects, but note that when using the typeof operator it will return Function as the data type

const myFun = () => true;

function App() {
  return true;
}

typeof App // "Function"

Having said all this I think we can start

When we work with primitive data and assign it from one variable to another javascript makes a copy of this.

let foo = 10;

let bar = foo;

foo = 20;

bar // 10

Even if we change the value of foo, the variable bar will still have the value 10, since it does not even know that the variable foo was changed in value.

but with non-primitive data javascript behaves in a different way. with non-primitive data javascript instead of making a copy of the data as it happens with the primitive data, javascript passes a reference of this.

let person1 = { name: "john" };

let person2 = person1;

person2.name = "carl";

person1.name // carl

in this case javascript passes a reference which points to the memory space in which the data is stored (as if it were a pointer) so if the value of person1 is modified it will be reflected in person2 and in the same way if person2 Modify the data of the object this will also be reflected in person1 since both variables are pointing to the same reference of the data.

so when we are working with primitive data and objects in javascript we must take into account the aforementioned, this will help to better understand how javascript works and helps us find bugs and errors more quickly.

Rethinking the way we handle dependency imports in deno

Erick Sosa Garcia — Mon, 17 Aug 2020 05:20:58 +0000

I've been using deno for a while and I must say I love it, using typescript without compiling it first, using import / export instead of require and the other facilities that deno allows, I love it.

One of the main premises is the non-use of a package manager, since as in a browser you can import locally or from a url, this is a total paradigm shift with respect to nodejs, This has its advantages, since packages and dependencies can be imported literally from anywhere, which fulfills the role of decentralizing the location of the dependencies, now here I want to share some of the disadvantages that the use of urls entails.

using packages in deno is very simple, just import the library or package.


import {/* ... */} from "https://deno.land/std@0.65.0/fs/mod.ts";

So far so good, but let's say that now we have 50 files that import from the fs package, here it becomes a bit complicated since if we want to update to another version of the package we would have to go to each of the 50 files to change the url. a solution for this that deno offers is to use import maps, which is a way of giving name aliases to urls in order to shorten and reuse the package.

then it would look like this.

import_map.json

{
  "imports": {
    "fs/": "https://deno.land/std@0.65.0/fs/"
  }
}

example file


import {/* ... */} from "fs/mod.ts";

much better now, we can use the packages in all the files we want and we just have to update them in one place in the import_map.json. actually create a command line tool for deno that wraps all this functionality and creates an experience similar to npm when searching and installing packages (Trex).

But with import maps there are some disadvantages, they cannot be used in packages that are distributed, and also they are still under the unstable flag since as it is not yet a web standard there is much doubt if it deno will continue to support import maps.

Another solution that they recommend and I think is the most used is to use a single deps.ts file where all the imports are and from this import everything.

then it would be something like this.

deps.ts

export * from "https://deno.land/std@0.65.0/fs/mod.ts";

example file


import {/* ... */} from "./deps.ts";

here comes the problems of using deps.ts, I have these two imports.


import { Application } from "./deps.ts";


import { Application } from "./deps.ts";

they look exactly the same, let's look at the deps.ts file

export * from "https://deno.land/x/abc@v1.0.3/mod.ts";

export * from "https://deno.land/x/oak@v6.0.1/mod.ts";

oak and abc have some methods and functions with the same names,
this can be fixed as follows.

export * as abc from "https://deno.land/x/abc@v1.0.3/mod.ts";

export * as oak from "https://deno.land/x/oak@v6.0.1/mod.ts";


import { oak } from "./deps.ts";

oak.Application;


import { abc } from "./deps.ts";

abc.Application;

but with this we lose explicitness, since everything is imported from a single deps.ts file, reading and having a clear idea of what is being imported and what package it is becomes more confusing.

A solution

As the future of using import maps is not clear within deno and that it has some shortcomings, we created a version of Trex which does not use import maps as the central axis. This version focuses on being as explicit and readable as possible when importing.

It works in the following way.

install a package

trex install --map fs@0.65.0

this creates the following structure.

imports/
 |- fs.ts
 |- deps.json

where for each installed package a file with the same name is created that exports the complete package.

fs.ts

export * from "https://deno.land/std@0.65.0/fs/mod.ts"

the deps.json file is generated for Trex interoperability,
to import it would be as follows.


import {/* ... */} from "./imports/fs.ts";
                          ^^^^^^^^^^^^^^^

This makes it more explicit from where we are importing and helps when reading the code, of course it adds a file for each package but if you don't want to upload this to the repository you just have to add this to the .gitignore

imports/*.ts

you only have to preserve the deps.json file and when the project is downloaded do a trex install and this will download and generate the files again.

The advantage of using imports in this way is that it is more explicit, easier to read and can be used by libraries instead of using import maps or deps.ts. For now this version is not available yet, but we already have all the functionalities adapted to this system and we hope to launch it soon.

If you have any opinion or comment I will gladly listen 😊

why deno want remove typescript from your internal code?

Erick Sosa Garcia — Thu, 16 Jul 2020 22:25:37 +0000

after it was announced that typing will be removed from the deno kernel, many thought it meant that deno no longer natively executed typescript. In this post I'm going to try to explain what it means to remove typescript from the deno core.

first of all, take it easy! deno will continue to support typescript.

this is ryan's reply in an issue on github

"" I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - very little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions. ""

the problems

one of the problems that drives to remove the internal typescript is the compilation time of the cjs/js files.
explain the following:

incremental compile time when changing files in cli/js takes minutes. This is crushingly slow and painful to modify.

performance issues:

The typescript organization/structure that we're using in cli/js is creating runtime performance problems. As an example, we recently realized that we're unable to to get TS to generate a class with the name "Header" because it shadows the declaration in our d.ts file. So instead we name the class "HeaderImpl" and assign it to "window.Header". But that creates the problem that "Header.name" has the wrong value. So we're forced to add unnecessary runtime code

Object.defineProperty(HeaderImpl, "name", { value: "Header" });

to fix "Header.name". Who knows if this kicks Header out of some optimization path in V8. The optimal thing is to generate "class Header { ... }" anything less suggests a fundamental flaw in the design.
TypeScript is supposed to be helping us organize code, but one could claim it has the opposite effect. For example, we have two independent Body classes https://github.com/denoland/deno/issues/4748. This is difficult to have visibility into because of the complexity involved with generating the runtime code.
Ideally we would have a system where two Body classes would be obviously wrong.

Our internal code and runtime TS declarations must already be manually kept in sync. TSC isn't helping us to generate the d.ts files - it was too much overhead and complexity when we attempted it before.

We have two independent TS compiler hosts: one for the internal Deno code in //deno_typescript/compiler_main.js and another other for external user code in cli/js/compiler/. These two hosts have similar goals - they seek to modify TSC to operate on Deno-style imports (e.g. with file extensions). The //deno_typescript is used at build-time while the cli/js/compiler/ is used at runtime.

solution

this is the solution proposed by the deno team:

A radical solution is to remove all build-time TS type checking and bundling for internal code. We would move ALL runtime code into a single big file cli/rt.js. This file would be dropped directly into V8 at build-time to create the snapshot. The corresponding cli/rt.d.ts would contain the type definitions and documentation.

In this setup it will be possible to write code like class Header { } and clearly understand what is provided and executed in the runtime.

At first glance the idea of having a 10k line javascript file sounds unappealing. But I think compared to the current system, this will allow new contributors to quickly understand how Deno bootstraps itself.

Build-time complexity and performance is obviously better with this setup. Of course we will still need to do a snapshot, but we will not have to build a special TSIsolate to first execute tsc.

Runtime complexity and performance is strictly better with this setup. It will be very clear if we have multiple definitions of a class. We will be able to see all code that is being executed clearly. We will be able to analyze and step through the code during debugging without worrying about additional source map complexity.

It's important to explicitly note that Deno user code will still be in typescript and type checked. We will have tests to make sure the code works as intended against cli/rt.d.ts

The compiler worker will need its own separate cli/compiler.js file. It does not need a corresponding d.ts. One drawback of this approach is that it will be difficult to share code between the compiler worker and the runtime itself.

conclusion

As ry explained, this is a problem that is not for the general public that uses deno, it is a problem of the team that develops deno, this would help improve the development of deno, and perhaps improve its general performance, and it is good not to draw conclusions without understanding in the context in which they are developed.

I hope the information has been useful to you, the sources where I got this information will be below. ¡Gracias por leer!

resources

weird and curious things in javascript

Erick Sosa Garcia — Tue, 30 Jun 2020 02:28:17 +0000

javascript was the first programming language I learned, but javascript is not a very intuitive language.

in this post list some curiosities of javascript and I will try to explain them.

#1

which goes first the egg or the chicken according to javascript.

If we take an array with two strings, one an emoji from an egg and the other that from a chicken and use the order function, how is it ordered?


["🥚", "🐔"].sort(); // ?

the answer is


["🐔", "🥚"]

why?

javascript uses utf-16 for character encoding, when comparing the two emojis it does so using its utf-16 number and the chicken emoji has a lower number than the egg emoji and the chicken is placed first. it is for this reason that the uppercase characters when passing the classification function remain at the beginning since they have a smaller number in the utf-16 encoding.

#2

What happens if you add 0.1 + 0.2 and then compare that sum with 0.3?


0.1 + 0.2 === 0.3 // false

This occurs because the calculations are done with base 2 and the calculations cannot be completely accurate.

what happens behind is that it makes the following comparison


const sum = 0.1 + 0.2;

sum.toFixed(24); // 0.300000000000000044408921

sum === 0.3 // false

for this reason the comparison returns false, this problem is not exclusive to javascript, other languages like python and ruby have this problem.

if you want to work with extreme precision with numbers in javascript, the latest versions of js can now be used bigInt

#3

What is the result of the following instruction?


"b" + "a" + + "a" + "a"

the answer is


"b" + "a" + + "a" + "a"    // baNaNa

This is evaluated as


("b") + ("a") + (+ "a") + ("a") // baNaNa 🍌

by type coercion if we add the plus symbol to a string it will try to make it a number and since the letter "a" is not a number this returns NaN or (Not a Number) the other letters being concatenated resulting in the word baNaNa.

#4

we all know that we can comment code in javascript in two ways.


// single comment

/*
multi line comment
*/

but did you know that it is possible to comment using html comments.


<!---
const baf = "😲";
--->

this is possible for javascript interoperability within html.

Let's rewrite Typescript in Rust!

Erick Sosa Garcia — Wed, 24 Jun 2020 02:27:45 +0000

If I'm sure of one thing, it is that typescript completely changed the way developers viewed javascript.

working with javascript in small and medium projects is not a problem but in bigger and more complex projects it is much more difficult. JavaScript was not originally intended to be a language for creating complex applications as it is today, behaviors like these are some of the reasons why javascript is heavily criticized:


{} + "" // 0

[] + {} // [object Object]

10 + "10" // 1010

10 - "5" // 5

Yes, javascript is rare but it is the language that changed the world since it is the only programming language to run in the backend and frontend.

In 2012, typescript arrived as a superset language that compiled to javascript and brought javascript closer to languages with strong types such as java or C#

So far so good, what is the problem?

typescript bottleneck

the typescript compiler is slow, and don't get me wrong the compiler developers are doing a good job, the problem is node js, node js is designed to use a single core of the processor, it can work with multiple processes but in practice only a single core is used. which causes that when compiling typescript node js cannot take full advantage of the power of your processor, so the compilation can be slow in some cases.

so what is the solution?

Rust

rust is a multi-paradigm language, compiled and concurrent that saw the light in its first version in 2015, this is developed by mozilla and is open source.

SWC is a compiler for typescript and javascript written in rust and is being developed by a 22 year old South Korean student. is making it possible to lower compile times by using rust as the language.

if tools like webpack or babel were written in languages like rust or go that allow us to use all the cores of our processor, we would have more efficient and faster development tools.

then Let's rewrite Typescript in Rust!

this post is inspired by the tweet of Jonny Burger
Let's rewrite Typescript in Rust!

Do we really need a package manager for deno?

Erick Sosa Garcia — Sun, 21 Jun 2020 22:34:00 +0000

When I heard about deno in 2019 I thought, why another runtime for javascript?

it has some problems in its internal architecture as ryan explains in this lecture.

A very common question about deno is where is the package manager? ryan in his lecture explains nodejs problems with npm and that trying to fix it is no longer feasible, so deno is intended to solve these problems without needing to use a package manager but changing the paradigm for some developers is not negotiable.

using urls to handle packages is used by other programming languages like go, the hard part is having to handle URLs in say 30 files. one solution is to have a file where all the modules are imported like this.

// deps.ts

export { equal } from "https://deno.land/std@0.58.0/bytes/mod.ts";
export { Sha1 } from "https://deno.land/std@0.58.0/hash/sha1.ts";
export { HmacSha256 } from "https://deno.land/std@0.58.0/hash/sha256.ts";
export {
  serve,
  serveTLS,
} from "https://deno.land/std@0.58.0/http/server.ts";
export {
  Status,
  STATUS_TEXT,
} from "https://deno.land/std@0.58.0/http/http_status.ts";
export { BufReader, BufWriter } from "https://deno.land/std@0.58.0/io/bufio.ts";
export { copyBytes } from "https://deno.land/std@0.58.0/io/util.ts";
export {
  basename,
  extname,
  join,
  isAbsolute,
  normalize,
  parse,
  resolve,
  sep,
} from "https://deno.land/std@0.58.0/path/mod.ts";
export { assert } from "https://deno.land/std@0.58.0/testing/asserts.ts";
export {
  acceptable,
  acceptWebSocket,
  WebSocket,
} from "https://deno.land/std@0.58.0/ws/mod.ts";

// 3rd party dependencies

export {
  contentType,
  extension,
  lookup,
} from "https://deno.land/x/media_types@v2.3.7/mod.ts";
export {
  compile,
  Key,
  parse as pathParse,
  ParseOptions,
  pathToRegexp,
  TokensToRegexpOptions,
} from "https://raw.githubusercontent.com/pillarjs/path-to-regexp/v6.1.0/src/index.ts";

another way is using import map a proposal for the web that deno already implements but for now is an unstable feature.

// import_map.json
{
   "imports": {
      "fmt/": "https://deno.land/std@0.55.0/fmt/"
   }
}

this allows importing in a much more traditional way

import { red } from "fmt/colors.ts";

console.log(red("hello world"));

but we can have a way to handle modules like with npm but without dragging the problems that npm has. Trex is a project that I am developing that tries to implement the best of both sides, It combines the way to install modules using a cli but without the node_modules folder since everything is cached, the ability to install tools like velociraptor and denon in a very simple way.

Trex just creates an import_map.json file where all the dependencies are listed.

npm in node js:

$ npm install lowdash

Trex in deno:

$ trex install --map oak

all modules are extracted from the deno website, so any modules that are in the standard library and in deno.land/x can be installed with Trex.

You can also install a custom module from anywhere using:

$ trex --custom React=https://unpkg.com/react-dom@16/umd/react-dom.development.js

likewise it is added to the import map and the cache.

Create command shortcuts for deno using Commands

Erick Sosa Garcia — Sun, 24 May 2020 02:10:18 +0000

With Commands you can create shortcuts for commands to execute files and also observe changes in files to execute them.

to install Commands in deno here the repository on github link

First look with deno

Erick Sosa Garcia — Tue, 19 May 2020 22:41:43 +0000

On May 13, version 1.0 of deno was released, a new Runtime Environment for javascript and typescript created in rust and using v8 as the javascript engine.

but why a new runtime environment for javascript? Well, we already have a runtime environment for javascript outside the browser, which is the js node created by Ryan Dahl in 2009, but this was created without taking into account the evolution that javascript would have as a language in the following years.

Node js

The node js is created in C ++ and uses libuv as a library to handle the asynchronous code, but initially I didn't have a package manager or ways to import modules "require, import", Another problem that not only node js has but also other interpreted languages have, managing and accessing system resources making them less secure than others, We did not have "async await",
"promises" or other resources that are common in today's language. Of course today we have NPM and "require" but these were introduced in an architecture that did not have it planned.

The problem called npm

Everyone who has programmed JavaScript with node js surely knows the node_modules directory where dependencies and development libraries are stored, but the problem is that npm is an external company to node js and
everything is centralized when the Internet and software is intended to be decentralized, It may also happen that you download a library to handle system files and use smaller libraries, it may happen that a code script inside one of these libraries has some malicious purpose.

Another problem of npm is the so-called Dependency Hell which is the complex dependence of libraries on each other, in this post it is better explained. but the Dependency Hell is not a problem of node js but of npm, of course but npm is an indispensable tool to develop with node js it affects you in that we have a directory that depending on the complexity and the number of modules and libraries can reach a lot of space in the disk.

the image above is a representation of gatsby dependencies where each node represents a library and its joins. tool link.

deno

Now deno comes to solve many node js problems, but who is leading this project is not just anybody, it is the same node js creator Ryan Dahl since he is aware of node problems, but node is an already stable project, so decided to start from scratch.

the interesting thing about deno is that it only has approximately 2 years of development, that it is written in rust the Mozilla language and that it does not use libuv but tokyo to handle the asynchronous code. Other interesting things is that it can also execute typescript since it comes with the compiler, it has a strong emphasis on security for resource management since we must explicitly give access to resources such as reading and writing files or to the network using the flags " --allow-net, --allow-read y --allow-write " all this with a modern approach since it does not natively support promises but uses async await for asynchronous events. It does not have node_modules, npm or require since the dependencies are managed by means of a link or links very similar to GO and in place of require this import from ES6, the libraries are supervised by the deno development team so it increases security. another deno feature is the toplevel await, which means this, that the main function that runs all the code in the callstack has already declared async.

deno is an interesting proposal to node js but only time will tell if it is up to it, for now I will be posting more interesting things about deno

First look with deno (Spanish)

Erick Sosa Garcia — Mon, 18 May 2020 21:51:21 +0000

El pasado 13 de mayo fue liberada la version 1.0 de deno, un nuevo Runtime Environment para javascript y typescript creado en rust y usando v8 como motor de javascript.

pero ¿porque un nuevo entorno de ejecución para javascript?. bien ya tenemos un entorno de ejecución para javascript fuera del navegador que es node js creado por Ryan Dahl en 2009, pero este se creo sin tomar en cuenta la evolución que javascript como lenguaje iba a tener en los siguientes años.

Node js

Node js esta creado en C++ y utiliza como librería para manejar código asíncrono libuv pero en un inicio este no tenia un manejador de paquetes ni formas de importar modulos "require, import", otro problema que no solo node js posee sino que otros lenguajes interpretados tienen, es el manejo y acceso a recurso de sistema convirtiéndolos en entornos menos seguros que otros, no existía async await promesas ni otros recursos que hoy día son comunes en el lenguaje, Claro hoy tenemos NPM y require pero estos fueron introducidos en una arquitectura que no lo tenia previsto.

El problema llamado npm

todo aquel que a programado javascript con node seguro a trabajado con el directorio node_modules donde se almacenan las dependencias y librerías de desarrollo pero el problema que que npm es una empresa externa a node y esta centralizada cuando Internet y el software tiene como pauta ser descentralizado, ademas puede pasar que descargas una librería para manejar archivos del sistema y esta utiliza otras mas pequeñas, puede pasar que un script de código dentro de una de estas librerías tenga algún fin malicioso.

otro problema de npm es el llamado Dependency Hell que es la compleja dependencia de librerías unas de otras, en este post se explica mejor. pero el Dependency Hell no es un problema de node sino de npm, claro pero al npm ser una herramienta indispensable para desarrollar con node le afecta en que tenemos un directorio que dependiendo la complejidad y la cantidad de módulos y librerías puede alcanzar muchos espacio en el disco.

la imagen anterior es una representación de las dependencias de gatsby donde cada nodo representa una librería y sus uniones. link de la herramienta.

deno

ahora bien deno viene a resolver muchos problemas de node js, pero quien lidera este proyecto no es cualquiera es el mismo creador de node js Ryan Dahl ya que el es consiente de los problemas de node, pero node es un proyecto ya estable por lo que decidió empezar desde cero.

lo interesante de deno es que solo tiene aproximadamente 2 años de desarrollo, que esta escrito en rust el lenguaje de Mozilla y que no usa libuv sino tokio para manejar el código asíncrono. otras cosas interesantes es que también puede ejecutar typescript ya que viene con el compilador, tiene un fuerte énfasis en la seguridad para el manejo de recursos ya que debemos explicita mente dar acceso a los recursos como leer y escribir archivos o a la red usando las banderas " --allow-net, --allow-read y --allow-write " todo esto con un enfoque moderno ya que no soporta promesas de manera nativa sino que utiliza async await para los eventos asíncronos. no tiene node_modules, npm ni require ya que las dependencias se manejan mediante link o vínculos muy similar a GO y en remplazo de require esta import de ES6, las librerías son supervisadas por el equipo de desarrollo de deno por lo que amplia la seguridad. otra característica de deno es el toplevel await, que quiere decir esto, que la función principal que corre todo el código en el callstack ya tiene declarado async.

Este es un post que consta de dos partes esta es la primera parte, en el siguiente veremos código con deno. estará en este enlace.

Explained and created a simple virtual DOM from scratch

Erick Sosa Garcia — Tue, 14 Apr 2020 19:31:08 +0000

When I first heard about the virtual DOM, I was wondering how it worked and how to create my own virtual DOM. after doing a little research and practice I will show the virtual dom that I created.

What is the dom?

Document Object Model (DOM) is a way to represent the webpage in the structured hierarchical way so that it will become easier for programmers and users to glide through the document. With DOM, we can easily access and manipulate tags, IDs, classes, Attributes or Elements using commands or methods provided by Document object.

Why called as Object Model ?

Documents are modeled using objects, and the model includes not only the structure of a document but also the behavior of a document and the objects of which it is composed of like tag elements with attributes in HTML.

Structure of DOM:

DOM can be thought of as Tree or Forest(more than one tree). The term structure model is sometimes used to describe the tree-like representation of a document. One important property of DOM structure models is structural isomorphism: if any two DOM implementations are used to create a representation of the same document, they will create the same structure model, with precisely the same objects and relationships.

More information

What is Virtual DOM?

the virtual DOM is an in-memory representation of the real DOM elements in a object. Example:

const myButton = {
    tagName: 'button',
    attrs: {
        id: 'btn',
        class: 'save-btn'
    },
    children: ['save']
};

html equivalent


  <button id="btn" class="save-btn">save</button>

Understanding all this let's start 😊

we need a function to create an object that represents the elements and return this object

// createElement.js

function createElement(tagName, { attrs = {}, children = [] } = {}){

    return {
        tagName,
        attrs,
        children
    }
}

export default createElement;

now we need create a function to render the element

// render.js

function render({ tagName, attrs = {}, children = [] }){
    let element = document.createElement(tagName);
        // insert all children elements
        children.forEach( child =>  {
            if (typeof child === 'string'){
               // if the children is a kind of string create a text Node object
                element.appendChild(document.createTextNode(child));
            }
            else {
                // repeat the process with the children elements
                element.appendChild(render(child));
                }
            });
      // if it has attributes it adds them to the element
    if (Object.keys(attrs).length){
        for (const [key, value] of Object.entries(attrs)) {
            element.setAttribute(key, value);
        }
    }

    return element;
};

export default render;

then create a function to insert the element into the DOM

// insert.js

function insertElement(element, domElement){
    domElement.replaceWith(element);
    return element;
}

export default insertElement;

Now that we have the tools, let's try them out!

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>my vDOM</title>
</head>
<body>
    <div id="root">
    </div>
    <script src="./main.js" type="module"></script>
</body>
</html>

// main.js

import createElement from './createElement.js';
import render from './render.js';
import insertElement from './insert.js';

let myVirtualElement = createElement("div", {
  attrs: { id: "container" },
  children: [
    createElement("p", {
      attrs: { id: "text" },
      children: ["hello world"],
    }),
  ]
});

let element = render(myVirtualElement);
let rootElemet = insertElement(element, document.querySelector('#root'));

run this on any web server, i run it with live server in vscode

We got it! 🥳

Now we can make it more interesting, taking the algorithm to make differences between virtual elements created by Jason Yu in this Post.

// diff.js

import render from './render.js';

const zip = (xs, ys) => {
  const zipped = [];
  for (let i = 0; i < Math.max(xs.length, ys.length); i++) {
    zipped.push([xs[i], ys[i]]);
  }
  return zipped;
};

const diffAttrs = (oldAttrs, newAttrs) => {
  const patches = [];

  // set new attributes
  for (const [k, v] of Object.entries(newAttrs)) {
    patches.push($node => {
      $node.setAttribute(k, v);
      return $node;
    });
  }

  // remove old attributes
  for (const k in oldAttrs) {
    if (!(k in newAttrs)) {
      patches.push($node => {
        $node.removeAttribute(k);
        return $node;
      });
    }
  }

  return $node => {
    for (const patch of patches) {
      patch($node);
    }
  };
};

const diffChildren = (oldVChildren, newVChildren) => {
  const childPatches = [];
  oldVChildren.forEach((oldVChild, i) => {
    childPatches.push(diff(oldVChild, newVChildren[i]));
  });

  const additionalPatches = [];
  for (const additionalVChild of newVChildren.slice(oldVChildren.length)) {
    additionalPatches.push($node => {
      $node.appendChild(render(additionalVChild));
      return $node;
    });
  }

  return $parent => {
    for (const [patch, child] of zip(childPatches, $parent.childNodes)) {
      patch(child);
    }

    for (const patch of additionalPatches) {
      patch($parent);
    }

    return $parent;
  };
};

const diff = (vOldNode, vNewNode) => {
  if (vNewNode === undefined) {
    return $node => {
      $node.remove();
      return undefined;
    };
  }

  if (typeof vOldNode === 'string' || typeof vNewNode === 'string') {
    if (vOldNode !== vNewNode) {
      return $node => {
        const $newNode = render(vNewNode);
        $node.replaceWith($newNode);
        return $newNode;
      };
    } else {
      return $node => undefined;
    }
  }

  if (vOldNode.tagName !== vNewNode.tagName) {
    return $node => {
      const $newNode = render(vNewNode);
      $node.replaceWith($newNode);
      return $newNode;
    };
  }

  const patchAttrs = diffAttrs(vOldNode.attrs, vNewNode.attrs);
  const patchChildren = diffChildren(vOldNode.children, vNewNode.children);

  return $node => {
    patchAttrs($node);
    patchChildren($node);
    return $node;
  };
};

export default diff;

now we change main.js

// main.js

import createElement from './createElement.js';
import render from './render.js';
import insertElement from './insert.js';
import diff from './diff.js';

let myElement = createElement('div', {
    attrs: { class: 'container'},
    children: [createElement('img', {
        attrs: { id: 'img', src: 'https://i.picsum.photos/id/1/200/300.jpg' },
        children: []
    })]
})


let element = render(myElement);
let rootElemet = insertElement(element, document.querySelector('#root'));

let count = 0;

setInterval(()=> {
    count += 1;
    let myVirtualElemet = createElement('div', {
        attrs: { class: 'img'},
        children: [createElement('img', {
            attrs: { id: 'img', src: `https://i.picsum.photos/id/${count}/200/300.jpg` },
            children: []
        })]
    })

    const patch = diff(myElement, myVirtualElemet);

    rootElemet = patch(rootElemet);


    myElement = myVirtualElemet;

}, 1000);

run it 🤞

We got it! 🥳

every second we change the src attribute with a new id inside the link so it updates and applies the changes in the DOM.

Sorry for writing so bad i don't speak english

DEV Community: Erick Sosa Garcia

values and references in javascript

within the primitive values ​​we have:

within the object values ​​we have:

Having said all this I think we can start

Rethinking the way we handle dependency imports in deno

A solution

why deno want remove typescript from your internal code?

the problems

solution

conclusion

resources

weird and curious things in javascript

#1

which goes first the egg or the chicken according to javascript.

#2

#3

#4

Let's rewrite Typescript in Rust!

typescript bottleneck

Rust

Do we really need a package manager for deno?

Create command shortcuts for deno using Commands

First look with deno

Node js

The problem called npm

deno

First look with deno (Spanish)

Node js

El problema llamado npm

deno

Explained and created a simple virtual DOM from scratch

What is the dom?

Why called as Object Model ?

Structure of DOM:

What is Virtual DOM?

Understanding all this let's start 😊

Sorry for writing so bad i don't speak english

within the primitive values we have:

within the object values we have: