DEV Community: Omar E. Lopez

Introducing genix for build event driven applications

Omar E. Lopez — Mon, 19 Oct 2020 20:34:27 +0000

genix is a new zero dependency library for build event driven applications, it make easier reach low levels of coupling in our applications and at the same time give us a set of tools that make the testing process very smoothly. The main building blocks in genix are events and commands, this concepts are very similar being its main differences semantics. In this post I want present its the basic features, and then in future posts show how we can use it with more complete examples. Being said that let's start.

Events

As I mentioned genix allow us develop applications very easy to test, with low levels of coupling through the use of events. An event as usual represent something that happened or changed and they can be used as a notification mechanism that connect different components of our applications. Example of events can be orderReady, userLogged, paymentDone, always they should communicate actions that have already ocurred.

In genix we can work with events using the following functions:

// register a handler for some event name
onEvent(eventName, handler); 

// emit an event so every handler function 
// associated to it will be executed
emit(eventName, ...arguments);

Let's implement an example which will be a counter that increase a value every second and after 10 seconds the value is restored to zero, it's is a very simple problem but it serve to show events in action.

import { onEvent, emit } from 'genix';

function counter(initialValue) {
  let value = initialValue;

  onEvent('tick', () => {
    value++;
    console.log(`Value updated ${value}`);
  });

  onEvent('10SecondsPassed', () => {
    value = initialValue;
    console.log('Set Initial value ');
  });
}

function ticker() {
  setInterval(() => emit('tick'), 1000);
  setInterval(() => emit('10SecondsPassed'), 10000);
}

function main() {
  counter(0);
  ticker();
}

main();

From the previous snippet we can say:

counter and ticker don't know anything about each other, they are completely independent being this a basic feature of pub/sub mechanisms.
handlers should be registered before emit events, as you can see counter function is executed before ticker.
privacy is reached through JS closure, this is something not obtained from genix but I think is good highlight it.
In this example wasn't used, but onEvent return a subscription object with an unsubscribe method that allow us cancel handlers in order to avoid memory leaks.
The API of our components specifically counter in this case are the events that they register.

Commands

On the other hand in genix we have commands. Commands are similar to events in the sense that a command has a name with a handler associated to it, but besides that they have important differences.

Semantically a command represent a future action, they are like an order that we want execute, so when we run a command we are triggering an action.
We can have only one handler per command, if we try to associate two handler to the same command we get an exception, so with events we can have more than one handler for the same event but this isn't the case with commands.
When a command is executed it can return some value , based that a command is an action that we are executing, we can get a value returned from it.

Commands should be named with a verb in imperative mood, for example finishOrder, loadData, executePayment. In the command API there are 2 functions, one to register commands and another to execute them:

// register a handler for some command name
onCommand(commandName, handler); 

// execute a command passing arguments
exec(commandName, ...args);

Now let's see our example but using commands:

import { onCommand, exec } from 'genix';

function counter(initialValue) {
  let value = initialValue;

  onCommand('increment', (amount) => {
    value += amount;
  });

  onCommand('resetValue', () => {
    value = 0;
  });
}

function ticker() {
  setInterval(() => exec('increment', 1), 1000);
  setInterval(() => exec('resetValue'), 10000);
}

function main() {
  counter(0);
  ticker();
}

In this snippet we can note that:

Again counter and ticker didn't know anything about each other which is very helpful in order to hide implementation details.
In this case the public API of our counter if the set of commands registered.
ticker in this example isn't notifying, instead it's like giving orders, the same behavior is obtained but with different semantic mechanism.

Testing

After see events and commands in genix and how they can be used to connect different components, now is time to speak about testing to show others features of this library.
Testing examples will be around the counter function, the implementation will be changed a little bit in order to mix events and commands so we get a more complete example that show many capabilities.

import { onCommand, onEvent, emit, exec } from 'genix';

function counter() {
  const initialValue = exec('getInitialValue');
  let value = initialValue;

  onEvent('tick', (amount) => {
    value += amount;
    emit('valueUpdated', value);
  });

  onCommand('resetValue', () => {
    value = initialValue;
  });

  onCommand('getValue', () => value);
}

function ticker() {
  setInterval(() => emit('tick'), 1000);
  setInterval(() => exec('resetValue'), 10000);
}

export { ticker, counter };

There are 3 important changes in our counter function:

counter register a new getValue command, it will be used like a getter to expose our value variable being that very helpful in our tests.
It depends on getInitialValue command to get the initial value that now isn't passed as argument, so to counter work properly this command should be defined in some way.
When the tick event is emitted counter update value and emit a new valueUpdated event passing the new value as argument.

Let's write a few tests for counter and at the same time explaining the testing tools that genix provide.

import { counter } from './counter';
import genix from 'genix';

describe('Counter', () => {
  it('should allow get the actual value', async () => {
    // using genix to build a wrapper 
    // around the function tested
    const wrapper = genix.wrap(counter);

    // mocking getInitialValue command
    wrapper.onCommand('getInitialValue', () => 10);

    // indicating that getValue will be executed
    // this is a lazy execution so for now nothing happen
    wrapper.exec('getValue');

    // running our wrapper
    const { data } = await wrapper.run();

    expect(data).toBe(10);
  });
});

Note in the previous test the following:

