DEV Community: Igor Bykov

The most complex challenge of your career

Igor Bykov — Wed, 11 May 2022 19:22:12 +0000

Hey fellows!

You know, when you do interviews, people sometimes ask you things like:

What's the most complex technical challenge you've ever solved?

I think, I even read it somewhere that Elon Musk asks this during interviews as well.

Now, I'm not about to apply to Tesla (don't think they've plugged TypeScript into that fancy display, did they?), but I never had a clear idea what to answer to that question!

Please, showcase your examples. Strike me with them, if you wish!

A plain, practical guide on recursion in JS

Igor Bykov — Thu, 18 Mar 2021 21:47:57 +0000

Overview

A guide to recursion for those who want to know in what cases recursion might be useful & how it could be applied IRL.

No Big O, algorithms, Fibonacci, word reversing, exponents, or other arbitrary CS topics. I promise.

Sorry, no TL;DR.

Unless you did a computer science course in university, recursion might be one of those concepts that you heard of but never had time to finally find out how that could be useful to you.

It also just happens so, that in modern day-to-day web development, there seem to be quite a few cases where recursion is the only possible solution to a particular problem.

Nevertheless, recursion is an exciting topic that might provide you with several important insights & even change the way you think about programming problems.

So, yes! That's a brilliant idea to finally understand the recursion.

Intro

Recursion is 1 of just 2 ways to repeat a process in computer programs.

The second way is called "iteration" & you are most probably already pretty familiar with this one. For instance, for & while loops, Array.prototype.map and Array.prototype.forEach are great examples of how iteration works.

The idea of iteration is simple - go a step at a time and repeat whatever procedure you are provided with on each step.

Let's see an example:

// A magical structure that repeats whatever
// we need to repeat an arbitrary number of times
// ⬇️
for (let i = 0; i <= 10; i++) {
  console.log(i); // ⬅️ procedure to repeat
}

However, how does the for loop works under the hood?
What if for whatever reason we would be about to write our own forLoop function without using for, do...while, while or any other built-in loop?

As for now, we don't have any tools to do this, hence, this task would only result in a mental block & might seem to be impossible, but hold on! It is possible since we've got 2 ways to repeat a process.

The mental model I find very helpful is the following:

Recursion is no more than an alternative, more flexible way to repeat a process without writing a loop.

Recursion

One of the primary mental blocks I had in understanding recursion was that it doesn't have any available APIs/special language constructs/built-in functions.

In the case of iteration, we have loops of all flavours but in the case of recursion, we aren't provided with any built-in solutions. We have to implement it from scratch.

That might be a blocker for learning, but ultimately this is exactly what makes recursion useful because it gives us total control over when, why & how repetition is performed.

Let's see some examples! First off, let's console.log numbers from 0 to 10, exactly the same as we did above with for loop but recursively this time:

const printNumbersUpTo10 = (num = 0) => { // #1 for (let i = 0;
  if (num <= 10) { // #2 i <= 10;
    console.log(num); // ⬅️ procedure to repeat
    printNumbersUpTo10(num + 1); // #3 i++)
  }
};

printNumbersUpTo10();

