You don't know spread operator !

Valentin PARSY — Sun, 12 Sep 2021 12:27:23 +0000

I was recently reading a blog post about iteration from Axel Rauschmayer (I suggest you follow him, all his posts are minegold for JS devs).
This post was mindblowing to me as I learned so much about iteratables in JavaScript.

Let's challenge our knowledge

Let me sum up a bit of what I learned here with a small challenge to you :
When I use the spread operator on a Number, I want the result to be an array that counts from 1 to the given value :

First steps to an answer

First thing to do is try the code for yourself and you will see that using a spread operator on a Number throws an error => Uncaught TypeError: X is not iterable

Then what is an iterable ?
An iterable is an object that defines an iteration behavior, meaning it has a property with a Symbol.iterator key and an iterator as value.
This iterator should respect the iteration protocol which means it is a function that returns an object with a next fonction that returns an object with 2 properties : "value" (the current iteration's value) and "done" (a boolean indicating weither we are done iterating with this iterator or not).

The spread operator is simply a consummer of such iterables: when you give it an iterable, it'll call the next function of its Symbol.iterator property until it returns an object with {done: true} (and push each time the result in an array).

Verify that with an Array

An array in JavaScript is an iterable since it has an iterator as a value of its property with Symbol.iterator key.
Here is how you can use this iterator :

Answer to the challenge

So how do I make the spread operator not throwing an error when given a number ? You set the Symbol.iterator property on the Number primitive wrapper object.
Let's make all numbers iterables !

Conclusion

Obviously you never want to change the prototype of a primitive wrapper object, it's too dangerous.
But the knowledge of how iteration and the spread operator works is I think very valuable as a developper.

Piece of Mind: Testing

Valentin PARSY — Thu, 31 Oct 2019 09:52:14 +0000

Welcome to this series of articles Piece of Mind.
In these articles I will just tackle the surface of subjects I care about and what is my thought process on them. They will hopefully bring you to reflect and maybe research them in order to grow your own ideas and practices on them.

Testing your code is a very important step in your developer journey. Unfortunately, a lot of people think it's useless and/or don't need that much consideration while coding. I often see code badly tested (false positives, unreadable tests, etc...) when it should be a priority to the project.

Anti-regression

When updating a codebase, especially a big one, you can't always guess what your changes will bring.
Let's say you have a slider with a blue button on the first slide and a yellow button on the others.
You are now asked to change the last slide button color to green.
You add one line of code there, remove one here, you compile and launch the project to visually test that the last button is green.
Everything's perfect, you have done your job, and the project manager will be happy to see their green button.
But at the next meeting, the project manager is not happy ... they (or the QA team) found that the first button is no longer blue. You completely missed that when you checked for your modification on the last slide.

Well it wouldn't have happened with tests (ok ok it still happens ... but a lot less !)
With correct tests, you can catch regressions before they happen.
If a test says "On the first slide the button should be blue" and another says "On every page but the first one, the button should be yellow" and after you update the code the first test fails, you know you broke something and can quickly fix it (and you also know you should update your tests to add a test about the last button).

Project comprehension

Good tests can be an awesome tool for project comprehension. Sure you can read all the codebase and have a pretty good idea about what's going on, but not everyone is capable of that and anyone can miss some points.
With well-written tests, you can just read the test descriptions to know what was asked of the developer.
Without reading any code, you open the tests for the button from the previous example and you read :

First test: "The button is blue on the first slide"
Second test: "The button is yellow on all slides but first and last"
Third test: "The button is green on the last slide"

After 3 lines you know exactly what this component is all about, and what is expected of it by UI/UX/Business

TDD (Test Driven Development)

The 3 big letters of testing! You surely may have heard of it before. TDD is a way of writing tests for your project. Basically you write tests BEFORE you write code. The tests obviously fail, your job is then to make them pass.
This is a great way to work because you just have to translate what you've been asked: just write down as description what is expected ("The button is blue on the first slide").
The big downside, at first, of this process is that it's hard to work like that on a technology you're not used to yet or when you begin to learn how to write tests... Once you got those two requirements, try TDD out =D

Ideas to go further :

https://kentcdodds.com/ : Kent C.Dodds is a software developer that is passionate about testing and testing good practices. Even if his talks/articles are mainly about front-end development, any developer can learn from him.
A great article about rules to follow to create great tests in your projects.
For JavaScript developers: a nice article that compares some testing tool. Because it's important to choose a good tool for a job.
Nice tips for writing good test descriptions by Yahel Yechieli.

A special thanks to Rudy Weber for helping me writing this piece of mind.

DEV Community: Valentin PARSY