Always the function tested must be wrapped, is this isn't done can occur some race conditions between tests.
Every tests using genix testing tools should be async because the run method return a promise.
onCommand method of our wrapper allow us mock commands that we have as dependencies.
exec method of our wrapper indicate a command that will be triggered against the function tested, this method can receive arguments after the command name.
Before the run call nothing happen, in this way can be said that that our wrapper behave lazily, for example exec indicate a command that we can trigger but only as specification, only when run is called is that actually the command is executed.
run execution return a promise containing an object, this object has a data property that represent the value returned by the last command triggered against of our function, in the previous tes was declared only one command getValue to happen so data will be the return value of it.

Now let's apply all of this to another test, and show how events can be emitted in our tests

describe('Counter', () => {
  it('should react to tick event correctly', async () => {
    const wrapper = genix.wrap(counter);

    wrapper
      .onCommand('getInitialValue', () => 0)
      .emit('tick')
      .emit('tick')
      .exec('getValue');

    const { data, events } = await wrapper.run();

    expect(data).toBe(2);

    expect(events.valueUpdated.length).toBe(2);
    expect(events.valueUpdated[0]).toBe(1);
    expect(events.valueUpdated[1]).toBe(2);
  });
});

genix wrappers expose a fluent API so the wrapper methods can be chained.
The run call besides data also expose a events property, this is a object in which every property correspond to an event emitted by our function during its execution.
In this test the only event emitted was valueUpdated so we have a property with the same name on events this valueUpdated property will be an array containing the list arguments used to emit this event, so valueUpdated[0] contain the arguments used the first time when valueUpdated was emitted.

Let's finish with a simple test to check the behavior of resetValue command.

describe('Counter', () => {
  it('should reset value correctly', async () => {
    const wrapper = genix.wrap(counter);

    wrapper
      .onCommand('getInitialValue', () => 5)
      .emit('tick')
      .exec('resetValue')
      .exec('getValue');

    const { data } = await wrapper.run();

    expect(data).toBe(0);
  });
});

Summarizing genix features that makes tests easier we have:

Allow different environment for every test .
Commands used as dependencies can be mocked.
Events can be emitted and commands triggered during testing.
Inner events emitted during testing are fully exposed.
Access to the result value of the last command executed in our chain of operation , make easier test side effects.

Conclusion

Until this point was described the two main building blocks that genix provide us to build event driven applications, they are events and commands. The idea of this post as I mentioned is show the public API of this library and its capabilities, in future posts I will show some more real world examples using it along with React and also with Express in the backend side.

The advantages of genix can be seen mainly in large application which involve the interaction of many components from severals domain, in this cases the coupling between different parts can be decreased a lot. This ideas of event driven should not be arbitrary applied because this can lead to more problems than it solve, so genix can work as a tool but is important have a good architecture.

The library is very new, it born from my own ideas onto how make my applications easier to test, feel free to try it and any kind of feedback or contribution is more than welcome, you can find the source code here. There are many things to improve like documentation, type coverage, etc..., so stay tuned.

Do you know the most powerful feature of JS generators ?

Omar E. Lopez — Tue, 28 Jul 2020 20:58:51 +0000

Photo by Amar Yashlaha on Unsplash

In a previous article I described the concept of generator in JS, there was explained the strong relation that exists between Iterators, Iterables and Generators. Now in this post I want to focus on one specific feature that make generators unique inside of JS landscape, this is:

Bidirectional communication

Push and Pull protocols

In order to understand what is bidirectional communication(BC) first Push and Pull as communication protocols, between data producers and consumers should be understood.

With Pull the consumer is who determine when the data is received from the producer. Functions are the simpler example of pull in JS. For any function F is true that it doesn't know when the data will be produced or in another way F doesn't know when it will be executed, the consumer has all responsibility over the F() call to pull some kind of data.

In the other hand with Push protocol the producer has full control over the moment when the data is produced, the consumer doesn't know neither when or how the data is produced.
Promises comply with this definition of Push.
For every promise P a callback should be passed to its then method in order to get the promise data asynchronously, later at some point this callback will be executed when the promise is fulfilled, in this case the callback doesn't know about how the data was produced, the inner implementation of P determine when data is pushed to our callback.

Iterables are another example of Pull and Observables works as a Push mechanism.

Bidirectional communication using generators

BC over generators is based on the fact that they support Pull and Push at the same time, or in other words generators can be at the same time data consumers and data producers.

An example of generator as data producer:

function* producerGen() {
  yield 1;
  yield 2;
  yield 3;
}

function consumer() {
  const it = producerGen();

  console.log(it.next()); // {done: false, value:1 }
  console.log(it.next()); // {done: false, value:2 }
  console.log(it.next()); // {done: false, value:3 }
}

In this example producerGen is only acting as producer, the values are consumed inside of consumer function, here we have a pulling happening through our it variable. But a generator can consume data and producing it as well:

function* generator() {
  const dataFromOutSide = yield 1;
  console.log(dataFromOutSide); // 2
}

function consumer() {
  const it = generator();

  const dataFromGenerator = it.next().value;

  console.log(dataFromGenerator); // 1

  it.next(2);
}

consumer();

Analyzing this piece of code step by step, first iterator it is obtained from generator function.
The first call to it.next() run generator till the point when it reach the yield keyword, at this point the execution of generator is paused and 1 is send to outside, acting generator in its roll as data producer. Then the value emitted from generator is printed and next is called again but passing an argument in the call it.next(2), when next is called with an argument generator execution is resumed, and also the previous yield expression is replaced by the argument used in the call to next, in this example yield 1 will be replaced by 2 so the variable dataFromOutside will receive 2.