There might be some surprising parts (we'll get to them later) but let's first concentrate on similarities between recursive & iterative approaches.

Similarities with iteration

I mapped lines of recursive printNumbersUpTo10 function to equivalent parts of for loop, let's see them step by step:

On line #1 we declare a variable that we will increment on each ~~iteration~~ step. So, this line is equivalent to:

for (
  let i = 0; // ⬅️
  i <= 10;
  i++
) { console.log(i); }

On line #2 we set a condition that will check on each ~~iteration~~ step whether we are already done or there are more steps to perform. In recursive functions this condition has a special name, it's called "base case". So, this line is equivalent to:

for (
  let i = 0;
  i <= 10; // ⬅️
  i++
) { console.log(i); }

On line #3 we increment our counter variable. So, this line is equivalent to:

for (
  let i = 0;
  i <= 10;
  i++ // ⬅️
) { console.log(i); }

In spite of having a lot in common, recursion & iteration differ in several important aspects. To understand those differences, let's discuss in detail how recursion works.

How does recursion work?

From any JavaScript engine's point of view, recursion is simply a situation when a function calls itself.

To see what this means, let's refactor our printNumbersUpTo10 function from the previous example. Let's say we decided that printNumbersUpTo10 is too specific, so, we want a more generic printNumbersUpTo function that will accept 1 argument - the highest number it should print.

So, when we will call printNumbersUpTo(5) it should console.log numbers from 0 to 5.

Our first attempt to implement this could look something like this:

const printNumbersUpTo = (num) => {
  if (num >= 0) {
    console.log(num);
    printNumbersUpTo(num - 1); // ⬅️ this line makes it tick
  }
};

printNumbersUpTo(5); // ➡️ logs 5, 4, 3, 2, 1, 0

However, we've got a couple of problems here:

Numbers are printed 5 to 0 instead of 0 to 5.
We have to make an additional unnecessary step just to print 0 because our console.log statement is placed next to printNumbersUpTo call which makes printNumbersUpTo call itself one additional time when num is 0 (-1 is not logged because it fails the check inside the if statement).

Let's try to get rid of both problems. A better solution could be something like this:

const printNumbersUpTo = (num) => {
  if (num > 0) {
    printNumbersUpTo(num - 1);
  }

  console.log(num);
};

printNumbersUpTo(5); // ➡️ logs 0, 1, 2, 3, 4, 5

Did you notice how moving console.log below the printNumbersUpTo(num - 1) call changed the logging sequence from 5 ➡️ 0 to 0 ➡️ 5?

It worked this way because when a JS compiler gets to printNumbersUpTo(num - 1) it starts executing it straight away, then it sees printNumbersUpTo(num - 1) again and starts executing it, and so on.

As a result, the compiler first goes all the way in to the call where num finally equals 0. When num is 0, the condition inside of the if statement is false, so, the if statement is skipped & the console.log is executed.

There's nothing after console.log, so the compiler finishes with the innermost function & then starts to get back out to the outermost scope.

You can see a visualization of this process using a wonderful tool called "Loupe" built by Philip Roberts. Here is the preview:

To make it even clearer, let's replace each recursive printNumbersUpTo(num - 1) call with the content of the printNumbersUpTo function in order to visualize how a JS compiler sees & executes it.

This is what recursion looks like:

const printNumbersUpToVisualized = (num) => {
  if (num > 0) {
    if ((num - 1) > 0) {
      if ((num - 1 - 1) > 0) {
        if ((num - 1 - 1 - 1) > 0) {
          if ((num - 1 - 1 - 1 - 1) > 0) {
            if ((num - 1 - 1 - 1 - 1 - 1) > 0) {
               // this is never executed since
               // num is already 0 here and the
               // condition is false
            }
            console.log(num - 1 - 1 - 1 - 1 - 1);
          }
          console.log(num - 1 - 1 - 1 - 1);
        }
        console.log(num - 1 - 1 - 1);
      }
      console.log(num - 1 - 1);
    }
    console.log(num - 1);
  }
  console.log(num);
};

printNumbersUpToVisualized(5);

The 2 most important ideas here are:

Recursion is about stacking up function calls on top of each other until the desired condition is met.
The order of execution is important and with recursion, we have complete control over it.

How recursion is different from iteration?

Due to the fact that we completely control the order of execution (since we can place recursive calls anywhere), the recursive approach allows more flexibility & let us do things that are hard to achieve using loops.

For instance, let's take a quick look at this example:

const mirrorNumbersUpTo = (num) => {
  console.log(num);

  if (num > 0) {
    mirrorNumbersUpTo(num - 1);
    console.log(num);
  }
};

mirrorNumbersUpTo(5); // ➡️ logs 5, 4, 3, 2, 1, 0, 1, 2, 3, 4, 5

We modified printNumbersUpTo just a slight bit in order to make it mirror numbers. Even in this simple case, it'd be more problematic to implement this same functionality inside a for loop.

In fact, mirrorNumbersUpTo is equivalent to a loop that first decrements the number down to 0 (for (let i = 5; 0 <= i; i--)) and then increments a variable from 1 until it equals the initially provided value (for (let i = 1; i <= 5; i++)).

At this point, one could say:

Ok, wonderful, but is there a single real-world scenario in which a programmer is not satisfied with the way a for loop runs?

Let's see!

Practical use cases

1. Normalizing arbitrary data structures

In modern JS we have something called Array.prototype.flat which is a function that can flatten nested arrays given how deep a nested array structure should be flattened.

While it's valid to call it like this:

nestedArrays.flat(Infinity);

in order to flatten an array completely (so, it contains no nested arrays), it is considered a bad practice to do so.

So, a possible workaround might look like this tiny recursive function adapted from one of the examples on MDN site:

const flatToBase = array => array.reduce(
  (accumulator, value) => accumulator.concat(
    Array.isArray(value) ? flatToBase(value) : value
  ),
  [],
);

flatToBase([[[[[[[ 42 ]]]], 36]]]); // -> [ 42, 36 ]

2. Traversing arbitrary data structures

Let's say we're building a browser extension that collects & shows some general statistics about the current HTML page.

For instance, we want to show our users how many HTML tags of each type we have on the current page, how deep the average tag is located, what is the most deeply located tag and so on.

In order to achieve this, we will obviously need to traverse the entire DOM structure element by element. If we try to use iteration to achieve this task, things get hard from the start. As the first step we could get all children of an element, for instance with something like this:

const bodyChildren = [...document.body.children];

for (let i = 0; i < bodyChildren.length; i++) {
  // So... how do we get children of each body child?
  analyseElement(bodyChildren[i]);
}

But what do we do after we have iterated over each direct child of body? Each direct child might have children as well, its children might have children and so on. We will not be able to write enough loops.

In situations like this, when the data structure we're working on is not known beforehand or is simply too nested, recursion is frequently the only approach we can use. So, let's do a quick prototype of the function that will recursively traverse all HTML elements on the page.

In this example, we are not going to analyse elements in any way, just traverse all of them & stringify the DOM structure in order to see that our function works fine.

const traverseHtmlElement = (rootElement, _level = 0) => {
  // Get all element's children stringified if any
  let rootChildren = '';
  if (rootElement.childElementCount) {
    rootChildren = traverseHtmlElement(rootElement.firstElementChild, _level + 1);
  }

  // Get all element's siblings stringified if any
  let rootSiblings = '';
  const nextSibling = rootElement.nextElementSibling;
  if (nextSibling) {
    rootSiblings = traverseHtmlElement(nextSibling, _level);
  }

  // The recursive part is already done above. All code
  // below is just to print HTML structure in a pretty way. 
  const ident =  '  '.repeat(_level);
  const tagName = rootElement.tagName.toLowerCase();
  const id = rootElement.getAttribute('id');
  const classList = rootElement.classList.toString();
  const rootId = id ? ` id="${id}"` : '';
  const rootClasses = classList ? ` class="${classList}"` : '';

  // Assemble tags with no children
  if (!rootChildren) {
    return ''.concat(
      ident,
      '<',
      tagName,
      rootId,
      rootClasses,
      ' />',
      '\n',
      rootSiblings,
    );
  }

  // Assemble tags with children
  return ''.concat(
    ident,
    '<',
    tagName,
    rootId,
    rootClasses,
    '>',
    '\n',
    rootChildren,
    ident,
    `</${tagName}>`,
    '\n',
    rootSiblings,
  );
};

const stringifiedHTML = traverseHtmlElement(document.body);
console.log(stringifiedHTML);

3. Processing data structures of arbitrary depth

Let's say we are building a web forum where people could discuss things, post images & leave comments about nearly anything they wish.

Frequently forums don't put any restrictions on conversations' depth, which basically means that any comment might have a sub-comment that might have a sub-comment that might have yet another sub-comment & so on. The simplified data structure that we receive from BE would look something like this:

const comments = [
  {
    text: 'comment 1',
    comments: [
      {
        text: 'comment 2',
        comments: [],
      },
    ],
  },
  {
    text: 'comment 3',
    comments: [
      {
        text: 'comment 4',
        comments: [],
      },
      {
        text: 'comment 5',
        comments: [{
          text: 'comment 6',
          comments: [{
            text: 'comment 7',
            comments: [
              {
                text: 'comment 8',
                comments: [],
              },
              {
                text: 'comment 9',
                comments: [],
              }
            ],
          }],
        }]
      },
      {
        text: 'comment 10',
        comments: [],
      },
    ],
  },
];

Let's prove we can print it prettily using recursion:

printComment function from the example above is fairly similar to traverseHtmlElement, you could notice that all the children/sibling wording already sounds pretty familiar. That's no surprise since those 2 functions do almost the same thing.

Did you notice that small getArrayIterator generator function that we used as a helper?
I used it because unlike DOM elements that have the nextElementSibling property, arrays don't provide a way to go to the next element from the current one.

In order to avoid reinventing the wheel, we can use generators that provide a very handy way to go to the next step & define whether the iteration is already done or not within a recursive function.

4. Arbitrary depth currying

This example is heavily inspired by an awesome article on amazing javascript.info. If you've never heard of it, I'd strongly recommend you to check it out.

For the sake of simplicity, we will write a pretty simple sum function. I must admit that, unlike other examples, this example can barely be useful IRL even theoretically, however, the concept it demonstrates is too interesting to omit.

Let's consider that we want to create a function called sum that sums up all numbers we feed it. Sounds trivial, however, we want our function to work with pretty much any call signature, so, all these signatures must be valid:

sum();
sum(1, 1)();
sum(1)(5)(12)();
sum(1)(132, 4)();
sum(1, 2, 3)(7, 8, 9)(5)();
sum(1, 1)(4)(6, 13, 7)(2)(3)(2)(2, 1)();

It turns out that we can solve this puzzle with recursion quite easily. The trick is to apply it a little bit differently this time.

The implementation could look something like this:

The most interesting part here is that sumOnce returns itself without invoking itself as long as any argument is supplied.

This makes sumOnce a recursive function despite the fact that the invocation part is now delegated to users of this function.

5. Creating a higher-level abstraction

Sometimes, the iterative approach might help to abstract things out making code cleaner, more organized & easier to use.

For instance, let's say that we are building a colour wheel, just like this one that I have found on canva.com.

In order to make our colour wheel work, we'll need to calculate what colours do we have in order to render them. Since we know that on the Web we use the RGB colour scheme, we are able to say that we have 256 * 256 * 256 colours available (which is about 17 million colours!), so it looks like our colour wheel is going to be really huge.

However, today, the design is not our primary concern. The main question now is:

How do we calculate all possible combinations of three numbers in the range from 0 to 255?

Thanks to this brilliant answer on math.stackexchange.com we now know that it's relatively easy to calculate all possible combinations using nested for loops.

Let's do a quick test to make sure it really works. We are going to calculate all combinations that can give us 2 numbers in the 0 - 1 range.

out = [];
for (let i = 0; i < 2; i++) {
  for (let j = 0; j < 2; j++) {
    out.push([ i, j ]);
  }
}

console.log(out); // -> [[ 0, 0 ], [ 0, 1 ], [ 1, 0 ], [ 1, 1 ]]

It works! So, in our case, luckily, we'll need just 3 nested loops.

However, what if we would like to have a more generic function that could calculate all possible combinations for any set of numbers?

Well, one option would be to create for loops recursively.
Let's create such a function & see it in action!

If you inspect the screen above, you'll find out that it's made up of 10x10 divs and each div on the screen has a unique colour.

Those colours are calculated automatically by findAllNumericCombinations that generates exactly the needed number of nested loops to calculate all possible combinations of a given set of ranges.

As you can see, only a few (particularly, 2304) colours are printed out. That's because printing out all 17 million would probably make your browser strongly dislike particular shades of orange :)

Iteration + Recursion = ❤️

Now when you feel more comfortable with recursion, it's time to clarify that you don't necessarily need to stick to one or another.

Iteration & recursion are not contradicting programming paradigms, not red & blue Matrix pills. Their light swords are of different colours but both are true Jedis!

Jokes apart, sometimes it's quite convenient to mix both in order to get the desired result.

You might already notice in previous examples that recursion & iteration might work quite well together.
Let's see yet another example of such a synergy. Let's say we have an array that has a very misfortune structure and looks like this:

const nestedNumbers = [
  [[0], [[[[[[[1, 2]]]]]]], [3]],
  [[[4], [[5]]], [[[6, 7, 8]]]],
  [9]
];

The bad news is that it can only come in this form from the server, so, we must deal with it.

The good news is that it always strictly follows the following rule:

Any array contains either other array(/s) or number(/s).

Let's say we want to increment each number in this array by 1 leaving the structure in exactly the same state as it came from the server.

We'll have to use recursion since arrays that contain numbers might be nested at an arbitrary depth, so, we don't know beforehand how many iterations it will take to get to them.

However, once we found an array that contains several numbers, how do we make our recursive function go through each number in the array?
While we could implement this logic using recursion, it's not that fun to keep track of pointers position inside arrays.

Shall we re-invent the wheel at all? Recursion is great at processing repetitive data structures while iteration is great at looping through arrays. So, there's no good reason to limit our toolbox to just one thing or another.

Let's try to get the best out of the two worlds:

// Fetched from server
const nestedNumbers = [
  [[0], [[[[[[[1, 2]]]]]]], [3]],
  [[[4], [[5]]], [[[6, 7, 8]]]],
  [9]
];

const incrementNestedNumbers = (arrayWithNums) => {
  for (let i = 0; i < arrayWithNums.length; i++) {
    if (Array.isArray(arrayWithNums[i])) { // if array
      incrementNestedNumbers(arrayWithNums[i]);
    } else { // if number
      arrayWithNums[i] = arrayWithNums[i] + 1;
    }
  }
};

incrementNestedNumbers(nestedNumbers);

/* nestedNumbers now look like this:
  [[1], [[[[[[[2, 3]]]]]]], [4]],
  [[[5], [[6]]], [[[7, 8, 9]]]],
  [10]
*/

Wonderful, isn't it? We use recursion to find all nested arrays & iteration to actually loop through them while both of our tools seem to enjoy working shoulder to shoulder.

Some people will surely argue that this type of code can easily cause memory leaks & performance problems, however, from the practical point of view, if you understand what you are doing & test it well before using it in production, it will unlikely produce any undesired effects.

Conclusion

Recursion is not that difficult to understand.
Recursion can be very useful for certain tasks, sometimes, it is the only way to achieve the desired result.
Recursion might give you the power to abstract things that could not be abstracted without it.
Recursion has its cons, most famous being that it can lead to an infinite loop or memory leaks too easily in some cases.
There's no good reason why one should avoid learning about recursion or using it when it fits.
Recursion is unlikely a tool that you will use every single day, however, it is a very valuable tool because it helps you think about programming problems in a broader & more structured way.
Recursion pops-up in tech interviews quite frequently.
Recursion & iteration might work well together, don't limit your toolbox by forcing yourself to choose just 1 of 2 available tools.

I hope this article helped you to understand recursion a little better & you enjoyed it!

React: Calling functional components as functions

Igor Bykov — Wed, 26 Aug 2020 23:58:12 +0000

TL;DR

To be a component ≠ Return JSX
<Component /> ≠ Component()

Note: This article tries to explain a somewhat advanced concept.

One of my favourite things in web development is that almost any question can lead to an unforgettable deep dive that will reveal something completely new about a very familiar thing.

That just happened to me, so now I know a tiny bit more about React & want to share it with you.

It all started with a bug which we are going to reproduce now step by step. Here is the starting point:

This app contains just 2 components App & Counter.

Let's inspect App's code:



const App = () => {
  const [total, setTotal] = useState(0);
  const incrementTotal = () => setTotal(currentTotal => currentTotal + 1);

  return (
    <div className="App">
      <div>
        <h4>Total Clicks: {total}</h4>
      </div>
      <div className="CountersContainer">
        <Counter onClick={incrementTotal} />
        <Counter onClick={incrementTotal} />
        <Counter onClick={incrementTotal} />
      </div>
    </div>
  );
};

Nothing interesting as for now, right? It just renders 3 Counters & keeps track and displays the sum of all counters.

Now let's add a brief description to our app:



const App = () => {
  const [total, setTotal] = useState(0);
  const incrementTotal = () => setTotal((currentTotal) => currentTotal + 1);
+ const Description = () => (
+   <p>
+     I like coding counters!
+     Sum of all counters is now {total}
+   </p>
+ );

  return (
    <div className="App">
      <div>
        <h4>Total Clicks: {total}</h4>
+       <Description />
      </div>
      <div className="CountersContainer">
        <Counter onClick={incrementTotal} />
        <Counter onClick={incrementTotal} />
        <Counter onClick={incrementTotal} />
      </div>
    </div>
  );
};

Works perfectly as before, but now it has a shiny new description, cool!

You might notice that I declared component Description instead of just writing JSX straight inside App's return statement.
There might be plenty of reasons for that, let's just say that I wanted to keep JSX inside App's return clean & easily readable, so, I moved all messy JSX inside Description component.

You could also notice that I declared Description inside App. It's not a standard way, but Description needs to know the current state to display total clicks.
I could refactor it and pass total as a prop, but I don't plan to ever reuse Description because I need just one for the whole app!

Now, what if we also wanted to display some additional text above the central counter? Let's try to add it:



const App = () => {
  const [total, setTotal] = useState(0);
  const incrementTotal = () => setTotal((currentTotal) => currentTotal + 1);
  const Description = () => (
    <p>
      I like coding counters!
      Sum of all counters is now {total}
    </p>
  );
+
+ const CounterWithWeekday = (props) => {
+   let today;
+   switch (new Date().getDay()) {
+     case 0:
+     case 6:
+       today = "a weekend!";
+       break;
+     case 1:
+       today = "Monday";
+       break;
+     case 2:
+       today = "Tuesday";
+       break;
+     default:
+       today = "some day close to a weekend!";
+       break;
+   }
+
+   return (
+     <div>
+       <Counter {...props} />
+       <br />
+       <span>Today is {today}</span>
+     </div>
+   );
+ };

  return (
    <div className="App">
      <div>
        <h4>Total Clicks: {total}</h4>
        <Description />
      </div>
      <div className="CountersContainer">
        <Counter onClick={incrementTotal} />
-       <Counter onClick={incrementTotal} />
+       <CounterWithWeekday onClick={incrementTotal} />
        <Counter onClick={incrementTotal} />
      </div>
    </div>
  );
};

Brilliant! Now we do have a bug! Check it out:

Note how total is incremented when you click on the central counter, but the counter itself always stays at 0.

Now, what surprised me is not the bug itself, but rather that I accidentally found out that the following works seamlessly:



  return (
    <div className="App">
      <div>
        <h4>Total Clicks: {total}</h4>
        <Description />
      </div>
      <div className="CountersContainer">
        <Counter onClick={incrementTotal} />
-       <CounterWithWeekday onClick={incrementTotal} />
+       { CounterWithWeekday({ onClick: incrementTotal }) }
        <Counter onClick={incrementTotal} />
      </div>
    </div>
  );

Surprised as well? Let's dive into together!

The bug

The bug happens because we create brand new CounterWithWeekday on each App update.
This happens because CounterWithWeekday is declared inside App which might be considered an anti-pattern.

In this particular case, it's easy to solve. Just move CounterWithWeekday declaration outside of the App, and the bug is gone.

You might wonder why we don't have the same problem with Description if it is also declared inside the App.
We actually do! It's just not obvious because React re-mounts the component so fast, that we can't notice and since this component has no inner state, it's not getting lost as in case of CounterWithWeekday.

But why directly calling CounterWithWeekday resolves the bug as well? Is it documented somewhere that you can just call a functional component as a plain function? What is the difference between the 2 options? Shouldn't a function return exactly the same thing disregard of the way it's invoked? 🤔

Let's go step by step.

Direct invocation

From React documentation we know that component is just a plain JS class or function that eventually returns JSX (most of the time).

However, if functional components are just functions, why wouldn't we call them directly? Why do we use <Component /> syntax instead?

It turns out to be that direct invocation was quite a hot topic for discussion in earlier versions of React. In fact, the author of the post shares a link to a Babel plug-in that (instead of creating React elements) helps in calling your components directly.

I haven't found a single mention about calling functional components directly in React docs, however, there is one technique where such a possibility is demonstrated - render props.

After some experiments, I came to quite a curious conclusion.

What is a Component at all?

Returning JSX, accepting props or rendering something to the screen has nothing to do with being a component.

The same function might act as a component & as plain function at the same time.

Being a component has much more to do with having own lifecycle & state.

Let's check how <CounterWithWeekday onClick={incrementTotal} /> from the previous example looks like in React dev tools:

So, it's a component that renders another component (Counter).

Now let's change it to { CounterWithWeekday({ onClick: incrementTotal }) } and check React devtools again:

Exactly! There's no CounterWithWeekday component. It simply doesn't exist.

The Counter component and text returned from CounterWithWeekday are now direct children of App.

Also, the bug is gone now because since CounterWithWeekday component doesn't exist, the central Counter doesn't depend on its lifecycle anymore, hence, it works exactly the same as its sibling Counters.

Here are a couple of quick answers to the questions I've been struggling with. Hope it'll help someone.

Why `CounterWithWeekday` component is not displayed in React dev tools anymore?

The reason is that it's not a component anymore, it's just a function call.

When you do something like this:



const HelloWorld = () => {
  const text = () => 'Hello, World';

  return (
    <h2>{text()}</h2>
  );
}

it's clear that the variable text is not a component.
If it would return JSX, it wouldn't be a component.
If it would accept a single argument called props, it wouldn't be a component either.

A function that could be used as a component is not necessarily will be used as a component. So, to be a component, it needs to be used as <Text /> instead.

Same with CounterWithWeekday.

By the way, components can return plain strings.

Why Counter doesn't lose state now?

To answer that, let's answer why Counter's state was reset first.

Here is what happens step by step:

CounterWithWeekday is declared inside the App & is used as a component.
It is initially rendered.
With each App update, a new CounterWithWeekday is created.
CounterWithWeekday is a brand new function on each App update, hence, React can't figure out that it's the same component.
React clears CounterWithWeekday's previous output (including its children) and mounts new CounterWithWeekday's output on each App update. So, unlike other components, CounterWithWeekday is never updated, but always mounted from scratch.
Since Counter is re-created on each App update, its state after each parent update will always be 0.

So, when we call CounterWithWeekday as a function, it is also re-declared on each App update, however, it doesn't matter anymore. Let's check hello world example once again to see why:



const HelloWorld = () => {
  const text = () => 'Hello, World';

  return (
    <h2>{text()}</h2>
  );
}

In this case, it wouldn't make sense for React to expect the text reference to be the same when HelloWorld is updated, right?

In fact, React cannot even check what text reference is. It doesn't know that text exists at all. React literally wouldn't notice the difference if we would just inline text like this:



const HelloWorld = () => {
- const text = () => 'Hello, World';
-
  return (
-   <h2>{text()}</h2>
+   <h2>Hello, World</h2>
  );
}

So, by using <Component /> we make the component visible to React. However, since text in our example is just called directly, React will never know about its existence.
In this case, React just compares JSX (or text in this case). Until the content returned by text is the same, nothing gets re-rendered.

That exactly what happened to CounterWithWeekday. If we don't use it like <CounterWithWeekday />, it is never exposed to React.

This way, React will just compare the output of the function, but not the function itself (as it would, in the case if we use it as a component).
Since CounterWithWeekday's output is ok nothing gets re-mounted.

Conclusion

A function that returns JSX might not be a component, depending on how it is used.
To be a component function returning JSX should be used as <Component /> and not as Component().
When a functional component is used as <Component /> it will have a lifecycle and can have a state.
When a function is called directly as Component() it will just run and (probably) return something. No lifecycle, no hooks, none of the React magic. It's very similar to assigning some JSX to a variable, but with more flexibility (you can use if statements, switch, throw, etc.).
Using state in a non-component is dangerous.
Using functions that return JSX without being a component might be officially considered to be an anti-pattern in the future. There are edge cases (like render props), but generally, you almost always want to refactor those functions to be components because it's the recommended way.
If you have to declare a function that returns JSX inside a functional component (for instance, due to tightly coupled logic), directly calling it as {component()} could be a better choice than using it as <Component />.
Converting simple <Component /> into {Component()} might be very handy for debugging purposes.

Handle loading errors & fallback with HtmlWebpackPlugin

Igor Bykov — Sun, 23 Aug 2020 20:44:53 +0000

TL;DR

If you use HtmlWebpackPlugin & sometimes things go wrong while your bundles are loading, we’ve got you covered.

Errors happen.

This is particularly true about programming. However, when errors happen before the code of your program even had a chance to execute, this is somewhat surprising & might be extremely tricky to handle.

This is exactly the problem I had to deal with recently, and it seems likely that this might be a very common issue in client-side web apps.

The error I have seen looked like this:

Uncaught SyntaxError: Unexpected token '<'

After some research, it turned out that the scenario when the error happened was something like this:

A user’s browser caches the page on the initial visit to the website. User doesn’t visit the site again until the day X
We actively develop the website & make releases meanwhile
Each new release adds a bundle with a unique hash to the server
We store several latest releases on the server, however, since server resources are limited, with each new release coming in, we erase the oldest release
It is day X and the user with the cached version of the page happily comes in
User’s browser tries to fetch bundle.[too-old-hash].js but it doesn’t exist on the server since we already made several deploys and this old release was erased
The server subsequently responds with 404 which is an HTML page
JS compiler cannot parse HTML & throws SyntaxError
Our application would normally be rendered with React on client-side but since there is no bundle, the user sees a blank page

So, how do you handle an error that happens due to the fact that your entire application is unavailable? Below I will show a possible frontend-only solution.

If you prefer to code along, you can find sample repo with all setup but no solution implemented here.

Setup

We use webpack to compile & bundle our code and HtmlWebpackPlugin to generate an HTML page where our application will eventually live.

Our application could be whatever. This article is framework-agnostic.

Possible solutions & caveats

First of all, logically we will not be able to do anything in the bundle.[hash].js, because this file will fail to load & will be unavailable during runtime.

So, what do we do? Well, we could add some inline JS on our page. It will always be present & hence, will be able to do some handling.

Let’s create src/index.ejs which is the default place for the template used by HtmlWebpackPlugin to generate the HTML page. By creating this file, we will be able to customize the HTML skeleton of the generated page.

My first naive attempt was to add some inline JS in HtmlWebpackPlugin template to listen for error event on the app’s script tag like this:

src/index.ejs:

<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Handling script loading errors with HtmlWebpackPlugin</title>
</head>
<body>
    <h1 id="content"></h1>
    <script>
    (function(){
        function showErrorPage() {
            // Doesn't matter for now
        }

        var appScript = document.querySelector('script[src^="bundle"]');
        appScript.addEventListener('error', showErrorPage);
    })();
    </script>
    <!--
    HTMLWebpackPlugin will insert bundled script here on build.
    It will look something like this:

    <script src="bundle.foo12.js"></script>
    -->
</body>
</html>

However, this will not work because when inline <script>’s code is executed, <script src="bundle.foo12.js"></script> does not even exist yet in the DOM because it is located below the inline script tag and it hasn’t been parsed by the browser yet. Ok, let’s wait until the DOM is ready & once it is, let’s do the same and attach the event listener (below I will omit unchanged parts of the document for brevity):

src/index.ejs:

<script>
(function(){
    function showErrorPage() {
        // Doesn't matter for now
    }

    window.addEventListener('DOMContentLoaded', function() {
        var appScript = document.querySelector('script[src^="bundle"]');
        appScript.addEventListener('error', showErrorPage);
    });
})();
</script>

Unfortunately, this will not work either because when the browser sees the plain script tag that tries to load our bundle, it fetches and executes the bundle straight away, then it resumes HTML parsing and once it reaches </html> it fires the DOMContentLoaded event.

Here is what it looks like graphically:

In this case, we attach event listener long ago fetching and execution stages are completed and our callback will never be fired.
So, it looks like we come either too early or too late.

At this stage, we could try to check the bundle’s script presence in the DOM with a very short interval or some other brute-force solution of this type.

Luckily, this is not necessary since HtmlWebpackPlugin provides us with everything to implement an elegant & efficient solution.

Solution

We clearly need to listen for loading events.
However, in order to be able to listen for loading events, we need more control over when our bundle starts to load to attach event listeners on time.

Ok, let’s overtake control.

First of all, let’s tell HtmlWebpackPlugin that we don’t want it to inject <script>‘s that we can't control into the page.

webpack.config.js:

plugins: [
    new HtmlWebpackPlugin({
        inject: false
    })
]

Now we don’t have bundle’s <script> tag at all, so, our app will never be loaded. That’s no good, but we can create <script> tag ourselves using the information HtmlWebpackPlugin provides to us.

src/index.ejs:

<script>
(function() {
    function showErrorMessage() {
        alert('Oops, something went wrong! Please reload the page.');
    }

    // Paths of all bundles
    var bundlesSrcs = <%= JSON.stringify(htmlWebpackPlugin.files.js) %>;
    for(var i=0; i < bundlesSrcs.length; i++) {
        // Create script tag & configure it
        var scriptTag = document.createElement('script');
        scriptTag.src = bundlesSrcs[i];
        scriptTag.addEventListener('error', showErrorMessage);

        // Append script tag into body 
        document.body.appendChild(scriptTag);
    }
})();
</script>

If you use a template HtmlWebpackPlugin will pass a variable called htmlWebpackPlugin to it. Here we access htmlWebpackPlugin.files.js which is an array that contains paths of all javascript bundles created by webpack during this run.

This strange construction “<%= … %>” is just Embedded JavaScript templating syntax for printing information into the document.
In this case, it will be resolved on the build to something like ['bundle.foo12.js'].

Once we get the array of paths, we can iterate through this array and create a <script> tag for each path.
Before inserting the newly created <script> into the document, we will attach our error listener to it. This time we attached the listener on time, so, if any error happens, it will be fired.

Note that I’m trying to use ES5-compliant syntax here because this code will not be compiled & will be shipped into the browser as it is.

Bonus: Insert images in the error message

IRL we probably want to show some nice “error page” instead of a message in browser’s alert box. Probably, we want to show an image on the error page.

There is no problem with it. Our template is flexible enough to make it possible.

First of all, let’s install file-loader that can handle images.

terminal:

npm install file-loader --save-dev

Now let’s tell webpack to use this loader.

webpack.config.js:

module: {
    rules: [
        {
            test: /\.(png|jpe?g|gif)$/i,
            loader: 'file-loader'
        }
    ]
}

Now we can directly require images inside our index.ejs template like this:

<%= require('./path_to_image').default %>

Here is the full src/index.ejs file.

<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Handling script loading errors with HtmlWebpackPlugin</title>
    <style>
        html, body, h1 {
            padding: 0;
            margin: 0;
        }
        #bundleLoadingErrorContainer {
            position: fixed;
            display: flex;
            flex-direction: column;
            align-items: center;
            justify-content: center;
            background-color: #FFF;
            text-align: center;
            width: 100%;
            height: 100%;
        }
        .bundle_error_title {
            padding: 0 1.5%;
        }
    </style>
