
## What are the differences between `var`, `let`, and `const`?

In JavaScript, we can declare variables and optionally assign them values:

```javascript
// declaring a variable with `var` keyword
var name;

// Declaring a variable and assigning a value
var name = "John";
```

Historically, `var` was the only way to assign a variable, with `let` / `const` introduced later as part of the [ECMAScript 2015 (6th)](http://www.ecma-international.org/ecma-262/6.0/).

The `var` declaration has some confusing properties when it comes to scope. On the other hand, `const` and `let` have cleaner scoping rules and usually should be preferred.

Let's see how they differ.

Variables declared with `var` have a so-called "function-level scoping". They are accessible to any code within the same functions.

```javascript
function testScope() {
  var v = 123;
  console.log(v); //=> 123
}
console.log(v); //=> Uncaught ReferenceError: v is not defined
```

When used outside of any function, it will assign values to the global scope. That means it will be accessible globally in any part of the code and available on the global object (e.g., `window.myVar`).

Note that polluting global scope should be avoided  (see the next question for details).

Functional scoping is opposed to block scoping when a variable is only visible within a block (that is, within curly braces `{` / `}`). The `let` and `const` keywords declare variables with block scope.

Compare,

```javascript
if (true) {
  var name = "Emma";
  let surname = "Stone";
}

console.log("name", name);
console.log("surname", surname); // ReferenceError: surname is not defined
```

Block-scoping is useful because it allows variables to only be visible within a block, thus preventing possible errors with overlapping variable names.

`const` works similar to `let` in terms of scoping. A difference between those two is that the format prevents re-assigning. You can only assign a value to that variable once, and it must be done at the time of declaration.

```javascript
const age = 123;
age = 321; // TypeError: Assignment to constant variable.

let name = "John";
name = "Alex"; // No problem here
```

It's important to note that `const` prevents re-assignment, but it doesn't make an object immutable.

```javascript
const person = { name: "John" };
person.name = "Anna"; // perfectly valid
```

In practice, it's good to always default to `const`. If you know that you'll need to re-assign the variable sooner, use `let`. Avoid using `var` (unless you specifically mean "function-level" scoping).


In this article, we are explaining the difference between var, let, and const.

What are the differences between var, let, and const


You are a React developer in 2020, and this pattern is too familiar.

You can probably type it with your eyes closed.

```javascript
function App() {
  return (
    <CounterStateProvider>
      <Counter />
      <CounterIncButton />
    </CounterStateProvider>
  );
}

const CounterContext = React.createContext({ value: 0, incrementValue: () => {} });

function CounterStateProvider({ children }) {

  const [ value, setValue ] = useState(0)

  const incrementValue: () => {
    setValue( value + 1 )
  }

  return (
    <CounterContext.Provider value={{ value, incrementValue }>
      { children }
    </CounterContext.Provider>
  )

}
```

Two components in different parts of your application need to share the same state.

You don't want to pass values and callbacks via props all the way, so you're using [React's Context](https://reactjs.org/docs/context.html).

In this simplified example, we have just two components: `Counter` displays the current counter value, and `CounterIncButton` increments that value by one.

What if I tell you that you can achieve the same behavior without introducing the ugly CounterStateProvider, and have it framework-agnostic? No extra libraries, plain JavaScript, and just under 30 lines of code.

## Let's start from the end...

I would ask you to close your eyes now and imagine that we already built our shiny state manager.

How does it look like? Or, to put it correctly, what interface are we going to implement?

What we need is:

- (1) a way to read the current value,
- (2) a way to update it, and
- (3) to be able to react when the value is changed.

```javascript
const counterStore = createStore(0);

// get and update the value
counterStore.getValue(); // => 0
counterStore.setValue(1);
counterStore.getValue(); // => 1

const clean = counterStore.onChange(() => {
  // this function is invoked every time the value changes
  // and it returns a function that remove the callback
});
```

We'll get to implementation soon, but first, let's get React out of the way.

## Binding with your favorite framework

Assuming that our store is working, how can we "bind" the state to the component (by which I mean to re-render on change).

A great way to force a re-render is to simply call `setState`.

```javascript
// create store with a default value 0
const counterStore = createStore(0);

const Counter = () => {
  const [value, setValue] = useState(counterStore.value());

  useEffect(() => {
    // add a change callback
    const clean = counterStore.onChange((newVal) => {
      // envoking setState to cause re-render
      setState(newVal);
    });

    // don't forget to clean
    return clean;
  }, []);

  return <div>{value}</div>;
};
```

Now that's a bit clumsy. All that code inside useEffect has nothing to do with the business logic and only clutters the view.

Thankfully we can abstract it away by introducing a hook.

```
// ==================
// THIS ONE YOU PROBABLY WOULD KEEP IN A DIFFERENT FILE
// ==================
const useSharedStore = (store) => {
  const [value, setValue] = useState(counterStore.value());

  useEffect(() => {
    // add a change callback
    const clean = counterStore.onChange((newVal) => {
      // envoking setState to cause re-render
      setState(newVal);
    });

    // don't forget to clean
    return clean;
  }, []);

  return [ value, counterStore.setValue ]
}
// ===================


const counterStore = createStore(0);

const Counter = () => {
  const [ val ] = useSharedStore(counterStore)
  return <div>{value}</div>;
};

const CounterIncBtn = () => {
  const [ val, setValue ] = useSharedStore(counterStore)
  return <button onClick={() => setValue(val + 1)}>+1</button>;
};
```

😍, right?

Note how we emulated the `useState` interface. In the same fashion, our hook returns an array with two items, the first one being the value itself, and the second one is the setter.

The difference is that `useState` creates a local state, while we have just created a shared state!

This little hook is what we need to connect our store with the React world. Otherwise, our little state manager is completely framework-agnostic.

Finally, with React out of the way, we can talk about the implementation...

## The unnecessary implementation

It's unnecessary because we already asked the good question, which is half of the answer — we know the interface.

To put it the other way, we proved that the problem has a solution.

Should we also actually solve it?

If you insist.

Let me remind that our store has nothing to do with React. Our state manager is entirely free from any framework-related assumptions.

What this means is that we'll be able to share the state not only between components of React tree but also between different frameworks.

As you recall, we need to implement a function that creates a new store and returns 3 functions:

```javascript
function createStore(defaultValue) {
  const getValue = () => {
    // implement me
  };

  const setValue = () => {
    // implement me
  };

  const onChange = () => {
    // implement me
  };

  return {
    getValue,
    setValue,
    onChange,
  };
}
```

We can store a value right there in a closure.

```javascript
function createStore(defaultValue) {
  let value = defaultValue;

  const getValue = () => {
    return value;
  };

  const setValue = () => {
    // implement me
  };

  const onChange = () => {
    // implement me
  };

  return {
    getValue,
    setValue,
    onChange,
  };
}
```

`setValue` should do 2 things: update the inner value, and also notify all subscribers that the value has been changed.

```javascript
function createStore(defaultValue) {
  let value = defaultValue;

  const callbacks = [];

  const getValue = () => {
    return value;
  };

  const setValue = (newValue) => {
    value = newValue;
    callbacks.forEach((cb) => cb(newValue));
  };

  const onChange = () => {
    // implement me
  };

  return {
    getValue,
    setValue,
    onChange,
  };
}
```

Finally, `onChange` should add the passed callback, and also return a function to remove the callback.

```javascript
function createStore(defaultValue) {
  let value = defaultValue;

  const callbacks = [];

  const getValue = () => {
    return value;
  };

  const setValue = (newValue) => {
    value = newValue;
    callbacks.forEach((cb) => cb(newValue));
  };

  const onChange = (cb) => {
    callbacks.push(cb);
    return () => {
      const index = callbacks.findIndex(cb);
      callbacks.splice(index, 1);
    };
  };

  return {
    getValue,
    setValue,
    onChange,
  };
}
```

The implementation is pretty naive.

For example, we will notify all subscribers even if the value didn't change (setValue invoked with the same value twice).

Or, you might argue that setValue should accept a function instead to be able to make atomic changes.

Long story short, there's a room for improvement. But as a skeleton it'll do, and as I promised it's just 28 lines of code.

## Let's draw a line here real quick

Here's what we've learned.

1. A shared state can be implemented outside of React ecosystem (you don't need Context, or redux, or whatever) as a simple store with callbacks.
2. That store can be used to share state even across different components and even different frameworks.
3. We need a bit of code to connect our store toa particular framework. For React, it was a simple hook, using `setState` to cause re-render.


We will show how to implement a shared state manager in plain JavaScript, with no extra libraries and completely framework-agnostic, and we will use it to share state between React components.

Shared State Without React's Context


ECMAScript 2020, the 11th installment of our favorite programming language, contains a handful of new features. Some are small ones, but others have the potential to change forever the way we write JavaScript.

This article is an attempt at a short and concise overview of those new features. Grab your cup of tea and let's go.

## Dynamic import()

ES2015 introduced the `static import` syntax. Now you could export a variable from one module and then import it in another.

```javascript
// utils.js
export function splitName(name) {
  return name.split(" ");
}

// index.js
import { splitName } from "./utils";

console.log(splitName("John Snow"));
```

That syntax is called static because you can't import a module dynamically (depending on some conditions) at runtime. Note that it's not necessarily a bad thing: static imports can be optimized at compile time, allowing for [Tree Shaking](https://webpack.js.org/guides/tree-shaking/).

Dynamic imports, on the other hand, when used wisely, can help with reducing bundle size by loading dependencies on-demand.

The new `dynamic import` syntax looks like a function (but it's not), and it returns [a promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise), which also means we can use [async/await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) with it.

```javascript
// ...
const mod = figure.kind === "rectangle" ? "rectangle.js" : "circle.js";
const { calcSquare } = await import(mod);
console.log(calcSquare(figure));
```

## Nullish coalescing

The popular way of setting a default value with [short-circuting](https://en.wikipedia.org/wiki/Short-circuit_evaluation) has its flaws. Since it's not really checking for the emptiness, but rather checking for the [falsyness](https://developer.mozilla.org/en-US/docs/Glossary/Falsy), it breaks with values like `false`, or `0` (both of which are considered to be falsy).

ES2020 introduces a new operator `??` which works similarly but only evaluates to the right-hand when the initial value is either `null` or `undefined`.

Here's a quick example:

```javascript
const initialVal = 0;

// old way
const myVar = initialVal || 10; // => 10

// new way
const myVar = initialVal ?? 10; // => 0
```

[I wrote a detailed article](https://www.strictmode.io/articles/nullish-coalescing-vs/) about this feature and how it compares to the other methods for setting a default value.

## Optional chaining

The new `optional chaining` operator aims to make the code shorter when dealing with nested objects and checking for possible `undefineds`.

```javascript
const user = { name: "John" };

// Fails with `Uncaught TypeError: Cannot read property 'city' of undefined`
const city = user.address.city;

// Works but verbose
let city = "Not Set";
if (user.address !== undefined && user.address !== null) {
  city = user.address.city;
}

// Works and concise but requires a 3rd party library
const city = _.get(user, "address.city", "Not Set");

// 🤗
const city = user?.address?.city ?? "Not Set";
```

## BigInt

`BigInt` is a new object that represents numbers higher than `Number.MAX_SAFE_INTEGER` (which is `2^53 - 1`). While for normal folks, it may sound more than enough, for some math applications and machine learning, the new `BigInt` type comes in handy.

It comes with its own literal notation (just add an `n` to a number):

```javascript
const x = 9007199254740991n;

// or it can be constructed from a string
const y = BigInt("9007199254740991234");
```

`BigInts` come with their own algebra, which is not translated to regular numbers by which we can't mix up numbers and BigInts. They should be coerced to either type first.

```javascript
1 === 1n; // => false
1n + 1; // throws Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions
6n << 3; // nope
6n << 3n; // that works
```

## String.matchAll

So here's an example. Imagine, you have a very long string of text, and you need to extract all the tags (that are words starting with `#`) out of it. [Regular expressions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions) to the rescue!

```javascript
const tweet = "#JavaScript is full of #surprises. Both good and bad ones #TIL";

for (h of tweet.matchAll(/(#\w+)/g)) {
  console.log(h[0]);
}

// or

const tags = [...tweet.matchAll(/(#\w+)/g)];
```

`matchAll` returns an iterator. We could either iterate over it with `for..of`, or we can convert it to an array.

## Promise.allSettled

Remember the [Promise.all](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all) function? It resolves only when all of the passed promises get resolved. It rejects if at least one of the promises got rejected, while the others may still be pending.

The new `allSettled` behaves differently. It resolves whenever all of the promises finished working, that is, became either fulfilled or rejected. It resolves to an array that contains both the status of the promise and what it resolved to (or an error).

Thus, `allSettled` is never rejected. It's either `pending`, or `resolved`.

A real-world problem might be removing a loading indicator:

```
// const urls = [...]
try {
  await Promise.all(urls.map(fetch))
} catch (e) {
  // at least one fetch is rejected here, but there may others still pending
  // so it may be too early for removing the loading indicator
  removeLoading()
}

// with allSettled
await Promise.allSettled(urls.map(fetch))
removeLoading()
```

## globalThis

In JavaScript, there's always one big context object that contains everything. Traditionally, in browsers it was `window`. But if you try accessing it in Node application, you'll get an error. There is no `window` global object in Node; instead there is `global` object. Then again, in WebWorkers, there is no access to `window`, but there is `self` instead.

The new `globalThis` property abstracts away the difference. Meaning that you can always refer to `globalThis` without caring in which context you are now.

Now, if you think that the naming is rather awkward, I'm totally with you, but note that naming it `self` or `global` could make some older code incompatible. So I guess we'll have to live with that.

## What's next?

For your convenience, here are the links to the MDN documentation for each of the features mentioned in this article.

- [Dynamic imports](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import)
- [Nullish coalescing operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing_operator) but also [my own article](https://www.strictmode.io/articles/nullish-coalescing-vs/)
- [Optional chaining](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)
- [BigInt](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt)
- [Promise.allSettled](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled)
- [globalThis](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis)

If you like articles like this, you can [follow me on Twitter](https://twitter.com/janis_t) to get notified about the new ones.


Here's a list of features coming with ECMAScript2020 along with examples. Have a quick glimpse at dynamic imports, nullish coalescing, optional chaining, BigInt, and more.

What's new in ECMAScript 2020


> **TL;DR**: For better readability, keep the "cognitive stack" as small as possible. Scroll to the bottom for some practical rules. Read on to see how they derive from the first principle.

Readability is a quality of your code that tells how easy it is for an **average** developer to read and understand your code.

I want to start with a very simple idea. The less information you have to keep in your head while reading the code, the easier it is to make sense of it.

I like to think of it as [a stack](<https://en.wikipedia.org/wiki/Stack_(abstract_data_type)>). While we read through the code and we stumble across different variable and function declarations (or any important pieces of information really), we push it into our "cognitive stack", and then later when it is no longer needed our brain can pop them out.

The more stuff we have in our stack, the harder it is to reason about the code. And at some point (which happens to me embarrassingly often), we can have it overflowed when we are no longer capable of digesting the information.

So how do you write readable code?

The general idea is to keep the "cognitive stack" size minimal.

In this article, I'll try to show how several readability rules derive from this simple idea.

## Refactoring

Have a look at this only slightly exaggerated example,

```javascript
async function processResults() {
  let elm,
    urlBase = "https://api.mydomain.com/api/v1/",
    href = window.location.href,
    query;

  const userSession = readSession();

  let searchPars = "";
  if (href.indexOf(?) > -1) {
    searchPars = href.split("?")[1];
  }

  elm = document.querySelector("body");

  if (searchPars) {
    const pairs = searchPars.split("&").map((p) => p.split("="));
    const q = pairs.find((p) => p[0] === "query");
    if (q) {
      query = q[1];
    } else {
      query = "";
    }
  } else {
    query = "";
  }

  const data = await fetch(
    urlBase + `/?query=${query}&token=${userSession.token}`
  );
  const json = await data.json();

  elm.append(
    document
      .createElement("div")
      .append(document.createTextNode(`Query: ${query}`))
  );
  data.forEach((d) => {
    elm.append(
      document.createElement("div").append(document.createTextNode(d))
    );
  });
}
```

After spending some time reading through this piece of code, you will easily figure out what it does. It reads some parameters from the URL, then loads some data and renders the result on the screen. But you probably also notice that it's far from perfection, and your hands are itchy to refactor it.

Let's try to do that, keeping in mind the "minimal cognitive stack size" principle.

The first thing that you notice is that the `elm` variable is declared tens of lines before it is actually used. While we read that piece from top to bottom we have to keep that variable in mind, while there is absolutely no reason for that. That leads us to our first conclusion,

> **Keep the declarations as close to the first usage as possible.**

Plus, it also declared with the `let` keyword. Which means we should keep in mind the fact that it can get changed (while it doesn't).

> **Prefer `const` to `let`, immutable data to mutable.**

Let's apply those 2 ideas and see what we'll have.

```javascript
async function processResults() {
  // read the query param from the URL
  const href = window.location.href;

  let query;
  if (href.indexOf("?") > -1) {
    const searchPars = href.split("?")[1];
    if (searchPars) {
      const pairs = searchPars.split("&").map((p) => p.split("="));
      const q = pairs.find((p) => p[0] === "query");
      if (q) {
        query = q[1];
      } else {
        query = "";
      }
    } else {
      query = "";
    }
  } else {
    query = "";
  }

  // Load the data
  const userSession = readSession();
  const data = await fetch(
    `https://api.mydomain.com/api/v1/?query=${query}&token=${userSession.token}`
  );
  const json = await data.json();

  // render the results
  const elm = document.querySelector("body");
  elm.append(
    document
      .createElement("div")
      .append(document.createTextNode(`Query: ${query}`))
  );
  data.forEach((d) => {
    elm.append(
      document.createElement("div").append(document.createTextNode(d))
    );
  });
}
```

OK, it looks a little bit better now.

But what also happened now that we moved the variable declarations closer to their first usage, is that now the 3 distinct parts have emerged. This means that we can extract those into their own functions.

Why would we want to do that? Because a function has its own lexical scope. And a new lexical scope means that we can "nullify" our stack inside of it.

> **Prefer breaking down code into the smaller functions**

That only holds true unless a function does something to its environment (i.e. modifies variable from the outer scope), and if the result depends only on the passed params. Those kind of functions are called [the pure functions](https://en.wikipedia.org/wiki/Pure_function). When a function is not pure, we can't empty our stack as we'll need to keep in mind the state of the outer environment.

> **Prefer the pure functions**

```javascript
async function processResults() {
  const query = extractQueryParam(window.location.href);
  const data = loadData(query);
  render(data);
}

function extractQueryParam(url) {
  let query;

  if (url.indexOf("?") > -1) {
    const searchPars = href.split("?")[1];
    if (searchPars) {
      const pairs = searchPars.split("&").map((p) => p.split("="));
      const q = pairs.find((p) => p[0] === "query");
      if (q) {
        query = q[1];
      } else {
        query = "";
      }
    } else {
      query = "";
    }
  } else {
    query = "";
  }

  return query;
}

async function loadData(query) {
  const userSession = readSession();
  const data = await fetch(
    `https://api.mydomain.com/api/v1/?query=${query}&token=${userSession.token}`
  );
  const json = await data.json();
  return json;
}

function render(data) {
  // render the results
  const elm = document.querySelector("body");
  elm.append(
    document
      .createElement("div")
      .append(document.createTextNode(`Query: ${query}`))
  );
  data.forEach((d) => {
    elm.append(
      document.createElement("div").append(document.createTextNode(d))
    );
  });
}
```

Pure functions is a God sent. Those are small isolated pieces of code that can be tested, modified and reasoned about separately. What's even better you can name them as well! Naming the pieces of your code is the kind of superpower you can and should use to make your code more readable. Good naming means that a reader may not even have to look what's inside of your function, and save time.

Note how, in this example the higher-order function go first, and then the functions of lower abstraction order (=importance) come next. We can do this in JavaScript because of the [hoisting](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting), which basically means that you can declare functions after they being used. Doing so with variables can lead to bugs, but functions fit just nice and let us build our code in a way, where the higher order details come first, and the implementation comes second.

> **Keep the code responsible for higher-order abstraction higher in the file**

Now, lets quickly glimpse at the `extractQueryParam` function.

```javascript
function extractQueryParam(url) {
  let query;

  if (url.indexOf("?") > -1) {
    const searchPars = href.split("?")[1];
    if (searchPars) {
      const pairs = searchPars.split("&").map((p) => p.split("="));
      const q = pairs.find((p) => p[0] === "query");
      if (q) {
        query = q[1];
      } else {
        query = "";
      }
    } else {
      query = "";
    }
  } else {
    query = "";
  }

  return query;
}
```

It is pure (the output result depends only on the input params), which is nice, but still it doesn't look right. There are several nested `if` branches which means that the code leans to the right. What's worse is that at every branch we have have to push more info into our `cognitive stack` as our `query` variable can be modified at any line. There is [a remedy for this](http://wilsonpage.co.uk/return-early/).

> **Prefer returning early**

```javascript
function extractQueryParam(url) {
  if (url.indexOf("?") === -1) {
    return "";
  }

  const searchPars = href.split("?")[1];
  if (!searchPars) {
    return "";
  }

  const pairs = searchPars.split("&").map((p) => p.split("="));
  const q = pairs.find((p) => p[0] === "query");
  if (!q) {
    return "";
  }

  return q[1];
}
```

Now we got rid of the `query` variable altogether.

## Getting philosophical

It's easy to see that the very same principle holds for any complex system.

Splitting a complex problem into several smaller ones is always beneficial in terms of minimizing the cognitive load. You can't split them randomly thought.

To solve a problem, you need to find the right ["mental model"](https://en.wikipedia.org/wiki/Mental_model) - a way to think about it that keeps your inner "cognitive stack" relatively small. Programming is all about managing complexities, and this is just another side of it.

That's where the principles like ["divide and conquer"](https://en.wikipedia.org/wiki/Divide_and_rule) come from.

The infamous [Occam's razor](https://en.wikipedia.org/wiki/Occam%27s_razor) leads to the same idea. Not multiplying the entities without necessity is again keeping your "cognitive stack" as small as possible.

## Conclusion

We deduced several readability rules from the very simple principle of keeping our `cognitive stack` as small as possible.

Here they are once again to recap.

- Keep the declarations as close to the first usage as possible
- Prefer `const` to `let`, immutable data to mutable.
- Break down into the smaller functions
- Prefer using the pure functions
- Keep the code responsible for higher-order abstraction higher in the file
- Prefer returning early

Obviously, that's not an exhaustive list, and you can come up with many others yourself.


How do you write readable JavaScript? Is there a single rule to keep in mind? It turns out there is and it's a very simple one.

Readable JavaScript


The "Nullish Coalescing" (which is still [in stage 3](https://github.com/tc39/proposal-nullish-coalescing) by the way) has made its way into [the latest TypeScript release](https://devblogs.microsoft.com/typescript/announcing-typescript-3-7/), so I thought that might be a perfect time to finally have a closer look at what is this and how does it compare to other options.

**Note**: Most of the examples in this article are in pure `JavaScript`, except where noted.

## What is the nullish coalescing?

In a nutshell, the nullish coalescing operator is set to help in a handful of cases where the short-circuit `||` operator falls short (always intend your puns!).

The short-circuiting (`||`) is a convenient way to set defaults.

```
const myVar = x || "default"
```

If `x` is `null` or `undefined`, `myVar` will end up being "default." That's because `null` and `undefined` are [falsy values](https://developer.mozilla.org/en-US/docs/Glossary/Falsy) - they evaluate to `false` when used with logical operations.

The problem is that there are other `falsy` values, those include `false` itself, `0` and an empty string `""` (if you need to check whether a value is truthy or falsy, the easiest way is to double negate it `!!myVar`).

> Fun fact! This is not so in other languages. In [Ruby](https://www.ruby-lang.org/en/), both `0` and `""` are truthy. While in [Python](https://www.python.org/), an empty array `[]` and `{}` are considered to be falsy.

Here's a proper example.

You want to provide a default value for a number of spaces used in your editor. The function can accept any decimal number or `false` (which means it should use the Tab character instead). The default value is 2.

```javascript
function setTabSize(tabSize) {
  set("tabSize", tabSize || 2);
}
```

The problem with that function is that it won't let us use the tabs instead of spaces (which might be a good thing?).

Calling `setTabSize(false)` results in setting `tabSize` to `2`. That's because `false || 2 === 2`.

What if we could only set it to 2 when there is no value at all (that means `tabSize` arguments comes in as `null` or `undefined`)? That's exactly what `??` operator is for.

```javascript
function setTabSize(tabSize) {
  set("tabSize", tabSize ?? 2);
}
```

Now, `setTabSize(false)` will actually set the value to `false`. While calling the function with `null` or without any arguments at all will lead to using the default value.

## A comparison

Let's compare how a function behaves with different techniques used for setting a default values.

Here's a simple function that takes an argument and prints it to the console.

**Default param**:

```javascript
function p(arg) {
  console.log(arg);
}

p(); // => "default"
p(null); // => null
p(undefined); // => "default"
p(""); // => ""
p(false); // => false
p(0); // => 0
```

**Short-circuting**:

```typescript
function p(name) {
  console.log(name || "default");
}
p(); // => "default"
p(null); // => "default"
p(undefined); // => "default"
p(""); // => "default"
p(false); // => "default"
p(0); // => "default"
```

**Nullish coalescing**:

Note, this example is in **TypeScript**. I've marked the sole function argument as `any` cause we want to test it with different types, and we don't want TypeScript to stand in our way.

```typescript
function p(arg?: any) {
  console.log(arg ?? "default");
}

p(); // => "default"
p(null); // => "default"
p(undefined); // => "default"
p(""); // => ""
p(false); // => false
p(0); // => 0
```

The "Nullish coalescing" seems to have the most proper behaviour. Here's how it translates to JavaScript:

```javascript
function p(name) {
  console.log(name !== null && name !== void 0 ? name : "default");
}
```

No magic there. It simply compares the value to `null` and `undefined`.

> Fun fact! People still use `void 0` instead of `undefined` because in older versions of JavaScript (<1.5 ?) `undefined` was a global variable that you could override.

Note that `"" ?? "string"` evaluates to `""`. Which may not always be desired. For example, an API response might return null in some cases, and an empty string in the others. In those cases, I'd still use `||` operator.

That bothers me a little because `??` turns out not to be a drop-in replacement to `||`, and now we'll always have to remember the difference and think ahead which one is most suitable in the particular case.

## Runtime checking

I wanted to stop the article here, but there is one thing that bothers me about the `setTabSize`.

We can make it better, if we will be explicit about what we expect as the function's argument and then fail fast and loud.

```javascript
const setTabSizeExpectedValues = [null, undefined, 2, 4];
function setTabSize(tabSize) {
  // first let's ensure we get an argument of expected value
  if (!setTabSizeExpectedValues.some((v) => tabSize === v)) {
    throw new Error(`Unexpected tabSize value: ${tabSize}. `);
  }

  set("tabSize", tabSize || 2);
}
```

In this case, it doesn't really matter if we use `||` or `??`, we can always be sure that our function behaves as expected, and if not we will see a clear fail reason in the logs.

Obviously, you don't want to do this for every single case, as it adds some performance and cognitive overhead to your function but in some cases it is justified.


What is nullish coalescing? How does it compare to setting a default function argument or the short-circuiting with `||`?

Nullish Coalescing vs. Short-circuit vs. Default Params

Forms interactions.

It's too easy to mess them up with JavaScript, AJAX, and modern frameworks. Being unable to submit with enter, or jump between the fields with tab is not fun. The good news is that the fix is usually trivial.

Lets have a look at some of the properties of a good form.

**Here's a checklist**:

- Put focus on the first type-able input
- Make sure your labels are clickable
- Pressing enter should submit the form
- Tab moves the focus into the next input field
- Focus on the first invalid field on validation error
- Background network calls (as any other asynchronous work) should be indicated in UI

## Autofocus on the first input

Reaching out for a mouse when you type is quite annoying. Putting the cursor into the first input of the form lets the user start typing right away.

Doing this is as simple as adding [the autofocus attribute](https://davidwalsh.name/autofocus).

```html
<form>
  <input placeholder="E-mail" type="email" autofocus />

  <input placeholder="Password" type="password" />

  <input type="submit" />
</form>
```

A second benefit is that on mobile browser will auto-scroll the form into the view.

You might not want to do this when you have multiple forms on one page (though having 2 forms one page is a questionable practice).

**Note**: If you don't use the real labels (`label` tags), but placeholders only, you'd also want to make sure that the placeholder doesn't disappear when user focus into an empty field (some UI libraries will do this out of the box). The context is important.

## Make sure your labels are clickable

When a user clicks on a label, it should focus on the corresponding input. Clicking on a checkbox label should check/uncheck it.

You don't even need to do anything. This is the default behavior. Just make sure to use the real _label_ elements with `for` attribute assigned to the `id` of the element. If you don't have an `id`, you can wrap input in label and that should also work.

Here's another catch. A user knows if something is clickable from what the cursor looks like. So it's a good idea to change the cursor to "pointer". Here's a pretty trivial CSS snippet:

```css
label {
  cursor: pointer;
}
```

## Pressing enter should submit the form

When using AJAX to submit a form, it is not obligatory to use form's `onSubmit` handler. Button's `onClick` can be used instead, and sometimes developers don't use the `form` tag at all.

But a bunch of inputs might look like a form, while lack some important features a real `form` has. In this case, nothing's gonna happen when you press the enter inside a field.

Making it work is straightforward. Wrap the inputs in a submittable form and make your AJAX interactions on form submit.

```html
<form onsubmit="onSubmit">
  
</form>
```

```javascript
function onSubmit(e) {
  e.preventDefault();
  // actually submit the form with AJAX
}
```

**Bonus**: Make pressing `Esc` clear the current field and your users will love you.

## Tab moves the focus into the next input field

In a perfect scenario, you don't need a mouse to submit a form.

You start with the first field (focus is already there), then you type the data, and hit the `Tab` to move from one field to another.

Sometimes (depending on your markup) you might find that this is not the case, and the focus moves to some meaningless elements like links or images.

If that's the case, you can fix it by using [the tabindex attribute](https://www.wufoo.com/html5/tabindex-attribute/) to explicitly set what elements (and in what particular order) should it move to.

Also, while we are here, it's easy to see that an input has focus because you have a cursor blinking inside it. Not so easy with dropdowns or submit buttons. Very often a submit button does receive a focus, but since there is no visual clue, it's not obvious whether it's any use in pressing enter.

Here's a simple CSS for that:

```css
button:focus {
  border: 1px solid blue;
}
```

## Focus on the first invalid field on validation error

Getting some validations errors is a quite appalling experience all by itself. The primary goal is to help the user with fixing those errors. There should be a clear error message, and the invalid fields should be highlighted in red.

Not so obviously, it is a very good practice also to put a focus on the first invalid field so that a user can fix the input right away. As a bonus browser will also scroll the field into the view.

```javascript
function onSubmitFail() {
  const field = document.querySelector("form .invalid");
  field.focus();
}
```

## Any AJAX processing should be communicated to user

Here's the thing. If a user submits a form normally (without AJAX), it is obvious that the form is loading because browsers will put some loading indicator near the address bar.

But on the other hand, when using an AJAX request, we will need to deal with the indicator ourselves.

We should explicitly tell the user: we took your data, now we're processing it, please wait. A simple spinner would do. But it is not magical, and it is easy to forget to put it.

**Note**: Also, it's a good practice to disable the form while submitting. Forgetting to do so may lead to multiple submissions (especially if the request takes some time to finish).

That was the 6 small and easily-fixable form problems. Please, pay attention! Respect your user!

Forms interactions. Even the most popular websites have some very basic problems with them, unable to submit by pressing enter, tab won't move the focus on the next field, and so on. The good news is that the fix is trivial.

6 Easily Fixable Web Form Issues


Every new JavaScript feature goes through four stages until it gets officially included in the language. A proposal starts at Stage 0, and chances are it will never get out of this stage. At Stage 3 though the proposal has almost 100% chance getting into the next version of the language. By that time there are usually already babel transformation plugins presented, and some browser engines might already have it implemented.

Now let's have a look at some of the most anticipated proposals that have high chances to get into the language.

## [BigInt](https://github.com/tc39/proposal-bigint) (Stage 3)

BigInt is a new primitive type that allows to have integers and perform math operations on numbers higher than `Number.MAX_SAFE_INTEGER` (which is `9007199254740991`).

The proposed syntax goes like this:

```javascript
const x = 9007199254740991n;

const y = BitInt("9007199254740991234");
```

Note that little `n` at the end of the number. In the second example, we use a constuctor to build a BigInt from a string, cause building from a regular number for such a big one wouldn't work.

It also can be compared to the regular numbers, and it is not equal strictly but loosely it is:

```javascript
0n === 0; // false
0n == 0; // true
```

Though the biggest gotcha here is that you can't mix in the regular numbers with BitInts performing Math operations:

```javascript
1n + 2; // TypeError!
```

## [Private methods](https://github.com/tc39/proposal-private-methods) (Stage 3)

I believe some of the features are implemented only to make JavaScript look more familiar to devs working in big corporations (that is `Java` and `C#` programmers). Thus all the changes around classes started from EC6 (just reminder, there were no "classes" prior to that in JavaScript).

Of cause, EC6 classes are still missing some of the features, one of which is private members.

Not a fan, but I guess this is where it was heading.

Soon we'll be able to add private methods and members to classes. They will be accessible when called from the other methods but won't be visible from the outside. Thus it lets us hide the implementational details of the class.

Here's an example:

```
class Counter extends HTMLElement {
  #xValue = 0;

  get #x() { return #xValue; }
  set #x(value) {
    this.#xValue = value;
    window.requestAnimationFrame(this.#render.bind(this));
  }

  #clicked() {
    this.#x++;
  }

  constructor() {
    super();
    this.onclick = this.#clicked.bind(this);
  }

  connectedCallback() { this.#render(); }

  #render() {
    this.textContent = this.#x.toString();
  }
}
```

Note that little `#` symbol. This is a marker for a private field or method.

Another proposal close to this one is [Static class features](https://github.com/tc39/proposal-static-class-features/) (also at Stage 3), which allows for adding static fields into classes and thus making JavaScript classes complete clones of `Java` classes (syntactically at least)

## [Nullish Coalescing for JavaScript](https://github.com/tc39/proposal-nullish-coalescing) (Stage 3)

This one should be particularly handy. The way `falsy` notion works in JavaScript is that all values are considered either truthy or falsy. That is often used to set a default value for a variable. For example,

```javascript
function greet(argName) {
  const name = argName || "stranger"
  console.log(`Welcome, ${name}`)
}
```

However, `0`, `''` (the empty string), and `false` are also "falsy". Which depending on the context might be proper values that should not be replaced with the defaults.

So what we really need here is some operator that will ensure the presense of the value (thus, not `null` and not `undefined`). Meet the new `??` operator:

```javascript
const weight = 0 || 10; // => 10
const weight = 0 ?? 10; // => 0
```

Such an operator is very welcomed as it will probably help to reduce and prevent many errors.

## [Optional Chaining](https://github.com/tc39/proposal-optional-chaining) (Stage 3)

When you need to dif up a value from a nested object, you do something like this:

```javascript
const age = deparatments[0].employees[0].personal.age;
```

However, if you're not sure about your data, you might get null or undefined at some point in this chain so it will break with an exception. One way to make it safer might be to insert the default values:

```javascript
const age = (
  ((((deparatments || [])[0] || {}).employees || [])[0] || {}).personal || {}
).age;
```

This is not too readable though. As a better alternative, we might use a third party library (say, `lodash`):

```javascript
const age = _.get(deparatments, "[0].employees[0].personal.age");
```

With the new `optional chaining` operator `?.`, we can access the fields safely:

```javascript
const age = deparatments?.[0]?.employees?.[0]?.personal?.age;
```

This code will not throw an exception but return `null` instead.

Just a quick note here, as I already see how this can be overused. Long chains like this can easily lead to bugs which are hard to debug.

Don't use it when the data structure is defined and should not contain nulls/undefined. For example, if there is an error in the backend code in the API (or the data is corrupted in the databse), you actually want it fail with the exception as soon as possible so you know that something is wrong.

## [Decorator](https://github.com/tc39/proposal-decorators) (Stage 2)

You might have already used decorators. (those little markers starting with `@`). They are used quite intensively in Angular and are supported in TypeScript or through a babel plugin. So it's a rather surprise it is still only at stage 2.

The core idea of decorators is a possibility to alter the functionality of some code by wrapping it up into another function.

For example,

```javascript
import { @logged } from "./logged";

class C {
  @logged
  method(arg) {
    this.#x = arg;
  }

  @logged
  set #x(value) { }
}
```

In this case the `method` doesn't know anything about logging, but by wrapping it or marking it with `@logged` annotation we can "inject" the logging capability right into it.

Here's an implementation of it:

```javascript
export decorator @logged {
  @wrap(f => {
    const name = f.name;
    function wrapped(...args) {
      console.log(`starting ${name} with arguments ${args.join(", ")}`);
      f.call(this, ...args);
      console.log(`ending ${name}`);
    }
    wrapped.name = name;
    return wrapped;
  })
}
```

Basically, here we simply get the initial function, then we wrap it into a new function surrounding the initial code with some additional functionality (in this case, we simply add `console.log`).

Decorators are quite famous in an object-oriented language (though sometimes they are called `annotations`). This particular implementation is very akin to [Python one](https://realpython.com/primer-on-python-decorators/).

## Other cool proposals out there

- [Underscore as a numeric separator](https://github.com/tc39/proposal-numeric-separator)

```javascript
let budget = 1_000_000_000; // 1 billion
```

- [WeksRefs](https://github.com/tc39/proposal-weakrefs)

This one allows having weak references to objects (when you have a weak reference only garbage collector may still destroy the object). It also adds finalizers (methods that are executed when the object is being destroyed).

- [Function implementation hiding proposal](https://github.com/tc39/proposal-function-implementation-hiding)

A rather curious proposal allowing to hide function implementation by adding a special directive:

```javascript
function foo() {
  const x = () => {};

  const y = () => {
    "hide implementation";
    class Z {
      m() {}
    }
  };
}
```

- [Pipeline operator](https://github.com/tc39/proposal-pipeline-operator)

Quite anticipated but still at the early Stage 1. I wrote a full article on [this feature here](https://www.weekendjs.com/articles/the-pipeline-operator-in-javascript/).

- [Partial application](https://github.com/tc39/proposal-partial-application)

Partial application is something many functional programming languages have. Also, one can achieve the same thing with a 3rd party library like Ramda.js. Here though it becomes a part of language syntax:

```javascript
const addOne = add(1, ?); // apply from the left
addOne(2); // 3

const addTen = add(?, 10); // apply from the right
addTen(2); // 12
```

- [Promise.any](https://github.com/tc39/proposal-promise-any)
  `Promise.any` returns a promise that is fulfilled by the first given promise, or rejected with an array of rejection reasons if all of the given promises are rejected.

## Where to go next?

We've only scratched the surface here. If you want to read more about coming features, the best place to start is [the official page of the tc39 commitee](https://github.com/tc39/proposal-string-replaceall).

Also, if you'd like to use some of the features today, there are babel transformation plugins available for most of them. Just google `babel` + the name of the feature.


In this article, let's have a closer look at what features are likely to become a part of official JavaScript spec very soon.

What Future Holds For JavaScript — Upcoming Features And Proposals


I find it extremely beneficial to ask a job seeker to solve some of the following exercises. It helps to understand how good is a person you're dealing with in JavaScript and also shows how he or she thinks about the problems in general.

In this article, I'd like to share some of those exercises.

Just putting them here in no particular order. Feel free to use any of them in your next interview.

## What is `reduce`? Please implement the `map` and `filter` functions with `reduce`.

**SOLUTION**: `Array.proptotype.reduce` is a function on an array, which allows to iterate through the array and collect a result to return (which can be modified on each iteration). It takes a reducer function and an initial value for the accumulator.

```javascript
const arr = [1, 2, 3];
arr.reduce((acc, el) => {
  return el + acc;
}, 0); // => 15
```

Here's how we can implement `map`:

```javascript
function map(arr, mapper) {
  return arr.reduce((acc, el) => {
    return [...acc, mapper(el)];
  }, []);
}
map([1, 2, 3], (x) => x * x); // => [1, 4, 9]
```

And here's `filter`:

```javascript
function filter(arr, f) {
  return arr.reduce((acc, el) => (f(el) ? [...acc, el] : acc), []);
}
filter([-1, 0, 1, 2], (x) => x > 0); // => [1, 2]
```

## Write the `uniq` function that removes repeated elements from the array.

**SOLUTION:**

```javascript
function uniq(arr) {
  return arr.reduce(
    (acc, el) => (acc.indexOf(el) > -1 ? acc : [...acc, el]),
    []
  );
}
uniq([1, 2, 3, 1, 2]); // => [1, 2, 3]
```

An even shorter solution is possible if we utilize [Set](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set) which can\t have non-unique members:

```javascript
const uniq = (arr) => [...new Set(arr)];
```

## `Flatten` is a function that puts elements from the inner arrays into the top array.

Can you implement `deepFlatten` so that

```javascript
deepFlatten([1, [2], [[3], [4, [5]]]]); // => [1, 2, 3, 4, 5]
```

**SOLUTION**:

```javascript
function deepFlatten(arr) {
  return arr.reduce(
    (acc, el) =>
      Array.isArray(el) ? [...acc, ...deepFlatten(el)] : [...acc, el],
    []
  );
}
```

## How many users per hobby?

Assuming we have an array of users

```javascript
const users = [
  { name: "John", hobbies: ["singing", "walking", "playing guitar"] },
  { name: "Terry", hobbies: ["swimming", "playing guitar"] },
  { name: "Anna", hobbies: ["walking", "swimming", "playing guitar"] },
  { name: "Paul", hobbies: ["swimming", "singing"] },
];
```

For each hobby, count the number of users occupied with it.

**SOLUTION**:

```javascript
const hobbies = uniq(flatten(users.map(u => u.hobbies)))
const hasHobby = (h) => (u) => u.hobbies.indexOf(h) > -1
const counts hobbies.map( h => ({
  hobby: h,
  count: users.filter(hasHobby(h)).length,
})) // => [ {hobby: 'singing', count: 2}, ... ]
```

**SOLUTION 2 (Imperative)**:

```javasript
const counts = {}

users.forEach(u => {
  u.hobbies.forEach(h => {
    counts[h] = (counts[h] || 0) + 1
  })
})
```

## Write a sample(arr, n) function that takes n random elements from an array.

**SOLUTION**:

```javascript
function sample(arr, n) {
  const length = arr.length
  const indices = []
  while(indices.length &lt; n){
    const r = Math.floor(Math.random() * length);
    if (indices.indexOf(r) === -1) indices.push(r);
  }
  return indices.map(i => arr[i])
}

sample([1, 2, 3, 4, 5, 6, 7, 8, 9], 3) // => [7, 9, 6]
```

## Write a `memoize` function

It wraps a given function and only runs it once for a list of parameters, saves the result in inner cache and return it the next time.

**SOLUTION (Basic)**:

```javascript
function memoize(fn) {
  const cache = {};
  return function (...args) {
    const key = args.join("-");
    if (!cache[key]) {
      cache[key] = fn(...args);
    }
    return cache[key];
  };
}
```

This solution is very simple. But it doesn’t work for some cases. We can make it more complex by asking: what if a function returns a boolean, what if a function is type-unsafe ( 1 vs “1” ), …

## Can you implement a function that will get a value from an object by logical path "a.b.c"?

...no matter how deep, and will return `null` if no value is there without throwing an exception.

Example:

```javascript
safeGet({ a: { b: 5 } }, "a.b"); // => 5
```

**SOLUTION**:

```javascript
function safeGet(obj, path) {
  const keys = path.split(".");
  return keys.reduce((acc, key) => {
    return (acc || {})[key] ? acc[key] : null;
  }, obj);
}

safeGet({ a: { b: 5 } }, "a.b"); //=> 5

safeGet({ a: { b: 5 } }, "a.b.c.d"); //=> null
```

## Currying is when you can call a function with only some arguments

...and it returns a new function which you can use with the rest of the arguments. Write the `curry` function.

Example:

```
sum(1, 2) // => 3
const addOne = sum(1)
addOne(2) // => 3
```

**SOLUTION**:

```javascript
function curry(fn, arity) {
  arity = arity || fn.length
  return function(...args) {
    if (args.length &lt; arity) {
      function f(...lefts) {
        return fn(...args, ...lefts)
      }
      return curry(f, arity - args.length)
    } else {
      return fn(...args)
    }
  }
}

const sum = curry((a, b, c) => a + b + c)

sum(1, 2, 3) //=> 6
sum(1)(2, 3) //=> 6
sum(1, 2)(3) //=> 6
sum(1)(2)(3) //=> 6
```


I find it extremely beneficial to ask a job seeker to solve some of the following exercises. It helps to understand how good is a person you're dealing with in JavaScript and also shows how he or she thinks about the problems in general. In this article, I'd like to share some of those exercises.

JavaScript Interview Exercises With Solutions 2019


It has been 164 issues of [my weekly JavaScript newsletter](https://www.weekendjs.com/) already. And this little article is becoming some sort of a tradition. I did one like this in 2017 and in 2018, so this is the third one.

Here I simply list the authors that **I think** are very good at writing about JavaScript. They are all strong personalities, achievers and what's the most important JavaScript community influencers.

Feel free to put everyone on this list into your favorite RSS reader without a second thought. You just can't regret it.

For every author, I provide a short overview and a small list of greatest hits. Enjoy!

## [Overreacted — Dan Abramov](https://overreacted.io/)

- We know Dan as an author of the Redux and a core member of the React team. But he's also a prolific author.
- His style is a bit informal but at the same time very structured.
- As you would expect he writes mostly about React but also about the human side of software development, soft skills, etc.
- [A Complete Guide to useEffect](https://overreacted.io/a-complete-guide-to-useeffect/)
- [React as a UI Runtime](https://overreacted.io/react-as-a-ui-runtime/)
- [Things I Don't Know as of 2018](https://overreacted.io/things-i-dont-know-as-of-2018/)

## [2ality — Dr. Axel Rauschmayer](http://2ality.com/)

- One of the oldest but still very valuable authors on JavaScript — the earliest blog posts are from 2005.
- He's also the author of several free ebooks: [“Exploring ES6”](http://exploringjs.com/es6/), [“Exploring ReasonML“](http://reasonmlhub.com/exploring-reasonml/)
- Axel writes about the modern JS features (ECMAScript20xx) and proposals
- [ES proposal: ](http://2ality.com/2019/01/symbol-prototype-description.html)`[Symbol.prototype.description](http://2ality.com/2019/01/symbol-prototype-description.html)`
- [Future JavaScript: what is still missing?](http://2ality.com/2019/01/future-js.html)

## [Tyler McGinnis](https://tylermcginnis.com/)

- Tyler is the author of [several](https://tylermcginnis.com/courses/react-fundamentals/) [successful](https://tylermcginnis.com/courses/modern-javascript/) [video](https://tylermcginnis.com/courses/react-router/) [courses](https://tylermcginnis.com/courses/redux/)
- Even though he doesn't write too often, the articles are usually very deep and come together with a video
- He writes a lot about Modern JavaScript, React and Redux
- [JavaScript Modules: From IIFEs to CommonJS to ES6 Modules](https://tylermcginnis.com/javascript-modules-iifes-commonjs-esmodules/)
- [Code Splitting with React and React Router](https://tylermcginnis.com/react-router-code-splitting/)
- [var vs let vs const in JavaScript](https://tylermcginnis.com/var-let-const/)

## [Human Who Codes — Nicholas C. Zakas](https://humanwhocodes.com/)

- Nicholas is a frequent conference speaker and the author of “[Understanding ECMAScript 6](https://amzn.to/2PGD9eI)” and other books
- Oh, and also he created [the eslint](https://eslint.org/).
- [The ECMAScript 2016 change you probably don't know](https://humanwhocodes.com/blog/2016/10/the-ecmascript-2016-change-you-probably-dont-know/)
- [My (somewhat) complete salary history as a software engineer](https://humanwhocodes.com/blog/2018/10/my-somewhat-complete-salary-history-software-engineer/)

## [Reginald Braithwaite](https://raganwald.com/)

- Reginald wrote one of my favorite JavaScript books – [“JavaScript Allongé”](https://leanpub.com/javascriptallongesix)
- His articles are not aimed at the beginners, as he writes mostly about some advanced JavaScript (and general programming) stuff
- [A Brutal Look at Balanced Parentheses, Computing Machines, and Pushdown Automata](http://raganwald.com/2019/02/14/i-love-programming-and-programmers.html)
- [Pattern Matching and Recursion](http://raganwald.com/2018/10/17/recursive-pattern-matching.html)

## **[David Walsh ](https://davidwalsh.name/)**

- David is a senior Mozilla developer and [a core MooTools contributor](https://mootools.net/)
- He writes on widely different topics (not JS-only)
- [Awesome Automation and Integration with Buddy](https://davidwalsh.name/buddy-automation)
- [JavaScript Promises](https://davidwalsh.name/promises)
- [fetch API](https://davidwalsh.name/fetch)

## [Todd Motto](https://toddmotto.com/)

- Todd is a public speaker, he has been teaching JavaScript for more than 5 years. Author of [https://ultimatecourses.com/](https://ultimatecourses.com/)
- If you were thinking there is too much React in this list. Todd writes a lot about Angular and TypeScript.
- [Classes vs Interfaces in TypeScript](https://toddmotto.com/classes-vs-interfaces-in-typescript)
- [Step by Step Custom Pipes in Angular](https://toddmotto.com/angular-pipes-custom-pipes)
- [Typing Arrays in TypeScript](https://toddmotto.com/typing-arrays-typescript)

## [Addy Osmani](https://addyosmani.com/blog/)

- Everyone knows Addy Osmani. He is one of the most prolific authors and conference speakers, the author of “[Learning JavaScript Design Patterns](https://addyosmani.com/resources/essentialjsdesignpatterns/book/index.html)” and other books
- Currently working in Google Chrome team.
- And thus there are lot's of articles written by him on performance optimizations and the inners of Chrome
- [Web Page Usability Matters](https://addyosmani.com/blog/usability/)
- [Exploring a back/forward cache for Chrome](https://addyosmani.com/blog/back-forward-cache/)
- [Native image lazy-loading for the web!](https://addyosmani.com/blog/lazy-loading/)

## [Wes Bos](https://wesbos.com/blog/)

- Wes Bos is a famous author and conference speaker
- He has [created](https://advancedreact.com/) [numerous](https://es6.io/) [JavaScript](https://reactforbeginners.com/) [courses](https://learnnode.com/).
- In his blog posts, he often promotes those. Nevertheless, the articles are highly valuable by themselves
- [Flying a DJI Tello Drone with React and Node.js](https://wesbos.com/drone-javascript/)
- [React's New Context API Explained](https://wesbos.com/react-context/)


Let me show you some of the greatest JavaScript authors. They are all strong personalities, achievers, and in many cases, critical JavaScript community influencers.

Best JavaScript Bloggers To Follow In 2019


For a long time if we wanted to create a stateful component in React we needed to create a class and inherit it from React.Component. But dealing with classes can be a frustrating experience and contradicts the functional nature of React itself. I wrote a [rant article on that before](https://yanis.blog/react-without-this/).

With the release of React v16.7.0-alpha, React team proposed a way to create stateful components based on functions, not on classes.

[Enter the hooks](https://reactjs.org/docs/hooks-intro.html).

Hooks API is a set of functions that allows you to “hook into” the lifecycle or state right from your component function.

In order to use them you need to update to the bleeding age: `npm i react@next react-dom@next --save`.

Now let’s migrate a class component to a functional one. Imaging, we have a component like this.

```javascript
class MyComponent extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      loading: false,
    }
  }

  async function componentWillMount({ setState }) {
    setState({ loading: true })
    const employee = await fetchEmployee(this.props.employeeId)
    setState({ employee, loading: false })
  }

  async remove() {
    await removeEmployee(this.state.employee.id)
    this.setState({ employee: undefined })
  }

  render() {
    const { loading, employee } = this.state
    return (
      <div>
        {
          loading && <Spinner />
        }
        {
          !loading && (
            <div>
              <span>{ employee.name }</span>
              <button onClick={this.remove}>Remove</button>
            </div>
          )
        }
      </div>
    )
  }
}
```

MyComponent shows a single employee. It needs to fetch it via some sort of API first. That’s why we are using componentWillMount. And it also can remove the employee by using another asynchronous API call. When the data is loading, it displays a spinner.

Now, how should we proceed with the hooks?

```jsx
import { useState, useEffect } from "react";

function MyComponent({ employeeId }) {
  const [loading, setLoading] = useState(false);
  const [employee, setEmployee] = useState();

  useEffect(async () => {
    setLoading(true);
    const employee = await fetchEmployee(this.props.employee_id);
    setLoading(false);
    setEmployee(employee);
  });

  return (
    <div>
      {loading && <Spinner />}
      {!loading && (
        <div>
          <span>{employee.name}</span>
          <button onClick={remove}>Remove</button>
        </div>
      )}
    </div>
  );

  async function remove() {
    await removeEmployee(employee.id);
    setEmployee(undefined);
  }
}
```

As you can see code became a little bit more straightforward. `this` is gone. Let’s see what happened.

So we used two hooks here. The first one is [useState](https://reactjs.org/docs/hooks-state.html). As the name implies it allows you to hook into state functionality. It accepts a default value and returns the current value and a setter. So instead of calling `this.setState`, we are now gonna call this setter directly when we want to update the value.

The initialization logic is moved from `componentWillMount` to [useEffect](https://reactjs.org/docs/hooks-effect.html). This is a special hook that is here to allow hooking into the lifecycle of the component.

Also note, how remove function is now defined as a simple function inside of our component function. Because of that, it is able to access the same scope variables as the render part, for example employee. This is a simple JavaScript, no magic here.

## Conclusion

I hope you are as excited as I am about the hooks. This is a long-awaited change that will help to clean up many class-based components (many of which by now looks not better than the infamous jQuery spaghetti).

By the time I’m writing this, the API is still in alpha so some changes may follow. But it is clear that React is headed to a brighter no-OOP future, and I’m really glad it is.


This article covers how to convert a typical React app with a state managed by React.Component to new Hooks framework which allows to write your components without classes.

Converting A React Component To Hooks


There is [a very early proposal](https://github.com/tc39/proposal-pipeline-operator) for the next version of JavaScript (aka ESNext proposal) which I’m really eager to see making it through.

I’m talking about the pipeline operator `|>`.

Immediately, all the guys coming from the functional world know what I’m talking about. Pipeline operator has been for some time in [Elm](http://www.bbenson.co/post/exploring-the-pipeline-pattern-in-elm/), [Elixir](https://elixirschool.com/en/lessons/basics/pipe-operator/), [ReasonML](https://reasonml.github.io/docs/en/pipe-first) and many other functional languages. Unix users can also feel some familiar vibes.

So what is a pipeline?

Well, the basic idea is very straightforward. But let’s consider a problem first.

## THE problem

Very often (or even always?) the code we write is about a series of transformation. We take some piece of data and consequentially transform it to get in the end the desired result.

Let's look at the example you will probably never see in real life ;) We’ll pretend we have the infamous lodash library at our disposition.

```javascript
function maxSalary(departments) {
  // finds the maximal salary across the whole company
  const employees = _.flatten(_.map(departements, (d) => d.employees));
  const salaries = _.map(employees, (e) => e.salary);
  return _.max(salaries);
}
```

Here we take the departments array and then transform it several times to get the max salary amongh all the workers.

And it apparently works. But it introduces several variables along the way which are not really needed here. The alternative is to write the whole expression in one very long row.

```javascript
function maxSalary(departments) {
  return _.max(
    _.map(_.flatten(_.map(departements, (d) => d.employees)), (e) => e.salary)
  );
}
```

I don't even have to tell why it is ugly, right? It's simply incomprehensible. We have to read it from right to left (or rather from the middle and sideways), which for most of us is hard.

Until now, there was only one way to [streamline that expression](https://lodash.com/docs/4.17.11#lodash) but only if having a luxury of using the lodash. Which by chance we do.

```javascript
function maxSalary(departments) {
  return _(departements)
    .map((d) => d.employees)
    .flatten.map((e) => e.salary)
    .max();
}
```

Much better, isn’t it? We don’t introduce any new variables and still, our code is pretty clean. The flow is going from top to the bottom and from left to the right.

The only downside to this approach is that you a have to pack and unpack your data. And you gotta use a 3rd party library, of cause.

## Pipeline to the rescue

So finally, let’s see how the proposed pipeline operator helps to fix this.

```javascript
function maxSalary(departments) {
  return (
    departments
    |> _.map((d) => d.employees)
    |> _.flatten
    |> _.map((e) => e.salary)
    |> _.max
  );
}
```

The `|>` symbol in this code is the pipeline operator. It takes a piece of data on the left side and passes it to a function on its right side.

And this is not a new concept but rather just a syntactic sugar.

Expressions `Math.sqrt(64)` and `64 |> Math.sqrt` are equivalent. The difference is in how we read it. With pipeline operator data flows from left to the right, and thus making it much more comprehensible without the need to introduce extra variables.

## Conclusion

I gotta say that this proposal is at a very early stage. There are actually two proposals now competing with each other, each has its own opinion on how async/await should work with pipelines and how to use the [partial application](https://github.com/tc39/proposal-partial-application), which is a different proposal (stage 1 as I’m writing this).

Still, I’m pretty sure it will go through pretty soon. The benefits are quite obvious especially for those who tried it in other functional languages.

I mean c'mon guys, [we have dragged freaking symbols into JavaScript](https://stackoverflow.com/questions/21724326/what-is-the-motivation-for-bringing-symbols-to-es6).

## Where to go from here

- As usual, I will be glad to [connect on Twitter](https://twitter.com/janis_t)
- [The official TC38 proposal](https://github.com/tc39/proposal-partial-application)
- 2ality tracks [some other interesting features coming](http://2ality.com/2018/02/ecmascript-2019.html) to JavaScript in 2019


Meet the pipe operator, a latest JavaScript proposal that can make the code look much better, cleaner, and shorter. What problem is supposed to solve and why? Let me show you.