This gif show the communication flowing in both directions from side to side, so is clear how generator produce and consume data, in fact consumer function is also a producer.

Advantages of Bidirectional Communication

After understand this feature, someone might wonder What are the benefits of bidirectional communication ?, and the answer is:

separation of concern
inversion of control
code easier to test
high level of decoupling

As example I'll implement a function two times one using async-await and another using generators, in order to analyze what is gained from bidirectional communication in the generator based implementation.
Suppose a function to get user data that first check if the user is in cache else it request the data from server.

async function getUserData(userId) {
  const userOnCache = await cache.get(`user:${userId}`);

  if (!userOnCache) {
    const userFromBackend = await server.getUser(userId);
    return userFromBackend;
  }

  return userOnCache;
}

Error handling is not covered for simplicity

Thinking a moment about this function with unit tests in mind first thing to note is that getUserData depends on cache and server, is known that during unit tests should be avoided any call to backend and also any read against cache storage, therefore to test this function in isolation its dependencies should be mocked.
But mocking is a big topic in software development, there are many libraries dedicated to make easier mocks creation and in other hand there are some opinions about mocking as a code smell, besides all of this, developers claiming testing as a difficult task is a fact, mainly in situation when they have a implementation with high level of coupling and therefore should be implemented many mocks, this developers don't enjoy the testing process or worse they decide not to test the code at all.

getUserData can be implemented using some sort of dependency injection making it easier to test but this topic is out of the scope.

After use async-await and conclude that mocks are needed for unit test let's see what happen in the implementation using generators, for this async will be replaced by function* and every await sentence by yield.

function* getUserData(userId) {
  const userOnCache = yield cache.getUser(`user:${userId}`);

  if (!userOnCache) {
    const userFromBackend = yield server.getUser(userId);
    return userFromBackend;
  }

  return userOnCache;
}

Now getUserData is a generator that will yield promises. Write unit tests for this generator is simple, for example a test for the use case when we don't have user data in cache so we get our user from the server can be:

import { getUserData } from './get-user-data';

it("should get user data from backend when user isn't cached", () => {
  // fake user data
  const userData = { name: 'Jhon', lastName: 'Doe' };

  // get an iterator from generator, remember this iterator will emit promises
  const it = getUserData('user123');

  // run generator til the first yield
  it.next();

  // resume generator execution passing undefined as data
  it.next(undefined);

  // resume generator, passing to it userData simulating the server response,
  // also retrieve the next value emitted by it,
  // at this point value came from the return statement
  const { value } = it.next(userData);

  // check that the correct data was returned
  expect(value).toEqual(userData);
});

This show how easy is to test the code using bidirectional communication. The difference with the first implementation is that with async-await promises are send to JS engine and it will be in charge to resolve them and resume the function execution, that communication between the engine and our code can't be intercepted, so for test the function in isolation its dependencies should be mocked. In other hand generators give full control over the promises yielded by getUserData so they can be intercepted allowing pass to our generator whatever kind of data, indeed getUserData is totally unaware is the promise was resolved or if is fake data being injected.

This test could seem very brittle, coupled to our implementation, because next calls are linked to yield statements of getUserData also for every call to next should be passed manually the correct type of data, having this as a consequence that a little change one the implementation might break the test. For sure this is true this test can be improved, but I'm only showing how powerful BC is, maybe I cover this topic in a future post.

One drawback of generators is that with async functions they can be invoked and the language knows how to execute them, awaiting and resuming promises automatically. The same isn't true for generators, I mean JS doesn't what kind of values generators will produce and what should be done with them, so we as developers are in charge to get data and resume the execution of our generators. But don't worry if we know what type of values will be yielded then we can implement a function that pull values from our generator and resume it automatically.

This idea of write generator runners is not new and is used by some libraries

A siple run function that can execute generators can be:

async function run(iterator) {
  let iteratorResult = it.next();

  while (!iteratorResult.done) {
    const result = await iter.value;
    iteratorResult = it.next(result);
  }

  return iteratorResult.value;
}

run will receive an iterator, then get the first data using next(), after that it will continue retrieving data from iterator while it isn't done, for every piece of data we await the property value to resume our generator passing the promise result in the next call, by last we return the last value emitted by iterator.

Run can be used like:

run(getUserData('user123')).then((userData) => {});

Conclusions

In summary this post explained very briefly Pull and Push as communication protocols also how bidirectional communication works on generators.
We explored this feature transforming a generators in data producers and consumers. As example the behavior of async-await was reproduced using generators, trying to exemplify how easy is build tests for a generator based implementation. This post isn't a comparative between generators and async-await, both are powerful and I'm really glad that JS support them. Hopefully you understand the basics of BC after this read, in the future post I'll continue writing about it exposing what we can achieve.

Thanks for read.

Converting decimals in Romans using FP

Omar E. Lopez — Mon, 06 Jul 2020 21:10:41 +0000

Photo by Alexander Schimmeck on Unsplash

Let's explore how we can implement an algorithm that allow us convert a decimal number in it's roman representation. I like functional programming(FP) so also during the implementation I want use common concepts from FP like pure functions and function composition , so hopefully this also serve as example to show how you can apply FP to problem solving.

We will develop a simple converter function that will receive a decimal number as input and output the roman representation of our input, for example:

convert(1679) === 'MDCLXXIX';

Algorithm

Before deep dive in the implementation, let analyze step by step our conversion algorithm.

First we should know what characters we have available in the roman numeric system and the decimal number that every one of them represent,we have the following set of characters:

For simplify our converter the algorithm will be for numbers less than 5000

| Roman | Decimal | | ----- | ------- | | M | 1000 | | CM | 900 | | D | 500 | | CD | 400 | | C | 100 | | XC | 90 | | L | 50 | | XL | 40 | | X | 10 | | IX | 9 | | V | 5 | | IV | 4 | | I | 1 |

As you see I represented some decimals using two letters example CD, this is in order to avoid in our algorithm the subtractions that take place in the roman numeric system, think as this 2 characters as a whole that is associated with a decimal value

The next step is for every decimal number try to decompose it as a sum, using only the decimals number exposed previously, we should use the minimum number of operands in our sum, let's see:

As we can see, from this decomposition is very straightforward get the roman representation. So this is how our algorithm work, it will go from top to bottom over our available decimals and check if the roman token associated with it should be in our final representation and how many times we should include the respective token.

Our algorithm will build the roman number in an incremental way, for check how many times a specific roman token should be present we use the / operator in conjunction with the decimal representation of this token against our input, the % operator is used in every step to get the remain that we will use as input when processing the next roman character, as we know an example is worth than thousand words so let see how we can transform 38:

At this point we end and Roman = XXXVIII is our initial number represented using roman notation

Note the following in our algorithm:

We process roman characters from top to bottom staring from M to I.
In every step we do exactly the same operations (/ , concatenation, %) over our arguments.
We update in every steps our Roman representation concatenating new characters or maybe nothing.
We update in every step our input that will be used in the next step.
The / operation is used to find how many time a specific characters should be included in our representation.
The % operation is used to find the remaining amount that need to be converted.

Implementation

Now that we saw how the conversion algorithm works let's go through it's implementation.

First I will start implement some utility functions that we will use.

Divider

As in every step / and % operations are used let's start implementing a function that help us with this task:

function divider(a, b) {
  return {
    cocient: Math.floor(a / b),
    rest: a % b,
  };
}

Repeat

We need a function that allow us repeat a character a specific amount of times:

const repeat = (times, char) => new Array(times).fill(char).join('');

Pipe

As I mention earlier we will use function composition in the implementation, for this let's use a pipe function. With pipe we can for example write g = arg => f2(f1(arg)) as g = pipe(f1,f2), in this example g is composed by f1 and f2, the out of f1 is passed as and argument to f2:

const pipe = (...fns) => (arg) => fns.reduce((x, f) => f(x), arg);

/* 
    If you not follow the pipe implementation don't worry 
    just remind that this function serve 
    to pass the output of one function as input to another.
*/

Now let's see the implementation, we know that during the conversion we did the same operation in every steps over our input, the only thing different was the roman character and the decimal that is represent. With this in mind let's build a process function that receive as arguments a romanChar and it's decimal representation and return a function F that will be responsible to run the conversion algorithm:

function process(romanChar, decimal) {
  /* function to check if our romanChar will we in our final representation */
  return (arg) => {
    /*
        arg:{
          num: decimal number that we are converting
          roman: partial representation of our solution
        }
    */
    const { num, roman } = arg;

    /* num equal 0 imply that there is not anything to transform */
    if (num === 0) {
      return arg;
    }

    /* find how many time we should repeat romanChar and the remain that need to transform */
    const { cocient, rest } = divider(num, decimal);

    /* get the new romans characters */
    const newRomanChars = repeat(cocient, romanChar);

    /* update num as rest and update our actual roman representation concatenating newChars */
    return {
      num: rest,
      roman: `${roman}${newRomanChars}`,
    };
  };
}

Ok until this point we have our process function that allow us check if a specific roman character should be present in our final transformation for example const f = process('V', 5) give us a function f that should receive our arg object and determine if V should be included in our final solution.

The last step is create a converter function composing different function where each one has
only the responsibility to check one character, our transformation will be passed from one function to another.At the end we end with an object which num is 0 and roman is the full conversion,

const convert = pipe(
  (number) => ({ num: number, roman: '' }),
  process(1000, 'M'),
  process(900, 'CM'),
  process(500, 'D'),
  process(400, 'CD'),
  process(100, 'C'),
  process(90, 'XC'),
  process(50, 'L'),
  process(40, 'XL'),
  process(10, 'X'),
  process(9, 'IX'),
  process(5, 'V'),
  process(4, 'IV'),
  process(1, 'I'),
  ({ roman }) => roman
);

Note how our convert function receive a number and in the first step(first function) we transform it to our arg shape so we can start the conversion, also in the last step we get our arg object and extract from it roman property with the full conversion.

Full source code can be found here

Conclusions

As we stated at the beginning we used function composition, and pure functions in the sense that none of our functions rely on side effects, in every step we don't modify our arg instead we a create a new object, that will be passed to the next function in our chain.

This example is simple but I hope that it give you some insights on how you can use this concepts in your every day tasks.

This approach to build our convert function in a declarative way give us as advantage that is easier adapt to new requirements, for example our convert function can be refactored to work with numbers greater than 5000 only adding another call without modify our process function.

Thanks for read

If you like this article and want read more from me, you can follow me.

Improve your commits using vscode

Omar E. Lopez — Sun, 31 May 2020 12:43:09 +0000