</head>
<body>
    <h1 id="content"></h1>
    <div id="bundleLoadingErrorContainer" style="display: none;">
        <h2 class="bundle_error_title">Oops, something went wrong. Please reload the page.</h2>
        <figure class="photo">
            <img src="<%= require('./assets/bird.jpg').default %>" width="300" height="200" alt="bird">
            <br>
            <br>
            <figcaption>
                Photo by <a href="https://unsplash.com/@photoholgic" target="_blank" rel="external noopener">Holger Link</a> on <a href="https://unsplash.com/" target="_blank" rel="external noopener">Unsplash</a>
            </figcaption>
        </figure>
    </div>
    <script>
    (function() {
        function showErrorMessage() {
            document.getElementById('bundleLoadingErrorContainer').removeAttribute('style');
        }

        var bundlesSrcs = <%= JSON.stringify(htmlWebpackPlugin.files.js) %>;
        for(var i=0; i < bundlesSrcs.length; i++) {
            var scriptTag = document.createElement('script');
            scriptTag.src = bundlesSrcs[i];
            scriptTag.addEventListener('error', showErrorMessage);

            document.body.appendChild(scriptTag);
        }
    })();
    </script>
</body>
</html>

Conclusion

Hope it was helpful! You can find all the code of the final version in this repo.

Now, we’re all done and you can test how error handler works using not so well-known Chrome’s request blocking feature.

DEV Community: Igor Bykov

The most complex challenge of your career

A plain, practical guide on recursion in JS

Overview

Intro

Recursion

Similarities with iteration

How does recursion work?

How recursion is different from iteration?

Practical use cases

1. Normalizing arbitrary data structures

2. Traversing arbitrary data structures

3. Processing data structures of arbitrary depth

4. Arbitrary depth currying

5. Creating a higher-level abstraction

Iteration + Recursion = ❤️

Conclusion

React: Calling functional components as functions

The bug

Direct invocation

What is a Component at all?

Why CounterWithWeekday component is not displayed in React dev tools anymore?

Why Counter doesn't lose state now?

Conclusion

Handle loading errors & fallback with HtmlWebpackPlugin

Setup

Possible solutions & caveats

Solution

Bonus: Insert images in the error message

Conclusion

Why `CounterWithWeekday` component is not displayed in React dev tools anymore?