Photo by yancymin at Unplash

If you are like me and enjoy Visual Studio Code(vscode) as a tool keep reading. Today I want show a simple trick using this editor to commit our code in a more organized way(in my opinion). I have been using this editor for almost 3 years, but it wasn't till some months ago that I figure it that I can commit my files partially, that means I can create a commit that doesn't include every changes that I made to a single files.

I had to learn this because I was working in a project where the people in charge to review my code were very strict about the commits, things like the changes included were very important for them, in order to understand the work done by some developer. One of the main requirements was doesn't merge changes related to new features with changes regarding to refactorization, so in this way we separate concerns in our commits. At the beginning I struggled achieving this, but after learnt how files can be partially committed everything was easier.

Partially commits in vscode

Suppose that we have the following changes:

As we can see here we have implemented a new feature function and also refactored our getSessionKey function, we want include this two changes in two different commits .

In vscode with for do that we select the changes that we want include in the next commit doing right click on the diff view and Stage Selected Ranges

The editor allow us during the diff view, add changes on different selections, so we can select for example lines 5-10 and stage them, after that select lines 30-40 and stage them, repeating this until we have staged all the changes that we want commit.

After this we can see that our file is in the staging area ready for be included in our next commit, but note that we have staged only our change related to new feature.

At this point we can proceed to commit and do the process again for the remaining changes.

As you can see this is very easy and allow us to separate concern in our commits. I think that this is very helpful in many occasions when we work and make many changes not being related or unable to live in the same commit, also with this approach we end with a detailed history of our work which for communicate our intentions and facilitates the code review process.

If you know another useful trick that we can use in vscode share it in the comments, thanks for your read.

PS: I love the new UI for writing post thanks to @devteam

If you are looking for job, HackerRank offer industry-vetted skills directory

Omar E. Lopez — Sat, 23 May 2020 19:58:28 +0000

On May 21 HackerRank published a detailed library of in-demand technical skills. This directory came out with the objective to help in the creation of standardized interview process from the technical point of view. So after the required skills and competences being defined you as developer trying to get a job or as interviewer can be in the same page during the evaluation.

For every skills there are defined 3 different categories Basic, Intermediate and Advanced, and is detailed the require knowledge for every category. Among the skills we can find AWS, Node.js, Django, Docker, CSS, React and many more. Also some skills have their own subset of question, which is be very helpful in my opinion for newcomers that sometime struggling regarding to what they should learn, also this questions can help more experienced developers in how they should prepare before a job interview.

So if you are a searching for a job, are in charge of the interview process at some company or just simply want know what you should learn about some specific technology check this directory.

HackerRank Skills Directory

Explaining JavaScript Generators

Omar E. Lopez — Mon, 18 May 2020 00:46:19 +0000

Photo by Jason Strull on Unsplash

Today I want to explain my mental model about Generators in JavaScript. I'll try to do this mixing technical concepts with my own view of how they fit together. Summarizing I'll be talking about Iterators,Iterables and Generators.

Very often I see some sort of confusion around generators concept, based in the fact that there are many terms and expressions used when developers speak about them,this make a little bit hard to figure it out what it's happening. I went through this confusion the first time that I ear about it, and the situation is worst for junior developers. The first pieces of information that I read about generators 2-3 years ago was somethings like:

The are function that don't run-to-completion, they can stop its execution in the middle of the function body, and can be resumed later either right away or later in time.
When you run a generator function const it = gen() you actually don't run code in the generator instead you get and iterator but if you log it in the console you get Object [Generator] {}
They allow bidirectional communication improving the async flow control

From that comments I had the following issues:

Why I want a function that doesn't run-to-completion ?
I run the function but it in fact not ran.
What is an generator object.

Even though they were added on ES6, today I think that generators are a blurry concept for many developers, many don't use it or try to avoid, sometimes because they don't find a use case that is very well suited for generator or are developers that simply don't fully understand the concept. So let's begin with the explanations.

Note: The concepts exposed here are relevant to JavaScript, they are available in another languages as well but I'm focus on its relevance for JS.

Iterator

In my opinion for gain a clear understanding around Generators we need to understand another underlying concepts related to them, and in that way conform the base over which generators are developed. The first of this concept is Iterators. Adapting an simplifying the definition from the MDN we have:

The iterator protocol defines a standard way to produce a sequence of values (either finite or infinite). An object is an iterator when it implements a next() method that allow us consume the values from a container.

So and iterator allow us produce and/or traverse values that belongs to a container, note that this container not necessarily must be a list,it can be an object, set, tree, graph, map or simply values generated on demand. The iterator protocol mentioned in the definition give us and standard way to consume values, in summary the protocol define the following:

the values can be consumed calling the next() method.
the next() method return and object with two properties:
- done: A boolean that indicates a completion status of the iteration, using this property the consumer is able to know if all the values were consumed or not.
- value: current iteration value or final return value

for example:

const container = [1,2];

const iterator = {
  index: 0,
  next() {
    if (this.index === container.length) {
      return { done: true, value: undefined };
    }

    return { done: false, value: container[this.index++] };
  },
};

console.log(iterator.next()); // {done: false, value: 1}
console.log(iterator.next()); // {done: false, value: 2
console.log(iterator.next()); // {done: true, value: undefined}

So in this example we have the following:

container array is not an iterator by itself if we execute container.next() we get TypeError: container.next is not a function, see how the container doesn't obey the iterator protocol and doesn't know how its values can be consumed.
iterator object implement the iterator protocol through it's next method,allowing us consume container array values.

Iterables

Now that we saw in brief the concept of Iterators lets talk about Iterables. As in the case of Iterators, based on the MDN documentation we can define Iterables as:

In order to be iterable, an object must implement the [Symbol.iterator] method, the implementation must be a zero-argument function that returns an iterator.

If an object meets the previous definition then it's one iterable, and follow the iterable protocol. This protocol is just an standard way to allow containers define or customize their iteration behavior.

Exist many tools built in the language that are integrated with this iterable protocol, as example can be for...of loops, spread operator,etc... Also the main data structures of the language are iterables by default, this is the case of String, Arrays, Sets, Maps.

After all of this we can simply say that an iterable has a method stored in a very specific property(Symbol.iterator) that when is executed return an iterator that can be used to consume the iterable values.

Example:

const iterable = [1,2];
const arrayIterator = iterable[Symbol.iterator]();

console.log(arrayIterator.next()); // {value: 1, done: false}
console.log(arrayIterator.next()); // {value: 2, done: false}
console.log(arrayIterator.next()); // {value: undefined, done: true}

In this snippet we consume the values of the array iterable, but without implement by our self the iterator just using what the language provide to us.

Let's see another example but now making our own iterable, we will make a plain object iterable and the iteration should will be over its properties, also lets be a little bit funny and implement a simple functions that allow us consume values from iterables

/*
  - The keys of an object can be retrieved using Object.keys 
    you know that,
    but this is a just a simple example.
*/

/* Function that allow another function consume an iterator */

function consumeIterator(consumerFn, iterator) {
  const iterResult = iterator.next();

  /*
    Note that this function is very naive, 
    and assume that when the iterator is done its value is undefined 
  */

  if (iterResult.done !== true) {
    consumerFn(iterResult.value);
    consumeIterator(consumerFn, iterator);
  }
}

/* Function that allow another function consume an iterable */

function consumeIterable(consumerFn, iterable) {
  const iterator = iterable[Symbol.iterator]();
  consumeIterator(consumerFn, iterator);
  console.log('Iterable consumed\n');
}

/* by default object literals are not iterables */

const objectIterable = {
  foo: 1,
  baz: 2,

  /* lets add our special property to make it iterable */

  [Symbol.iterator]() {
    const keys = Object.keys(this);
    return Array.prototype[Symbol.iterator].call(keys);
  },
};

/* Consume our iterable object using our new helper function */

consumeIterable(console.log, objectIterable);

/* Consume the object again but now applying a different consumer function */

const logUpperCase = (value) => console.log(value.toUpperCase());

consumeIterable(logUpperCase, objectIterable);

After running this piece of code the output is:

foo
baz
Iterable consumed

FOO
BAZ
Iterable consumed

The code has a plenty of comments, anyway if you have a question don't hesitate on leave it in the comments section. In the previous example we were able to write functions that work over any iterable/iterator thanks to the protocols.

If the implementation for [Symbol.iterator] in our iterable object looks a little bit confusing you can read my previous article about how this behave in JS to reach a better understanding.

Generators

OK so far we saw that iterators allow us consume values from some specific container, and iterables define an common interface to expose iterators so ...What about generators ?

Generators are a simply and very straightforward way of generate iterables and iterators.

For me this is how I visualize generators, they are a function that define how values from some iterable are emitted, I think that is more easy see them as iterables that we want use in our application, and from there about a generator that emit those values, rather than not thinking about functions that doesn't fully run to completion and other stuffs regarding generators, at least in order to start using them . I'm not saying that is wrong all of the other facts about this concept indeed they are correct, I'm just only exposing how is easier for me think about iterables consumption.

Some advantages of generators are:

They return an object(Object [Generator]) that is iterator and iterable at the same time.
The values returned or yielded from the generator are automatically wrapped as an object that meet the iterator protocol.
With them is easier to keep iterator inner state without necessity of extra variables
Generators allow inject data before create the iterator making the whole process more dynamic.
They allow communication in both direction acting as a pulling and pushing mechanism at the same time.

lets see one example:

/* a function generators is declared using function* */

function* gen() {

  /*yield mean a pause point and emit a value that can be consumed */

  yield 1;
  yield 2;
}

const iter = gen();

/* look how iter is an iterator */

console.log(iter.next()); // {value: 1, done: false}
console.log(iter.next()); // {value: 2, done: false}
console.log(iter.next()); // {value: undefined, done: true}

/* at the same time the value returned by the generator is an iterable */

const iterator1 = gen();
const newIt = iterator1[Symbol.iterator]();

console.log(newIt.next()); // {value: 1, done: fasle}
console.log(newIt.next()); // {value: 2, done: false}
console.log(newIt.next()); // {value: undefined, done: true}

Two things to note here are how we are yielding a number but the consumer get an object under the iterator protocol, and for show that the generator also return an iterable we call again the gen generator, we do this to avoid extract the iterator directly from the iter iterable because when an iterator generated reach its done state it remain there in every successive call to next.

Lets recreatee our previous example related to object keys:

function* genObjectKeys(obj) {
  for (const key of Object.keys(obj)) {
    /* pausing point, 
       inner state of the loop is automatically manage by the interpreter */
    yield key;
  }
}

/* we can dinamicaly inject the object at creation time*/

const it = genObjectKeys({foo: 1, baz: 2});

/* we can use our previous helper, this is a huge advantage that protocols give us */

consumeIterator(console.log, it);

Conclusion

So with this we saw a very basic overview of how iterators, iterables, and generators are in a very strict relation. There are many aspects regarding this concepts that I skipped in order to cover the basics, somethings like async iterators, iterators composition, bidirectional communication using generators, etc ...

Anyway if your are interested in some of this topics or want see a more realistic example using generators let me know in the comments.

Thank you for read

Deno is coming

Omar E. Lopez — Sun, 10 May 2020 17:45:26 +0000

The creator of Node.js from some time has been working in a new project called Deno, the first stable version of this project should be published in 3 days on May 13.

The project is defined as

Deno is a JavaScript/TypeScript runtime with secure defaults and a great developer experience.

From the official repo we can summarize some of the main features:

Supports TypeScript out of the box.
Has built-in utilities.: It include a dependency inspector(deno info), code formatter(deno fmt), test runner(deno test), bundler(deno bundle), documentation generator(deno doc), debugger
Ships a single executable.
Scripts can be bundled into a single javascript file.
Secure by default: This mean that unlike Node when we run our applications they by default don't have access to the file system, network or enviroment, for that we need enable them using some flags as command line options to allow access for example deno --allow-read=/etc

Some difference with Node are:

Deno doesn't use npm, it uses modules referenced as URLs or file paths
Deno doesn't use package.json in its module resolution algorithm.
All async actions in Deno return a promise. Thus Deno provides different APIs than Node.
Explicit permissions.
Deno always dies on uncaught errors.
Uses ES Modules and doesn't support require().

This and more information can be found on the official repo I expose it here just in order to show a quick resume. So now that we know main features, and differences what are your thoughts regarding it.

Will you give a try it in upcoming projects ?
Do you think it will cause a huge change in the Node community
In your opinion what is the best feature
What your dislike most about it

Above I share some of the main question that I hear when I talk about it with some fellows at work. I'll be glad to read your opinions in the comments.

Thanks in advance

JavaScript why 'this'

Omar E. Lopez — Sat, 02 May 2020 18:30:23 +0000

Recently I was working on a project with Angular 7 when a teammate told me about a problem he had within a component, the problem was that he subscribed to an observable returned by one service implemented in the application and within the callback in charge of receiving the values did not have access to an attribute defined in the component.

Specifically, the problem was on line 14 that data isn't defined as property of this 🙄🤔.

After analyzing the code I told him that the problem wasn't related to Angular, and to understand the cause of it he should know how this binding works in JavaScript. A few days after I told about this error to another colleague, and while I explain it I realized that he also didn't have a complete understanding of how this work.

In the article this is used to represent the JavaScript keyword and not the English word

Currently JavaScript is within one of the most used languages worldwide, I think it's very common to find developers working with JavaScript that use this without really understanding the basics of this feature that the language provides us. I think this is largely due to the introduction of pseudo-classes in ES6, since they try to imitate a similar syntax for the definition of classes to that of other languages, and therefore less experienced developers tend to associate this in the same way that it works in other programming languages (my colleagues had worked with PHP and C# respectively).

`this` binding

The keyword this in JavaScript is automatically defined inside of the scope of any function f, and within each f we have that this represents a given object. The problem really with this is that the object represented is not defined by the way we implement the function, but is defined dynamically at run time depending on how we call the function, that is, the object represented by this hasn't nothing to do with where f is declared, but it has to do with the way f is called.

Simplifying we can say that the interpreter uses 5 rules to determine the object that this represents within f, we will explain each of these rules and then define their precedence levels.

Default binding

The first rule that we will examine is the simplest of all, and applies whenever one of the others is not applicable, so we can also say that it is the rule of least precedence.

The default binding is applied when a function f is called in the form f(). When this rule is applied this points to the global scope, note that this has the consequence that if we modify this within the function for example by inserting some property it will be accessible even after executing the function because it would be defined globally, for example:

It is valid to clarify that the variable name within the global scope is accessible only in the case of browsers, for the case of Node on line 6 it would have been printed undefined

In the previous snippet it is exemplified as this points to the global scope.

In the case that we execute our script in strict mode at the time of applying the default binding the interpreter doesn't allow this to represent the global scope, therefore this will point to undefined. The previous snippet running in strict mode throw the following error:

TypeError: Cannot read property 'name' of undefined

Implicit binding

The second rule or implicit binding is applied in the case that a function f contained in an obj object is executed using dot notation for its execution obj.f(), example:

In the previous example we see how both objects contain printInfo property that refers to the same function, but despite this when executing the function in one case this represent the dwarf object, while for the other it's threeEyesRaven. This is because in each of the calls to the function an object is used, which we can name as context, in this case the implicit binding define that within the function this points to the context object, therefore saying this.name would be the same as saying dwarf.name or threeEyesRaven.name depending on the object used in the call.

Lost Implicity

It's very common for some developers to lose at some point in the source code the implicit binding defined for some specific object, which means that the binding that is applied would be the default binding having this pointing to the global scope or undefined. This can happen when we use callbacks, for example:

What happens is that here we are passing directly to setTimeout a reference to our function printInfo without passing the object where it's contained, on the other hand we have no control of how setTimeout call the function, to better understand what happens suppose this pseudo implementation of setTimeout:

Analyzing the call-site of fn in the previous snippet is easy to conclude that the default binding is applied and the explicit binding that was previously available is lost, because dot notation isn't used to call the function.

Explicit Binding

So far we have seen 2 rules to determine the value of this within a function, the first applies when we call the function as standalone function and the second when the function is executed by accessing it as part of an object.

Next we will see another type of binding for the case in which we explicitly define the object to which this points within a function, this type of binding is known as explicit binding.

To get into the explanation of this type of binding we must start talking about 2 methods present in every JavaScript functions, these methods are apply and call. Both methods take the object to be pointed by this as the first parameter and then execute the function with this configuration. Because we directly indicate what will be the value for this when executing the function we are in presence of explicit binding. For example:

In the previous example, we noticed how the first time we executed the print function, it print "Rob Stark" because that is the value of the name property of kingInTheNorth object which contains the print function and therefore applying the implicit binding when executing the function this will point to the object. The second time we execute the function then "Jon Snow" is printed instead of Rob Stark even though we are accessing to the same function contained in the kingInTheNorth object, what happens is that in the function's call-site we are calling the call method and explicitly indicating that the function is executed using the newKing object as this, so in that case within the function this.name refers to newKing.name.

Explicit binding with `bind`

Sometimes is desirable to indicate this for some function without executing it. For this case, each function has a bind method which, like apply and call, takes as its first parameter the object that this will represent but instead of executing the function bind returns a new function with this already linked to the specified object, let's look at the following example:

Here we see from the same house function two new functions were created through the use of bind, using in each case different objects to represent this, note how in the bind call the house function is not executed at any time, in this way at the end we have created a house for the Targaryen and a house for the Tyrell.

`new` Binding

To understand the new binding we must know what happens when a function is called preceded by new, in this case the following occurs:

A new object is created.
The new object is linked to the prototype of the function executed.
The new object created is set as this within that function.
Unless the function returns something different, the new object is automatically returned by the function.

For simplicity, let's completely ignore the step 2 it and let's focus on the others

Here we see how each time the function is invoked using new, a new object is created on each call, this object is automatically returned from the King function even though it doesn't have return statement.

Currently the vast majority of developers don't use new to execute functions but when invoking es6 classes, in this example a function were used because we are analyzing the behavior of this within functions , although classes are at the end functions as well 😎😉.

Arrow functions

A new way of declaring functions was introduced in ES6(arrow functions), to declare a function in this way we use the operator =>, for example:

One of the features of this approach is that the functions alter the behavior of this, so that it's not dynamic depending on the function's call-site, but is lexical. In a simplified way, this within an arrow function represents the same object that it represented in the parent scope that contains the defined function, that is, the arrow function inherits this from the enclosing scope, example:

Observe that when the timer is executed we don't lose the reference of this pointing to HouseStark object, which happens in case that we pass an anonymous function function(){} to setTimeout, the above is because we are using an arrow function as timer first argument. The parent scope in this example is defined by the printMembers function, when executing this function from the HouseStark object, the implicit binding is applied and this will be the object itself, as a consequence then this within the arrow function will be HouseStark object so we can access to all its properties without problems.

Determining `this`

To know what this represent within a function we first find the call-site of that function, remember that this depends directly on the way in which the function is executed, then we follow this steps:

(new binding) Is the function called using new ? If so, this points to a new empty object built before executing the function.
(explicit binding) Is the function executed using call or apply ? this points to an object explicitly specified as the first parameter of the call.
(implicit binding) Is the function executed by accessing it through an object that contain it ? In that case, this represent the object that contains the function as one of its properties.
(default binding) In another case this points to the global scope or undefined if we are in strict mode.

In case of arrow functions then this will be inherited from the enclosing scope, and this in the enclosing scope is determined following the previous steps.

Conclusions

As a recap we can say that this in JavaScript is dynamically defined at run time, depending on the call-site of a function. There are 4 different types of binding. Using arrow functions we can say that it would not have its own this but inherits it from the enclosing scope.

Now that we have talked in detail about this , would you know what is the problem in the code published initially 👍

For more information on the subject I highly recommend this book from Kyle Simpson

Any recommendations do not hesitate to leave your comments, thank you for read

What happen with echojs.com

Omar E. Lopez — Wed, 14 Feb 2018 14:53:51 +0000

Yesterday in the morning as always I went to check echojs.com ,website which read a lot of what was happening in the javascript environment and I found this

Someone knows because the site is not publishing the news as they have always done...??

DEV Community: Omar E. Lopez

Introducing genix for build event driven applications

Events

Commands

Testing

Conclusion

Do you know the most powerful feature of JS generators ?

Bidirectional communication

Push and Pull protocols

Bidirectional communication using generators

Advantages of Bidirectional Communication

Conclusions

Converting decimals in Romans using FP

Algorithm

Implementation

Divider

Repeat

Pipe

Conclusions

Improve your commits using vscode

Partially commits in vscode

If you are looking for job, HackerRank offer industry-vetted skills directory

Explaining JavaScript Generators

Iterator

Iterables

Generators

Generators are a simply and very straightforward way of generate iterables and iterators.

Conclusion

Deno is coming

JavaScript why 'this'

this binding

Default binding

Implicit binding

Lost Implicity

Explicit Binding

Explicit binding with bind

new Binding

Arrow functions

Determining this

Conclusions

What happen with echojs.com

`this` binding

Explicit binding with `bind`

`new` Binding

Determining `this`