Luca Del Puppo — Run, Code & Learn

Automating my Codemotion Badge with Antigravity

Wed, 08 Jul 2026 00:00:00 GMT

Today, I wanna show you how to set up your devices with Antigravity using only the agentic mode, without touching any code.

At the last CodeMotion Rome, I got my special badge. A CM Node, a special hardware board, that you can customise for your conferences.

I'm not a super nerd for this kind of stuff, so I decided to use Antigravity and all its capabilities to build and flash the best board ever for my future conferences.

Small intro about the board

This board has been delivered with a GitHub repository to understand how to flash it and how it works. In Rome, I saw different attendees with awesome badges. For instance, Soumaya had built a badge with a small plastic hand that used a sensor when someone was near her; it started waving to say hi.
Since that day, I have been thinking about what I can build to have a cool badge. Nothing has come to my mind, so today, with this blog, we will build my badge together, and thanks to Antigravity, we will create the best version possible.

Antigravity

If you don't know Antigravity. Antigravity is a set of tools built by Google. We have:

Antigravity 2.0: is a dedicated platform to work with agents. Orchestrate multiple autonomous agents working in parallel across independent projects.
Antigravity CLI: terminal-first surface to interact with Antigravity agents. Stay in your flow without context switching
Antigravity IDE: editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurable agent
Antigravity SDK: build AI agents that autonomously read files, run commands, edit code, and more. The Agent SDK gives you the same tools, agent loop, and context management that power Google Antigravity, programmable in Python.

Today, in this blog post, we will use Antigravity 2.0 to set up the board. You can use this tool to orchestrate many projects from a unique UI. This tool is fully agentic; using natural language, you can spawn agents, plan, and work on your projects. If you want to check the codebase in detail, you must use the Antigravity IDE. I’m not a fan of this decision, I’d prefer one tool for both, but this is what we have, and we must use it as it is.

Let’s start cooking

Okay, after this introduction, let’s see what we can do with Antigravity and the CodeMotion Board.

So, I’m dumb about this board right now, and I want to use Antigravity to figure out what I can do with it and get an idea of what my badge might look like.

I open the Antigravity app, and from the UI, I start a new project, and in the prompt, I type

I want to set up my Codemotion Badge.
It's a CMNode v0 https://www.cmnode.it/en/, and it can be programmed.
I want to create two different screens: the first a classic one with name, surname, heading, and company, and a QR code linking to my website.
The second one must be fantastic, and I want different options to choose from you.

I have this repository as an example to set up the badge https://github.com/Codemotion-Official/CMNode; you can use it as an example to create my badge.
Lastly, I don't want to flash the ROM every time, so I'd like a small web page I can access via Wi-Fi to update the information.

Can you plan the work to do it?
Include also two or three possible ideas for the second screen. It must be cool and fancy!

The badge is already connected to the laptop in case you want to deploy the result.

Now, I press enter and let’s see the result and what it will cook.

The result

CMNode v0 WiFi Configuration & Dual Screen Setup

The goal of this task is to upgrade your CMNode v0 badge by replacing the serial-based configuration with a Wi-Fi-based web interface. We will also save the configured data to flash memory so it persists across reboots, and implement two different display layouts: a "Classic" screen and a "Fantastic" screen.

User Review Required

IMPORTANT

Please review the proposed ideas for the "Fantastic" screen below. Let me know which one you prefer, or if you'd like to combine elements from different ideas!

Ideas for the "Fantastic" Second Screen:

The "Hacker Terminal" : A retro command-line interface aesthetic. The screen features a black background with white text, simulating a terminal session (e.g., > user@cmnode:~$ whoami, followed by your details). We can use monospace fonts and add some faux hex-dumps or ASCII elements.

The "RPG Stats / Gamer Card" : Your badge becomes a character stat sheet. It will display you as a "Level 99 Developer" with stats like "INT: 99", "COFFEE: 100%", an energy bar, and your details integrated into a game-like UI.

The "Minimalist Cyberpunk" : A bold, modern, and high-contrast design. It uses large vertical typography for your name, heavy geometric shapes, thick red accent lines, and a large barcode aesthetic alongside your QR code.

Let me know which of these three ideas (or a mix!) you want me to build for the second screen.

Proposed Changes

We will modify the firmware to support a captive-like Wi-Fi Access Point and Web Server.

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Wi-Fi Access Point : The ESP32-C3 will broadcast an SSID (e.g., CMNode-Config). You can connect to it with your phone or laptop.

Web Server : A built-in web server will serve a simple, mobile-friendly HTML configuration page at http://192.168.4.1.

Form Submission : The webpage will contain a form to update your Name, Surname, Role, Company, QR Link, and a dropdown to select the active screen layout (Classic vs Fantastic).

Persistent Storage : Integrate the Preferences library to save your data to the ESP32's non-volatile storage (NVS). This ensures your badge remembers your details even after turning off.

Display Pipeline : Refactor the drawContent() function to support rendering two completely different layouts based on your selection.

Verification Plan

Manual Verification

I will write the updated code and you will flash it to your badge via PlatformIO or Arduino IDE.

We will verify that the badge broadcasts the CMNode-Config Wi-Fi network.

We will connect to it, open the web page, submit new data, and verify that the E-paper display updates immediately.

We will reboot the badge to confirm the data is preserved.

We will toggle between the Classic and Fantastic screens to verify the layouts.

I commented on the plan, deciding to go with option one and asked for an example design.
Antigravity has started reviewing the plan and updated it in this way

CMNode v0 WiFi Configuration & Dual Screen Setup

The goal of this task is to upgrade your CMNode v0 badge by replacing the serial-based configuration with a Wi-Fi-based web interface. We will also save the configured data to flash memory so it persists across reboots, and implement two different display layouts: a "Classic" screen and a "Fantastic" screen.

Design Choice: "Hacker Terminal"

You've selected the Hacker Terminal idea for the second screen. This layout will simulate a retro command-line interface on the E-ink display:

Background : Black (inverted).

Text : Monospace white font, simulating terminal output (root@cmnode:~$ whoami).

Data : Your name, surname, role, and company will be displayed as the "output" of the terminal command.

Accents : Faux hex-dumps or system logs on the side, and a right-aligned QR code.

Here is a mockup of the design:

Does this mockup and the updated plan look good to you? If so, I will proceed with the implementation!

Proposed Changes

We will modify the firmware to support a captive-like Wi-Fi Access Point and Web Server.

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Wi-Fi Access Point : The ESP32-C3 will broadcast an SSID (e.g., CMNode-Config). You can connect to it with your phone or laptop.

Web Server : A built-in web server will serve a simple, mobile-friendly HTML configuration page at http://192.168.4.1.

Form Submission : The webpage will contain a form to update your Name, Surname, Role, Company, QR Link, and a dropdown to select the active screen layout (Classic vs Fantastic).

Persistent Storage : Integrate the Preferences library to save your data to the ESP32's non-volatile storage (NVS). This ensures your badge remembers your details even after turning off.

Display Pipeline : Refactor the drawContent() function to support rendering two completely different layouts based on your selection.

Verification Plan

Manual Verification

I will write the updated code and you will flash it to your badge via PlatformIO or Arduino IDE.

We will verify that the badge broadcasts the CMNode-Config Wi-Fi network.

We will connect to it, open the web page, submit new data, and verify that the E-paper display updates immediately.

We will reboot the badge to confirm the data is preserved.

We will toggle between the Classic and Fantastic screens to verify the layouts.

As you can see, we now have a clear idea of how the second screen should look and a plan to implement everything, but before spawning the agent work, I'd also like to have a design of the first screen of the badge, so using the chat, I ask to include it also in the plan.
After two iterations of the prompt, this is the result

The implementation

To implement the plan, we just need to press the Proceed button and wait

During the implementation, we can check what is happening through the UI

And if we notice something weird, we can stop the agent and type a new prompt to drive it again on the right path.
If you, like me, prefer to get confirmation before running commands or editing files, you must also approve these actions through the UI.

After 2 minutes, this is the result.

And if I connect my laptop to the badge Wi-Fi, I can configure my badge.

The refine

Now we have a badge working, but we want to improve it a bit: first, I want to change the screen by pressing the button on the back without connecting to the badge's Wi-Fi, and I want to set the Wi-Fi password via Environment Variables.
So I can prompt this

Can we also change the screen view using the button on the rear of the badge without connecting to the badge's Wi-Fi?

And after a minute, the result is ready, and my badge has been flashed.
And lastly, I can ask not to hard-code the password but use an environment variable,

use an environment variable for the wifi password

same here, after one minute and a couple of approvals, the result is again ready and in my badge.

To complete, I want to change the layout by using one of the buttons on the back of the badge. So again I ask Antigravity to do it for me.

Can we change the screen view also by using the button in the rear of the badge without connecting to the badge wifi?

and same here, after some minutes, sometimes the result is happier in the badge.

And the final result is this one

and this one

Conclusion

It's time to wrap up!
So my experience with Antigravity has been great! I love to use it to build new things, or as a teammate to learn new technology, or just to prototype a pet project like this one.

If you are in the agentic development, this tool can be a good one for you!
The experience is great, and if you want to have control over different projects or streams, it can be really helpful. The only pain point for me is the fact that if you want to check the code, you must install another tool, the Antigravity IDE, to check it.

In this era of agent development, what I find great is the ability to plan and review the changes before the agent implements them! This is the game-changer for me in this moment, and then a lot and a lot of code review!

Okay, that's it! I hope you enjoy this introduction to Antigravity and that you now want to test it for your project.

I hope you also like my new super badge 🚀

p.s. to check the code result, you can navigate to this repository

Google Cloud credits are provided for this project.

Take control of your job with GitLens Launchpad

Tue, 23 Dec 2025 00:00:00 GMT

As a developer, you have to take control of your projects every day. Whether it is a company repository, an open source project you maintain or collaborate on, or a simple pet project.

Gaining control over your projects often depends on the platform you're working with. While there are many options available, such as Atlassian and GitLab, today I will focus on using GitHub as the platform of choice. Let me guide you through how you can effectively manage your projects on GitHub.

I’ll talk about the GitHub one because that is where I’m working on.

For me, checking the status of my PRs is essential in my daily work. On average, I spend about one or two hours a day tracking down failing CI checks and keeping my PRs in sync with the main branch, or reviewing other PRs.

To do that, I used to use the GitHub website on my PRs page. This page is good; you can find all your PRs, including those where your teammates are requesting a review. You can check whether your PR has reviews and whether the CI passes.

Here you can see my PRs at this specific moment.

As you can see, you can immediately receive information about the PRs, the number of comments, and more.

I used this page for a while because it is a perfect way to check all the work across many repositories, but it has a small problem: to check the page, I have to switch between VSCode and the browser during my job. This constant switching might seem trivial, but research suggests it takes an average of 23 seconds to return to a productive state after such a context switch. In the fast-paced developer environment, these seconds add up, potentially impacting overall efficiency and output.

So, I decided to search for another solution that would let me have the same information across the projects without leaving my VSCode instance.

The first useful extensions to the migration

GitHub Pull Requests was the first extension I started to test. This extension enables checking all PRs in the current repository I’m working on. I can see my open PRs and my teammates' open PRs. From a VSCode panel, I can check the status of a PR or review another one.
This extension enables us to open a PR directly from VSCode without using the GitHub website, reducing the need to switch context between the editor and the GitHub website.
Here is a picture of the extension

As you can see, in the left panel, we can control PRs and Issues. By clicking the PR, we can view its home page. By clicking the arrow icon that appears when you hover over the PR, you can go to the Review mode and add comments or suggestions to that PR.

That extension has improved my DX experience, especially in PR creation and review, but, as you can see, it works only on the open repository, which is a limitation, since I cannot see if in other projects something or someone is blocked by my work, or it’s waiting for a review or something else.

The Final Solution

While browsing the web, I came across a feature of GitKraken called Launchpad. This feature enables us to get a big-picture view of all issues and PRs where we are the creator or a follower. If you don’t know GitKraken, it is a Git client with an awesome UI for managing your repositories. You can use it as a desktop app, website, editor extension (GitLens), or the CLI. They have also released an MCP server in the last period to manage your repository through an LLM.
As you can imagine, I use the GitLens extension, which has a panel that lets me see everything across my repositories.
Spoiler: I use it with GitHub, but you can also use it with Bitbucket and GitLab. It can also combine data across different platforms.

In this panel, there are different groups where you can find your PRs that meet that status. If you click the PR, you will see a pop-up that lets you get more info or jump into the repository if you have already set it up on your machine.

As you can see, just using these two extensions, I reduced the number of switches between my lovely VSCode and the GitHub website. In my editor, I already have control over all my repositories, and with the correct panel, I can do most of my work directly in the editor.

Before closing, I’d like to give you another extension that reduces the need to switch between the editor and the GitHub website. This extension is the GitHub Actions one. This extension lets you check the status of actions directly in the editor, without jumping to GitHub to search for them.

Conclusion

It’s time to wrap up this article.
At first, I showed how I used to check my current work across projects on GitHub, but eventually it became a pain point because switching between the editor and the browser was annoying.
Then I moved to the GitHub Pull Requests extension, which enables me to open, review, and check PRs and Issues in the current open repository.
Lastly, I talked about the GitLens Launchpad, which, through a panel in the editor, provides a big-picture view of all the PRs across the repositories I’m working on and helps me reduce switching between the editor and GitHub during my daily work.

If you want to use the GitLens Launchpad, it is a PRO feature that requires a valid GitKraken license. To buy one, check this in this reference.

That’s it for this article. I hope this feature can also improve your daily DX, and see you in the following articles.

Bye bye 👋

The Mood Mirror App - My Antigravity first experience

Thu, 04 Dec 2025 00:00:00 GMT

Just a week ago, Google launched Antigravity, and why not give it a try and share my experience? And here I am for this.

In this article, I'll talk about my first experience with Antigravity and how I built a small web app called The Mood Mirror. This app emulates an artist who can convert your mood into abstract images or videos.

Spoiler: this app uses Gemini 3, Nano Banana Pro and Veo, but I'll talk about them in a future article.

Antigravity Intro

Let's start with a small presentation about Antigravity.

Google Antigravity is an Agentic IDE. It is a fork of VSCode with a dedicated agent section that features models such as Gemini, Claude, and GPT.

This last part is what makes Antigravity different from VSCode or Cursor; this section is built and maintained by Google. Yes, the experiences are common, but how this Agent section is integrated into the IDE is what differentiates it from the others, and this is where all the IDE teams are working to improve their users' DX.

For more info about Google Antigravity, you can check its website in this reference.

"The Mood Mirror" Setup

To test the tool's full power, I decided to build the application almost entirely in "Vibe Coding". To that end, I began by setting up the project and wrote a prompt outlining my intention and what I hoped to achieve.

In this picture, you can see what Antigravity looks like, and as you can imagine, in the chat, you can prompt our intention.

For my application, I entered this prompt.

Role: You are a Senior Software Engineer Agent.

Project: Build a responsive web application called "Mood Mirror".

Stack: React, Tailwind CSS, and the Gemini 3 SDK.

Core Functionality:

Input: Create a clean, minimalist text area where the user enters how they feel (e.g., "I am anxious about my deadline").
The "Director" Logic (Gemini 3): When the user submits, send the text to Gemini 3.

Analyse the Sentiment Score (0 to +1.0).
Extract an Emotional Colour Palette (e.g., "Stormy Grey and Electric Blue").
Generate a Creative Prompt for an abstract art piece based on that emotion.

The "Artist" Execution (Nano Banana):

Pass the Creative Prompt to the Nano Banana Pro API.
Conditional Logic: If the Sentiment Score is extreme (above 0.8 or below -0.8), request a 5-second looping Video (MP4). Otherwise, request a High-Res Image (PNG).

Dynamic UI: Update the app's background gradient instantly to match the Emotional Colour Palette returned by Gemini while the image generates.

Execution Plan:

Scaffold the project.
Write the SentimentService using the Gemini 3 logic.
Implement the Nano Banana API hook.
Deploy to preview.

The result of this prompt was a plan of action for Antigravity to implement my request. I got this result because I selected "planning" in the bottom-left drop-down. If you decide to go with the fast option, Antigravity doesn't show the plan and immediately develops it.

Btw, I chose the planning options so that I can check and comment on this plan directly in the IDE.

In the image above, you can see an example of the plan I received. As you can see, you can either accept it or review it, and then ask Antigravity to check your comments and review the plan.

The prompt and its plan are the result of this commit.

What went wrong? 😑

The setup has gone smoothly and pretty well, but I ran into an issue: Antigravity generated a JavaScript application rather than a TypeScript one. Not a big deal. Later, I asked it to review the project in JavaScript and TypeScript, and it converted it without any issues. in the GitHub repository you can see the result.
And lastly, it generated two files, one for the Sentiment discovery and the other for the image generation, but it created a sort of mock service without.
I didn’t iterate again to fix them, but I’ve worked on them later.

Commit linting into the project

The second test I did was about setting up a development tool to verify the commit messages. I like to use commitlint and conventional commits for my project, so my second test was adding the setup for these tools.
I opened a new chat, and I entered this prompt.

I want to add commitlint and conventional-commit to this project. Can you set it up?

I was concerned that the prompt wasn’t particular, but I did it to see what Antigravity produces and how good the results are.

I ran that prompt in “fast” mode, and the first result was pretty good. It installs and sets up @commitlint/cli and @commitlint/config-conventional and after that, it added husky to validate the commit message in the pre-commit hook. I’m not a husky fan, I prefer lefthook. So after this first iteration, I asked Antigravity to replace husky with lefthook. The result I got worked, but it wasn’t the best solution ever. I decided not to reiterate this time, to leave it in the repo and also show what an Agentic IDE can generate when we don’t check its results and trust it too much.

In this second iteration, Antigravity added lefthook without any problem, but it didn’t remove all the husky references. In fact, if you check the commit, you can see the _husky folder with two files, with no sense script for this repo, and in the package.json, it forgot to remove the prepare script.

As you can see, our code review when using these tools is crucial to avoid trash or unnecessary code.

The Gemini 3.0 integration

The next test was the Gemini integration to build the Sentiment analysis service.
As I did in the previous tests, I started from a new chat.
The prompt in this case was a bit more articulated. I asked to generate a service that accepts a text and, through Gemini, returns a structured result with these fields:

moodScore: a value between 0 and 1 to determine the mood score
promptType: This is the value that determines if the mirror will show an image or a video
promptText: This is the text to pass later to generate the video or the image

This result must later be used to generate an image or a video using NanoBanana Pro or Veo 3.

This iteration has been a bit convoluted. The first version used the old npm package @google/generative-ai and not the new one @google/genai. So I kept reiterating to get the code updated to the new version of the SDK. Another issue I had was that Antigravity created a single file to handle both images and videos. So, for that, I reiterated the need to split the logic for image and video generation into two separate files, and I also fixed the video generation to use the video model instead of the image model.

After that, I got a working application that met my first requirements, and you can see a demo in the video below. [and in the GitHub repository you can check the commit]

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=098qvXvpVZQ

Conclusion

It’s time to wrap up this first experience with Antigravity.

Overall, the experience with the tool was good. This is its first version, and only a few weeks after its release, Antigravity showed great DX and a good understanding of what I want to achieve.

Yes, it is not perfect, and in some cases, the plan described at the beginning hasn’t been satisfied. But this also happens with IDEs that have been in place for months.

As with the other Agentic IDEs, including Antigravity, developer checks are key to boosting implementation velocity while maintaining codebase quality.

The planning mode is fantastic in my opinion, because taking a look at the plan and reviewing or confirming it before starting the implementation can reduce the time wasted on reiterating the Agent result; as we saw, it’s still not perfect yet, but I’m pretty sure it will be tuned and improved in the future.

If I had to rate this first experience, I'd give it 7/10 because the flow was excellent, but I expected more precise results.

Okay, that’s all. I hope you enjoyed this article. Let me know in the comments your experience with Antigravity or other Agentic IDEs.

Bye Bye 👋

Improve Your Git Commit Messages with GitLens Tips

Fri, 03 Oct 2025 00:00:00 GMT

In the AI era, we can do many different things with LLM: generate code, images, videos or ask whatever we want and wait for an answer.
The AI is here, and we cannot snub it. I love using it to simplify my day, help me find solutions, or learn new things. For instance, one of the most challenging tasks I perform every day is crafting a commit message for my next commit. I love to commit often, and I avoid commit messages like “WIP”, “work in progress”, “first step”, “second step”, and so on.
In the past, I spent a considerable amount of time crafting the perfect commit message for the next commit. Currently, thanks to GitLens (by GitKraken), I can ask for help from the AI to generate a prefilled message based on my actions, and then review the generated message.

How to generate messages

To generate the commit messages, first of all, you have to change your codebase 😎
After that, when you are ready to commit, it’s time to generate the message.
To do that, you need to go to the Source Control panel in VSCode, and if you have the GitLens extension installed, you can use the “Magic” icon to generate the message.

If you click the button, you should have three options

Generate Commit Message with GitLens
Compose Commit (Preview)
Switch GitLens AI Provider/Model

It goes without saying that the first option is the correct one to use when generating your commit message.

After clicking the button, you must wait for a couple of seconds, and the result will appear in the text box.

As you can see, the result is excellent. A commit message that follows the conventional commit rules and a small description of what happened in the code.

Now, you can decide whether the message is okay and commit without changing it, or review it and then commit with your edited message.

Custom Instructions

As with all AI features, instructions are crucial to achieving the best possible result.
Also, for this feature, we can set up instructions to guide the AI in creating the messages.
To do that, you have to go to Settings and search for “GitLens commit message AI custom instruction”.
You should find an option “Gitlens › Ai › Generate Commit Message: Custom Instructions (Preview)”, and this option has a text box that you can fill.
In my case, I inserted this instruction: “Please generate the commit message in the format of conventional commit,” but you can insert all the instructions that you want.
These instructions will help the AI generate the best messages based on your needs, and they will likely reduce the changes required to achieve the best message in the end.

Conclusions

As you can see, this feature is pretty simple but very helpful. It can reduce the time you spend generating commit messages and help you describe the intention of your commits in the best way.
I use it daily, and it helps me to be more precise in my commit messages, which in turn helps me summarise the commit in the best way.
N.B. I’m not a native English speaker, and this feature helps me express myself in the best possible way in my commits.

Okay, that’s all, folks. I hope you’ve enjoyed the content and found it helpful.
See you soon

Bye Bye 👋

Do you really need the Cloud to work with AI?

Wed, 25 Jun 2025 00:00:00 GMT

We are in the AI era. New models emerge daily, and many applications have already integrated AI into their workflows.

Gemini, OpenAI, Copilot, Deepseek, Llama, and many others enable AI in your applications or help you write code, but they all need an internet connection to be accessible. You need the Cloud or to connect to a managed service to get an answer from the model. In some scenarios, this approach exposes you to security issues or the risk of sharing data with another service, and you may want to avoid it.

To help the team and companies benefit from AI and avoid these issues, the Chrome team is working to make Gemini (nano) part of the Chrome browser. The idea is to download the models in the browser when you have connectivity and use them directly from the browser, offline, if needed.

So let's see how it works 🚀

These features are on the building; most are available only under the Canary version and feature flag. If you are interested, you can find all the info at this in this reference.

Features available

As you've already understood, only limited features are available; some are stable, and some are not.

Let's start by listing the features, and later, we will look at some of them.

The available API are:

Some are stable from Chrome 138, and some are available for local experiments; you can check out the status of the APIs in this reference so you can be sure about the current situation when you read this post.

As you can see, the APIs' names are fantastic, and they explain their behaviour.

If you want to try these features, start from this documentation section. Unfortunately, you must enable the features through the configurations, so follow these steps to get a Chrome instance ready to run AI models directly from your laptop.

Before closing this chapter, here is a quick reflection on these APIs. As you can notice, all of them work with text; some produce, some detect, some translate, and so on. So, for now, you can work with text and not produce images or videos from the browser, but it's a great starting point!

Let's talk about features

Language Detector

The language detector API is one of the features available from Chrome 138. It allows you to detect the language of a specific word or phrase.

It returns a list of possible languages with the confidence score for that language. This means that we need to make a strategy to choose the best language for our application, but in most cases, the language with the best score is the best one for our application!

How it works!

One thing to do is check if the API is available or not to prevent errors.

To do that, you must check the self object.

if ('LanguageDetector' in self) {
  // Language Detector Available
}

Then, you must check if the model is already available in your browser or if you need to download it.

const availability = await LanguageDetector.availability();

This result can have four possible values:

"unavailable": The requested options are unsupported, or the model cannot be prompted.
"downloadable": The request is supported, but you need to download additional files before creating a session. These downloads may include the language model or fine-tuning.
"downloading": The request is supported and a download is ongoing, which must be completed before creating a session..
"available": The request is supported, and you can create a session.

This method is pretty much the same for all APIs. Following this flow, you can check if a specific API is available.

When you reach the available status, you are finally ready to work with the LanguageDetector API, and you can create an instance of it by following the next code.

const instance = await LanguageDetector.create();
const result = await instance.detect('Hello world!');

// result = [{
//   detectedLanguage: 'en',
//   confidence: 0.9973934888839722
// }];

As you can see, this API is straightforward and pretty easy to learn.
With that, you have completed your first learning about AI in Chrome with Gemini Nano, and it’s time to move on to another fantastic API!

N.B. If you are working with TypeScript and want to get the best DX possible, a types package that simplifies your work and enables IntelliSense for these APIs exists. @types/dom-chromium-ai This is the name of the package, and we have to thank you, Christian Liebel and Thomas Steiner, for it.

Translator API

Translator API is one of the most common features for an AI. It's pretty simple: you send a text, and you will receive the text translated. This API is available from Chrome 138.
But let’s see how it works.

How it works!

First, you must check if the API is available in the browser.

if ('Translator' in self) {
  // Translator API available
}

If the API is enabled, you must check if the languages you need for source and target are available.
To do that, you must use the availability method exposed by the Translator object.

const translatorCapabilities = await Translator.availability({
  sourceLanguage: 'en',
  targetLanguage: 'it',
});

The result of this method can have four different values:

"unavailable": The implementation does not support translation of the given languages.
"downloadable": The implementation supports translation of the given languages, but a download is required to proceed. The download may be the browser model.
"downloading": The implementation supports translation of the given languages. The browser is finishing an ongoing download, as part of creating the associated object.
"available": The implementation supports translation of the given languages, and any required downloads are already complete.

Now, if you don’t receive "unavailable", you can create the translator instance. This method will download the model for you if it hasn’t already been downloaded.

const translator = await Translator.create({
  sourceLanguage: 'en',
  targetLanguage: 'it',
  monitor(m) {
    m.addEventListener('downloadprogress', (e) => {
      console.log(`Downloaded ${e.loaded * 100}%`);
    });
  },
});

As you can see, using the create method, you can create your instance and pass your source and target languages. Then, using the monitor method, you can listen to the download progress and maybe create a loader for the user to provide feedback and create a better UX experience. Obviously, the promise will fail if something goes wrong during the download, and you must handle it.
But if everything is okay, you can use the new translator instance to translate the text by using the translate method.

await translator.translate('Where is the next bus stop, please?');
// Dov'è la prossima fermata dell'autobus, per favore?

One important thing to know about this API is that it processes messages sequentially. So, if you have many messages, you must keep this limitation in mind. Then, if you need to translate large amounts of text, it’s better to chunk it and create a loading interface as feedback for the user.

As is evident, this API is also straightforward. There are some methods to learn, and you can integrate this API into your applications by using them.

Also, for this API, you can use the @types/dom-chromium-ai package to get a better experience with TypeScript.

Summarizer API

The last API you will meet in this article is the Summarizer API.
This API enable you to summarise small or large text. Also, this API is available from Chrome 138 stable.

How it works!

First, you must check if the API is available in the browser.

if ('Summarizer' in self) {
  // Summarizer API available
}

If the API is enabled, then you must check if the model is available.

const summarizerCapabilities = await Summarizer.availability();

Also, for this method, the possible results can be:

"unavailable" means that the implementation does not support the requested options.
"downloadable" means that the implementation supports the requested options, but first, the browser has to download something, such as a model (in Chrome's case, Gemini Nano) or fine-tuning for the model.
"downloading" means that the implementation supports the requested options, but it has to finish an ongoing download before it can proceed.
"available" means that the implementation supports the requested options and the summarizer can proceed.

Now, if everything is okay, it’s time to create an instance of the Summarizer API.

const summarizer = await Summarizer.create({
  monitor(m) {
    m.addEventListener('downloadprogress', (e) => {
      console.log(`Downloaded ${e.loaded * 100}%`);
    });
  }
});

This create method exposes the monitor function to listen to the download progress and create a better experience for the user as well.
This create method has different parameters you can pass to get different types of summaries or drive the summary's length.

These parameters are:

sharedContext: Additional shared context that can help the summarizer.
type: The type of summarisation, with the allowed values key-points (default), tldr, teaser, and headline. To learn more about them, follow this in this reference.
format: The format of the summarisation, with the allowed values markdown (default) and plain-text.
length: The length of the summarisation, with the allowed values short, medium (default), and long. The meanings of these lengths vary depending on the requested type.

It's important to know that parameters can’t be changed. So, once you create a new instance, if you need to modify the parameters, you must create a new instance.

Now that you have the summarizer instance, you can use it to summarise the text.

const longText = 'Blah blah blah......';
const summary = await summarizer.summarize(longText, {
  context: 'This is a recipe.',
});

This API also exposes another method, just in case you want to stream the summary result and make it available “faster.”
To do that, you need to use the summarizeStreaming method instead of the summarize one.

const longText = 'Blah blah blah......';
const summary = await summarizer.summarizeStreaming(longText, {
  context: 'This is a recipe.',
});

And with that, you learnt the last AI API for Browsers available in this article 😃

Like the others, this API is straightforward too. There are just some methods to know, and you can integrate this API into your applications.

Recipe Radar with AI App

I wrote a lot in this article, I know, but to let you know how these APIs work. I created a sample app with some recipes. On the detail page, you can see the Language Detector and Translator API in action. Therefore, on the search page, you can see the Summarizer API in action to summarise the recipe and return a summary of the recipe to the user.
If you are interested in it, here is the link to the repo and to the website:

Github Repo: https://github.com/Puppo/recipe-radar-with-ai
GitHub Page Website: https://puppo.github.io/recipe-radar-with-ai/

Please don’t take too much care of the code structure. I vibe-coded the application's structure to reduce the time it took to create, and I spent more time on the AI feature and its integration.

By the way, this application example implements and runs all these APIS on a website. It’s important to test in a Chrome version with these APIs available.

Conclusion

Okay, it’s time to wrap up!
In this article, you learn how to integrate AI inside the Browser without relying on any services or cloud providers.
You learnt how to use Language Detector, Translator, and Summarizer API on the Web and what they look like.
Remember that these new features are not available in all browsers, so please be careful when using them in production.

That’s it, folks. I hope you enjoyed the content. If so, please leave a comment or a reaction!

See you soon with other awesome content 🚀

Bye Bye 👋

Google Cloud credits are provided for this project. #AISprint

A Promise is forever

Tue, 06 Feb 2024 00:00:00 GMT

In the ever-evolving world of web development, mastering asynchronous operations is a crucial skill for any JavaScript developer. Asynchronous programming allows web applications to handle tasks like API requests, file operations, or any activities that require waiting for results without blocking the main thread. Traditionally, this was managed through callback functions, leading to the infamous "callback hell," where code becomes tangled and difficult to maintain. Enter JavaScript Promises - a powerful and elegant solution to simplify asynchronous code management.

Promises in JavaScript represent the eventual completion or failure of an asynchronous operation and its resulting value. They not only provide a cleaner and more manageable way to handle asynchronous tasks but also offer improved error handling and readability. This makes them an indispensable tool in the modern JavaScript developer's toolkit.

In this comprehensive guide, we'll embark on a journey to unravel the mysteries of JavaScript Promises. From their fundamental concepts to advanced techniques, we will explore how Promises can streamline your code and make handling asynchronous operations a breeze. Whether you're just starting your journey with JavaScript or are a seasoned developer, this post aims to enhance your understanding and skills in working with Promises.

So, let's dive in and unlock the full potential of JavaScript Promises, transforming the way you write and manage asynchronous code!

Section 1: Understanding Promises

What is a Promise?

At its core, a JavaScript Promise is an object that represents the eventual completion or failure of an asynchronous operation and its resulting value. Unlike the immediate return of values in synchronous code, a Promise gives us a placeholder for a future value, which we can work with in a more structured and predictable manner.

This approach solves many issues associated with older, callback-based patterns, commonly known as "callback hell." Promises allow for more readable and maintainable code, especially when dealing with complex sequences of asynchronous operations.

Creating a Promise

A Promise in JavaScript is created using the Promise constructor. It takes a function as its argument, known as the executor function. This executor function is called immediately by the Promise implementation and it receives two functions as parameters: resolve and reject.

resolve is called when the asynchronous task completes successfully, passing the result.
reject is used when the task fails, passing the error or reason for failure.

Here's a basic example of creating a Promise:

let myPromise = new Promise((resolve, reject) => {
  // Asynchronous operation code here
  if(/* operation successful */) {
    resolve('Success');
  } else {
    reject('Error');
  }
});

In this example, the Promise will either resolve with Success or reject with Error, depending on the outcome of the asynchronous operation encapsulated within it.

Promise States

A Promise can be in one of three states:

Pending : The initial state of a Promise. The operation has not been completed yet.
Fulfilled : The operation was completed successfully, and the Promise now holds the resulting value.
Rejected : The operation failed, and the Promise holds the reason for the failure.

This state model ensures that a Promise can only be resolved or rejected once and its state and value become immutable after that change.

Understanding these foundational concepts is crucial for working effectively with Promises in JavaScript. They form the building blocks upon which more complex asynchronous operations can be built, allowing for more readable and maintainable code.

Section 2: Working with Promises

then, catch, and finally

After creating a Promise, the next step is handling its resolution or rejection. This is where the methods then, catch, and finally come into play.

then : This method is used to access the result of a Promise if it is successfully resolved. It takes up to two functions as arguments: the first for the resolved case and the second for the rejected case.
catch : This method is used for error handling in Promises. It is essentially a shorthand for then(null, rejection).
finally : Introduced in ES2018, finally is a method that executes a specified piece of code when the Promise is settled, regardless of its outcome (resolved or rejected). It's useful for cleanup actions.

Chaining Promises

One of the key strengths of Promises is their ability to be chained. This is done by returning another Promise in the then method, which allows for sequential asynchronous operations.

new Promise((resolve, reject) => {
  setTimeout(() => resolve(1), 1000);})
  .then(result => {
    console.log(result); // 1
    return result * 2;
  })
  .then(result => {
    console.log(result); // 2
    return result * 3;
  })
  .then(result => {
    console.log(result); // 6
    return result * 4;
  });

In this chain, each then receives the result of the previous operation, allowing for a sequence of asynchronous tasks to be handled in a clean and readable manner.

Error Handling in Promises

Error handling is crucial in asynchronous code. In a Promise chain, if an error is thrown in any of the then methods, it propagates down the chain until it is caught by a catch method. This makes it easier to manage errors in complex asynchronous code.

doSomething()
  .then(result => doSomethingElse(result))
  .then(newResult => doThirdThing(newResult))
  .catch(error => console.error(error))
  .finally(() => console.log('Operation done'));

Real-world Examples

Promises are particularly useful when dealing with API requests. For example, fetching data from a remote server:

fetch('https://api.example.com/data')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

This section on working with Promises is critical for understanding how to effectively implement and manage asynchronous operations in JavaScript. It covers the fundamental methods for handling Promises and demonstrates the power of chaining for complex tasks, along with practical examples that the readers can relate to and implement in their own projects.

Section 3: Advanced Promise Concepts

Async/Await Syntax

Introduced in ES2017, async/await is a syntactic feature in JavaScript that allows you to work with Promises in a more synchronous-like manner, making your asynchronous code look and behave a bit more like synchronous code.

Async Functions : Declaring a function as async automatically wraps its return value in a Promise. This means you can use await within these functions to pause the execution until the awaited Promise is resolved.
Await : The await keyword is used to pause the execution of an async function until a Promise is resolved, allowing you to write cleaner and more readable asynchronous code.

Error Handling in Async/Await

Error handling in async/await is achieved using try/catch blocks, making it syntactically similar to synchronous error handling.

async function safeFetch() {
  try {
    const response = await fetch('https://api.example.com/data');
    return await response.json();
  } catch (error) {
    console.error('Fetch failed:', error);
    throw error; // Re-throwing the error is important for caller awareness
  }
}

Handling Multiple Promises

Promise.all

Promise.all is used when you need to wait for multiple Promises to complete. It takes an array of Promises and returns a new Promise that resolves when all of the input Promises resolve or rejects as soon as one of them rejects.

Promise.all([asyncTask1(), asyncTask2(), asyncTask3()])
  .then(results => {
    console.log('All tasks completed:', results);
  })
  .catch(error => {
    console.error('One of the tasks failed:', error);
  });

Promise.race

Promise.race resolves or rejects as soon as one of the Promises in an iterable resolves or rejects, with the value or reason from that Promise.

Promise.race([asyncTask1(), asyncTask2(), asyncTask3()])
  .then(result => {
     console.log('First task completed:', result);
  })
  .catch(error => {
      console.error('One of the tasks failed:', error);
  });

Promise.allSettled

Promise.allSettled is a method that returns a Promise that resolves after all of the given Promises have either been resolved or rejected, with an array of objects describing the outcome of each Promise.

Promise.allSettled([asyncTask1(), asyncTask2(), asyncTask3()])
  .then(results => {
     results.forEach((result) => {
       if (result.status === 'fulfilled') {
         console.log('Success:', result.value);
       } else {
         console.log('Failure:', result.reason);
       }
     });
  });

Promise.any

Promise.any takes multiple Promises and as soon as one of the Promises resolves, it returns a single Promise that resolves with the value from that Promise. If all of the passed-in Promises reject, then the returned Promise is rejected with an AggregateError.

Promise.any([asyncTask1(), asyncTask2(), asyncTask3()])
  .then(result => {
    console.log('First successful task:', result);
  })
  .catch(error => {
    console.error('All promises failed:', error);
  });

These methods for handling multiple Promises are powerful tools in a JavaScript developer's arsenal. They offer different ways to manage multiple asynchronous operations, making it easier to write clean and efficient code. Understanding when and how to use each of these methods can significantly improve the way you handle concurrency in JavaScript.

Understanding Promise.withResolvers

In the realm of JavaScript Promises, Promise.withResolvers could be conceptualized as a utility function designed to enhance the flexibility and control over Promise resolution and rejection. Unlike the standard Promise constructor, which encapsulates the executor function, Promise.withResolvers could provide direct access to the resolve and reject functions outside the Promise context. This feature would be particularly useful in scenarios where the resolution or rejection of a Promise needs to be triggered externally or in more complex control flows.

Imagine Promise.withResolvers functioning as follows:

Promise.withResolvers = Promise.withResolvers ?? function() { 
  let resolve, reject;
  const promise = new Promise((res, rej) => {
    resolve = res;
    reject = rej;
  });
  return { promise, resolve, reject };
}

const { promise, resolve, reject } = Promise.withResolvers();

promise
  .then(value => console.log(`Resolved with: ${value}`))
  .catch(error => 
    console.error(`Rejected with: ${error}`));
// The Promise can be resolved or rejected externally
resolve("Success!");
// or reject("Failure");

In this hypothetical implementation, Promise.withResolvers returns an object containing the Promise itself and its respective resolve and reject functions. This setup offers a more declarative way of handling Promises, especially in cases where the resolution condition is not immediately known or is dependent on external factors.

This approach, while offering more control, also requires careful management to avoid issues like unresolved Promises or memory leaks. It exemplifies the flexibility of Promises in JavaScript and how they can be tailored to fit specific programming paradigms or application needs. This method has been implemented in ES2023 but creates a polyfill for it; it is really a piece of cake as you can see.

Section 4: Under the Hood

Event Loop and Promises

JavaScript's concurrency model revolves around the Event Loop, which plays a critical role in executing asynchronous code like Promises. Understanding this mechanism is key to mastering JavaScript's asynchronous behavior.

Event Loop : JavaScript has a single-threaded runtime, meaning it can only execute one command at a time. The event loop enables non-blocking operations by offloading tasks like I/O, timers, and HTTP requests, which are handled outside the JavaScript engine.
Role of Promises : When a Promise is resolved or rejected, its callback is moved to the Microtask Queue, which is processed after the current execution stack is complete but before the event loop continues to the next iteration. This ensures that Promise callbacks are executed as soon as the JavaScript engine has the opportunity to do so, maintaining the non-blocking nature of asynchronous operations.

Creating Custom Promises

While many asynchronous operations are handled by built-in functions returning Promises, there are scenarios where you might need to create your own Promises.

Custom Promise Example : Let's say you're interfacing with a legacy API that uses callbacks, and you want to adapt it to use Promises for better code consistency and readability.

function legacyApiFunction(callback) {
  // Simulating a callback-based API
  setTimeout(() => {
    const data = 'some data';
    callback(null, data);
  }, 1000);
}

function promisifyLegacyApi() {
  return new Promise((resolve, reject) => {
    legacyApiFunction((err, data) => {
      if (err) {
        reject(err);
      } else {
        resolve(data);
      }
    });
  });
}

promisifyLegacyApi()
  .then(data => console.log(data))
  .catch(error => console.error(error));

In this example, promisifyLegacyApi wraps the old callback-style function in a new Promise, providing a more modern, Promise-based interface for the same functionality.

Best Practices and Pitfalls

Avoiding the "Promise Hell" : Similar to "callback hell," it's possible to end up in a situation with deeply nested Promises. To avoid this, leverage chaining and return Promises from within then callbacks, keeping the code flat.
Error Handling : Always handle errors in Promises, either using catch for individual Promises or global error handlers for unhandled Promise rejections.
Debugging : Debugging asynchronous code can be tricky. Utilize modern tools and techniques such as browser developer tools, which provide features to track and inspect Promises.

If you want to dive deep into Promise, don't leave my YouTube video about it.

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=ROwJX3i_m2Q

Conclusion

As we conclude our journey through the world of JavaScript Promises, it's clear that they are much more than just a tool for handling asynchronous operations. They represent a fundamental shift in how we write and think about asynchronous code in JavaScript, offering a robust and elegant way to manage complex operations.

From understanding the basics of what a Promise is and how to create one, to exploring advanced concepts like Promise.all, Promise.race, Promise.allSettled, and Promise.any, we've covered a broad spectrum of functionalities that Promises provide. The async/await syntax further simplifies working with Promises, allowing for code that is not only more readable but also easier to maintain.

The real power of Promises lies in their ability to streamline complex asynchronous tasks, making our code cleaner, more efficient, and more reliable. By understanding the event loop and how Promises fit into JavaScript's concurrency model, developers can write more performant and bug-free code.

As you incorporate these concepts into your daily coding practices, remember that mastering Promises is a journey. There's always more to learn and new patterns to explore. Keep experimenting, keep learning, and most importantly, keep coding. The world of JavaScript is constantly evolving, and with tools like Promises at your disposal, you're well-equipped to tackle the challenges of modern web development.

Happy coding!

You can find the code of this article in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

The Reflect API: The Swiss Army Knife Every JavaScript Developer Needs

Thu, 09 Nov 2023 00:00:00 GMT

Ever wished for a magical toolkit that gives you superhero-like control over JavaScript objects? Say hello to the Reflect API, the Swiss Army knife every modern JavaScript developer needs! From peeping into objects to conjuring custom behaviors Reflectis your one-stop spellbook! 📜

Strap in as we teleport through this arcane realm of JavaScript, where we'll not only decode Reflect, but also empower you with hands-on examples and practical tips! 🚀

🎯 Core Objectives of Reflect

Introspection : Much like looking into a magic mirror, Reflect allows you to delve into an object's properties and characteristics, enabling you to perform introspective tasks like checking property existence or retrieving property descriptors.
Manipulation : Think of Reflect as your Swiss Army knife for object operations. You can easily add, delete, or modify object properties and even trap or monitor these operations.
Extensibility : The Reflect API can be seen as a foundational layer that sets the stage for creating Proxy objects, empowering you to build custom behaviors for basic operations (like property lookup, assignment, enumeration, and more).

🛠 Reflect Methods

1. `Reflect.apply()`

Forget the complexities of Function.prototype.apply()! With Reflect.apply(), invoking functions is a breeze.

const numbers = [1, 2, 3];
const sum = (a, b, c) => a + b + c;

// Using Reflect.apply()
const result = Reflect.apply(sum, null, numbers);

console.log(result); // Output: 6

2. `Reflect.get()`

Tired of the limitations of vanilla property retrieval? Reflect.get() offers more control and flexibility.

const obj = { x: 42, y: 'hello' };

// Using Reflect.get()
const value = Reflect.get(obj, 'x');

console.log(value); // Output: 42

3. `Reflect.set()`

Modify properties with pinpoint accuracy, even within complex object hierarchies.

const obj = { x: 42 };

// Using Reflect.set()
Reflect.set(obj, 'x', 13);

console.log(obj.x); // Output: 13

4. `Reflect.defineProperty()`

Defining properties with their descriptors has never been easier!

const obj = {};

// Using Reflect.defineProperty()
Reflect.defineProperty(obj, 'x', { value: 42, writable: false });

console.log(obj.x); // Output: 42

5. `Reflect.deleteProperty()`

Wipe properties off the face of your object as if they never existed.

const obj = { x: 42 };

// Using Reflect.deleteProperty()
Reflect.deleteProperty(obj, 'x');

console.log('x' in obj); // Output: false

6. `Reflect.ownKeys()`

Discover all the keys an object owns, including Symbols!

const obj = { x: 42, [Symbol('key')]: 'symbolValue' };

// Using Reflect.ownKeys()
const keys = Reflect.ownKeys(obj);

console.log(keys); // Output: ['x', Symbol(key)]

🚀 Why Use Reflect?

By now, you might be asking yourself, "Why should I dive into Reflect when there are other ways to manipulate and inspect JavaScript objects?" Great question! Let's unravel the reasons that make Reflect a powerful tool in your JavaScript arsenal.

1. Functional Paradigm

The Reflect API offers static methods that embrace the functional programming paradigm, making them first-class citizens that you can pass around in your code.

👉 Example:

Suppose you want to make property retrieval generic. You can do so with ease.

const genericGet = Reflect.get;
const value = genericGet(someObject, 'someProperty');

2. Enhanced Error Handling

Unlike methods in the Object API that often throw errors, Reflect methods return a Boolean to indicate success or failure, allowing for more elegant error handling.

👉 Example:

With Reflect.set(), you can check if a property was set successfully and proceed accordingly.

if (Reflect.set(obj, 'key', 'value')) {
    // Property was set successfully
} else {
    // Failed to set the property
}

3. Proxy Integration

Reflect and Proxy are like two peas in a pod. The methods available in Reflect align perfectly with Proxy traps, allowing for seamless and straightforward custom behaviors.

👉 Example:

Creating a logging proxy becomes ridiculously simple.

const handler = {
    get(target, property) {
        console.log(`Reading property: ${property}`);
        return Reflect.get(target, property);
    }
};
const proxy = new Proxy(someObject, handler);

4. Consistency and Predictability

Methods in Reflect offer a more consistent API. They always return values (often Booleans) instead of throwing errors, and the parameter orders are predictable, leading to cleaner and more maintainable code.

👉 Example:

Both Reflect.get() and Reflect.set() have consistent argument ordering: target, propertyKey[, receiver].

Reflect.get(target, property);
Reflect.set(target, property, value);

5. Intuitive and Self-Documenting

Reflect methods are often more intuitive and self-documenting than their Object counterparts. This readability makes it easier for developers, new and experienced alike, to understand the code.

👉 Example:

Compare Reflect.ownKeys(obj) with Object.getOwnPropertyNames(obj).concat(Object.getOwnPropertySymbols(obj)).

Which one do you find more intuitive?

6. Future-Proofing

As JavaScript evolves, new methods are more likely to be added to the Reflect API, making it a wise choice for long-term projects.

For more info don't waste my YouTube video on my YouTube Channel.

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=gaCvSu3ncbw

Conclusion

And just like that, we've come to the end of our magical journey through the labyrinthine world of JavaScript's Reflect API! You're now armed with the tools, tricks, and spells—err methods—to perform object manipulation wizardry that would make Dumbledore proud.

Ready to cast your own spells? Grab your keyboard wand, and let's make the JavaScript realm a little more enchanted, one Reflect method at a time!

Remember, the magic isn't just in the code; it's in you, the coding sorcerer who brings it to life. Until our next spellbinding adventure, code on, wizards! 🚀

You can find the code of this article in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Cracking the JavaScript Code: Unveil the Magic of Object Property Descriptors

Thu, 02 Nov 2023 00:00:00 GMT

👋 Hey, JavaScript developers!

Ever wondered what makes your objects tick? Or how to go all "Inception" on your JavaScript code by manipulating object properties at a deeper, more granular level? Well, you're in luck! Today, we're diving into the magical world of Object Property Descriptors in JavaScript—a realm where you become the puppet master of your objects. 🎭

Get ready for a roller coaster ride that takes you through the hidden alleys of JavaScript's objects. By the end of this post, you'll be wielding Object Property Descriptors like a wizard casting spells, giving you full control over properties, and even the behaviour of your objects. 🧙

What is a JavaScript Object Property Descriptor?

In JavaScript, objects are more than just key-value pairs. They're intricate entities with characteristics that often go unnoticed, hidden beneath the surface like an iceberg in an ocean of code. Welcome to the fascinating realm of Object Property Descriptors, a tool that lets you truly tap into the full potential of JavaScript objects.

An Object Property Descriptor is essentially a metadata object that details how a property on an object behaves. It's like the DNA of the property, encoding its attributes and defining its characteristics. You can think of an Object Property Descriptor as a control panel, giving you knobs and levers to fine-tune how a property can be accessed, modified, enumerated, or deleted.

Here are the attributes you can configure with an Object Property Descriptor:

value: The actual value of the property. Simple enough, right? 📦
writable: Determines if the property value can be changed. It's like a lock that you can engage or disengage at will. 🔒
enumerable: Controls whether the property shows up during enumeration, like when you use a for...in loop or Object.keys(). It's like a spotlight—or lack thereof—on your property. 🔦
configurable: Decides if the property can be deleted or has its attributes changed. Think of it as the ultimate veto power. 🛑

You can access and modify these attributes using built-in JavaScript methods like Object.getOwnPropertyDescriptor(), Object.defineProperty(), and Object.defineProperties(). These are your magic wands to perform spellbinding feats of object manipulation!

For example, to make a property read-only, you can set its writable attribute to false. Or if you want to hide a property from enumeration, just set the enumerable attribute to false. It's like tailoring your object properties to fit your exact needs, almost as if you're crafting a bespoke suit!

Object Property Descriptors in Practice

It's time to get our hands dirty and jump into the practical aspects of using Object Property Descriptors in JavaScript.

1. Accessing Descriptors with `Object.getOwnPropertyDescriptor()`

Let's start with the basics. Ever wondered what the descriptor of an existing object property looks like? Object.getOwnPropertyDescriptor() is your answer. It takes two arguments: the object itself and the property name as a string.

const myObj = { age: 30 };
const descriptor = Object.getOwnPropertyDescriptor(myObj, 'age');

console.log(descriptor); // Output: { value: 30, writable: true, enumerable: true, configurable: true }

Here, the descriptor object shows the default attributes: value, writable, enumerable, and configurable. No surprises, everything is set to true by default! 🎉

2. Defining Descriptors with `Object.defineProperty()`

Okay, ready to step it up? What if you want to create a property with custom attributes? Say hello to Object.defineProperty(). It takes three arguments: the object, the property name, and the descriptor object.

const person = {};
Object.defineProperty(
    person,
    'name',
    {
        value: 'Alice',
        writable: false,
        enumerable: true,
        configurable: false
    }
);

console.log(person.name); // Output: Alice

Now, person.name is read-only and not configurable but still enumerable. Try changing its value, and JavaScript will be like, "Nice try, buddy!" 🤨

3. Batch Operation with `Object.defineProperties()`

But wait, there's more! What if you want to define multiple properties at once? Object.defineProperties() has got your back.

const animal = {};
Object.defineProperties(animal, {
    name: {
        value: 'Dog',
        writable: true
    },
    sound: {
        value: 'Woof',
        enumerable: false
    }
});

Here, animal gets two properties, each with its own set of descriptors. Efficient, isn't it? 🤓

4. Computed property with `Object.defineProperty()`

But wait, there's more again. What if you want to define a property that depends on other ones? Object.defineProperty() has got your back again.

const person = {
  firstName: 'John',
  lastName: 'Doe',
};

// Define a read-only property
Object.defineProperty(person, 'fullName', {
  get() {
    return `${this.firstName} ${this.lastName}`;
  },
  enumerable: true,
});

console.log(person.fullName); // John Doe

Here person has three properties, firstName, lastName and fullName. fullName depends on the others and it's enumerable so that it's included in the for...in loop and Object.keys() method.

Ok, I think the idea now it's clear and you can use your imagination to combine these configurations to provide the best descriptors for your objects.

To find out more don't waste my YouTube video on my YouTube Channel

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=AHLdUs8LtIA

Conclusion

In conclusion, Object Property Descriptors are a powerful feature of JavaScript that allows you to manipulate and define object properties with fine-grained control. This advanced feature offers developers the ability to create more dynamic and flexible code.

Whether you're a junior developer or an expert, understanding Object Property Descriptors can help you level up your JavaScript skills.

So go ahead, tinker with your code, challenge the norms, and keep pushing the boundaries. The JavaScript universe is your playground! 🚀

You can find the code of this article in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

JavaScript FinalizationRegistry Unraveled: Memory Management Magic Explained!

Wed, 25 Oct 2023 00:00:00 GMT

Introduction

JavaScript's memory management can be tricky, especially when it comes to handling objects that are no longer needed. As developers, we often need to deal with memory leaks and other issues that arise from improper garbage collection. Fortunately, JavaScript has introduced a new feature called the FinalizationRegistry to help us manage memory more efficiently. In this blog post, we'll dive deep into the world of FinalizationRegistry, exploring its purpose, how to use it, and real-world scenarios where it can come in handy.

A Simple Example

To begin, let's take a look at a simple example to understand how FinalizationRegistry works. The FinalizationRegistry is an object that enables you to register a callback function that will be invoked when an object is garbage collected. Here's a basic example:

const registry = new FinalizationRegistry((heldValue) => {
  console.log(`Clean up: ${heldValue}`);
});

function createObject() {
  const obj = {id: 1};
  registry.register(obj, "Object 1");
}

createObject();
// After some time, when the object is garbage collected, the console will log: "Clean up: Object 1"

In this example, we create a new FinalizationRegistry and provide a callback function that logs a message when the registered object is garbage collected. We then create an object and register it with the registry.

Real-World Scenario

Now, let's explore a more realistic scenario where FinalizationRegistry can be beneficial. Imagine we have a web application that allows users to upload and manipulate images. We use a third-party library to handle the image manipulation, and this library creates large objects that consume a significant amount of memory. To prevent memory leaks, we can use FinalizationRegistry to ensure that these objects are properly cleaned up when they are no longer needed.

const imageRegistry = new FinalizationRegistry((imageData) => {
  console.log(`Cleaning up image data: ${imageData}`);
  // Perform additional cleanup tasks, such as releasing resources associated with imageData
});

function loadImage(imageUrl) {
  return fetch(imageUrl)
    .then((response) => response.blob())
    .then((imageBlob) => {
      const imageData = new ImageData(imageBlob);
      imageRegistry.register(imageData, `Image: ${imageUrl}`);
      return imageData;
    });
}

function manipulateImage(imageData) {
  // Use the third-party library to manipulate the image
}

loadImage('https://example.com/image.jpg')
  .then((imageData) => {
    manipulateImage(imageData);
    // After manipulation, the imageData object will eventually be garbage collected
  });

In this example, we create an imageRegistry using FinalizationRegistry and register the ImageData objects when they are loaded. When an ImageData object is garbage collected, the provided callback function will log a message and perform any additional cleanup tasks required.

Considerations

While the FinalizationRegistry is a powerful tool for managing memory, there are some important considerations to keep in mind:

The timing of garbage collection is not guaranteed, and the callback function may not be invoked immediately after an object becomes unreachable.
FinalizationRegistry should not be used to manage critical resources, as it only provides a best-effort cleanup mechanism.
The held values in the registry should not be used to access the registered objects, as it may prevent them from being garbage collected.

To find out more don't waste my YouTube video on my YouTube channel

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=3sgIFrjA61U

Conclusion

The JavaScript FinalizationRegistry is a valuable addition to the language that can help developers manage memory more efficiently and prevent memory leaks. By understanding how it works and knowing when to use it, you can create more performant and memory-efficient applications. Keep in mind the considerations mentioned above, and happy coding!

You can find the code of this article in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Unlocking the Power of Proxies: JavaScript's Secret Superheroes

Wed, 18 Oct 2023 00:00:00 GMT

JavaScript's Proxy object is a powerful feature that enables you to intercept and customize operations performed on objects. This versatile tool allows developers to create more efficient and flexible code while also improving code maintainability. In this article, we will dive into the world of JavaScript proxies, explore their use cases, and provide examples for expert developers.

A Brief Introduction to Proxies in JavaScript

A Proxy object in JavaScript is used to define custom behaviour for fundamental operations such as property lookup, assignment, enumeration, and function invocation. It acts as a wrapper around another object, called the target, and allows you to intercept and manipulate operations performed on the target object.

Creating a JavaScript Proxy

To create a JavaScript Proxy, you need two things: a target object and a handler object. The target object is the object you want to wrap with the Proxy, while the handler object defines the custom behaviour for the proxy.

Here's a simple example of creating a Proxy:

const target = { name: "John", surname: "Doe", fullName: "John Doe" };
const handler = {
  get(_target, prop) {
    return _target[prop] ? _target[prop].toUpperCase() : "Property not found";
  },
  set(_target, prop, value) {
    if (prop === 'name') {
      _target.fullName = value + ' ' + _target.surname;
    }
    if (prop === 'surname') {
      _target.fullName = _target.name + ' ' + value;
    }
    if (prop === 'fullName') {
      throw new Error('fullName is not writable')
    }
    _target[prop] = value;
    return true;
  }
};

const proxy = new Proxy(target, handler);
console.log(proxy.fullName); // Output: "JOHN DOE"
console.log(proxy.nonexistent); // Output: "Property not found"
proxy.name = 'Jane';
console.log(proxy.fullName); // Output: "Jane Doe"
proxy.surname = 'Smith';
console.log(proxy.fullName); // Output: "Jane Smith"
proxy.fullName = 'Tom Smith'; // Error: fullName is not writable

In this example, we defined a get trap in the handler object, which intercepts the property lookup operation on the target object. When a property is accessed on the proxy object, the get trap is invoked, and it returns the property value in uppercase if the property exists or a custom message if it doesn't.
Then, we defined a set trap, which intercepts a property's set. If the property name is name or surname calculates the fullName and sets the target object with the right value, but if you try to set the fullName property the code raises an error.

Use Cases for Proxies in JavaScript

Validation and Constraints

Proxies can be used to enforce data validation and constraints when setting properties on an object. For example, you can ensure that a property value is a certain type or within a specific range.

const target = { age: 25 };
const handler = {
  set(_target, prop, value) {
    if (prop === "age" && (typeof value !== "number" || value < 0 || value > 150)) {
      throw new TypeError("Invalid age value");
    }
    _target[prop] = value;
    return true;
  },
};

const proxy = new Proxy(target, handler);
proxy.age = 30; // Works fine
proxy.age = "thirty"; // Throws TypeError: "Invalid age value"

Logging and Profiling

Proxies can be used to log and profile operations performed on an object, which can be helpful during debugging and performance analysis.

const target = { message: "Hello, World!" };
const handler = {
  get(_target, prop) {
    console.log(`Accessing property "${prop}"`);
    return _target[prop];
  },
  set(_target, prop, value) {
    console.log(`Setting property "${prop}" to "${value}"`);
    _target[prop] = value;
    return true;
  },
};

const proxy = new Proxy(target, handler);
console.log(proxy.message); // Logs: "Accessing property "message"" and outputs: "Hello, World!"
proxy.message = "Goodbye, World!"; // Logs: "Setting property "message" to "Goodbye, World!""

To learn more don't miss my YouTube video about JavaScript Proxy on my YouTube channel

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=e7_lxSrP_Ok

Conclusion

JavaScript's Proxy object is a powerful and versatile feature that allows developers to create more efficient and flexible code. By understanding and utilizing proxies, you can unlock their full potential and become a true JavaScript superhero.

You can find the code of this article in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

JavaScript WeakRef Explained: Harnessing Memory Management Magic

Wed, 11 Oct 2023 00:00:00 GMT

Introduction to WeakRef

WeakRef is a powerful feature in JavaScript that allows developers to create weak object references. A weak reference is a reference that does not prevent the object it refers to from being garbage collected. This can be useful when you want to maintain a reference to an object without preventing it from being cleaned up by the garbage collector.

How WeakRef Works

WeakRef works by creating a weak reference to an object. This reference does not count towards the object's reference count and does not prevent it from being garbage collected. To access the object, you can call the deref() method on the WeakRef instance. If the object is still alive, the method will return the object; otherwise, it will return undefined.

Implementing WeakRef in Your Code

To use WeakRef in your code, follow these steps:

Create a new WeakRef instance by passing the object you want to reference as an argument: const weakRef = new WeakRef(targetObject);
To access the object, call the deref() method on the WeakRef instance: const object = weakRef.deref();
Check if the object is still alive by testing if it is not undefined: if (object !== undefined) { /* object is still alive */ }

Use Cases for WeakRef

WeakRef can be helpful in several scenarios, such as:

Caching: Use WeakRef to create a cache for expensive-to-create objects. When an object is no longer needed, it can be garbage collected automatically, freeing up memory.
DOM Element References: In web applications, you can use WeakRef to hold references to DOM elements. This can help prevent memory leaks when you need to keep track of elements for event handling or manipulation.
Resource Cleanup: When working with external resources like files or network connections, you can use WeakRef to keep track of those resources. If the resource becomes unused (e.g., a file is closed or a network connection is no longer needed), it can be automatically released.
Memoization: Implement memoization using WeakRef to store the results of function calls. This allows you to cache function results without preventing the input arguments from being garbage-collected when they're no longer needed.
Managing Timers: When using timers (e.g., setTimeout or setInterval), you can use WeakRef to hold references to objects associated with the timer. This can help ensure that the timer doesn't keep objects alive longer than necessary.
Event Handling: In event-driven applications, you can use WeakRef to manage event listeners. When an object with event listeners is no longer in use, the associated event listeners can be automatically removed.
Reacting to DOM Node Removal: In cases where you want to perform actions when DOM nodes are removed, you can use WeakRef to track DOM nodes. When a node is removed from the DOM, you can receive a notification and perform cleanup tasks.
Custom Data Structures: Create custom data structures that use WeakRef to hold references to elements. This can be particularly useful in scenarios like implementing caches or data structures with automatic cleanup.
Managing Web Workers: When working with Web Workers, you can use WeakRef to manage references to worker instances. When a worker is no longer needed, its reference can be automatically released.
Optimizing Memory-Intensive Applications: In memory-intensive applications, you can use WeakRef to ensure that large data structures or objects are only kept in memory as long as they're actively used.

Best Practices and Limitations

When using WeakRef, keep in mind the following best practices and limitations:

Use WeakRef only when necessary, as it can introduce complexity and potential performance issues.
Do not rely on the timing of garbage collection, as it may vary across JavaScript engines and environments.
Be aware that WeakRef is not supported in all environments, so you may need to provide a fallback implementation or polyfill.

If you want to learn more about WeakRef, don't miss out on my YouTube video on my YouTube channel 🚀

🎬 Watch / View Embedded Resource: https://youtu.be/-rN03KAHGC4

Conclusion

WeakRef is a powerful feature in JavaScript that allows you to create weak references to objects, enabling you to maintain references without preventing garbage collection. By understanding how WeakRef works and its use cases, you can use memory more efficiently in your applications and avoid memory leaks.

Here is the source code of this post.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Unlock the Power of JavaScript WeakSet: Mastering a Hidden Gem!

Wed, 04 Oct 2023 00:00:00 GMT

In the vast landscape of JavaScript, many powerful features often go unnoticed. One such hidden gem is the WeakSet, an unsung hero of the language that can help you optimize your code and manage memory more effectively. In this article, we'll dive deep into WeakSet, uncovering their potential and learning how to use them effectively in our JavaScript projects.

A Brief Introduction to WeakSet

WeakSet is a collection of objects similar to the more commonly used Set.
However, there's a significant difference between the two: WeakSet holds only weak references to the objects stored within them. This means that if an object is only referenced by a WeakSet, it can still be garbage collected, freeing up valuable memory resources.

This unique feature of WeakSet makes it an excellent choice for managing certain types of data relationships, mainly when memory management is a priority.

Creating and Using WeakSet

To create a WeakSet, instantiate a new instance of the WeakSet class:

const weakSet = new WeakSet();

Adding objects to a WeakSet is easy. Just use the add method:

const obj1 = {};
const obj2 = {};

weakSet.add(obj1);
weakSet.add(obj2);

WeakSets also provide methods for checking if an object is present (has) and removing objects (delete):

console.log(weakSet.has(obj1)); // true
weakSet.delete(obj1);
console.log(weakSet.has(obj1)); // false

However, unlike Sets, WeakSets do not have methods for iterating over their contents or determining their size. This is because of their weakly-referenced nature, which makes it impossible to know how many objects are still being held in memory.

Use Cases for WeakSets

1. Managing DOM Elements

WeakSet can be incredibly useful when working with the DOM. You can store references to DOM elements without worrying about memory leaks. When an element is removed from the DOM, the reference in the WeakSet will be automatically garbage collected.

const domElements = new WeakSet();
const element = document.querySelector('.my-element');
domElements.add(element);

// Later, when the element is removed from the DOM
domElements.has(element); // false (garbage collected)

2. Private Data Storage

WeakSet can be used to store private data associated with an object without exposing it. Since the references are weak, the data will be automatically removed when the object is no longer reachable.

const privateData = new WeakSet();

class MyClass {
  constructor() {
    privateData.add(this);
  }

  #data = 'I am private data';

  getData() {
    if (privateData.has(this)) {
      return this.#data;
    }
    return undefined;
  }
}

To see WeakSets in action, don't waste the opportunity to look at my YouTube video about them.

🎬 Watch / View Embedded Resource: https://youtu.be/m3BKqgeVAa4

In Conclusion

WeakSet may not be the most well-known feature of JavaScript, but it offers unique capabilities that can be invaluable in certain situations. By understanding and embracing WeakSet, you can optimize your code, enhance memory management, and unlock the full potential of this hidden gem in the JavaScript universe.

You can find the source code in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Unlocking JavaScript's Secret Weapon: The Power of WeakMaps

Wed, 27 Sep 2023 00:00:00 GMT

Introduction

JavaScript is a powerful and versatile programming language that has evolved over the years, introducing new features and improvements to enhance its performance and capabilities. One such feature is the WeakMap, a collection of key-value pairs that offers unique benefits regarding memory management and data privacy. This article will delve into the world of WeakMap in JavaScript, exploring their creation, usage, limitations, and real-world applications.

Understanding WeakMap

In JavaScript, a WeakMap is a type of Map that holds key-value pairs where the keys are objects, and the values can be any arbitrary data. The primary difference between a Map and a WeakMap is how they manage memory management. In a WeakMap, when a key object becomes inaccessible, the entry is automatically removed, allowing the garbage collector to reclaim memory efficiently.

Creating and Using WeakMap

To create a new WeakMap, use the new WeakMap() constructor. Once created, you can set values for the keys using the set method, as shown below:

const weakmap = new WeakMap();
const key = { name: "John Doe" };
weakmap.set(key, "Some value");

To retrieve values associated with keys, use the get method:

const value = weakmap.get(key); // "Some value"

You can remove entries from the WeakMap using the delete method and check for the existence of a key using the has method:

weakmap.delete(key); // true
weakmap.has(key); // false

Practical Applications of WeakMap

WeakMap offers several practical applications in JavaScript:

Privacy and Encapsulation: By storing private data separately from the object, WeakMap can enhance privacy and encapsulation. This is particularly useful for classes and objects where internal data should not be exposed to the outside world.
Memory Management: WeakMap automatically releases unreferenced keys and associated values, allowing for efficient memory management in large applications.
Caching: WeakMap can implement caching mechanisms without causing memory leaks, as they automatically remove entries when keys are no longer accessible.

Limitations of WeakMap

Despite their benefits, WeakMap has some limitations:

Keys must be objects: Unlike Maps, WeakMap requires keys to be objects, not primitive values.
No built-in iteration methods: WeakMap does not have built-in methods for iterating over their entries, such as forEach or entries.
No clear method: There is no built-in method to clear the entire WeakMap.
Limited compatibility: WeakMap is not supported in some older browsers, limiting their compatibility.

Real-world Examples and Use Cases

WeakMap can be utilized in various real-world scenarios:

Event Listeners: When managing event listeners in DOM elements, WeakMap can help prevent memory leaks by automatically removing entries when elements are no longer accessible.
Private Data Storage: WeakMap can store private data in classes and objects, ensuring that internal data is not exposed to the outside world.
Large Applications: WeakMap can optimize memory usage in large applications by automatically releasing unreferenced data, improving performance and reducing memory leaks.

To find out more about WeakMap don't miss out on my Youtube video on my Youtube channel.

🎬 Watch / View Embedded Resource: https://youtu.be/8Z4ZYDSxN3A

Conclusion

In conclusion, WeakMap offers powerful features and applications for efficient memory management and data privacy in JavaScript. While they have some limitations, their benefits often outweigh these drawbacks, making them a valuable addition to a JavaScript developer's toolkit. As the language continues to evolve, future developments will likely address these limitations and further improve the usefulness of WeakMap in JavaScript applications.

The code of this article is available in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Unveiling the Magic: Exploring JavaScript Symbols

Wed, 20 Sep 2023 00:00:00 GMT

Introduction to JavaScript Symbols

JavaScript Symbols are a new primitive data type introduced in ECMAScript 6 (ES6). They are used as unique, non-string identifiers for object properties, useful in avoiding naming collisions and enabling more advanced programming techniques.

🎬 Watch / View Embedded Resource: https://youtu.be/o8YDHAS-fo0

Creating and Understanding Symbols

Symbols are created using the Symbol() function, which can take an optional description as an argument. Each symbol is unique; even if two symbols have the same description, they are considered distinct.

const propSymbol = Symbol("propName");
const propSymbol2 = Symbol("propName");

propSymbol === propSymbol2 // false

Unique Identifiers and Property Keys

Symbols are often used as property keys in objects to ensure uniqueness and prevent naming collisions. They can be used alongside string keys without conflict, and their uniqueness makes them ideal for use as metadata or private properties in objects.

const propSymbol = Symbol("propName");
const propSymbol2 = Symbol("propName");

const obj = {
  [propSymbol]: "propSymbol",
  [propSymbol2]: "propSymbol2"
}

The Global Symbol Registry

The global Symbol registry allows you to create and share symbols across different scopes and realms. To create a global symbol, use Symbol.for(key), which takes a string as its argument. This method checks if a symbol with the same key exists in the registry; if not, it creates a new one.

// my-module-1.js
export const propSymbol = Symbol("propName");
export const propSymbolShare = Symbol.for("propName");

// my-module-2.js
export const propSymbol = Symbol("propName");
export const propSymbolShare = Symbol.for("propName");

// index.js
import { propSymbol as propSymbolM1, propSymbolShare as propSymbolShareM1 } from './my-module.js'
import { propSymbol as propSymbolM2, propSymbolShare as propSymbolShareM2 } from './my-module-2.js'

console.log(propSymbolM1 === propSymbolM2); // false

console.log(propSymbolM1 === propSymbolShareM1); // false
console.log(propSymbolM2 === propSymbolShareM2); // false

console.log(propSymbolShareM1 === propSymbolShareM2); // true

It's also possible to retrieve the key of a Symbol using Symbol.keyFor(key) but only for shared keys.

export const propSymbol = Symbol("propName");
export const propSymbolShare = Symbol.for("propName");

console.log(Symbol.keyFor(propSymbol)); // undefined
console.log(Symbol.keyFor(propSymbolShare)); // propName

Symbols and Iteration

Symbols are not enumerable, which means they are not included in standard iteration methods like for...in loops or Object.keys(). To access an object's symbol properties, use Object.getOwnPropertySymbols().

const propSymbol = Symbol("propName");
const propSymbol2 = Symbol("propName");

const obj = {
  [propSymbol]: "propSymbol",
  [propSymbol2]: "propSymbol2"
}
console.log(JSON.stringify(obj)); // {}
console.log(Object.keys(obj)); // []
console.log(Object.getOwnPropertyNames(obj)); // []
for (const key in obj) {
  console.log(key); // nothing
}

console.log(Object.getOwnPropertySymbols(obj)); // [Symbol(propName), Symbol(propName)]

Well-Known Symbols in JavaScript

Well-known symbols are predefined global symbols that represent common behaviours in JavaScript, such as Symbol.iterator, Symbol.asyncIterator, Symbol.toStringTag, and Symbol.species. These symbols can be used to customize the behaviour of built-in JavaScript objects and classes.

Use Cases and Practical Applications

Symbols can be used to implement private properties, metadata, or methods, avoiding naming collisions in libraries and frameworks. They are also used to customize the behaviour of well-known JavaScript objects and classes, such as iterators and string conversion.

Limitations and Considerations

Symbols are not supported in older JavaScript environments, and their unique nature may require additional care when working with serialization or proxy objects. Additionally, they are not directly accessible during iteration, which may require extra steps to access their properties.

Conclusion

JavaScript Symbols provide a powerful, unique identifier for object properties, helping to avoid naming collisions and enabling advanced programming techniques. Understanding their use cases and limitations is essential for modern JavaScript developers.

You can find the source code in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

JavaScript Async Generators Unleashed: Harnessing Asynchronous Power

Fri, 15 Sep 2023 00:00:00 GMT

In the dynamic realm of JavaScript, the ability to efficiently handle asynchronous operations is paramount for building responsive and robust applications. While Async Iterators have already proven their worth in managing asynchronous data streams, JavaScript takes another leap forward with Async Generators. Imagine a world where you can effortlessly produce a continuous stream of asynchronous data while dynamically controlling its flow. This is precisely where Async Generators excel, revolutionizing the way we handle and manipulate asynchronous sequences.

In this blog post, we're diving deep into the captivating world of JavaScript Async Generators. We'll unveil how Async Generators empower developers to create elegant solutions for complex asynchronous scenarios. Whether you're grappling with real-time data synchronization, asynchronous data processing, or any scenario demanding fine-tuned control over data flow, join us on this journey as we unravel the capabilities, nuances, and transformative power of JavaScript Async Generators.

Before we delve into Async Generators, let's recap the basics of asynchronous programming. In JavaScript, asynchronous tasks are crucial for handling time-consuming operations without blocking the main thread. Functions like setTimeout, AJAX requests, and Promises have become commonplace in managing asynchronous operations.

Generators, denoted by function* syntax, are a powerful feature introduced in ES6. They allow us to pause and resume the execution of a function, providing a valuable mechanism for lazy evaluation. The yield keyword within a generator function lets us yield values individually, pausing the function's execution until the next value is requested. If you want to learn more, there is relative content about them in this series.

Now, imagine combining the magic of asynchronous operations with the versatility of generators. Enter Async Generators! These supercharged functions enable us to work with asynchronous data streams more intuitively and elegantly.

An async generator function is declared using async function* syntax. Inside, the yield keyword can be combined with await to handle asynchronous operations gracefully. This means we can yield promises, fetch data and seamlessly integrate it into our data stream.

The real beauty of async generators lies in their ability to simplify complex asynchronous tasks. They're particularly handy when dealing with data streams from sources like databases, APIs, or even real-time event streams. Imagine processing a continuous stream of sensor data or handling multiple concurrent requests without drowning in callback hell!

Let's take a look at an example

async function* getUsers(ids: number[]) {
  for (const id of ids) {
    console.log("getUsers next");
    const data = fetch(`https://reqres.in/api/users/${id}`).then(res =>
      res.json()
    );
    yield data;
  }
}

Using a for-of loop, the function iterates over the IDs and fetches the data for every user on every iteration. However, using the yield, stop the execution and resume it only when the caller asks for the next value.
Like Async Iterators, also Async Generators can be iterated using a for-await-of loop.

for await (const user of getUsers([1, 2, 3, 4, 5])) {
  console.log(user);
}

Error handling and completion are crucial aspects of asynchronous programming. With async generators, we can catch errors using try-catch blocks within the generator function. Plus, we can signal the end of data using the 'return' statement, closing the loop on our data stream.

try {
  for await (const user of getUsers([1, 2, 3, 4, 5])) {
    console.log(user);
  }
} catch (err) {
  console.error(err);
}

async function* getUsers(ids: number[]) {
  for (const id of ids) {
    console.log("getUsers next");
    const data = fetch(`https://reqres.in/api/users/${id}`).then(res =>
      res.json()
    );
    if (id > 4) return data; // <-- Return
    yield data;
  }
}

Like Generators, also Async Generators can be combined. For instance, we can create an Async Generator map function that accepts an Async Generator and a transformation function and returns a new async generator with the transformations.

async function* map<T, U>(
  asyncIterable: AsyncIterable<T>,
  callback: (value: T) => U
) {
  for await (const item of asyncIterable) {
    yield callback(item);
  }
}

Asynchronous programming in JavaScript continues to evolve, and Async Generators are a testament to its dynamic nature. With their power to elegantly manage complex asynchronous tasks, async generators offer a glimpse into the future of streamlined coding. So, fellow developers, embrace this innovative tool and unlock new possibilities in your projects.

I also created a video about Async Generators on my Youtube channel and you can find it below.

🎬 Watch / View Embedded Resource: https://youtu.be/0uQvNZ8th08

That's a wrap for today's discussion on JavaScript Async Generators. I hope you found this exploration insightful and inspiring. Remember, staying curious and open to new concepts is the key to mastering your craft in the ever-evolving programming landscape.

If you enjoyed this post, like and share it. And if you have questions, feedback or doubts let me know in the comments.

Until next time, happy coding and thanks for reading 👩💻👨💻

N.B. you can find the code of this post in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Mastering JavaScript Async Iterators: Unlocking Asynchronous Magic

Fri, 08 Sep 2023 00:00:00 GMT

In the ever-evolving landscape of JavaScript, staying up-to-date with its latest features is crucial for writing efficient and modern code. One such feature that has garnered significant attention is the Async Iterator. While iterators have long been an integral part of JavaScript for sequential data processing, the introduction of asynchronous programming patterns brought about the need for asynchronous iteration.

Imagine effortlessly traversing through data streams that might involve fetching data from APIs, reading from files, or any other asynchronous data source. This is precisely where Async Iterators shine, providing a seamless and elegant solution to handle such scenarios. In this blog post, we'll delve into the world of JavaScript Async Iterators, exploring their fundamentals, understanding their benefits, and uncovering how they can be a game-changer in writing robust asynchronous code. Whether you're a seasoned developer looking to expand your skill set or a newcomer curious about advanced JavaScript techniques, this blog post is for you. We will unravel the power of Async Iterators and take your asynchronous programming skills to new heights.

Before we jump into the code, let's understand what async iterators are. In JavaScript, iterators are objects that allow us to loop over collections. Async iterators take this concept a step further by allowing us to handle asynchronous operations, like fetching data from APIs or reading from streams.

Creating an async iterable is simple. We use the Symbol.asyncIterator to define the async iterator method inside an object. This method will return an object with the next method that resolves a promise containing the next value in the asynchronous sequence.
Let's take a look at an example.

const getUsers = (ids: number[]): AsyncIterable<User> => {
  return {
    [Symbol.asyncIterator]() {
      let i = 0;
      return {
        async next() {
          console.log("getUsers next");
          if (i === ids.length) {
            return { done: true, value: null };
          }
          const data = await fetch(
            `https://reqres.in/api/users/${ids[i++]}`
          ).then(res => res.json());
          return { done: false, value: data };
        },
      };
    },
  };
};

Imagine you have a list of IDs and want to read the user data only if needed. Using AsyncIterators, you can create a function that handles the API and returns the result of every request on every iteration, making the code more transparent.

To consume the values of an async iterable, we use the for-await-of loop. This loop works just like the regular for-of loop, but it's designed specifically for asynchronous iterables.

for await (const user of getUsers([1, 2, 3, 4, 5])) {
  console.log(user);
}

Error handling is crucial when dealing with asynchronous operations. Async iterators allow us to handle errors using try-catch blocks around the for-await-of loop.

try {
    for await (const user of getUsers([1, 2, 3, 4, 5])) {
      console.log(user);
    }
  } catch (err) {
    console.error(err);
  }

AsyncIterator runs code only if needed, so until you don't call the next method, nothing happens, like for Iterators.

The return method exists also for AsyncIterators. This method is used in case the code doesn't complete all the iterations. Imagine the loop calls a break or a return; in this case, JavaScript under the hood calls the return method for us. In this method, we can handle whatever we need. We may need to reset something or check the current value of the iterator.

const getUsers = (ids: number[]): AsyncIterable<User> => {
  return {
    [Symbol.asyncIterator]() {
      let i = 0;
      return {
        ...
        async return() {
          console.log("getUsers return");
          return { done: true, value: null };
        },
      };
    },
  };
};

Async Iterators are powerful like Iterators, and we can create functions that accept an AsyncIterator and manipulate it to return another Async Iterator. For instance, we can create a map function that accepts an Async Iterator and returns another with a callback specified by the user.

function map<T, U>(iter: AsyncIterable<T>, fn: (v: T) => U): AsyncIterable<U> {
  return {
    [Symbol.asyncIterator]() {
      const iterator = iter[Symbol.asyncIterator]();
      return {
        async next() {
          console.log("map next");
          const { done, value } = await iterator.next();
          if (done) return { done, value: null };
          return { done, value: fn(value) };
        },
        async return() {
          console.log("map return");
          if (iterator?.return) await iterator?.return();
          return { done: true, value: null };
        },
      };
    },
  };
}

These functions have all the benefits said before. Javascript does nothing until the codebase doesn't ask for the next function; the same is true for the return method, and now you can compose the getUsers with the map to build a new Async Iterator.

const iterator = map(getUsers([1, 2, 3, 4, 5]), user => user.data.id)
for await (const num of iterator) {
  if (num === 3) break;
  console.log(num);
}

And there you have it a deep dive into the world of asynchronous iterators in JavaScript. They provide an elegant solution to working with asynchronous data streams, making your code more organized and efficient. Experiment with async iterators in your projects, and you'll be amazed at how they simplify complex asynchronous workflows.

I also created a video on my Youtube channel, that you can find below.

🎬 Watch / View Embedded Resource: https://youtube.com/watch?v=0_mzZ9QOebg

If you found this content helpful, like and share it. And if you have any questions, feedback, or doubts, let me know in the comments 😀

Thanks for reading! And Happy coding! 👩💻 👨💻

N.B. you can find the code of this post in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Unleashing the Power: Demystifying JavaScript Generators

Fri, 01 Sep 2023 00:00:00 GMT

Welcome to this blog post, where we're diving into the fascinating world of JavaScript generators. If you're looking to take your coding skills to the next level and explore a powerful tool for managing operations, you've come to the right place.

In the fast-paced landscape of web development, managing tasks and handling complex flows of data can be quite challenging. This is where JavaScript generators come into play. These remarkable constructs introduce a new level of control and flexibility, allowing developers to write code that can be paused, resumed, and iterated step by step.

In this blog post, we'll take you on a journey through the core concepts of JavaScript generators. We'll unravel their syntax, explore their capabilities, and showcase examples of how they can simplify your code and make it more manageable. By the end of this read, you'll not only understand the ins and outs of generators but also be equipped with the knowledge to start using them effectively in your own projects.

Buckle up as we embark on this exploration of JavaScript generators, unravelling their potential and discovering how they can revolutionize the way you write code. Whether you're a seasoned developer or just starting with JavaScript, there's something valuable here for you. Let's begin!

A generator in JavaScript is a function that, after the function keyword, has a *. It's not possible to create generators in JavaScript using arrow functions. Generators are special functions that implement the Iterable interface very simply; you can learn more about them in this blog post. The particularity of generators is the yield keyword. Using the yield, we can return a new value to the iteration but without ending the function execution, simply putting it on pause, until the next request for the next value and until it's not completed.

function* range(start: number, end: number): Iterable<number> {
  let n = start;
  while (n <= end) {
    console.log("range next");
    yield n++;
  }
}

As you can notice, the range generator is a simple generator function, and it's understandable from the * near-function keyword. Using a simple while, the function checks if the current value is less or equal to the end value and if true, using the yield returns the value; else exists from the while and closes the generator. Like iterators, generators only run once someone calls for the next value.

It's possible to go through a generator using a simple for-of-loop.

for (const num of range(1, 10)) {
  console.log(num);
}

Using the Iterable interface

const iterator = range(1, 10)[Symbol.iterator]();
while (true) {
  const { done, value } = iterator.next();
  if (done) break;
  console.log(value);
}

Or using the spread operator to save all the values in an Array.

for (const num of [...range(1, 10)]) {
  console.log(num);
}

It's important to remember that if you use the spread operator, you will lose all the generators' benefits because it runs the generator until it's not completed to copy all the values in the array.

Like iterators also, generators can be combined. For instance, we can create a map generator function that accepts an iterator and a transformation function and returns the computation inside the transformation with the value emitted by the generator.

And that's the result.

function* map<T, U>(
  iterable: Iterable<T>,
  callback: (value: T) => U
): Iterable<U> {
  for (const value of iterable) {
    yield callback(value);
  }
}

const mapRange = map(range(1, 10), value => value * 10);

for (const num of mapRange) {
  console.log(num);
}

That's all folks. You can find a video about them on my Youtube channel.

🎬 Watch / View Embedded Resource: https://youtu.be/mi2JlrXBRIs

In conclusion, JavaScript generators stand as a remarkable tool in the arsenal of every developer striving for more efficient and flexible programming. Through their unique ability to pause and resume execution, generators provide an innovative solution to managing complex flows of data and operations.

Throughout this blog post, we've journeyed through the syntax, use cases, and benefits of JavaScript generators. We've seen how they can simplify code, making it more readable and maintainable.

By harnessing the power of generators, you can transform the way you approach programming challenges. These constructs not only offer a structured approach to handling tasks but also contribute to writing code that is less error-prone and easier to reason about.

As you venture into the realm of generators, remember that practice is key. Experiment with different scenarios, explore their interplay with other techniques and gradually integrate them into your projects. With time, you'll become proficient in leveraging generators to create responsive and efficient applications.

So, whether you're a front-end developer aiming to tame complex UI interactions or a back-end engineer dealing with intricate data processing, generators offer a fresh perspective on tackling programming. Embrace their power, refine your skills, and elevate your coding prowess in the dynamic world of JavaScript.

Thank you for reading and happy generating! 👩💻 👨💻 😜

N.B. you can find the code of this post in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Iterate Like a Pro: Mastering JavaScript Iterators for Effortless Code

Fri, 25 Aug 2023 00:00:00 GMT

Welcome to this blog post, where we're about to unravel the power and versatility of JavaScript iterators. If you've ever found yourself working with data collections and wondered if there's a more efficient and elegant way to navigate them, you're in the right place.

In the realm of modern web development, efficiently managing and manipulating data is a crucial skill. This is where JavaScript iterators come into play, offering a systematic approach to traversing various data structures such as arrays, maps, and sets. Whether you're a beginner eager to understand the basics or an experienced developer looking to fine-tune your code, grasping the concept of iterators can significantly enhance your programming journey.

In this blog post, we'll embark on a comprehensive exploration of JavaScript iterators. We'll break down their fundamental principles, explore practical examples of their usage, and demonstrate how they can simplify complex data operations. By the time you finish reading, you'll not only understand iterators inside and out but also be equipped to leverage their potential to write more concise, readable, and efficient code.

So, whether you're striving to make your codebase more elegant or seeking to optimize your data manipulation techniques, join us as we delve into the world of JavaScript iterators. From novice to expert, there's something here for everyone. Let's dive in!

Built-in in Javascript exists many structures that implement the Iterators pattern, for instance: Array, Set and Map. In Javascript, an object to be iterable must implement the Iterable interface.

But what is the Iterable interface? First, to be iterable, an object must have a next method. This method must return two properties: done and value. Done is used to detect if the iteration is completed; instead, the value contains the current value. Last but not least, if you want your object to become an iterator, you must expose the iterable interface in the Symbol.iterator of your object, like in this example.

const array = [1, 2, 3, 4, 5];
const iterator = array[Symbol.iterator]();
for (let result = iterator.next(); !result.done; result = iterator.next()) {
  console.log(result.value);
}

For example, here is a range function implemented as an iterator.

const range = (start: number, end: number): Iterable<number> => {
  return {
    [Symbol.iterator]() {
      let n = start;
      return {
        next() {
          console.log("range next");
          if (n > end) {
            return { done: true, value: null };
          }
          return { done: false, value: n++ };
        },
      };
    },
  };
};

As you can notice, this function accepts two numbers, start and end and returns a new object with a single property, in this case, the iterator property. Then, inside this function, there is the next function that, on every call, checks if the current value is greater than the end and, if true, returns a new object with done as true and value as null; else returns an object with done false and value with the current value. The beautiful thing about iterator is that javascript only does something once you ask for the next value.

Every iterator can be iterated using the for-of loop

for (const num of range(1, 10)) {
  console.log(num);
}

or using its native method, so calling the Symbol.iterator function and then using the next method and checking the done property if it is true or not.

const rangeIterator = range(1, 10)[Symbol.iterator]();
for (let result = rangeIterator.next(); !result.done; result = rangeIterator.next()) {
  console.log(result.value);
}

It's possible to copy all the iterator values in an Array using the spread operator too.

for (const num of [...range(1, 10)]) {
  console.log(num);
}

Iterator also has another method, the return method. This method is used in case the code doesn't complete the iteration. Imagine the loop call a break or a return; in this case, JavaScript under the hood calls the return method for us. In this method, we can handle whatever we need. We may need to reset something or check the current value of the iterator.

const range = (start: number, end: number): Iterable<number> => {
  return {
    [Symbol.iterator]() {
      let n = start;
      return {
        next() {
          console.log("range next");
          if (n > end) {
            return { done: true, value: null };
          }
          return { done: false, value: n++ };
        },
        return() {
          console.log("range return");
          return { done: true, value: null };
        },
      };
    },
  };
};

for (const num of range(1, 10)) {
  if (num > 5) break;
  console.log(num);
}

Iterators are powerful, and we can also create functions that accept an iterator and manipulate it to return another iterator. For instance, we can create a map function that accepts an iterator and returns another with a callback specified by the user.

function mapIterable<T, U>(
  iterable: Iterable<T>,
  callback: (value: T) => U
): Iterable<U> {
  return {
    [Symbol.iterator]() {
      const iterator = iterable[Symbol.iterator]();
      return {
        next() {
          console.log("mapIterable next");
          const { done, value } = iterator.next();
          if (done) {
            return { done: true, value: null };
          }
          return { done, value: callback(value) };
        },
        return() {
          console.log("mapIterable return");
          if (iterator.return) {
            iterator.return();
          }
          return { done: true, value: null };
        },
      };
    },
  };
}

All the info said before is true also for this new iterator. JavaScript does nothing until the codebase doesn't ask for the next value; the same is true for the return method, and now you can compose the range iterators with the map iterator to build a new one.

const mapRange = mapIterable(range(1, 10), value => value * 10);

for (const num of mapRange) {
  if (num > 50) break;
  console.log(num);
}

Ok folks, that's all!
If you want to dive deep with Iterators, don't waste my video on my Youtube Channel.

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=BSctSkMGtiM

In conclusion, understanding and utilizing JavaScript iterators can greatly enhance your ability to work with collections of data in a more elegant and efficient manner. With iterators, you can streamline your code, improve its readability, and reduce memory consumption by processing data one element at a time. This powerful concept empowers developers to implement custom iteration behaviour, making their code more adaptable to different scenarios.

By grasping the fundamentals of iterators, such as the next() method and the concept of iterable objects, you open the door to more sophisticated programming techniques and design patterns. Whether you're working with arrays, maps, sets, or other data structures, iterators provide a standardized way to traverse through data and perform operations without unnecessary complexity.

As the JavaScript language continues to evolve, iterators remain a foundational concept that plays a crucial role in modern programming paradigms. Incorporating iterators into your coding arsenal equips you with a versatile tool for managing data, ultimately leading to cleaner, more maintainable, and more robust code.

So, as you embark on your journey to master JavaScript iterators, remember that they are more than just technical features; they represent a shift in how you approach and solve problems in your code. With practice and exploration, you'll be able to wield iterators effectively, making your codebase more efficient and your development experience more enjoyable.

Thanks for reading and Happy coding! 😃 👩💻 👨💻

N.B. you can find the code of this article in the GitHub repository!

🎬 Watch / View Embedded Resource: https://dev.to/puppo

🏆 My journey to the MVP Award 🏆

Fri, 09 Jun 2023 00:00:00 GMT

This history started many years ago! I was a student, and I was going to the ITS in Pordenone.
I spent two years of my life in that school, where I met great friends and learned a lot from awesome teachers, one of them is Andrea Dottor.
In the first lesson with him, he started with his presentation, "I'm a freelancer, I work with different companies and blah blah blah... I'm a Microsoft MVP too".
That was the first time that I heard about this program. As you can imagine, I was 20, and I didn't get any importance to that tense, but in reality, it was the first moment that I came across the MVP program.

After that, Andrea and I became colleagues and friends. I always see Andrea as a Mentor, and I have always followed him. So I started to go with him to the xedotnet meetup. I met other incredible developers like Mirco Vanini (another MVP), Daniele Morosinotto and many others there. Thanks to xe, I learned what a community is and how a community works. I started to understand the benefit of sharing knowledge in the development environment, and my mind started to build a strange idea "One day you will be like them, maybe not an MVP but a speaker yes, and you will share your knowledge with the others."

I was young at that moment and decided to continue to follow the community, but I put my effort into improving myself in my job.
For almost 8 years, I dedicated my time to learn stuff in my bedroom and in my free time, developing different projects in my daily routine, and I changed 3 jobs too.
When I started to work in Flowing, in my mind something happened.
Flowing was an environment with awesome developers, and many of them were and are speakers too. But I was not ready to do my first talk, so I tried to think of something different that could be useful for the community. After some days, I decided to write my first series about Typescripts.
Why typescript? It is my favorite language with javascript, and many times, I saw people fighting with it. So I said: "Ok, this is the right topic, let's go!".
21 articles compose my first series, " Typescript - Tips & Tricks Series", which you can find in this reference. In reality, the audience at the beginning was not so much, but after some months, Lars contacted me to ask if I would join the "This is learning" community, and as you can imagine, I accepted :) Here I also met another good man: Santosh, who runs with Lars "This is learning" community.
During that period, another crazy and good friend had a strange idea. I organized and took as "Teacher" a workshop about Nx in Flowing, and he was invited as an attendee. He appreciated the workshop so much that he invited me to his youtube channel to speak about Nx (Nx the return). The name of the friend is Francesco Sciuti, another MVP and also the Batman of the developers.
In that period, I was also writing a new series called "RxJS - Getting Started", 15 articles to help developers to be more confident with RxJS. Why this topic? Because I worked on many Angular projects and saw many developers stuck or completely unfamiliar with it.

After that, a colleague and friend (Francesco Strazzullo) tried to push me out of my comfort zone, and he asked me to be a speaker at the Mug meetup. I was a bit scared; speaking in front of many people created a strange sensation in me, but after some sane pushing, I said yes! So the 7th of October 2021, I did my first talk called Stay Reactive Stay Quiet with RxJS. The sensations at the end were really good, so on the 19th of October, I did the second at the FEVR community called "Is it possible to build your UI components using only web components?" (thanks to Matteo Guidotto for this talk).
It was the COVID period, so taking talks and doing conferences in 2021 was really difficult. For this reason, I continued to write another series called: It's Prisma Time.

At the beginning of 2022, the decisive turning point. During a chat with Andrea, I told him: "I would become a Microsoft MVP; what have I to do to achieve it?" I had this idea for some months, but I wanted to concretize it at that moment. He looked at me and said, "It's time to do some great conferences and maybe speak more about some Microsoft technologies".
So I went back home, and with the euphoria in my blood, I started to write some articles about Visual Studio Code. These articles spoke about some common commands for me when I worked with VsCode, but these articles were awesome for the community! Many and many people didn't know these commands, and the articles received a lot of appreciation. Another thing I did was research conferences and check out conferences where I could send a CFP.
I remember I sent so many CFPs that I forgot how many noes I received 😅
But at the beginning of September, the first confirmations arrived: AngularDay 2022, then the workshop at the react day with Fabio Biondi, another MVP and good friend that shared with me also a great weekend at the GDP Pescara, where I talked about Prisma and last but not least the ngrome.
During this period, I also continued to do meetups, thanks to Milano Frontend and React JS Milano having me as a speaker.
If you are curious, you can find the list of all my talks and contributions in this reference.

In the middle of December 2022, I spoke again with Andrea to ask him if he could nominate me as Microsoft MVP. He did it, and I spent an evening filling out the form of all my contributions during the last year. Why last year? Because the MVP Award is based on the last year. I started my history 10 years ago, yes, but the MVP Award takes into consideration only the last year. I decided to tell you the entire story because I know the last year is only the cherry on top, but without the previous nine, the last year would probably be a failure.

As you can imagine, after the filling, you have to wait for the evaluation, which takes at most 3 months. I was lucky; on the 3rd of January 2023, in my inbox appeared an email that said: "Congratulation! You are a Microsoft MVP 2023"! Now, I suppose you can imagine how much happy I was, I think I stayed euphory for the following two or three days 😅
Then after some weeks, I did a call with Cristina. She takes care of all the MVPs on the Meditterian side and explained to me how the program works, its benefits and so on. She is really kind and she really put a lot of effort into helping the MVPs. Thanks Cristina, for all the things you do for us! 🫶

Now my journey is only at the beginning. I have different ideas for continuing.
I opened my own Youtube channel, I'll continue to write articles, and I'll continue to do talks at conferences and meetups.

What did I learn from this story?
The MVP award is "only" a simple and beautiful award that helps me remember all the effort I put in these years to improve myself and try to help others! And if you want to join the program: love communities, and put your effort into helping them! Do this, and you'll be on the right path to being part of the MVP Family.
Remember: improve yourself, help others and follow your passion!

Photo by Vlad Bagacian on Unsplash

React Query - Infinite Queries

Wed, 07 Jun 2023 00:00:00 GMT

Hey Folks,

Today it's time to learn how you can build an infinite query with React Query.

To build an infinite query you have to use the useInfiniteQuery hook. This hook is similar to the useQuery but with some more properties to handle the infinite loading in the best way.

The key concepts, if you are working with useInfiniteQuery are:

Key : in this case, the key is unique for each page, useInfiniteQuery handles all the pages inside its state
page : each chunk of your infinite query is represented as a page and the first page returned by the useInfiniteQuery is undefined. This helps you to understand if it's the first iteration or not.
hasNextPage : is a variable returned by the hook and its scope is to determine if another chunk exists or not
fetchNextPage : is a function used to fetch the next chunk
isLoading : is a flag that determines if there is a loading ongoing (The query has no data yet)
isFetching : is a flag that determines if there is a fetch request ongoing
getNextPageParam : this function is an option to pass at the hook and it is used to determine if there is another chunk or not after the response

ok, let's see the code to be clearer

import { useInfiniteQuery } from '@tanstack/react-query';
import { useState } from 'react';

const fetchTodos = async (
  page: number,
  limit: number,
  signal: AbortSignal | undefined
): Promise<{
  totals: number;
  todos: Todo[];
}> => {
  const response = await fetch(`api/tasks?_page=${page + 1}&_limit=${limit}`, {
    signal,
  });
  if (!response.ok) {
    throw new ResponseError('Failed to fetch todos', response);
  }
  const todos: Todo[] = await response.json();
  const totals = Number.parseInt(
    response.headers.get('x-total-count') || '0',
    10
  );

  return {
    totals,
    todos,
  };
};

interface UseTodos {
  todos: Todo[];
  isLoading: boolean;
  isFetching: boolean;
  error?: string;
  hasNext: boolean;
  next?: () => void;
}

export const useTodos = (): UseTodos => {
  const [limit] = useState<number>(5);

  const { data, hasNextPage, fetchNextPage, isLoading, isFetching, error } =
    useInfiniteQuery(
      [QUERY_KEY.todos],
      ({ signal, pageParam: page = 0 }) => fetchTodos(page, limit, signal),
      {
        refetchOnWindowFocus: false,
        retry: 2,
        getNextPageParam: (lastPage, pages) => {
          if (Math.ceil(lastPage.totals / limit) > pages.length)
            return pages.length;
          return undefined;
        },
      }
    );

  return {
    todos: data?.pages.flatMap(({ todos }) => todos) || [],
    isLoading,
    isFetching,
    error: mapError(error),
    next: fetchNextPage,
    hasNext: hasNextPage || false,
  };
};

As you can notice, the flow is very simple, the hook returns the current page or chunk, you have to handle the fetch request and then you can determine the result and if there is another chunk or not.
Another important thing to keep in mind is that the result of the useInfiniteQuery is an array and each element of the array contains the data of each chunk.

Ok, I suppose you have an idea of how Infinite Queries work in React Query, but if you want to deep into it don't miss my youtube about it.

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=F1KD4GY1iws

I think thats all from this article.

This is the last post of this series, I hope you enjoyed the content and now you are aware of using ReactQuery in your React application.

See you soon folks
Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - Paginated List

Thu, 01 Jun 2023 00:00:00 GMT

Hey Folks,

Today it's time to learn how you can paginate a list with ReactQuery.

It's common to create a pagination of a list to improve the user interface of your platform if you are building a list in your application, but also to limitate the work in your API.

Using ReactQuery, building a paginate list is a piece of cake.

You have to follow 3 steps:

Create a state to save the value of the current page
Create a state to save the limit of the pages (the number of elements on every page)
Fetch the data every time the user changes one of the previous states.

But let's see an example that is easier to understand

const fetchTodos = async (
  page: number,
  limit: number,
  signal: AbortSignal | undefined
): Promise<{
  totals: number;
  todos: Todo[];
}> => {
  const response = await fetch(`api/tasks?_page=${page}&_limit=${limit}`, {
    signal,
  });
  if (!response.ok) {
    throw new ResponseError('Failed to fetch todos', response);
  }
  const todos: Todo[] = await response.json();
  const totals = Number.parseInt(
    response.headers.get('x-total-count') || '0',
    10
  );

  return {
    totals,
    todos,
  };
};

interface UseTodos {
  todos: Todo[];
  isLoading: boolean;
  isFetching: boolean;
  error?: string;
  pages: number;
  page: number;
  setPage: Dispatch<SetStateAction<number>>;
}

export const useTodos = (): UseTodos => {
  const [page, setPage] = useState<number>(1);
  const [limit] = useState<number>(5);

  const {
    data: { todos, totals } = {
      todos: [],
      totals: 0,
    },
    isLoading,
    isFetching,
    error,
  } = useQuery(
    [QUERY_KEY.todos, page, limit],
    ({ signal }) => fetchTodos(page, limit, signal),
    {
      refetchOnWindowFocus: false,
      retry: 2,
    }
  );

  return {
    todos,
    isLoading,
    isFetching,
    error: mapError(error),
    pages: Math.ceil(totals / limit),
    page,
    setPage,
  };
};

As you can notice, the process to build a pagination with ReactQuery is very simple.
The fetch request has to contain the page and the limit (you can handle a pagination also with limit and offset if you want) and in your useQuery you have to handle some simple stuff. First, the key of your query must include the page and limit too, second you must pass page and limit to your fetch request.

As you can see, building a paginated list with ReactQuery is really a piece of cake, but if want to dive into it don't miss my youtube video about it

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=Ma7-hdNMdWs

I think thats all from this article; I hope you enjoyed this content!

See you soon folks
Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - Abort Request

Wed, 17 May 2023 00:00:00 GMT

Hey Folks,

Today it's time to learn how you can abort an ongoing request with ReactQuery.

Before moving to the example, I want to introduce the AbortSignal.

AbortSignal is a javascript interface used to abort ongoing methods. Typically, you can create an AbortSignal by an AbortController, which simplifies the creation and execution of the AbortSignal. When you create an AbortController (controller = new AbortController()) you get an instance of it that has two core concepts: the signal (controller.signal) and the abort method (controller.abort()).

The first one is important because it contains the signal with its status, and the second one is important because it allows you to change the status of the abort from false to true.

Using these two interfaces, in javascript, you can handle out-of-the-box the abort of an HTTP request created with the fetch API but also with axios if you want. When you create a request, both accept a signal and if you abort that signal you can abort the request.

AbortSignal has also a static method called timeout that accepts a number that describes the timeout time in milliseconds. Using this method you can create easily a signal that changes its status after some time. Very common if you want to handle a timeout of your request.

Just a quick example to make you understand the power of these interfaces.

try {
  const controller = new AbortController();
  const timeoutId = setTimeout(() => controller.abort(), 5000);
  const res = await fetch(url, { signal: controller.signal });
  const body = await res.json();
} catch (e) {
  if (e.name === "AbortError") {
    // Notify the user of abort.
    // Note this will never be a timeout error!
  } else {
    // A network error, or some other problem.
    console.log(`Type: ${e.name}, Message: ${e.message}`);
  }
} finally {
  clearTimeout(timeoutId);
}

In this example, you can see an abort request created with an AbortController. This example uses a setTimeout method to handle the timeout and as you can notice, when the code creates the fetch API passes the signal status to the fetch. In this way, the fetch request and the signal are linked together. This example could be simplified in this way using the AbortSignal timeout method.

try {
  const res = await fetch(url, { signal: AbortSignal.timeout(5000) });
  const body = await res.json();
} catch (e) {
  if (e.name === "AbortError") {
    // Notify the user of abort.
    // Note this will never be a timeout error!
  } else {
    // A network error, or some other problem.
    console.log(`Type: ${e.name}, Message: ${e.message}`);
  }
}

Ok, now you have an idea of how AbortSignal and AbortController work, so we can move on to the next step; how can you abort a request with ReactQuer?

Good news for you, ReactQuery out-of-the-box handles a signal for you for every query and mutation, and your business it's only decided if you want to use it or not.

Let's start with an example

const fetchTodos = async (signal: AbortSignal | undefined): Promise<Todo[]> => {
  const response = await fetch('api/tasks', {
    signal,
  });
  if (!response.ok) {
    throw new ResponseError('Failed to fetch todos', response);
  }
  return await response.json();
};

interface UseTodos {
  todos: Todo[];
  isLoading: boolean;
  isFetching: boolean;
  error?: string;
  setUserFilter: Dispatch<SetStateAction<number | null>>;
}

export const useTodos = (): UseTodos => {
  const client = useQueryClient();

  const {
    data: todos = [],
    isLoading,
    isFetching,
    error,
  } = useQuery([QUERY_KEY.todos], ({ signal }) => fetchTodos(signal), {
    refetchOnWindowFocus: false,
    retry: 2
  });

  return {
    todos,
    isLoading,
    isFetching,
    error: mapError(error),
    setUserFilter,
  };
};

As you can notice, useQuery has a second parameter that contains different options, one of them is the signal. This signal is an AbortSignal that you can use to abort your request if you want. In the example, for instance, the signal is passed to the fetchTodos method and then passed to fetch request.

As you can understand, aborting a request is a piece of cake 🍰

Ok, I think now you have all the notions to abort an HTTP request in javascript and in ReactQuery too.

If you want to go dive into the Abort Request with React query don't miss my Youtube channel 🚀

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=BL_E7SrymWI

I think thats all from this article; I hope you enjoyed this content!

See you soon folks
Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Improve user experience with optimistic update

Thu, 11 May 2023 00:00:00 GMT

Hey Folks,

Sometimes to improve the user experience you can decide to bet on the success of your code, so you can assume that the code will go in the right way to make your application faster in the eyes of your users. This approach is called Optimistic Update and can be handled in some lines of code using react query with the useMutation hook. Yes, this approach is like a bet with the code but it's also important to keep in mind to handle the errors in case of failure.

To handle the optimistic update you have to handle an useMutation hook in your codebase. This hook exposes three events to handle to perform the optimistic update: onMutate, onSuccess and the onError.

The onMutate event is called immediately when your code calls the useMutation hook. This event is used to create a snapshot of the current state before moving forward and updating the state with the new values. It's important to save the previous state because it permits you in case of failure to restore it in the future if needed.

The onSuccess event is called in case of success of the mutation. If your code jumps in this event, you are safe and everything has gone in the right way.

The onError event is called in case of failure of the mutation. If your code is inside of this event unfortunately something went wrong. In this case, you must handle the restoration of the state to the previous one and notify the user that something went wrong.

To help you to understand better the case let's see an example

import { useMutation, useQueryClient } from '@tanstack/react-query';
import { useSnackbar } from 'notistack';

const editTodoRequest = async (todo: Todo): Promise<Todo> => {
  await new Promise((resolve) => setTimeout(resolve, 3000));
  const response = await fetch(`api/tasks/${todo.id}`, {
    method: 'PUT',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(todo),
  });
  if (!response.ok) {
    throw new ResponseError(`Failed to edit todo with id ${todo.id}`, response);
  }
  return await response.json();
};

type UseEditTodo = (todo: Todo) => void;

export const useEditTodo = (): UseEditTodo => {
  const { enqueueSnackbar, closeSnackbar } = useSnackbar();
  const client = useQueryClient();
  const { mutate: editTodo } = useMutation<
    Todo,
    unknown,
    Todo,
    {
      oldTodos?: Todo[];
      oldTodo?: Todo;
      messageKey: string | number;
    }
  >(editTodoRequest, {
    onMutate: (todo) => {
      const messageKey = enqueueSnackbar('Todo edited', {
        variant: 'success',
      });
      const oldTodos = client.getQueryData<Todo[]>([QUERY_KEY.todos]);
      const oldTodo = client.getQueryData<Todo>([QUERY_KEY.todos, todo.id]);
      client.setQueryData([QUERY_KEY.todos, todo.id], todo);
      client.setQueryData<Todo[]>([QUERY_KEY.todos], (oldTodos) =>
        oldTodos?.map((oldTodo) => (oldTodo.id === todo.id ? todo : oldTodo))
      );

      return {
        oldTodos,
        oldTodo,
        messageKey,
      };
    },
    onSuccess: () => {
      client.invalidateQueries([QUERY_KEY.todos]);
    },
    onError: (error, todo, ctx) => {
      if (!ctx) return;
      const { oldTodos, oldTodo, messageKey } = ctx;
      closeSnackbar(messageKey);
      const errorMessage = mapError(error);
      enqueueSnackbar(
        `Ops! There was an error on editing todo: ${errorMessage}`,
        {
          variant: 'error',
        }
      );
      client.setQueryData([QUERY_KEY.todos, todo.id], oldTodo);
      client.setQueryData<Todo[]>([QUERY_KEY.todos], oldTodos);
    },
  });

  return editTodo;
};

As you can notice, in the mutate event, the code creates a toast for the user, which indicates that everything has gone in the right way and after that, the code takes the current state, returns it and update the state with the new values. The return is important because it permits getting this data in the onError event in case of failure. The onError event, as you can notice, handles the restoration of the state, removes the success toast and shows a new one with the error message. This part is crucial if you want to handle an optimistic update because it gives feedback to the user in case of failure.

Last but not least, you can also handle the onSuccess event if you want to invalidate a query after the mutation or for some other motivation. The onSuccess is not required always but depends on your case.

Ok, I think now you have an idea of how the optimistic update works in react query, but if you want to dive into it check out my youtube video too.

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=IwkhNxIyyzA

I think thats all from this article; I hope you enjoyed this content!

See you soon folks
Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - Keys & Prefetching

Wed, 03 May 2023 00:00:00 GMT

Hey Folks, Today I want to share two important things if you are using ReactQuery. The first is how the keys are composed, and the second is how to prefetch data to reduce the user's wasted time. So let's start 🚀

Keys

As you have already learned in this series, React query uses the keys to save the data of a specific API. And these keys must be unique for each specific API. When you create a useQuery hook, the first parameter is the query's key, which is an array. This array is used to compose the key, and it is in charge of you creating the key in the right way for your case. As said before, the key is an array, and in this way, you can create a key composed of different data.
So, for instance, you can have a key for the list of the todos and a key for the detail of a specific todo (["todos"] and ["todo", 2].)
As you can notice, you can put in the key whatever you want, string number or boolean; it is completely on your side; the important thing you must remember every time is that each key must be unique. This concept, and the key you choose, are also important if you want to prefetch the data because you must use the same key to save the data prefetched in the react query state.

Prefetching

In some scenarios, loading the data before the user asks for it could be interesting. This improves the user experience and reduces the waste time for them. But how can you do that with react query?
First, you need to use the QueryClient object that exposes the prefetchQuery method.
This method accepts two parameters: the query's key and the fetch request.
In this way, you can handle a simple but powerful prefetching flow with few lines of code. Let's take a look at this example

export const useTodos = (): UseTodos => {
  const client = useQueryClient();

  const [userFilter, setUserFilter] = useState<number | null>(null);

  const filterTodoByAssignee = useCallback(
    (todos: Todo[]) => {
      if (!userFilter) return todos;
      return todos.filter((todo) => todo.assigneeId === userFilter);
    },
    [userFilter]
  );

  const {
    data: todos = [],
    isLoading,
    isFetching,
    error,
  } = useQuery([QUERY_KEY.todos], fetchTodos, {
    refetchOnWindowFocus: false,
    retry: 2,
    select: filterTodoByAssignee,
    onSuccess: (data) => {
      data.forEach((todo) => {
        client.prefetchQuery([QUERY_KEY.todos, id], () => fetchTodo(id));
      });
    },
  });

  return {
    todos,
    isLoading,
    isFetching,
    error: mapError(error),
    setUserFilter,
  };
};

As you can notice, in this example in the onSuccess hook, the prefetch feature starts to load the data of every todo in the result of the list. That allows React Query to save the data in the storage and reuse them in the future when the application asks for that data. For instance, in a todo detail hook like this

const fetchTodo = async (id: Todo['id']): Promise<Todo> => {
  const response = await fetch(`api/tasks/${id}`);
  if (!response.ok) {
    throw new ResponseError(`Failed to fetch todo with id ${id}`, response);
  }
  return await response.json();
};

export const useGetTodoById = (id: Todo['id']): UseTodo => {
  const {
    data: todo = null,
    isLoading,
    error,
  } = useQuery([QUERY_KEY.todos, id], () => fetchTodo(id), {
    refetchOnMount: false,
    refetchOnWindowFocus: false,
    retry: 2,
  });

  return {
    todo,
    isLoading,
    error: mapError(error),
  };
};

As you can see, the key of this useQuery is the same as the key in the prefetch example, and in this way, ReactQuery is able to understand if the data are already loaded or not.
As you can imagine, with this simple feature, you can improve the quality of your application and maybe prefetch some data that could take too long to load.

Ok, I think you have a great idea of how key and prefetching work in React Query.
To learn more about them, check out also my Youtube video available here 👇

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=svvx-pl_hTE

I think thats all from this article; I hope you enjoyed this content!

See you soon folks
Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - Enable Query

Wed, 26 Apr 2023 00:00:00 GMT

Hey folks,
Do you know that you can enable or disable a query in react query? Noooo! Ok, it's time to learn it!

Some specific hooks must be enabled only if there are some data in the application; for instance, some queries must run only if the users are logged in.
To solve this problem, the useQuery hooks accept an option called enabled that accepts a boolean to determine if a condition is true or false.
Let's take a look at this example

import { useQuery } from '@tanstack/react-query';
import { QUERY_KEY } from 'src/app/constants/queryKeys';
import { Todo } from 'src/app/models';
import { User, useUser } from '../../../../auth/useUser';
import { ResponseError } from '../../../../utils/Errors/ResponseError';

const fetchTodos = async (user: User): Promise<Todo[]> => {
  const response = await fetch(`api/tasks?assigneeId=${user.user.id}`, {
    headers: {
      Authorization: `Bearer ${user.accessToken}`,
    },
  });
  if (!response.ok) {
    throw new ResponseError('Failed to fetch my todos', response);
  }
  return await response.json();
};

interface UseMyTodos {
  todos: Todo[];
  error?: string;
}

function mapError(error: unknown | undefined): undefined | string {
  if (!error) return undefined;
  if (error instanceof ResponseError) return error.response.statusText;
  if (error instanceof Error) return error.message;
  return 'Unknown error';
}

export const useMyTodos = (): UseMyTodos => {
  const { user } = useUser();

  const { data: todos = [], error } = useQuery(
    [QUERY_KEY.myTodos],
    () => fetchTodos(user!),
    {
      refetchOnWindowFocus: false,
      retry: 2,
      enabled: !!user,
    }
  );

  return {
    todos,
    error: mapError(error),
  };
};

As you can notice, in this case, a custom hook calls the API and gets all the todos assigned to the current users.
The key point of this example stands in the enabled option. As you can see, this useQuery is called only if there is a user; else, the query is stopped.
This feature permits developers to be sure to call a specific API only if a condition is satisfied, preventing a bad API request.
This feature is pretty simple but very powerful, as you can imagine!

To find out more about the enabled option take a look at my youtube video about it

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=5JSD_b2slJs

Ok, that's all from the enabled option.

I hope you enjoyed this content!

See you soon folks

Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - Filter Your Data

Wed, 19 Apr 2023 00:00:00 GMT

Hey folks,
Did you know that you can filter your data in react query? Noooo! Ok, it's time to learn it!

To filter the data in your useQuery hook, you have to handle the select option. This option accepts a function that is used to filter the data.
The function has one parameter, and this parameter contains the result of the query; the scope of the select function is to manipulate the query's result and returns a new result that respects some rules.

Let's take a look at this example

import { useQuery } from '@tanstack/react-query';
import { Dispatch, SetStateAction, useCallback, useState } from 'react';
import { QUERY_KEY } from 'src/app/constants/queryKeys';
import { Todo } from 'src/app/models';
import { ResponseError } from '../../../../utils/Errors/ResponseError';

const fetchTodos = async (): Promise<Todo[]> => {
  const response = await fetch('api/tasks');
  if (!response.ok) {
    throw new ResponseError('Failed to fetch todos', response);
  }
  return await response.json();
};

interface UseTodos {
  todos: Todo[];
  isLoading: boolean;
  isFetching: boolean;
  error?: string;
  setUserFilter: Dispatch<SetStateAction<number | null>>;
}

function mapError(error: unknown | undefined): undefined | string {
  if (!error) return undefined;
  if (error instanceof ResponseError) return error.response.statusText;
  if (error instanceof Error) return error.message;
  return 'Unknown error';
}

export const useTodos = (): UseTodos => {
  const [userFilter, setUserFilter] = useState<number | null>(null);

  const filterTodoByAssignee = useCallback(
    (todos: Todo[]) => {
      if (!userFilter) return todos;
      return todos.filter((todo) => todo.assigneeId === userFilter);
    },
    [userFilter]
  );

  const {
    data: todos = [],
    isLoading,
    isFetching,
    error,
  } = useQuery([QUERY_KEY.todos], fetchTodos, {
    refetchOnWindowFocus: false,
    retry: 2,
    select: filterTodoByAssignee,
  });

  return {
    todos,
    isLoading,
    isFetching,
    error: mapError(error),
    setUserFilter,
  };
};

As you can notice, this example has some key points to analyse.
First, the filterTodoByAssignee function is the select function passed to the useQuery hook. This function checks the userFilter state, and if it is empty, the function returns the entire list; else, it filters the result and returns only the todos that have the assigneeId that matches with the userFilter value.
It's important, in this case, to use the useCallback hook and pass to it the right dependencies to prevent a decrease in the performance of the application.
Then another important thing is the setUserFilter function that it's used to set the userFilter value. This function is exposed by the custom hook to permit the users to change the filter.

And that's all; in these two simple steps, you have a select function to filter the dataset got from the query. You can use this solution also to create a client-side pagination in your react query application (for the server-side pagination, there will be a post in the future)

If you want to find out more, check my youtube video about this topic

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=H4l1QAA4Dxw

Ok, that's all from the select option!

I hope you enjoyed this content!

See you soon folks

Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - Authentication Flow

Wed, 12 Apr 2023 00:00:00 GMT

Every application should handle an authentication flow; in this article, you'll learn how to build an authentication flow in your React Application with React Query.

Sign Up

The first step to build an authentication flow is the sign-up action. As you have already learned in this series, you should build a mutation to do this action. A possible solution could be this

async function signUp(email: string, password: string): Promise<User> {
  const response = await fetch('/api/auth/signup', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ email, password })
  })
  if (!response.ok)
    throw new ResponseError('Failed on sign up request', response);

  return await response.json();
}

type IUseSignUp = UseMutateFunction<User, unknown, {
  email: string;
  password: string;
}, unknown>

export function useSignUp(): IUseSignUp {
  const queryClient = useQueryClient();
  const navigate = useNavigate();
  const { enqueueSnackbar } = useSnackbar();

  const { mutate: signUpMutation } = useMutation<User, unknown, { email: string, password: string }, unknown>(
    ({
      email,
      password
    }) => signUp(email, password), {
    onSuccess: (data) => {
      // TODO: save the user in the state
      navigate('/');
    },
    onError: (error) => {
      enqueueSnackbar('Ops.. Error on sign up. Try again!', {
        variant: 'error'
      });
    }
  });

  return signUpMutation
}

By creating a mutation like that, you build the signUp in a very simple and clear way.
Now using the useSignUp hook, you can get the mutation and call the signUp request to create a new user in your system. As you can notice, the code is pretty simple; the signUp method calls the API to post the new user's data and return the user data saved in the database. Then using the useMutation hook, you can build the mutation to handle the signUp action. If everything goes ok, the onSuccess hook calls the navigation to the home page; otherwise, the onError hook shows a toast with an error.
In the code, there is a TODO that indicates something missing; we'll get back to this line in the future of this post.

Sign In

The second step to build if you are building an authentication flow is SignIn. In this case, SignIn is pretty similar to SignUp; the only things that change are the endpoint and the scope of the hook.
So the code can be this

async function signIn(email: string, password: string): Promise<User> {
  const response = await fetch('/api/auth/signin', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ email, password })
  })
  if (!response.ok)
    throw new ResponseError('Failed on sign in request', response);

  return await response.json();
}

type IUseSignIn = UseMutateFunction<User, unknown, {
  email: string;
  password: string;
}, unknown>

export function useSignIn(): IUseSignIn {
  const queryClient = useQueryClient();
  const navigate = useNavigate();
  const { enqueueSnackbar } = useSnackbar();

  const { mutate: signInMutation } = useMutation<User, unknown, { email: string, password: string }, unknown>(
    ({
      email,
      password
    }) => signIn(email, password), {
    onSuccess: (data) => {
      // TODO: save the user in the state
      navigate('/');
    },
    onError: (error) => {
      enqueueSnackbar('Ops.. Error on sign in. Try again!', {
        variant: 'error'
      });
    }
  });

  return signInMutation
}

I don't want to spend much time describing this hook because it is very similar to the SignUp but only with the references for the SignIn. Also in this case, there is a TODO that we'll remove in the future of the post.

The user

The core part of an authentication flow is where you save the user in the state. To do that, in this case, the best way is to create a new hook called useUser which is the owner of the user data.
The useUser hook must have the user's data, and it has to save the user's data in the local storage and retrieve them when the user refreshes the page or gets back in the future.
Let's start with the code that handles the local storage. Typically, this code is created with small functions with a specific goal like the next.

import { User } from './useUser';

const USER_LOCAL_STORAGE_KEY = 'TODO_LIST-USER';

export function saveUser(user: User): void {
  localStorage.setItem(USER_LOCAL_STORAGE_KEY, JSON.stringify(user));
}

export function getUser(): User | undefined {
  const user = localStorage.getItem(USER_LOCAL_STORAGE_KEY);
  return user ? JSON.parse(user) : undefined;
}

export function removeUser(): void {
  localStorage.removeItem(USER_LOCAL_STORAGE_KEY);
}

In this way, you can create a small module that handles all the local storage functions for the user.

Now it's time to see how you can build the useUser hook.
Let's start with the code

async function getUser(user: User | null | undefined): Promise<User | null> {
  if (!user) return null;
  const response = await fetch(`/api/users/${user.user.id}`, {
    headers: {
      Authorization: `Bearer ${user.accessToken}`
    }
  })
  if (!response.ok)
    throw new ResponseError('Failed on get user request', response);

  return await response.json();
}

export interface User {
  accessToken: string;
  user: {
    email: string;
    id: number;
  }
}

interface IUseUser {
  user: User | null;
}

export function useUser(): IUseUser {
  const { data: user } = useQuery<User | null>(
    [QUERY_KEY.user],
    async (): Promise<User | null> => getUser(user),
    {
      refetchOnMount: false,
      refetchOnWindowFocus: false,
      refetchOnReconnect: false,
      initialData: userLocalStorage.getUser,
      onError: () => {
        userLocalStorage.removeUser();
      }
    });

  useEffect(() => {
    if (!user) userLocalStorage.removeUser();
    else userLocalStorage.saveUser(user);
  }, [user]);

  return {
    user: user ?? null,
  }
}

The getUser function is simple; it provides the HTTP request to get the user info; if the user is null, return null otherwise, it calls the HTTP endpoint.

The useQuery hook is similar to the others seen before, but there are two new configurations to understand.

refetchOnMount : this option is important to prevent the hook reloads the data each time it is used
initialData : this option is used to load the data from the local storage; the initialData accepts a function that returns the initial value; if the initial value is defined, react query uses this value to refresh the data.

Now you have all the blocks of the authentication flow, but it's time to link useSignUp and useSignIn with the useUser hook.
Using the QueryClient you can set the data of a specific query by the setQueryData function.
So the previous TODOs comments change in this way

export function useSignUp(): IUseSignUp {
  const queryClient = useQueryClient();
  const navigate = useNavigate();
  const { enqueueSnackbar } = useSnackbar();

  const { mutate: signUpMutation } = useMutation<User, unknown, { email: string, password: string }, unknown>(
    ({
      email,
      password
    }) => signUp(email, password), {
    onSuccess: (data) => {
      queryClient.setQueryData([QUERY_KEY.user], data);
      navigate('/');
    },
    onError: (error) => {
      enqueueSnackbar('Ops.. Error on sign up. Try again!', {
        variant: 'error'
      });
    }
  });

  return signUpMutation
}


export function useSignIn(): IUseSignIn {
  const queryClient = useQueryClient();
  const navigate = useNavigate();
  const { enqueueSnackbar } = useSnackbar();

  const { mutate: signInMutation } = useMutation<User, unknown, { email: string, password: string }, unknown>(
    ({
      email,
      password
    }) => signIn(email, password), {
    onSuccess: (data) => {
      queryClient.setQueryData([QUERY_KEY.user], data);
      navigate('/');
    },
    onError: (error) => {
      enqueueSnackbar('Ops.. Error on sign in. Try again!', {
        variant: 'error'
      });
    }
  });

  return signInMutation
}

With two simple lines of code, you can set the user in the useUser state because the key used to set the query data is the same as the useUser.
Then, with an useEffect in the useUser hook, you can remove or set the user data in the local storage when the user changes

export function useUser(): IUseUser {
  const { data: user } = useQuery<User | null>(
    [QUERY_KEY.user],
    async (): Promise<User | null> => getUser(user),
    {
      refetchOnMount: false,
      refetchOnWindowFocus: false,
      refetchOnReconnect: false,
      initialData: userLocalStorage.getUser,
      onError: () => {
        userLocalStorage.removeUser();
      }
    });

  useEffect(() => {
    if (!user) userLocalStorage.removeUser();
    else userLocalStorage.saveUser(user);
  }, [user]);

  return {
    user: user ?? null,
  }
}

To complete the authentication flow, the only missing thing is the logout.
You can build it with a custom hook called useSignOut; its implementation is straightforward and could be done in this way

import { useQueryClient } from '@tanstack/react-query';
import { useCallback } from 'react';
import { useNavigate } from 'react-router-dom';
import { QUERY_KEY } from '../constants/queryKeys';

type IUseSignOut = () => void

export function useSignOut(): IUseSignOut {
  const queryClient = useQueryClient();
  const navigate = useNavigate();

  const onSignOut = useCallback(() => {
    queryClient.setQueryData([QUERY_KEY.user], null);
    navigate('/auth/sign-in');
  }, [navigate, queryClient])

  return onSignOut
}

As you can notice, the hook returns a simple function that clears the value in the user state and navigates to the sign-in page.

Ok, perfect. Now you have all the notions of building an authentication flow with React Query, but If you want to find out more, watch my youtube video about authentication with React Query

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=JNoiAumC94g

Ok, that's all from authentication.

I hope you enjoyed this content!

See you soon folks

Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - UI Mode

Thu, 06 Apr 2023 00:00:00 GMT

Hi folks,
In release 1.32, Playwright released a new cool feature for us, the UI Mode!

This feature is still in beta yet, but you can use it by adding a simple option in the CLI --ui.

$ npx playwright test --ui

The result of this command is a new window in your display!

Using this view, you can run and debug your test. But let's dive into it.
The view is split into two parts: the left part contains the list of the tests, and the right part is the crucial view to check and debug the tests. If you are familiar with the Playwright tracer, the right section is similar to the tracer view.

But what can you do with this view?
First, you can run one or many tests using the run button at the right of each test or group of tests.

Playwright runs the tests by clicking this button, and you can see the result. A green tick means the test is ok, and a red icon with a circle X means there is an error in the test.

Now if you click on one of the tests in the right section, you can see what happened during its execution.
In this case, let's dive into the wrong test.
In the top section, you can see the timeline of the test; you can go over it with the mouse and see all the browser views during the execution.

In the action tab, you can find all the actions done by the test, for instance: the page creation, the navigation, each click on the page and so on. You can navigate in the history by clicking on one of these actions, and each time you click the action, the panel on the right shows the view at that specific moment. In this way, you can understand what happened during the test execution.

In the bottom bar, you can access different views: Source, Console, Network, and Log.
I think the last three views are pretty simple, and I want to focus on the Source view.
In the Source view, you can see all the code used by Playwright to run the test, and if you click on one of the actions, Playwright highlights the line of code that runs that action. If your test is wrong, Playwright shows you the error in the specific line of code where the error is thrown. In this way, you can immediately see the mistake and try fixing it.

The last cool feature introduced in this view is the possibility to open the Source code directly from the view! If you click the icon at the right of the Run icon, Playwright opens the file using Visual Studio Code.

Last but not least, Playwright keeps syncing your codebase with the Playwright UI Runner, so in this way, you can change and fix errors and retry the test immediately.

If you want to find out more or watch the Playwright UI Runner on working, check out my Youtube video.

https://www.youtube.com/watch?v=ErkRgqmHCmc

I think this solution and the integration of Playwright with VsCode are awesome, and Playwright is changing the Developer Experience in the best possible way!

Ok, that's all folks!
I hope you enjoyed this content, and now your testing phase is more comfortable and easier!

See you later!
Bye Bye 👋

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - DevTools

Wed, 05 Apr 2023 00:00:00 GMT

Hey Folks,

In this post, you'll learn how to debug and check whatever happens in your React Query application. It's normal when you begin to learn or use a tool; check the tools around it to understand the developer experience so you can decide whether to continue with it. The React query team knows that and has decided to build a tool to help the developer that wants to work with React Query.
This tool is called react-query-devtools and you can install it in a simple step.
Open your terminal and type

$ npm i @tanstack/react-query-devtools

Now, in your project, you can use it and get all the info required to debug your application.

This tool is simple to use. In your application, you must import it and render it where you render the ReactQueryProvider.

import { QueryClientProvider } from '@tanstack/react-query';
import { ReactQueryDevtools } from '@tanstack/react-query-devtools';
import React from "react";
import { queryClient } from './react-query/client';
import Router from './Router';

function App() {
  return (
    <React.StrictMode>
      <QueryClientProvider client={queryClient}>
        ...
        <ReactQueryDevtools />
      </QueryClientProvider>
    </React.StrictMode>
  );
}
export default App;

Easy peasy, no?
With ReactQueryDevtools, you don't have to pay attention to the environment to render or not the component because it provides it by default. It renders the component only if the condition process.env.NODE_ENV === 'development' is true.
You can customize the component or force its render also in production mode if you want. To find out more about these topics, you can check the documentation.

The benefit of using this component in your application is that it allows seeing what happens in ReactQuery at runtime. You can check the data saved in the state, how many application parts use the different queries, etc. You can also reset the state or remove part of it to re-fetch the data.

Yeap, it exposes many good features to debug and check your React Query application, and it is a good tool for every developer that works with React Query. Here you can find an example of ReactQueryDevtool at work

If you want to find out more, watch my Youtube video about React Query Devtool to see it in action.

🎬 Watch / View Embedded Resource: https://youtu.be/qXycRUetOX4

Ok, that's all! I think you have an idea of what React Query Devtools is and how you can integrate it into your application!
I hope you enjoyed this content!

See you soon folks Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

OramaSearch, a full-text search in your React application

Thu, 30 Mar 2023 00:00:00 GMT

In some applications, you need to create a full-text search to improve the search of data. In some scenarios, you build this using an API and leave the problem to the backend. But in other cases, you need to guarantee the feature without an internet connection, or you are building a hybrid application, or you need to reduce these kinds of searches directly in the browser to reduce the computation cost in the server. A simple example could be to perform a search on your blog to see which articles respect some criteria.
To do this, in the last period, Orama Search has born. A simple npm library that allows you to create a "small" typed database in your browser (and not only) and exposes a simple method that permits you to search data in this database.
So, in this article, you'll discover how to use Orama Search in your React application and learn how it is easy to integrate it into your next applications.

Before starting a quick explanation of the application, because I don't want to cover all the processes in this article but only the Orama integration.
The application is a simple React page where you can search for one or more Italian cities by a term. The terms could search the cities by names or by regions.
The application on startup loads all the possible cities and create an Orama database in the browser. Then you can search using the form the city you prefer.
I wrapped the Orama logic inside of a React Context, and you can interact with it using two hooks.

Here you can find the result

If you want to read this article with the full code of the application, you can find it in the GitHub repository.

N.B. in this article, I'll use ni instead of npm, yarn or pnpm, but you can use whichever you prefer without any problems.

Installation

The first step to use Orama in your application is to install it.
It's a piece of cake; in your terminal type:

ni @orama/orama

I think this step doesn't need a big explanation. But this is the door to start using Orama in your application. With this command, now in your node_modules, you can find the Orama packages, and now it's time to start using it!

Create Database

First of all, to use Orama you have to create a database. To do that, Orama exposes a method called create. This method accepts a schema that describes the database structure and some options to configure the database.
For this example, in addition to the schema, I want to show you how you can work with a different language (Italian, in this case) and how you can configure Orama to do that. Orama, to handle this process, uses stemmer out-of-the-box.
So to create a simple database in this case and to move your first steps with Orama, you can go to the folder src/core/useOrama where you'll find all the code to handle Orama in your application.
Let's start from the src/core/useOrama/context.ts file

import { Orama, Schema } from "@orama/orama";
import { createContext } from "react";
import { SchemaToTypes } from "./types";

export type OramaContext<S extends Schema = any> = {
  isCreated: boolean;
  isIndexed: boolean;
  db?: Orama;
  setData: (data: SchemaToTypes<S>[]) => Promise<void>;
};

export const OramaContext = createContext<OramaContext>({
  isCreated: false,
  isIndexed: false,
  setData: async values => undefined,
});

As you can see, the context of Orama for this application is simple. Two flags to understand the status of the database, the database and the setData function to insert the data in the database.

Now you can move to the OramaProvider inside of the src/core/useOrama/Provider.tsx file.

import {
  create,
  insertMultiple,
  Orama,
  Schema
} from "@orama/orama";
import {
  PropsWithChildren,
  useCallback,
  useEffect,
  useMemo,
  useState
} from "react";

import { OramaContext } from "./contex";
import { SchemaToTypes } from "./types";

type IOramaProviderProps<S extends Schema> = PropsWithChildren<{
  schema: S
  options?: Omit<Parameters<typeof create>[0], 'schema'>
}>

export const OramaProvider = <S extends Schema>({ schema, options, children }: IOramaProviderProps<S>) => {
  const [isIndexed, setIsIndexed] = useState(false);
  const [orama, setOrama] = useState<Orama | undefined>(undefined)

  const setData = useCallback(async (values: SchemaToTypes<S>[]) => {
    if (!orama) throw new Error(`Orama database is not created!`)
    setIsIndexed(false);
    await insertMultiple(orama, values);
    setIsIndexed(true);
  }, [orama, setIsIndexed])

  const context = useMemo<OramaContext>(() => ({
    isCreated: !!orama,
    isIndexed,
    db: orama,
    setData
  }), [setData, orama, isIndexed])

  useEffect(() => {
    async function init() {
      const db = await create({
        schema,
        ...(options ?? {}),
      });
      setOrama(db);
    }
    init();
  }, []);

  return <OramaContext.Provider value={context}>{children}</OramaContext.Provider>;
};

In this file, the code starts to be tricker.
First of all, the provider accepts two properties, the Orama schema and the Orama options. Orama uses these properties to create the database for the application.
Then the provider does some little things. First, it initializes two states to save the database and the isInidex flag. This flag is used to understand if the data used for the search are saved in the database. Then the provider creates the setData function used by the application to insert the data in the database. With an effect, it creates the database using the create method exposed by Orama, and then creates and returns the context using a useMemo to improve the performance and the OramaContext.Provider components.
If you are familiar with React and Javascript/Typescript, I think everything is simple and clear after one or two views of the code.
The last step is to render the Provider in the application. This is in the src/App.tsx.

import { createTheme, ThemeProvider } from '@mui/material/styles';
import { stemmer } from '@orama/orama/stemmer/it';

import { CITIES_SCHEMA } from './core/cities/oramaSchema';
import { OramaProvider } from './core/useOrama/Provider';
import Search from './page/Search';

const theme = createTheme();

function App() {
  return <ThemeProvider theme={theme}>
    <OramaProvider schema={CITIES_SCHEMA} options={{
      components: {
        tokenizer: {
          language: 'italian',
          tokenize: stemmer,
          normalizationCache: new Map<string, string>(),
        },
      },
    }}>
      <Search />
    </OramaProvider>
  </ThemeProvider>
}

export default App

Here there are two important things. First, the schema:

export const CITIES_SCHEMA = {
  city: "string",
  lat: "number",
  lng: "number",
  country: "string",
  iso2: "string",
  admin_name: "string",
  capital: "string",
  population: "number",
  population_proper: "number",
} as const;

Second, the Orama configuration. In this case, the configuration imports stemmer and indicates to Orama that the database contains Italian words. Orama works in English by default, but you can use it in other languages. You can find out more in the documentation.

Init Database

To initialize the database, you have to see the src/core/useOrama/useOramaSetData.tsx file.
This file contains the hook that exposes the function to set the data in the database.
This is the code

import {
  Schema
} from "@orama/orama";

import {
  useContext
} from "react";
import { OramaContext } from "./contex";

export const useOramaSetData = <S extends Schema = any>() => {
  const { setData, isCreated }: OramaContext<S> = useContext(OramaContext);
  return {
    canSetData: isCreated,
    setData
  };
};

As you can notice, the hook is pretty simple, get the setData function and the isCreated flag, and exposes them. Here the important concept stands in the Provider file where you defined the setData function.
Let's pick this part of the code again

const setData = useCallback(async (values: SchemaToTypes<S>[]) => {
  if (!orama) throw new Error(`Orama database is not created!`)
  setIsIndexed(false);
  await insertMultiple(orama, values);
  setIsIndexed(true);
}, [orama, setIsIndexed])

In this code, the insertMultiple function is an important concept for Orama. With the insertMultiple function, you can insert an array of rows in your database, and then Orama will use these data for future searches. There is also the insert method to insert only one row per time, but you can find more info in this reference.

Then, it's time to use this method on the Search page to initialize the database with the data.
To do that, go into the src/Search/index.ts file, and you can find the import of the hook and how to use it in an effect.

...
import { useOramaSetData } from '../../core/useOrama/useOramaSetData';
import { getCities } from '../../core/cities/httpCities';
...

export default function Search() {
...
  const { canSetData, setData } = useOramaSetData<typeof CITIES_SCHEMA>();
...

  useEffect(() => {
    if (!canSetData) return;

    async function initDb() {
      const cities = await getCities()
      setData(cities)
    }
    initDb()
  }, [canSetData]);

...
}

Now, your database is ready to perform the searches 🚀

Search in the Database

The core part of Orama is the search! Now it's time to dive into it.
To handle the search, you'll create another hook called useOramaSearch.
The search is pretty simple in Orama. There is a search method that accepts the Orama database, the terms to search and some possible options. You can find more in this reference.
The implementation of the search is this

import {
  Schema,
  search as searchWithOrama
} from "@orama/orama";

import {
  useCallback,
  useContext
} from "react";
import { OramaContext } from "./contex";
import { Results } from "./types";

export const useOramaSearch = <S extends Schema,>() => {
  const context: OramaContext<S> = useContext(OramaContext);

  const search = useCallback(
    async (term: string, properties: string[] | '*' = '*'): Promise<Results<S>> => {
      if (!context.db) throw new Error("Database not ready");

      const { length } = properties;
      const boost = properties === '*' ? {
        city: 2,
      } : properties.reduce((acc, key, index) => {
        const boostValue = (length - index) * 2;
        acc[key] = boostValue;
        return acc;
      }, {} as Record<string, number>);

      const result = await searchWithOrama(context.db, {
        term,
        properties,
        boost
      }) as unknown as Results<S>;

      return result;
    },
    [context]
  );

  return {
    isReady: context.isCreated && context.isIndexed,
    search,
  };
};

There are some interesting points in this code.
As you can notice, the search method accepts the terms and a list of properties.
The first is the search terms that the user wants to search; the second is the list of properties that you want Orama to use during the search (using * Orama searches in all the properties).
There is another strange option called boost in this example. This option is a configuration to indicate to Orama the importance of one or more fields in the search.
The last step is to use this hook in the Search page to run the search.
In the src/page/Search/index.tsx this implementation is done in this way.

...
import { useOramaSearch } from '../../core/useOrama/useOramaSearch';
...

export default function Search() {
  const { isReady, search } = useOramaSearch<typeof CITIES_SCHEMA>();
...

  const onSubmit: FormEventHandler<HTMLFormElement> = useCallback(async (e) => {
    e.preventDefault();
    const form = e.target as HTMLFormElement;
    const searchTerms = form.elements.namedItem('searchTerms') as HTMLInputElement;
    const results = await search(searchTerms.value,
      [searchType]);
    setResults(results)
  }, [search, searchType, setResults])

  ...
}

The last info about the search is the search result. It is composed in this way

elapsed : this object contains the statistic of the search; here, you can find how much time Orama has used to provide the result
hits : this is the list of the elements that respect the search; by default, Orama returns the first ten elements; you can paginate the result, passing the limit and the offset options in the search method.
count : here; you can find the number of elements that match the terms

And perfect now the application is ready to search the cities.

You can test the result in this reference 🚀

Conclusion

As you can notice, integrating Orama into your application is pretty simple.
The project has born some months ago and obviously it is not perfect and with huge features, but it works well, and the team will release many new features in the further future.
All the hooks and the context seen in this article could be early replaced by an npm package called use-orama; it is a working progress 🚧.

And that's all! I hope Orama can help your applications search data quickly in the future, and I think it will become a great product in the next few months!

If you are interested in it, you can learn more about it in the official documentation.
And don't forget to follow Orama on Twitter and Michere Riva its CTO.

🚧
N.b. The project is in beta version at this moment, so breaking changes or some bugs are opportunities to contribute to the project if you want 😎 in the GitHub repository you can find the GitHub Repo
🚧

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - useIsFetching & useIsMutation

Wed, 29 Mar 2023 00:00:00 GMT

Hey folks,

Today it is time to talk about two hooks exposed by react query: useIsFetching and useIsMutation.

Each of these hooks could be used to understand if there is a fetching request or if there is a mutation request ongoing in the application.

They are useful if we need to create a global loader that appears when there are one or more requests on going.

But how can you use them?

Let's start with the useIsFetching.

import { useIsFetching } from '@tanstack/react-query';

export default function Loader() {
  const isFetching = useIsFetching();
  if (!isFetching) return null;

  return <>Fetching...</>
}

As you can see, the syntax is pretty simple. You can import the hook from the library and you can use the hook in your components. The hook returns only a boolean value that indicates if there are one or more fetching requests in the application. Then with this data, you can decide if you have to show a loader or not. Easy peasy!

Now it's time to move to the useIsMutation hook. This hook is similar to the previous one, the only different concept is that this hook handles the mutation requests. Let's see an example!

import { useIsMutating } from '@tanstack/react-query';

export default function Loader() {
  const isMutating = useIsMutating();
  if (!isMutating) return null;

  return <>Mutating...</>
}

As you can notice, the syntax is the same as the previous one, the only difference stands in the name of the hook and in its concept.

If you want to find more about these two hooks see my Youtube video about them.

🎬 Watch / View Embedded Resource: https://youtu.be/dWuUjDNB6Yc

Ok, I think you have an idea of how these two hooks work. I hope you enjoyed this content.

See you soon folks

Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - useMutation

Wed, 22 Mar 2023 00:00:00 GMT

Hey Folks,
It's time to talk about the second core concept in React Query, mutation.

What is it?

Mutations are actions that a user can do in your application. You can imagine a mutation as an action to change or create something.
To understand better in the code what a mutation is, let's start with a code snippet

import { useMutation } from '@tanstack/react-query';

const postTodo = async (text: Todo['text']): Promise<Todo> => {
  const response = await fetch('api/tasks', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ text }),
  });
  if (!response.ok) {
    throw new ResponseError('Failed to insert new todo', response);
  }
  return await response.json();
};

export const useAddTodo = (): UseAddTodo => {
  const { mutate: addTodo, isLoading, error } = useMutation(postTodo, {
    onSuccess: () => {
      // Success actions
    },
    onError: (error) => {
      // Error actions
    },
  });

  return {
    addTodo,
  };
};

As you can see, the mutation is a simple hook with two params:

The function to handle the request
The options to handle, in this case, the success and the error hooks, but also to configure the mutation (retry, retry delay and so on).

The result has three main objects:

mutate: this is the action to run the mutation in your code
isLoading: this flag indicates if the mutation is ongoing
error: this indicates the errors in case there is an error in the request

Using mutations in your React applications, you can handle all those actions to mutate the data and simplify the management of the states of these requests.

Another important concept to know when you work with mutation is the QueryClient.
Using the QueryClient, you can invalidate a query already provided and say to react query to ask again for the data because you are sure that those data are not yet valid after the mutation.
To do that, you have to use the useQueryClient hook to retrieve the queryClient and using the invalidateQueries method, you can invalidate the react query cache for a specific query or multiple queries.
Here you can find an example

import { useMutation, useQueryClient } from '@tanstack/react-query';
import { QUERY_KEY } from '../../../../constants/queryKeys';

export const useAddTodo = (): UseAddTodo => {
  const client = useQueryClient();
  const { mutate: addTodo } = useMutation(postTodo, {
    onSuccess: () => {
      client.invalidateQueries([QUERY_KEY.todos]);
    },
  });
  ...
};

Ok, I think you have an idea of how useMutation and useQueryClient work, but if you want to dive into them, don't forget to see my Youtube video.

https://www.youtube.com/watch?v=Cpxoxj9sTXA

Ok, That's all!
I hope you enjoyed this content, and I'll get back to you soon with another concept of React Query.

Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

React Query - useQuery

Wed, 15 Mar 2023 00:00:00 GMT

Hey Folks,
It's time to take a journey on react query. Don't you know it? Perfect, you are in the right place 😁

Introduction

What is React Query? React query is an npm library created by @TannerLinsley.
It's a state manager for react that simplifies many tasks like handling the HTTP request state, saving data in the client to prevent many requests, sharing data in your application using hooks and so on.
You'll discover more in this series about it, learn how to use it, and appreciate its simplicity in your react applications.

useQuery

The first core concept is useQuery. Through it, you can retrieve data from a source and handle all the states of this request in a very simple way.
Let's see an example

import { useQuery } from '@tanstack/react-query';

const fetchTodos = async (): Promise<Todo[]> => {
  const response = await fetch('api/tasks');
  if (!response.ok) {
    throw new ResponseError('Failed to fetch todos', response);
  }
  return await response.json();
};

export const useTodos = (): UseTodos => {
  const {
    data: todos = [],
    isLoading,
    isFetching,
    error,
  } = useQuery(['todos'], fetchTodos, {
    refetchOnWindowFocus: false,
    retry: 2,
  });
...
};

In this example, you can see the essentials of useQuery.
UseQuery is a react hook; it takes 3 params:

The query key
The query function
The configurations

Let's start with the first one. The query key is a key used by react query to identify your queries; through the key, react query is able to store the result and use it in different parts of the application. The key is used to identify the query, and with it you can also reset the query or change the value by code using the React Query Client.

The query function is the method used to retrieve data from a source (rest, graphQL, etc. etc.). It's simple; a function that returns a kind of data could be a simple function or, in most cases, a promise.

Configurations, ok these are simple :) There are many possible options to run the query in different ways (amount of retries, when refreshing the data, how to cache the data and so on..)

The result of this hook has three important objects instead

data; this object contains the result of your query function. Please, pay attention that the data could be undefined too; this is because on the first call when the request is pending, data is not yet presented
isLoading; this flag indicates when react query is loading data. There is also the isFetching flag, which is important if you are creating infinite scrolling. The isFetching flag indicates that there is a request pending, which is perfect if the app is asking for the next info
error: this object contains the error if your request has a problem; using it, you can get the error and create a pretty info message for the user

Ok, you have an idea of how useQuery works and what its potentialities are, but if you are more interested in it, you can watch my video to learn more about it.

🎬 Watch / View Embedded Resource: https://www.youtube.com/watch?v=q2r2yoq5zaQ

ok, that's all! I'll get back to you with another react query feature soon.

I hope you enjoyed this content.

Bye Bye 👋

p.s. you can find the code of the video in the GitHub repository

Photo by Rahul Mishra on Unsplash

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Why I love GitLens in my VsCode - Interactive Rebase

Tue, 28 Feb 2023 00:00:00 GMT

One of the processes I typically do in my daily work is interactive rebase.
I commit a lot, and then before pushing the result, I try to make the history more readable.

If you have to do that by CLI, you should follow many steps:

> git log --oneline

This command returns the list of the commit

Now, you have to get the SHA of the commit from where you want to start the interactive rebase and run the command

> git rebase -i bf2478f

Now you can handle your rebase from your best editor, in my case VsCode.

pick 4fcdf0e add documentation
pick c7a47a9 add documentation

# Rebase bf2478f..c7a47a9 onto bf2478f (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
# commit's log message, unless -C is used, in which case
# keep only this commit's message; -c is same as -C but
# opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# create a merge commit using the original merge commit's
# message (or the oneline, if no original merge commit was
# specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
# to this position in the new commits. The <ref> is
# updated at the end of the rebase
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#

When you've finished fixing the history, you can save the file, close it and voila, your interactive rebase is completed.

First, you must know this flow before moving to the next solution.
The goal of this series is not to forget or don't learn git, but to help you understand how you can improve your developer experience with git using GitLens.

So now it's time to see how the interactive rebase becomes easier with GitLens.
First, you have to enable the feature from the command palette in this way.

Now you can use it from the commit history. Right-click on the interested commit and choose "Rebase Current Branch onto Commit".

Then you have to choose between two types of rebase, the normal and the interactive. It goes without saying that you have to choose the interactive rebase.

The view that appears is something like this

Here you can handle the rebase using drag and drop if you want to move the commit, or you can change the action for the commit using a simple dropdown.

When you're done, you can click the button in the bottom right, "Start Rebase", so the rebase will be completed.

If you change your mind during the rebase, you can abort the operation or close the file or click the "Abort" button.

But the magic doesn't end here. When you enable the Interactive Rebase, if you have set up VsCode as the default editor for git, when you run the git rebase -i .... command from the terminal, by default, VsCode opens the rebase page with the GitLens view.

Before closing, if you don't like this feature, you can disable it from the VsCode's command palette in this way.

Ok, that's all! I hope now your rebase will be easier and you will have a better developer experience during this operation.

See you soon folks

👋 Bye Bye 👋

If you are interested in it, use my referral in this reference to try GitLens or other GitKraken products for Free! gitkraken.com/invite/whbhwrJL

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Parametrize tests

Thu, 23 Feb 2023 00:00:00 GMT

Hey folks,

Today it's time to speak about how to parametrize tests with Playwright.

There are cases where we want to test the same behaviour but with different values, so in these cases, it's common to create a structure for the test and reuse it with different parameters.

The easiest way to do that with Playwright is using vanilla javascript.
You can create an array with different cases, and using the for clause, you can call the test N times with different parameters.

Coming back to the Tic Tac Toe application, a real example could be to simulate different rounds and, for each round, indicate the sequence of the moves and who must be the winner.

An implementation of this scenario can be done in this way

import { expect, test as base } from "@playwright/test";

const test = base.extend({
  page: async ({ baseURL, page }, use) => {
    baseURL && (await page.goto(baseURL));
    await use(page);
  },
});

type TestCase = {
  winner: "X" | "O";
  moves: number[];
};

const testCases: TestCase[] = [
  {
    winner: "X",
    moves: [1, 5, 6, 7, 3, 9, 2],
  },
  {
    winner: "O",
    moves: [3, 1, 5, 7, 9, 4],
  },
];

for (const { winner, moves } of testCases) {
  test(`should win the player "${winner}" with these ${moves}`, async ({
    page,
  }) => {
    for (const move of moves) {
      await page.locator(`button:nth-child(${move})`).click();
    }

    const winnerParagraph = await page.getByText(/winner/i);
    await expect(winnerParagraph).toContainText(winner);
  });
}

As you can notice, the result is quite simple:

Define a TestCase type
Create an array with the cases
Iterate the cases and create a test for each case
Run and check the test result

Ok, this solution is good and can resolve many of our cases, but you can do more with Playwright!
It's possible to load a csv file and use it to map all the test cases. Playwright doesn't fully expose this solution, but the simplicity with which Playwright is built permits a simple solution to do this.

Let me show you an example:

You can map the previous two cases in a csv file like this

// e2e/csv/winners_cases.csv
"test_case","winner","moves"
"should win the player X","X","1,5,6,7,3,9,2"
"should win the player O","O","3,1,5,7,9,4"

Then using an npm package called csv-parse we can load the csv in our test in this way

import { parse } from "csv-parse/sync";
import fs from "fs";
import path from "path";

const cases = parse(
  fs.readFileSync(
    path.join(process.cwd(), "e2e", "csv", "winners_cases.csv")
  ),
  {
    columns: true,
    skip_empty_lines: true,
  }
);

Now in the records variable, you have all the data that describe your test cases.
The last thing to do is to create the tests like in the previous example

 for (const testCase of cases) {
  test(testCase.test_case, async ({ page }) => {
    const moves = testCase.moves.split(",");
    for (const move of moves) {
      await page.locator(`button:nth-child(${move})`).click();
    }

    const winnerParagraph = await page.getByText(/winner/i);
    await expect(winnerParagraph).toContainText(testCase.winner);
  });
}

And voila, you have a test suite that runs the test from a csv file.

In my opinion, both ways are good, but with the csv file you have less control of your code and your tests, and it's easy to face an error that doesn't depend on the test or the code but because someone changed the file in the wrong way. So please pay attention to who touches the files 😊

Ok, I think you have an idea of how you can parameterize your tests.

It's time to say goodbye to this series, this is the last article. I'll come back to you in the future if there will be new features to share with you 😊 But for now, I suppose that's all!

I hope you enjoyed it and see you soon!

test.afterAll(() => {

Bye bye 👋

});

N.b. you can find the code of this article in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Why I love GitLens in my VsCode - Blame & Compare

Tue, 21 Feb 2023 00:00:00 GMT

When you work with git, you want to get info about commits and who changed the codebase quickly.

With GitLens, you can get much info about your current file without losing focus on it. First, at the top of your file, you can get info about the last change and the name of the person who pushed that commit. In addition, there is also info on the number of people that touched the file.

This information is clickable. You can click on the part relative to the last commit or the other one.
The first part opens the VsCode command with some possible actions to see the commit; you can see all the files relative to the commit, open the commit detail, and see the commit in the commit-graph. This is very helpful if you want to get info quickly about the changes in the file.

Instead, If you click on the second part (that is relative to the other authors of the file), GitLens opens a new bar on the left of the file and shows, for each line, the last commit relative to it, so you can understand who and why someone has changed the line.

This view is also available using the icon with the git logo in the top right of the file, and you can toggle this view by clicking it easily.

All these features are fantastic, but sometimes we need more, for instance, searching for a commit or comparing two different commits.
To do that, in the GitLens bar, you can find an option called "Search & Compare".

Let's start with the search feature. Using this feature, you can search for a commit by different filters: commit message, author, SHA, file or changes. Typically, in my case, I use this feature to find an old commit by message or by author. The feature is very straightforward. If you click the button, the extension opens a command with different options; you can select your choice and type your terms. After that, in the GitLens panel will appear the results of the search.

With this view, you can check the commits and see the files changed in those commits.

After the search could be necessary to compare two commits, you can use the other button called "Compare references" to do that.
Also, this feature is easy to use. Clicking the button "Compare References" appears a new VsCode command, where you can type the reference of your branches/tags or commits. Obviously, you have to indicate two references for the comparison.

For me, this is really convenient when I have to compare two different versions of the code in the past or to check when and why a piece of code has changed.

Ok, that's all folk.
I hope you have other tips for improving your productivity with git using GitLens.

Let me know if you think these features could be helpful to you too or if you already use them in your daily work.

See you soon folks

Bye bye 👋

If you are interested in it, use my referral in this reference to try GitLens or other GitKraken products for Free! gitkraken.com/invite/whbhwrJL

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Not just for Frontend

Thu, 16 Feb 2023 00:00:00 GMT

In this path with Playwright we spent a lot of time speaking about e2e tests and component testing in the frontend world. But now its time to spill the beans and tell you a secret. Playwright can be used on the backend side too.

API Testing

Playwright can test REST API too. In some scenarios, you don't have a UI, but you have an API integration and have to test your integration in some way.
Using API testing with Playwright, you can call your APIs without a user interface and check their correct execution.

The key volta for doing that on Playwright is the request object. Using this object, you can call your APIs and check their result.

But let's take a look at it.

First, I didn't create a backend API for this example, but I used a fake API to test. I created it with json-server and json-server-auth. They are two npm packages that use a JSON file as a database and expose the database in an API. You can find more about json-server in its documentation and about json-server-auth in this reference.

It's time to understand how API testing works.
A straightforward example could be this

test("should call a winner", async ({ request }) => {
  const result = await request.post("http://localhost:3001/api/winners", {
    data: {
      winner: "O",
    },
  });
  expect(result.ok()).toBeTruthy();
  expect(await result.json()).toEqual(
    expect.objectContaining({
      winner: "O",
      id: expect.any(Number),
    })
  );
});

This example is to understand the structure of an API test, then you'll see a more complex example.
The request object is exposed by Playwright in each test, like the page object in a standard e2e test in the browser. With this object, you can call one or more HTTP requests. Then, when you have the result of the requests, you can check if the result is ok or if the response respects a specific schema.
As you can notice, it's elementary

create a request
wait for the result
check the result

Typically, a simple API test has this flow, probably before you could have a login request because your APIs are under authentication, but a login request is just another request before.

I created a more complex example to give you a better idea of the flow you can create with Playwright and API testing (This approach could be used with e2e tests too).

The example is so structured. For each test, the suite:

creates a new json-server database
creates a new json-server process
runs the tests
kill the json-server
delete the temporary database

Let's start from the beginning. I created two files for the tests. One file is the database with one row for the winners and one user inside. The other file is the route file to make a sort of authentication in the API. (you can learn more about that following the json-server documentation seen before).

So these two files are in the db folder and appear in this way

// db_test.json
{
  "users": [
    {
      "email": "test@test.it",
      "password": "$2a$10$ONSI/ac5n4iyMj7LfcRIsOzYQ8dqPYK33TTH1Qp7YORPjvofkoTgS",
      "id": 1
    }
  ],
  "winners": [
    {
      "winner": "X",
      "createdAt": "2023-01-16T21:06:20.749Z",
      "id": 1
    }
  ]
}

// routes_test.json
{
  "/api/*": "/$1",
  "users": 600,
  "winners": 664
}

Now it's time to create a routine for each test that gets these two files, creates a copy of the database, and runs the json-server in a specific port. In this way, if we have many tests in parallel, each test doesn't depend on the actions done in the other tests.

To do that, I created this code

// api.spec.ts
import { expect, test } from "@playwright/test";
import { ChildProcess, exec } from "child_process";
import { randomUUID } from "crypto";
import { copyFile, unlink } from "fs/promises";
import { join } from "path";

const dbName = `db_test_${randomUUID()}.json`;

const dbInitPath = join(process.cwd(), "db", "db_test.json");
const dbPath = join(process.cwd(), "db", dbName);

const portsMapping = {
  chromium: 3001,
  firefox: 3002,
  webkit: 3003,
} as const;
let port: 3001 | 3002 | 3003;
let baseUrl: string;
let api_process: ChildProcess;

test.beforeAll(async ({ browserName }) => {
  port = portsMapping[browserName];
  baseUrl = `http://localhost:${port}/api`;
  // Create a file to be uploaded
  await copyFile(dbInitPath, dbPath);

  // Start the server
  await new Promise<void>((resolve, reject) => {
    api_process = exec(
      `npx json-server-auth --watch ${dbPath} --port ${port} --routes db/routes_test.json`,
      err => {
        if (err) reject(err);
      }
    );

    api_process.stdout?.on("data", data => {
      if (data.includes("Watching...")) {
        setTimeout(() => {
          resolve();
        }, 10);
      }
    });
  });
});

There are some critical points in this code:

const dbName = `db_test_${randomUUID()}.json`;

const dbInitPath = join(process.cwd(), "db", "db_test.json");
const dbPath = join(process.cwd(), "db", dbName);

Here I created two new variables, one contains the path of the init database file, and the second one is the path for the database used by the test.

Then I mapped each browser in different ports, so if the tests run in parallel, there aren't problems of concurrency in the same database. (If your suite is only for API testing you can run the suite only with one browser, in this case, I kept the suite like in the previous articles)

const portsMapping = {
  chromium: 3001,
  firefox: 3002,
  webkit: 3003,
} as const;
let port: 3001 | 3002 | 3003;

In the beforeAll hook, I created the copy of the database, and then I ran the json-server process to expose the API.

test.beforeAll(async ({ browserName }) => {
  port = portsMapping[browserName];
  baseUrl = `http://localhost:${port}/api`;
  // Create a file to be uploaded
  await copyFile(dbInitPath, dbPath);

  // Start the server
  await new Promise<void>((resolve, reject) => {
    api_process = exec(
      `npx json-server-auth --watch ${dbPath} --port ${port} --routes db/routes_test.json`,
      err => {
        if (err) reject(err);
      }
    );

    api_process.stdout?.on("data", data => {
      if (data.includes("Watching...")) {
        setTimeout(() => {
          resolve();
        }, 10);
      }
    });
  });
});

It seems a bit strange, but as you can see, in this way, I simulated a new database for each test file, so each test has its database and doesn't depend on the other tests.

As you can imagine, in this way, you can create a clean environment for each test.

Then I added another hook, the afterAll, where I killed the API process and deleted the database file.

test.afterAll(async () => {
  console.log("Kill server", baseUrl);
  api_process.kill();
  await unlink(dbPath);
});

Then I created the first test that checks if the result of the get method returns an array of winners.
This is easy peasy

test("should return an array of winner", async ({ request }) => {
  const result = await request.get(`${baseUrl}/winners`);
  expect(result.ok()).toBeTruthy();
  expect(await result.json()).toEqual(
    expect.arrayContaining([
      expect.objectContaining({
        winner: expect.stringMatching(/^O|X$/),
        id: expect.any(Number),
      }),
    ])
  );
});

I can call the API and get the result using the request object, and then I can check if the result is ok and if the response is like expected.
This example is pretty simple, so I don't want to spend too much time on it; I guess it is comprehensible.
But now it's time to move to another example that is a bit more complex.
The test has to test the insert in the winners' collection. To do this action, the user must be logged in, so before doing the post, we have to login into the API. The result is something like this.

test("should insert a winner", async ({ request }) => {
  console.log("Testing the server", baseUrl);
  const loginResult = await request.post(`${baseUrl}/login`, {
    data: {
      email: "test@test.it",
      password: "test",
    },
  });
  expect(loginResult.ok()).toBeTruthy();
  const { accessToken } = await loginResult.json();
  const result = await request.post(`${baseUrl}/winners`, {
    data: {
      winner: "O",
    },
    headers: {
      Authorization: `Bearer ${accessToken}`,
    },
  });
  expect(result.ok()).toBeTruthy();
  expect(await result.json()).toEqual(
    expect.objectContaining({
      winner: "O",
      id: expect.any(Number),
    })
  );
});

As you can see, in this example, I created a flow of authentication, and then the test moves to the post request for the winners if it is ok. Yes, probably if you are familiar with testing; this is not rocket science, but you can see how it's easy to create API testing with Playwright.

So far so good; in this article, you discovered API testing with Playwright and a medium example of how you can create a flow of API testing with Playwright.

That's all folks!
I hope you enjoyed it and see you soon!

Bye bye 👋

N.B. you can find the code of this article in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Why I love GitLens in my VsCode - First Steps

Tue, 14 Feb 2023 00:00:00 GMT

In my daily routine, I work with git, and I suppose it's the same for you.
I know all the standard commands to work with it in my terminal, and I love them.
I think every developer must know git and its commands, and work with it by the command line. If you don't know at least the basic git commands, please go to study them right away. There are many articles or videos about them and don't forget the documentation; that is the best place to learn and study new things.
When you have the fundaments, if you want to dive into it, this book is for you.

Btw, today I want to speak about something different, I love git and I love terminal, but sometimes I love having the info visualised appealingly and get info about the source control quickly. I work with VsCode typically, so some months ago I tried to find a solution for this editor that resolves what was said before. After googling and some testing, the result of my search was: GitLens.
Now, I want to show you how it works and how it can improve your routine.
So don't waste time and let's jump in it!

Installation

First of all, to use GitLens you have to install it. This process is a piece of cake if you are familiar with VsCode.

Open your editor
Go to the extension tab
Search "gitlens"
Install the extension

N.B. There are two extensions, the official and the insider; you can choose the one you prefer because the insider it's typically stable too. It goes without saying the insider version could have some bugs sometimes.

First Impact

After the installation, the extension is ready to use, and you can find it in your sidebar.

Before going on, I want to say you that the extension is free, but not all the features are free. Some cool features are available only in the pro subscription; you can find more in this reference.

As you can notice from the previous image, GitLens has different sections, and each section has its goal. Each title is already comprehensible as you can see, but now we'll deep into some of them and not only.

I'll use the Lyra repository for this article, so thanks to the Lyra contributors if this article has a great git history and awesome code.

Repository

In this tab, you can find all the info about your repository: branches, commits, tags, contributors and so on. I use this section sparingly because, in other areas, I find these data based on my needs. But here, you can find the best overview of your repository.

Commits

This section starts to become more interesting. Here there is the commits list of the current branch.

Typically, I don't use this section to see the commit; I have a git alias showing me the terminal's history. But, in this section, there are 4 commands very helpful:

Undo the commit (please pay attention when you use it)
Compare the commit with the head
Copy the SHA
Open the commit in the browser

The first, the second, and the last one are my favourites because I always forget the undo syntax, comparing the commit in some cases is very helpful using this tool, and opening the commit in the browser is straightforward in this way.
Another cool feature presented in this section is the commit-graph. This is a pro feature, but it's very powerful to understand the status of the branches. You can find it in the title bar of the Commit section.

The result of this command is this

With this graph understanding the branches' status or filtering or searching in your repository is easy, and you can find your answer quickly.
This is very helpful for me when I want to check where my current branch is compared to the main branch or others.

File history and line history

These sections are incredible! If you have a file open in the editor in these two tabs, you can see the history of the file in your repository and the history of the line where your cursor is.
Another cool integration are the notions present on the right of the current line directly in the file, where you can find the last commit's info of that line of code. So you can blame your colleague 🤪

The last feature that I want to face out in this article is the button that permits to see the changes between the current version of the file and the previous one. This button is in the top right of the file and the result if you click it is like this.

This feature is very cool and allow us to see immediately what has changed in the last commit. In this view, it's possible to continue the history navigation using the same icon at the top right of the button.

So far so good; I suppose that as a first look at GitLens, that's all. In the next article, we'll dive into other cool features in GitLens, but for now, let me know what you think about it. Do you already use it? Which are your impressions in this case?

See you soon folks

Bye bye 👋

If you are interested in it, use my referral in this reference to try GitLens or other GitKraken products for Free! https://www.gitkraken.com/invite/whbhwrJL

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Parallelism and sharding

Thu, 09 Feb 2023 00:00:00 GMT

Hey Folks,

Today I'll speak about parallelism and sharding with Playwright, so don't waste time and jump into it.

By default, Playwright runs your tests in parallel. It uses many worker processes at the same time. But you have different solutions to handle or remove parallelism in Playwright.

Test files are in parallel, and each file is executed in order, from the first test to the last one. This is the default configuration
Using test.describe.configure you can configure a file to run its tests in parallel
it's possible to configure the entire project to have all tests in all files that run in parallel using testProject.fullyParallel or testConfig.fullyParallel
it's possible to disable the parallelism limit by setting the number of workers to one.

Worker processes

Each test runs in its own worker processes, and communication between workers is impossible. A process is an Os process that runs independently and is orchestrated by the test runner. Each worker has the same environment and starts its own browser.
Playwright Test reuses a single worker as much as possible to make testing faster, so multiple test files are usually run in one worker one after another.
Each time a test fails, the worker is shouted down to guarantee a pristine environment for the following tests.

Limit the worker processes

Nonetheless, you can control the maximum number of parallel worker processes via the command line or in the configuration file in this way

npx playwright test --workers 4

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  // Limit the number of workers on CI, use default locally
  workers: process.env.CI ? 2 : undefined,
});

Disable parallelism

However, it's possible to disable the parallelism too. To do that, the solution is to set the workers' configuration to one by command line or configuration file.

npx playwright test --workers 1

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  // Limit the number of workers on CI, use default locally
  workers: 1,
});

Parallelize tests in a single file

Playwright, by default, runs all the tests in a single file in order, but it's possible to run them in parallel too. To do that, you have two possible solutions, by the configuration file or by the test.describe.configure()

The solution by the configuration file enables parallelism in each file of your test suite instead the test.describe.configure() enables it just in a single file.

By the way, the setting of this configuration is elementary; if you decide to enable it by the config file, the solution is this:

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  fullyParallel: true,
});

else, if you want to enable parallelism using test.describe.configure() the solution is this

import { test } from '@playwright/test';

test.describe.configure({ mode: 'parallel' });

It's essential to spend some words about beforeAll and afterAll hook. In this case, these hooks will be executed for each process, so they become like beforeEach and afterEach hooks.

Serial mode

Sometimes, you have to run the tests in the same file in serial. To do that in Playwright, you can configure the serial mode. In this way, Playwright executes all the tests in sequence, but if one of the chain fails, the following tests will not execute, and so they will be skipped.

This kind of configuration exists in Playwright, but it's not recommended.

However, if you want to enable it, you have to add this line of code to your test file

import { test, Page } from '@playwright/test';

// Annotate entire file as serial.
test.describe.configure({ mode: 'serial' });

Shard tests between multiple machines

Another cool feature, if you want to speed up your test suite, is the shard configuration. This configuration permits splitting the execution of the test suite in different machines so that you can parallelise your suite much more. This configuration helps the execution of your CI, so you don't have to waste too much time waiting for the CI.
To use this configuration, you have to use the --shard option and indicate 2 numbers

the total of shards
which shard Playwright has to run

So, for instance, an example could be like this

npx playwright test --shard=1/3
npx playwright test --shard=2/3
npx playwright test --shard=3/3

In this way, you are dividing your test suite into 3 shards, and each command runs one of them.

Control test order

By default, Playwright runs all the tests in parallel, so it doesn't guarantee the order execution. However, if you disable the parallelism, you should need to execute the test in a specific order. To do that, you have two options:

Sort test files alphabetically
Use a "test list" file

As you can imagine, for the first option, you have to choose a rule to order your files; for instance, in the official documentation, they say to add a prefix with three numbers: 001, 002, 003, etc. etc., easy peasy lemon squeeze.

For the second option instead, the game becomes trickier. You have to put your test in a helper file, and then you have to create a new file that imports all the helpers, and you have to wrap each helper in a test.describe.
Then, you have to disable the parallelism and indicate to Playwright to use only the file that contains the helpers. In my opinion, yes, it's a solution, but probably, I prefer the first approach. To leave you a concrete idea, here you can find a possible implementation picked directly from the official documentation

// feature-a.spec.ts
import { test, expect } from '@playwright/test';

export default function createTests() {
  test('feature-a example test', async ({ page }) => {
    // ... test goes here
  });
}

// feature-b.spec.ts
import { test, expect } from '@playwright/test';

export default function createTests() {
  test.use({ viewport: { width: 500, height: 500 } });

  test('feature-b example test', async ({ page }) => {
    // ... test goes here
  });
}

// test.list.ts
import { test } from '@playwright/test';
import featureBTests from './feature-b.spec.ts';
import featureATests from './feature-a.spec.ts';

test.describe(featureBTests);
test.describe(featureATests);

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  workers: 1,
  testMatch: 'test.list.ts',
});

Another critical thing to remember in this solution is to wrap all the tests in the helpers with a function; in this way, your tests will not depend on the import/export statement, and you will prevent strange mistakes.

Ok, that's all! Now, I suppose you have an idea of how parallelism works in Playwright and have all the notions to handle it.

I hope you enjoyed this article, and if you have any questions, don't hesitate to reach out to me, you are welcome.

See you soon folks
Bye Bye 👋

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Visual Comparisons

Thu, 02 Feb 2023 00:00:00 GMT

Hi there,

Today I want to speak about Visual comparisons with Playwright.

In some projects is crucial to respect the same size for the component on the page, or to guarantee the exact visualization each time, or to ensure the same colour, etc.

Playwright exposes this feature out of the box. To do that, Playwright uses snapshots and compares a specific snapshot with the test result to check that nothing has changed.

But don't waste time, and let's see how it works.

I want to use the Square component for this example, but you have to refactor it before moving to the test. First, you have to move the X and O png images from the public folder to the Square component folder. After that, you have to refactor the component so that it imports these images and uses them to render the icon.The result is something like this:

Folder Structure

 Square
    O.png
    Square.module.scss
    Square.tsx
    X.png

Square Component

import { TicTacToeValue } from '../../models/TicTacToeValue';
import { Nullable } from '../../utils/Nullable';
import Icon from '../Icon/Icon';
import OIcon from './O.png';
import styles from './Square.module.scss';
import XIcon from './X.png';

interface SquareProps {
  value: Nullable<TicTacToeValue>;
  onSelect: () => void
}

export default function Square(
  { value, onSelect }: SquareProps
) {

  const icon = value === 'X' ? XIcon : OIcon;

  return (
    <button
      type='button'
      className={styles.Square}
      onClick={onSelect}>
      {value && <Icon src={icon} title={value} />}
    </button>
  )
}

Perfect, now you are ready to create your first test to check the visual comparisons.

Before moving on to code, you should meet what you have to know to make visual comparisons with Playwright, and the only thing that you have to know is the assertion toHaveScreenshot. This assertion is your best friend if you want to implement visual comparisons with Playwright, it has some configurations, but you will see the most commons later. Now, don't waste and get your hands dirty.

First of all, you have to create a new file called src/components/Square/Square.spec.tsx, that will contain your tests. As first example, you can create a new test that checks if the Square component shows the X icon if the value is X. To do that, you have to make a test like this

import { expect, test } from '@playwright/experimental-ct-react';
import Square from './Square';

test.describe('Square', () => {
  test('should show the X icon without regression', async ({ mount, page }) => {
    await mount(<Square value={'X'} onSelect={() => { }} />);
    await expect(page).toHaveScreenshot();
  });
})

As you can notice, this article shows the visual comparisons in the testing of the components, but you can use it in the e2e tests too.Ok, now it's time to see the result by running the command npm run test-ct.The result is not like expected, I suppose. In fact, the result shows an error like this:

Error: A snapshot doesn't exist at playwright-series/snapshots/components/Square/Square.spec.tsx-snapshots/Square-should-show-the-X-icon-without-regression-1-chromium-darwin.png, writing actual.

As you can imagine, Playwright tries to run your tests but doesn't find a snapshot to compare with your result, so it raises an error for each platform (Chrome, Firefox and WebKit). However, you can notice that three new files came up in your project. These files are the snapshot of your test. You can find them at the root of your project in the folder __snapshots__ . From here, Playwright can run your test and check if the result is like on these snapshots. To check that, you can rerun the previous command and notice that the result will be better and your tests will be passed.

To double-check if the visual comparison works, you can change the icon sizes in the Square.module.scss file. For instance, from 100x100 pixels to 101x101 pixels.

.Square {
  width: 101px;
  height: 101px;
  background-color: #fff;
  border: 1px solid #000;
  display: flex;
  justify-content: center;
  align-items: center;
  font-size: 2rem;
  font-weight: bold;
  cursor: pointer;
  transition: background-color 0.3s ease;
}

If you rerun the command npm run test-ct, the result shows something like this:

3 failed
    [chromium] components/Square/Square.spec.tsx:6:3 Square should show the X icon without regression
    [firefox] components/Square/Square.spec.tsx:6:3 Square should show the X icon without regression
    [webkit] components/Square/Square.spec.tsx:6:3 Square should show the X icon without regression

And as you can imagine, your test suite failed because the result is not exactly like expected.

When we run with visual comparison, as you can imagine, introducing a regression is very easy, a pixel of difference and boom, the suite fails. Playwright knows this problem and permits you to be less strict in these cases. It's important to remember that by default, Playwright is strict and checks every single pixel of difference, but you can configure it with a threshold. The most commons are maxDiffPixelRatio, maxDiffPixels or threshold.Each configuration permits you to be slackers in different cases. For instance, if you choose the maxDiffPixels configuration, you can write the previous test in this way

test('should show the X icon without regression', async ({ mount, page }) => {
  await mount(<Square value={'X'} onSelect={() => { }} />);
  await expect(page).toHaveScreenshot({ maxDiffPixels: 500 });
});

If you run the command npm run test-ct , now the test suite has passed, and as you can imagine, Playwright has tested your new snapshot using the maxDiffPixels configuration. Hence, even if the size is different, the result is ok because it respects the maxDiffPixels configuration.

These kinds of configurations could be set as default if you want. For instance, you can decide that all the visual comparison tests must have the maxDiffPixels of 500. To do that, you can configure Playwright to have this configuration by default. In the Playwright configuration file, you can set the expect method with this configuration:

import { defineConfig } from '@playwright/test';
export default defineConfig({
  expect: {
    toHaveScreenshot: { maxDiffPixels: 500 },
  },
});

Last but not least, sometimes changing the component structure is required. In these cases, you have to change snapshots so that Playwright has the new comparison images in the future to check the results. To do that, you can run your test with the option --update-snapshots. This indicates to Playwright that the snapshots are old and that it has to change the previous results with the new ones.

Ok, I suppose you have a good idea of how visual comparison works on Playwright, and you can start to play with it without problems.I think that's all from Visual Comparison, I hope you enjoyed this content and if you have any questions, you are welcome!

See you soon folk

Bye bye

You can find the source code of this article in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Mock API

Thu, 26 Jan 2023 00:00:00 GMT

Hi there,
Today I want to talk about how to mock API with Playwright.

To do that, I add a new feature to the usual example. When one of the players wins, the system sends a POST request to the URL http://localhost:3001/api/winners to save the history of the results of the games.

The API server is built using json-server. You can find all the steps to reproduce the feature in this commit.

Mock API

Mocking API is a common feature in testing frameworks. In Playwright, to do that, you have to use the page.route method. This method permits you to work with API in different ways:

Mocking responses
Modify requests
Modify responses
Abort requests

Any request that a page does, including XHRs and fetch requests, can be tracked, modified and mocked in Playwright using page.route.

Mock API in action

In this article, I want to show you how to start to use this API.
Let's start with the test. The test is straightforward; it reproduces a game where the Player X wins and, in the end, checks if the application fetches the POST request to save the winner.

The test's base is composed in this way

test("should register the winner calling the winner API[POST]", async ({
  page,
  playerXWinMoves,
}) => {
  /// mock the API
  for (const move of playerXWinMoves) {
    await page.locator(`button:nth-child(${move})`).click();
  }
});

As you can see, the test is similar to the previous one.

Now it's time to see how you can mock the API.

First, you have to get your API; to do this, you have to use the page.route that way.

page.route("http://localhost:3001/api/winners", async route => {   
});

So, as you can notice, the page.route method accepts two parameters: the first is the URL of your API, and the second is a function used to work with your request.

Now it's time to get info from your request, for instance, the method and the body of the request.

page.route("http://localhost:3001/api/winners", async route => {
  const request = route.request();
  const method = await request.method();
  const postData = await request.postDataJSON();
});

Very simple, as you can see, it's important to remember that all the methods of the request return a Promise, and you have to use the await keyword to get the value.

Now, another important feature when you want to mock API is to return custom responses.

page.route("http://localhost:3001/api/winners", async route => {
  const request = route.request();
  const method = await request.method();
  const postData = await request.postDataJSON();

  await route.fulfill({
    status: 200,
    contentType: "application/json",
    body: JSON.stringify(Object.assign({ id: 1 }, postData)),
  });
});

Using route.fulfill you can mock the response. You can set the status code, content type, body, etc. In this way, you have all the power to work with the response.

Perfect, you have all the tools to mock the request. But before closing, I want to leave you another tip. You can use the page.route as the assertion of your test.

Let's see an example

page.route("http://localhost:3001/api/winners", async route => {
  const request = route.request();
  const method = await request.method();
  const postData = await request.postDataJSON();

  expect(await request.method()).toBe("POST");
  expect(await request.postDataJSON()).toEqual(
    expect.objectContaining({
      winner: expect.stringMatching("X"),
      createdAt: expect.any(String),
    })
  );

  await route.fulfill({
    status: 200,
    contentType: "application/json",
    body: JSON.stringify(Object.assign({ id: 1 }, postData)),
  });
});

As you can notice, you can use the expect function also inside of the page.route. So you can check if the request is called and in the right way.

To close the article, here you can find the entire test.

test("should register the winner calling the winner API[POST]", async ({
  page,
  playerXWinMoves,
}) => {
  page.route("http://localhost:3001/api/winners", async route => {
    const request = route.request();
    const method = await request.method();
    const postData = await request.postDataJSON();

    await route.fulfill({
      status: 200,
      contentType: "application/json",
      body: JSON.stringify(Object.assign({ id: 1 }, data)),
    });

    expect(await request.method()).toBe("POST");
    expect(await request.postDataJSON()).toEqual(
      expect.objectContaining({
        winner: expect.stringMatching("X"),
        createdAt: expect.any(String),
      })
    );
  });

  for (const move of playerXWinMoves) {
    await page.locator(`button:nth-child(${move})`).click();
  }
});

Ok, I think that's all from Mocking API. Now you have all the notions to start mocking API with Playwright, and if you have any doubt, you can reach out to me without problems or check the official documentation.
I hope you enjoyed this content.

See you soon folk!

Bye bye 👋

You can find the code of this article in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - CI

Thu, 19 Jan 2023 00:00:00 GMT

Hi there,
Today I want to speak about integrating Playwright in your GitHub action CI.
So don't waste time and let's start.

To start, you have to create a file called playwright.yml in this path .github/workflows.

The .github/workflows' path is used to save the files for your GitHub Actions, and the name of the file is not important for GitHub because the value for it is inside of your files.

Let's start to copy and paste this code into the playwright.yml

name: Playwright Tests
on: [push]

These two info are used to give a name to the CI and to define what triggers this CI.
These are standard fields that you can find in every GitHub Action in the world.
In this case, the CI will trigger every push in the project.

Now it's time to add the first job to run your e2e tests in CI.
To do that, add this to your file.

jobs:
  test-e2e:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        run: npx playwright test
      - uses: actions/upload-artifact@v3
        if: always()
        with:
          name: playwright-e2e-report
          path: playwright-report/
          retention-days: 30

Jobs are used in GitHub Action to run different stuff, like build, test, deploy etc. etc.
In this example, the test-e2e's job creates a list of steps to run the test in the CI.
But what this job does:

runs-on is used to indicate on which platform the job has to run
actions/checkout@v3 checkouts the code
actions/setup-node@v3 setups the node version for the job
Install dependencies installs all the dependencies in the node_modules
Install Playwright Browsers installs the browsers for Playwright
Run Playwright tests runs the e2e tests
actions/upload-artifact@v3 uploads the test's results in the GitHub Artifact

Ok, this is the job for the e2e tests; now it's time to add the job for the component tests.
To do that, copy and paste the following code

  test-ct:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        run: npx playwright test -c playwright-ct.config.ts
      - uses: actions/upload-artifact@v3
        if: always()
        with:
          name: playwright-ct-report
          path: playwright-report/
          retention-days: 30

As you can see, it's similar to the previous job but has different configurations, so I don't dive into it.
Now with these two jobs, you have a CI ready to run.
To do that, git add + git commit + git push, and go into your online GitHub repository. In the tab Actions, you can find your CI in action, and If you click on it, you can see the two jobs running. (It's important to understand that these two jobs run in parallel, you can find more info about job execution in the GitHub repository)

When the CI is ended, you are sure that your tests are ok as expected. And the result will be like this.

Perfect, now you have your first GitHub action configured to run your tests with Playwright.

Good, that's all folk, I think you have all the info to integrate Playwright in your CI without any problem.

Thank you and see you soon.

Bye Bye 👋

The code of this post is available in the GitHub repository.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Components testing

Thu, 12 Jan 2023 00:00:00 GMT

Hi there,
Today I'll speak about a beta feature in Playwright: Components.

The team is building a new feature to write component tests with Playwright, so it's time to see how it works.

Installation

To start to use this feature, you have to install it. To do that, type in your terminal

npm init playwright@latest -- --ct

The command asks you two questions:

Which framework do you use? (experimental) choose to react to this tutorial
Install Playwright browsers choose to true

When the installation ends, there will be a new file in your project called: playwright-ct.config.ts. This file contains the configuration for the components' testing.
For this tutorial, you have to change only one configuration, testDir property from ./ to ./src. Playwright uses this configuration to understand where the files used for the components' tests are located. In this example, you'll put the test file in the same folder as the component.

First Test

Let's start with the first component test.

Create a file called Icon.spec.tsx in the folder src/components/Icon/, and inside of it, copy this code.

import { expect, test } from '@playwright/experimental-ct-react';
import Icon from './Icon';

test.use({ viewport: { width: 500, height: 500 } });

const props = {
  src: 'src',
  title: 'title',
}

test('should work', async ({ mount }) => {
  const component = await mount(<Icon src={props.src} title={props.title} />);
  await expect(component).toHaveAttribute('src', 'src');
  await expect(component).toHaveAttribute('title', props.title);
});

As you can see, the structure is similar to other Testing Frameworks.
You have to import the methods relative to react components from the path @playwright/experimental-ct-react and import your component.
Then you can set up the viewport for your test; it's important to understand that the tests run in different browsers, so you can also test your components in different viewports. And at the end, it's time to check your component.
The test structure is straightforward; using the mount method, you can render the component in the DOM, and then you can check the result using the Playwright APIs.
For instance, in this case, the test checks if the src and title attributes have the correct value.
Using these tests, you can check the proper logic or the right representation of your components and guarantee the right render in different browsers.

Run the test

Cool, you set up Playwright, and you wrote the tests. Now it's time to run it.
Easy peasy lemon squeezy, type in your terminal the following command

npx playwright test -c playwright-ct.config.ts

and then

npx playwright show-report

the result is like this.

As you can notice, Playwright runs the test in three different browsers by default. You can decide where to run the tests, adding or removing the browsers from the configuration file.

Perfect! I think you have a good introduction to component testing with Playwright. The feature is in experimental mode, so use it carefully, please.
You can find out more info in the official documentation if you want to dive into it.

I hope you enjoyed this content.
See you soon folk.

Bye Bye 👋

You can find the code of this post in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Visual Studio Code - Tips & Tricks - Profile

Tue, 10 Jan 2023 00:00:00 GMT

Intro

During my daily work, sometimes I have to switch between different projects: backend frontend, nodejs, react, angular etc. etc.

I used to think that configuring VsCode in the best way for each project was impossible. In addition, Im a bit drug of extensions in my VsCode, which often causes performance decreases because some unused extensions (not required for the current project) use a lot of RAM or CPU. To go around this problem, typically, I used to disable these extensions but with the cons that I have to reenable them when I need to work with them. It was a bit frustrating, but some days ago, I came across a fantastic feature of VsCode. This feature is called Profile. Currently, the feature is present only in the Insider, but I hope it will become available to all early.

What is Profile?

Profile allows you to create different setups in base on your needs. Using a profile, you can have different setups based on the current language, include or exclude extensions, change shortcuts, etc. etc.

How can you set up your profile?

To work with profiles, you have to make your focus on the bottom-left of your editor. There is an icon where you can handle your profile. The default profile is called, as you can imagine, Default. If you have never heard about Profile before now, it goes without saying that you have the Default profile selected. But now, its time to learn how it works.

Its not rocket science, but its very helpful, in my opinion.

Create a new Profile

You must click the Profile section and select Create New Profile to create a new one. Now you can choose between two options: an empty configuration or starting from another profile. Now the decision is in your hands. Add, remove, and change your configuration as you want in base on your needs. For instance, I created different setups based on the context: AWS, Azure, Node, Angular, and React. You can find your best solution to improve your productivity.

Delete Profile

Delete profile is easy peasy; click on the Profile section and select "Delete Profile", then you have to choose the Profile that you want to delete (one or many) and click the Ok button. Now the game is done, the profile will be removed.

Conclusion

In my opinion, this feature is essential. I created my setups, and now VsCode works quickly and without performance problems. I hope it will be the same for you too.
Creating different Profiles allows me to create my best experience during my daily routine with VsCode and reduce the possibility of wasting time with performance problems created by extension that are useless at that moment.

I hope this content could be helpful for you too. Let me know in the comment if you already know it or if you will be surprised like me when I discovered it.

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Fixtures

Thu, 05 Jan 2023 00:00:00 GMT

Hey there,
Today I want to speak about Fixtures, a vital friend if you're going to work with Playwright and you want to share data between your tests or create custom executions.

Let's start with a simple example.

test('should win the player "X"', async ({ page }) => {
  await page.goto("/");
  await page.locator("button:nth-child(1)").click();
  await page.locator("button:nth-child(5)").click();
  await page.locator("button:nth-child(6)").click();
  await page.locator("button:nth-child(7)").click();
  await page.locator("button:nth-child(3)").click();
  await page.locator("button:nth-child(9)").click();
  await page.locator("button:nth-child(2)").click();

  const winnerParagraph = await page.getByText(/winner/i);
  await expect(winnerParagraph).toContainText("X");
});

Imagine you want to extract all the indexes of the buttons in an array to replicate this test and reduce all these click commands to have a shorter test.
So, the first refactor before introducing the fixture feature could be this.

test('should win the player "X"', async ({ page }) => {
  const playerXWinMoves = [1, 5, 6, 7, 3, 9, 2];

  for (const move of playerXWinMoves) {
    await page.locator(`button:nth-child(${move})`).click();
  }

  const winnerParagraph = await page.getByText(/winner/i);
  await expect(winnerParagraph).toContainText("X");
});

As you can notice, all the steps to reproduce the players' moves are contained in the playerXWinMoves variables. The test is concise, but most important, all the actions are in a single variable. Now it's time to introduce fixtures.

Before carrying on, let me spend some words describing what fixtures are.

What fixtures are

Test fixtures are used to establish an environment for each test, giving the test everything it needs and nothing else. Test fixtures are isolated between tests. With fixtures, you can group tests based on their meaning instead of their standard setup.
After this definition, you can think fixtures could be replaced by before/after hooks, but fixtures have several advantages over these hooks:

Fixtures encapsulate setup and teardown in the same place, making it easier to write.
Fixtures are reusable between test files - you can define them once and use them in all your tests. That's how Playwright's built-in page fixture works.
Fixtures are on-demand - you can define as many fixtures as you'd like, and Playwright Test will set up only the ones needed by your test and nothing else.
Fixtures are composable - they can depend on each other to provide complex behaviours.
Fixtures are flexible. Tests can use any combination of fixtures to tailor the precise environment they need without affecting other tests.
Fixtures simplify grouping. You no longer need to wrap tests in describes that set up an environment and are free to group your tests by their meaning instead.

Perfect, after this boring theoric part, it's time to get your hands dirty with fixtures in Playwright.
To start the explanation, I want to begin with the final result.

import { expect, test as base } from "@playwright/test";

type TestFixtures = {
  playerXWinMoves: [number, number, number, number, number, number, number];
};

const test = base.extend<TestFixtures>({
  playerXWinMoves: async ({}, use) => {
    await use([1, 5, 6, 7, 3, 9, 2]);
  },
});

test('should win the player "X"', async ({ page, playerXWinMoves }) => {
  for (const move of playerXWinMoves) {
    await page.locator(`button:nth-child(${move})`).click();
  }

  const winnerParagraph = await page.getByText(/winner/i);
  await expect(winnerParagraph).toContainText("X");
});

As you can see, to build our fixture, you have to extend the test object exposed by Playwright. Inside this function, you can create an object that represents your fixtures. In this case, I added the playerXWinMoves property to share the steps to reproduce the Player X win. In addition, just because I love working with Typescript, I added the TestFixtures type to describe my fixtures. It's essential to notice that inside the fixture, you must use the use method to set the value for your fixtures.
Ok, carry on and let's take a look at the test now. You can notice that you can get the playerXWinMoves fixture directly from the object passed to your test. And now, if you remove the previous variable and use the new one from the params, you will create your first test with Playwright using fixture.
Great, I hope you can understand the incredible power of this feature and how it can help you to make your test more readable or to bring together some data useful in many tests.
But before closing, let me leave you another bit. With fixtures, you can also override an object exposed directly by Playwright. For instance, you can override the page object, and instead of creating a beforeEach hook to navigate to the home page, you can override the page and add this step in a fixture, so every test, before its execution, runs the steps to navigate to the home page.
And how can we do that? Simply in this way.

const test = base.extend<TestFixtures>({
  page: async ({ baseURL, page }, use) => {
    baseURL && (await page.goto(baseURL));
    await use(page);
  },
});

Doing that, now each test, when it starts its execution, goes to the baseURL and then runs all the code. Incredible no? Now, you can remove the beforeEach hook in the test file and rerun your tests to check the result.

Ok, that's all folk!
Today you have learned how Playwright fixtures work and how to build one.
I hope you enjoyed this post, and if you have any doubts, don't hesitate to reach out to me; I will be happy to help you.

See you soon
Bye Bye 👋

p.s. you can check out the code of this article in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Generate tests' code

Thu, 29 Dec 2022 00:00:00 GMT

Hi there,
today you will learn how to generate the code for your tests.

First of all, you have to run the application, so type in your terminal npm run dev , and you will have your application up and running at the address http://localhost:5173.
Now you have to run the Playwright code generator. To do that, you have to open another tab in your terminal and type npx playwright codegen.
This command opens in your display a new browser and the Playwright inspector.
Now, the browser shows an empty tab, and the Playwright inspector is on a new page, ready to listen to what you will do in the browser. If you go into the browser's address bar and type http://localhost:5173, you can notice that something has changed in the Playwright Inspector. The inspector noted the page change and added this step to the test body. Now, you can click on one square and simulate a game between two players, you can notice that the inspector records all these steps and creates the body of the test for you. The result of these actions is this

test('test', async ({ page }) => {
  await page.goto('http://localhost:5173/');
  await page.locator('._Square_pba4r_1').first().click();
  await page.locator('button:nth-child(5)').click();
  await page.locator('button:nth-child(6)').click();
  await page.locator('button:nth-child(7)').click();
  await page.locator('button:nth-child(3)').click();
  await page.locator('button:nth-child(9)').click();
  await page.locator('button:nth-child(2)').click();
});

As you can see, the generated code is good but not perfect, so please use this tool with the head on the shoulders and check the result every time to ensure your test's value.

Say that, now it's time to copy and paste the code into our test file and improve its content. Let's start by changing the test name from test to should win the player "X" and changing the goto value from http://localhost:5173/ to / because our base root corresponds to the home page. Then refactoring the first click probably is a good refactor to improve the test, so you have to change the line from await page.locator('._Square_pba4r_1').first().click(); to await page.locator("button:nth-child(1)").click(); and last but not least, add the assertion. In this case, if the test name is should win the player "X" the best assertion is something like this

const winnerParagraph = await page.getByText(/winner/i);
await expect(winnerParagraph).toContainText("X");

So the code tries to get the paragraph with the winner text and checks if the value contains the X value.
The final result is this

test('should win the player "X"', async ({ page }) => {
    await page.goto("/");
    await page.locator("button:nth-child(1)").click();
    await page.locator("button:nth-child(5)").click();
    await page.locator("button:nth-child(6)").click();
    await page.locator("button:nth-child(7)").click();
    await page.locator("button:nth-child(3)").click();
    await page.locator("button:nth-child(9)").click();
    await page.locator("button:nth-child(2)").click();

    const winnerParagraph = await page.getByText(/winner/i);
    await expect(winnerParagraph).toContainText("X");
  });

Now, you can run the test and check the result which should be green.

Ok, I think that's all from the code generation.
In this article, you learnt how to record your steps and convert them to code for your tests. Please, as I said before, use this tool responsibly and check the generated code every time.

That's it, folk.

See you soon 👋

p.s. you can find the result of this article in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - debug your tests

Wed, 21 Dec 2022 00:00:00 GMT

Debug your tests

One of the most popular things done by developers is to debug the code using console.log.
But today I want to show you how to debug your Playwright tests.

Let's start with the Playwright Inspector.
Using the option --debug when you run the tests, Playwright opens two new windows in your display, a browser and the Playwright Inspector.
To try this, you can type in your terminal this command npx playwright test --debug, the result seems like this

You can use the commands in the inspector to move forward in the test and check the stuff.

Cool, but I prefer debugging the tests directly from my editor (VsCode). To do that, you have to install the official extension called Playwright Test for VSCode. The extension permits you to install Playwright in your projects or add new browsers configuration, but today the goal is the debug feature.
Now, in VsCode if you open the Test Explorer, you can see all your tests in the projects and run them or debug them directly from your editor. Here is an example.

Ok, now it's time to see how you can run or debug your test directly from VsCode.
First of all, using the command in the top right of the Test Explorer panel, you can decide between running or debugging all the tests in your suite. Clicking on the arrow on the left of these buttons, you can also decide in which browser you want to run your tests. Here is a short demo!

In this example, you can see how the runner works, but now it's time to see how it's possible to debug tests.
Let's start adding a break-point in the code base. If you are not familiar with this in VsCode, it's elementary, click with the mouse on the left of the line where you want the debugger stops its execution.

🎬 Watch / View Embedded Resource: https://youtu.be/QIryVOtMXvM

Now, it's time to debug the test. We will see two methods to debug the tests; the first runs all the tests, and the second runs only the necessary test.

Debug all the tests

Using the icon in the top-right of the test explorer, you can run all your tests in debug mode, and for each test with a break-point, VsCode can stop the execution and permits you to check the test's status. Here is a video example of that.

🎬 Watch / View Embedded Resource: https://youtu.be/F5L-qpg3UBA

That is a good example, but typically, you want to debug one test per time.

Debug only needed test

To do that, the flow is very similar, you have to choose which test you want to debug and insert a break-point where you want the execution will stop. Then in Test Explorer, you have to search for your test; you can type the name of your test in the search bar, or you can scroll through the three and find it using the mouse. To run your test now, you must press the icon relative to the debug execution on the right of the test name. Doing that, VsCode will run your test and will stop the execution when the code arrives at the break-point. Here, you can check your application's status and the problems in your test. Using the command in the top-right of the VsCode's window, you can move on in the execution.

🎬 Watch / View Embedded Resource: https://youtu.be/68mH0VsjV4M

As you can see, if you are playing with the Test Explorer, you can run or debug all the tests or a specific one. The same approach exists for groups of tests too, so you can run or debug a bunch of tests in the same describe.

Ok, I spent an entire article showing you how you can run or debug tests using VsCode because many times I see people that don't know how to debug, and they spend a lot of time finding the problem and fixing the test. Now you have all the tools to debug your tests with Playwright, so you can check and fix tests quickly.

That's it for today; you have learnt how to run and debug tests with Playwright; before using the Playwright inspector and then directly from VsCode.
I hope you enjoy this content, and if you have any questions, don't hesitate to reach out to me.

See you soon, folk

Bye bye

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - How to write tests

Wed, 14 Dec 2022 00:00:00 GMT

What are you going to learn in this post?

In this post, you will learn how to write tests with Playwright, using assertions, locators and something else.

Write tests

Let's start with an example

test('the first player must be the "X" player', async ({ page }) => {
  await page.goto("/");

  const playerParagraph = await page.getByRole("paragraph");

  await expect(playerParagraph).toContainText("X");
});

In this example, I introduced two new stuff, getByRole and toContainText.
getByRole is part of the locators and toContainText is part of the assertions, and now we will dive into these new things.

Locators

Locators are the central piece of Playwright's auto-waiting and retry-ability. Locators represent a way to find element(s) on the page at any moment.

Using locators, you can retrieve elements in your dom by these commands:

page.getByRole(role[, options]) to locate by explicit and implicit accessibility attributes.
page.getByText(text[, options]) to locate by text content.
page.getByLabel(text[, options]) to locate a form control by associated label's text.
page.getByPlaceholder(text[, options]) to locate an input by placeholder.
page.getByAltText(text[, options]) to locate an element, usually image, by its text alternative.
page.getByTitle(text[, options]) to locate an element by its title attribute.
page.getByTestId(testId) to locate an element based on its data-testid attribute (other attributes can be configured).
page.locator(selector) to locate an element base on its selected (Css or XPath)

As you can see, using these eight commands, you can find all the elements on your pages. Watching the previous example, you can view how using the getByRole method you can get the paragraph in your DOM and then check whatever you want. Okay, so a quick recap of what locators are: locators are methods that help you to search the elements in the DOM.

Assertions

Like any test framework that is respected, Playwright has its assertions. Assertions are used to check our results, and as developers, we use them to be sure the application or the code runs as expected. Playwright for this feature uses under the hood the expect function built by jest. So if you are familiar with jest, you won't have problems with Playwright. The most famous assertions that you can use are: toEqual, toContain, toMatch, toBe and many more. The assertions are your best friends to check if your application runs as expected.

As you can imagine, the combination of these two things permits you to build many tests to check the behaviours of your application.

So if you go back to the previous example and type npm run e2e in your terminal, you get the following result.

 npm run e2e

> react-e2e@0.0.0 e2e
> playwright test

Running 6 tests using 4 workers

  6 passed (5s)

Wow, it works. 😀 And now you know what to use to create your tests with Playwright.

Isolate your tests

If you are familiar with testing frameworks, you probably know there is a way to group a test list. To do that with Playwright, you have to use the describe method exposed by the test object, as in the following example.

import { expect, test } from "@playwright/test";

test.describe("On View", () => {
  test("show tic tac toe page", async ({ page }) => {
    await page.goto("/");

    await expect(page).toHaveTitle("Tic Tac Toe");
  });

  test('the first player must be the "X" player', async ({ page }) => {
    await page.goto("/");

    const playerParagraph = await page.getByRole("paragraph");

    await expect(playerParagraph).toContainText("X");
  });
});

The benefit of grouping is also visible in the report that now appears so.

As you can see, the label On View is present before each test.
So now, you can split your test file into different contexts if you have this need.

Hooks

Another critical feature if you love working with test frameworks is hooks.
Hooks allow you to run a piece of code before or after the test execution. Typically they are called: beforeEach beforeAll afterEach afterAll and you know what they are called in Playwright? Precisely in the same way 🚀

So, to give an example, you can refactor the code in this way to navigate the home page before each test.

import { expect, test } from "@playwright/test";

test.describe("On View", () => {
  test.beforeEach(async ({ page }) => {
    await page.goto("/");
  });

  test("show tic tac toe page", async ({ page }) => {
    await expect(page).toHaveTitle("Tic Tac Toe");
  });

  test('the first player must be the "X" player', async ({ page }) => {
    const playerParagraph = await page.getByRole("paragraph");

    await expect(playerParagraph).toContainText("X");
  });
});

The result is the same as before, but now you only have the navigation command inside the beforeEach hook.
These hooks are great if you have to mock API or if you have to do something before or after tests.

Play with your DOM

After all these things, it's time to write the last test of this post.
Now you will write a test that simulates the user's behaviours in the applications. The test simulates the click of the player "X" in the top left square and then checks if the next player is the "O".

test.describe("Users behaviours", () => {
  test.beforeEach(async ({ page }) => {
    await page.goto("/");
  });

  test('the first player select the top-left square and then the next player is the "O"', async ({
    page,
  }) => {
    const squares = await page.getByRole("button");

    const topLeftSquare = squares.first();
    await topLeftSquare.click();
    const topLeftSquareImg = await topLeftSquare.getByRole("img");

    await expect(topLeftSquareImg).toHaveAttribute("title", "X");
    await expect(topLeftSquareImg).toHaveAttribute("src", /x.png/i);

    const playerParagraph = await page.getByRole("paragraph");

    await expect(playerParagraph).toContainText("O");
  });
});

This example starts to become trickier. As you can notice, there are some new things. Let's start with the first one, the first method. In this case, the getByRole returns many elements, and only the first is required in the test. Using the first method, you can get the first element in the list.
Then when you have the first square on the board, you can simulate the click of this element by the user. Using the click method, you can do that. Easy peasy lemon squeezy. But now things start to become "complex". As you can see, now you can use the getByRole from the square element, and the method tries to find an image child of this element. After that, using toHaveAttribute assertion, you check if this image has a title with the "X" value and if the source contains the value "x.png". The final step is the same as in the previous post, where you get the paragraph and check if the next player is now the "O" player. Ok, it's not rocket science but a bit more complicated than the previous example.

Conclusion

Ok, I think you have materials to study for now! 😃
So, what you have learned in this post:

Locators
Assertions
How to isolate your test
Hooks
I suggest you get your hand dirty with these topics because they will be the fundamentals of your test with Playwright.

Ok, that's all folk, see you soon.
Bye Bye 👋

P.s. you can find the result of this post at this in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Playwright - Let's start

Wed, 07 Dec 2022 00:00:00 GMT

In the last period, in the frontend ecosystem, a new e2e tool has come up and it has started to become famous; its name is Playwright. In this short series, I want to leave you with some information on this and tips on how to get started.

What is it?

Let's start with what Playwright is. Playwright is a testing framework to handle e2e testing. With Playwright we can write e2e tests and run them in different browsers, like Chrome, Firefox and Webkit. We can run our tests on many platforms like Windows, Mac, Linux or CI, and we can write tests in Typescript, Javascript, Java, Phyton or .Net.

If you open the official website, you can find these characteristics:

Any browser Any platform One API
Resilient No flaky tests
No trade-offs No limits
Full isolation Fast execution
Powerful Tooling

In my opinion, the tool reflects all of these characteristics.

TicTacToe application

I want to use a TicTacToe application built with vite + react in this series. And you can find it in the GitHub repository.

As you can see, the application is straightforward, but with it, we can start to move to the first steps with Playwright.

Install Playwright

The first step to use Playwright is installing it, that is easy. Open your terminal and type npm init playwright@latest (I use npm but if you want to use yarn or pnpm read the docs). Ok, now the installation asks you some questions:

Where to put your end-to-end tests? The default option is tests but I prefer to use the folder e2e.
Add a GitHub Actions workflow? The default option is false; in this demo, I leave this option to false for now.
Install Playwright browsers (can be done manually via 'npx playwright install')? The default option is true, and I used this value

and now you have to wait until the installation ends. When the installation is completed... congratulation, you are ready to get your hands dirty with Playwright!

First Look

The installation created in your repository 3 new files:

playwright.config.ts
e2e/example.spec.ts
tests-examples/demo-todo-app.spec.ts

Let's start with the last one, the easiest 😊 This file contains a list of examples of how you can write tests with Playwright. It uses an application created by the playwright team (a simple to-do app) and illustrates how you can interact with your page.

Carrying on with the second one. This file is a quick example of some tests on the playwright website, but it's here only as a placeholder for your tests.

And now, the first one, the most important. Playwright uses the playwright.config.ts file to understand its configuration. Inside it, you can find configurations about the test folder, the timeout used by the expect function, the configurations for the browsers used by Playwright to run the tests, and more.

Run your first test

It's time to see Playwright in action, so open your terminal again and run the following command npx playwright test. The result is something like this

Playwright in this report shows you the result of its execution, and you can check if everything has gone ok. The report shows the result for each browser indicated in the configuration, in this case: Chromium, Firefox and Webkit.

Write your first test

Ok cool, but now it's time for you to write your first test with Playwright. Before doing this, you have to configure Playwright to be able to run your application before starting with the tests. To do that, you have to open the playwright.config.ts and add the following configuration

const config: PlaywrightTestConfig = {
  ...
  webServer: {
    command: "npm run dev",
    port: 5173,
  },
  ...
};

N.B. check your port running the command npm run dev you have to use the same port exposed by vite.

And now it's time for your first test. Open the file e2e/example.spec.ts and rename it to e2e/tit-tac-toe.spec.ts. Then clean everything in the file and leave only the import line import { expect, test } from "@playwright/test";.

Now add your first test

test("show tic tac toe page", async ({ page }) => {
  await page.goto("/");

  await expect(page).toHaveTitle("Tic Tac Toe");
});

ok, let's see this test together. First of all, you can indicate to Playwright that it is a test using the test function. As in every testing framework, the test function's first param is the test's name. The second param is the function to test our application. Using Playwright, this function is always an async function because your tests in these cases are always asynchronous. The first command in this example is a command to say to Playwright to navigate to the home page of our application. As you can see, already this command is async. Now, if the test can navigate to this page, you want to test if the title of the page is "Tic Tac Toe". Yes, it's elementary, but an excellent example of moving your first step.

Now, it's time to check if the test runs in Playwright, but before doing that, you can simplify the interaction with Playwright by adding a new script in the package.json, as shown here

   ....
   "scripts": {
    ...
    "e2e": "playwright test"
  },

now in your terminal you can type npm run e2e and voila, your test is gone

Adding another script in your package.json, you can open the report result in your browser

   ....
   "scripts": {
    ...
    "e2e": "playwright test",
    "e2e:report": "playwright show-report"
  },

And now, if you run the command npm run e2e:report in your browser, you can see the result of your first test.

Ok, I think that's all for now. In this post, you learnt:

How to install Playwright
How to run your test
How to write your first test with Playwright

In the next post, we will continue our journey in the Playwright world, but for now, that's all! See you soon, folks.

Bye Bye

p.s. You can find the result of this post at this in the GitHub repository

🎬 Watch / View Embedded Resource: https://dev.to/puppo

Be aware of your codebase with Nx

Tue, 29 Nov 2022 00:00:00 GMT

Preface

Is your team aware of the relations between your modules? Is a team member able to understand what is affected by the changes in a new feature quickly? Probably your answer is: it depends. It depends on the team member and on the time that this team member is on the project. But today I want to show you how you can make your team more confident in your codebase regardless of the seniority or the time he or she is in the project.

The problem

Imagine a typical first onboarding day in your company. Probably after the introduction and some hours with the HR team the new colleague starts the onboarding stage with a technical team member. The first thing shown is a demo of the software so they start to understand the business value of the project. After that or its coffee break time or its time to see the codebase. After the project's checkout, your new colleague and you will open the project in your editor or IDE and the first impact with the codebase for your newbie could be like this:

And now you start to illustrate how the codebase is structured for each folder. Yes, if you are on the project for a while you know much of the code but for your new colleague understanding and remembering all this stuff quickly is not simple. They also want to see which modules are connected and how, but you dont have a tool to see this information quickly. So you will be forced to open many files to know where the imports are, but for your new colleague, these actions will result in tedious unintelligible steps and will not leave the correct information in their mind.

But is there a way to improve this situation and help the newbie and the boomer of your project to have a picture of the project and get this info quickly anytime?

A better onboarding day

Ok, your onboarding day could probably be better, and your new colleague could be more confident about the project after the first day. Do you know that a picture is better than thousand words for your mind? Do you know that your mind remembers images better than words? Therefore, what if the first impression of the project for your new colleague could be like this?

The newbies will be grateful because they have a big picture of the project and by themselves, they can understand the relations in the codebase. But the surprises are not finished; if you click with the mouse on the relation's arrows, it's possible to see which file creates the connection between the modules, is it not cool?

Ok, fantastic, but now you are wondering "How can I do that?" Beah, it's simple, using Nx.

What is Nx?

Nx is a Smart , Fast , Extensible build System.

Nx is a tool built by Nrwl that allows teams to handle their projects in a great way. One of the goals of Nx is to improve the DevX of teams that work using Monorepo. Nx exposes out-of-the-box for testing: jest, storybook and cypress. Instead, Eslint and Prettier are already configurated to work with the code style. About frameworks, Nx is able to work in the same workspace with React, Angular, WebComponent, and NextJs on the frontend side and with Express, Fastify and NestJS on the backend side. The nrwl team officially maintains these frameworks, but it is also possible to use Nx with other languages or frameworks thanks to the plugins created by the community. Cool!! But Nx doesnt stop here its potential. Nx has an excellent feature called Nx Graph, available by a web application or the Nx Console (an extension created by the nrwl team that works both in VsCode and WebStorm). But lets deepen into Nx Graph.

Nx Graph

Nx Graph is a web application that shows the tree of your workspace and allows the team to see the state of the codebase. Using the Nx Graph is very simple to check the relations between the modules, and its easy to check the paths between two modules. But Nx doesnt end its power here because it is also able to understand what is changed in your feature branch and detects what is affected by these changes. In these cases, the Nx Graph highlights modules affected by the changes, so you and your team can visualize what could be impacted.

Nx under the hood uses this information to improve tasks like building and testing. Yes, you read well, it uses this info to enhance the tasks, so Nx is able to build and test only the modules affected by the changes. As you can understand, if your project snowballs, the build and the test time dont increase drastically.

Not only for onboarding days

The benefits of using Nx are not only during the onboarding days. Using the Nx Graph, your team can see in less time how the project has changed over time or check how the project is growing up. Using Nx is also possible to create rules to prevent relations between modules or tagging modules to develop rules around these tags, but this is another story that we will discover in future.

Okay, for today, that's all. I hope you understood this tool's power and that now you are curious about it. If so, visit the Nx site and start to take your first steps. If you are curious about the Nx Graph, I suggest you to watch this video by juri.

See you soon with other posts about Nx.

Bye bye

Working with GitHub Actions from your best editor

Tue, 08 Nov 2022 00:00:00 GMT

Hi folks,
today I'm going to speak about another cool VsCode Extension.

In many projects, I love using GitHub Actions as CI/CD tool, but switching between VsCode and the GitHub website is very boring and frustrating. So, one day I decided to google if there was a way to follow my actions directly in my best Editor, and some minutes later I found this fantastic extension: GitHub Actions. This extension and that seen in the previous article have changed my way of working, and now I'm almost free from the browser during my coding phase. I say almost because sometimes I have to check my email or scroll the Twitter wall to stay updated and get the last news 🙂 But let's see together what this extension is able to do 🚀

Installation

As with any other extensions, the installation is a piece of cake, you have to open the extensions tab and in the search box you can type GitHub Actions. There are many extensions with this name but you have to choose the extension created by Christopher Schleiden, after that, press the install button and wait until the process is ended.

Getting started

After the installation, the extension asks you to sign in with your GitHub account, so it will be able to read the status of your GitHub Actions.

Okay, press the "Allow" button, enter your GitHub credentials in the browser and follow the instructions to permit VsCode to get the access token for your extension.

After that, the extension is ready to visualize your actions.

There are 3 main sections to use this extension:

The icon to open the extension
The current branch section, where we can see all the actions about our current branch
The Workflows section, where we can see all our workflows and monitor their execution over time

Run and Watch your Workflow

To see the extension in action you have to push your commits into your repository as usual and when the action starts, you can follow its status directly from your Editor, without moving in your browser. Here is a demo.

As shown in the demo, you can see the status of the action, and for each status, there is a specific icon that represents the state. You are also able to watch the logs by clicking the step of your interest.

Unfortunately, sometimes opening the browser to see the action on the Github website is necessary, and to do that, there is a fantastic button that opens the browser directly to the action page.

Conclusion

Okay, I hope we had a short but exhaustive trip into this beautiful extension. I hope the combo of this extension with the GitHub Pull Requests and Issues extension improves your daily work and I hope they could be useful for you too. If you know other's extensions or you prefer others let me know, I'm curious and open to trying different extensions, especially if they improve my productivity.

See you soon with other tricks for our best editor (VsCode) :)

p.s. if you are interested in helping the VsCode team use the Insider version and test the new features before their release. In this way, you can help the team to release a better stable version

p.s.s. if you want to get your hands dirty, you can also contribute to making VsCode better, by implementing new features or fixing bugs. if you are interested in that but don't know where to start, watch this video

Working with Github from your best editor

Thu, 03 Nov 2022 00:00:00 GMT

In my daily work routine, many times I have to switch from VsCode and Github to create a PR, review a PR, check a GitHub Action, and more.

Therefore I have decided to google if there is a solution to prevent all these switches. The result of my search terminated with 2 new VsCode Extensions:

Today I'll speak a bit about the first one, and the second will be discovered in another article.

GitHub Pull Requests and Issues

This extension is an official extension created by the GitHub team. This extension allows you to do whatever you want if you are working with a PR and Issues. You can:

Create PR
Edit PR
Delete PR
Review PR
See all PR
Create Issue
Delete Issue
Edit Issue
See all Issues

As you can imagine, in our daily work if we are familiar with PRs and we work well with them, creating, editing, or reviewing PRs is a common practice.

So let's see better how this extension works.

Installation

Obviously, to install this extension we have to pass by the VsCode MarketPlace. Click the extension button in VsCode menu and in the search bar type "GitHub Pull Requests and Issues". When the search is finished, click the install button on the right, wait some seconds, and voila the extension is installed.

Login

It's going without saying that we have to sign in with our credentials to work with GitHub. To do that we have to open the extension and click the SignIn button that appears. After that VsCode asks you permission to open a new browser window to allow you to type your credentials, and at the end a popup browser asks you the permission to reopen VsCode with your credentials so you can begin to use our extensions. Now we are ready to use the extensions.

First Impression

When you are logged the extension shows you two sections:

Pull Request
Issues

its obvious that each section handles its topic.

PR

To create your first PR you have to click the icon in the top right of the PR section.

After that, the extension opens a new window where you can input the data of your PR:

From branch
To branch
Title
Description

Now, if you work using the review feature, you can add your review/s to your PR and if you want you can edit your PR too, or you can also add labels or milestones.

In the extension panel, under the PR section, you can find your PR and view or edit it if it is necessary.

If you select your PR, you can see all the changed files by the PR, and if you want to add some comments you can do that in the file directly.

It is awesome, innit?

The flow for your Issues is very similar to the PR flow and in my case doing these kind of stuffs direct in my editor is very useful because Im able to handle my projects direct in VsCode without switching every time from the editor to the browser and vice-versa.

Okay, I hope I stimulated your curiosity so what are you waiting for? Open your VsCode and try this fantastic extension. Let me know your impressions and if you wanna other info dont hesitate to ask me anything, you are welcome and for me its a pleasure to help you.

Thats all today folks.

See you soon to speak about the second extension GitHub Actions.

Bye bye

Validate your data with Zod

Mon, 31 Oct 2022 00:00:00 GMT

Preface

Many developers don't know very well which is the line between Javascript and Typescript. Probably, many of them waste much time understanding that if they write an interface like that:

interface User {
  id: number;
  username: string;
  age: number;
}

Typescript doesn't guarantee that the age field is really a number. And probably if they have an API that returns a list of users and they have to calculate the average ages of these users, the result will not appear as expected, if the API returns the age as string. This is because Typescript disappears after the build process and the type system goes away. This is one of the biggest problems that I face every day in the project where I work, especially in the frontend applications, many developers don't have the perception of this matter. Let me explain better it. First of all, I love Typescript and I work with it every day, but I also know what are its limitations. So, guaranteeing the type system at runtime is not its job, and we have to find a solution, but which is the solution? The solution is Javascript! Javascript doesn't disappear at runtime, and fortunately, it exists also at build time, therefore Javascript is our Volta key for our solution.

Lets start from here: what are the most vulnerable layers in our applications when Typescript disappears? The most vulnerable layers are those that receive data from outside of the application, the ports of our applications in a nutshell. These layers must protect our application from mistakes, and they are our safety to validate and check if the data received are exactly like we aspected. To do that we have to introduce something that converts our typescript definitions to functions that can validate our data so that we are sure that the data format is what we expect.

This check can be done with different libraries like: io-ts, typebox, or zod. These libraries allow you to create objects that represent your typescript definitions. Then, these objects can be used at runtime to validate the received data, in addition, you can also convert this object to a Typescript definition to have all the benefits of using typescript. These objects can be called schema validations because they are responsible for the data validation.

But stop wasting time and let's go deep into how zod works.

Zod

To use Zod, you simply have to install it using npm, yarn, pnpm. After that you have to create your first Zod type, as an example, we'll use the same type seen before, so, the User type can look like that:

import { z } from "zod";

export const User = z.object({
  id: z.number(),
  name: z.string(),
  age: z.number(),
});

As you can notice, we have to import Zod, and using it we can create our validation schema. This new object contains the rules to validate our data at runtime. But the Zod's magic doesn't stop here. With Zod, we can also extract the relative typescript definition in this way

export type User = z.infer<typeof User>;

Now let's go ahead and let's see how we can use this object to validate our data. We have an API that returns a user at the endpoint /users/1 and the response can be

{
  "id": 1,
  "name": "Chance",
  "age": 80
}

In this case, we can use the fetch API to call our endpoint and the result could be something like that

const user = await fetch("http://localhost:3001/users/1")
    .then(response => response.json())
    .then(json => User.parse(json));

if you look at this code probably you won't notice anything strange but if you take a look at this screen

you can see how typescript is able to detect the user's type, and this is possible thanks to Zod. And to leave you another proof, if I add the type to the user variable, typescript doesn't give errors because the type is the same.

Zod exposes to us two different ways to validate our objects:

parse, parseAsync
safeParse, safeParseAsync The firsts are assert function, therefore if the validation fails the method throws an exception. Instead, the seconds return a type guard composed like this

type SafeParseReturnType<Input, Output> = {
  success: true;
  data: Output;
} | {
  success: false;
  error: ZodError<Input>;
}

In this case, we have to check the success field to understand if the validation is successful or failed. And if the result is positive we have a property data that contains the object with the right type, otherwise, we have a property called error that contains an object with all the validation errors.

At this point, let's go a little bit deepen. Now we can create a little HTTP module that helps us to be confident of the result get by the API. To do that, we can wrap the fetch API, and using the power of the generic type we can create a method like that:

import { z, ZodType } from "zod";

export function get<Schema extends ZodType>(
  url: string,
  schema: Schema
): Promise<z.infer<Schema>> {
  return fetch(url)
    .then(response => response.json())
    .then(json => schema.parse(json));
}

and it can be used like this

As you can see, now using the get method we can do an HTTP get and check if the result is as expected. This is very important in our applications because by doing that we protect our application from strange mistakes and we are confident that our codebase after this layer receives the data exactly as we expected at build time. It goes without saying that if there is a bug after this layer, this is a problem of our code base and not a bug due to incongruous data.

Now using this pattern we can keep alive our typescript definitions at runtime too and we can prevent mistakes relative to incongruous data. Using this pattern moreover, we can consider all the assumptions done during the development mode correct at runtime too, where typescript disappears.

I know this layer can be considered too much sometimes, but I think every important application must have it. I want to leave you with this simple consideration, a time ago, a backend developer said to me: "Don't trust the Frontend" but now, as a Frontend developer I say to you "Don't trust the Backend either".

The code of that article can be found in the GitHub repository

Visual Studio Code - Tips & Tricks - Snippets

Mon, 21 Mar 2022 00:00:00 GMT

If you used to adopt Visual Studio in the past probably you already know something about Snippets. This feature exists out-of-the-box in VsCode too. If you open a javascript file or a typescript file and you type log and after you press TAB you get this result.

In VsCode there are many others snippets already implemented out-of-the-box but the VsCode's team doesn't stop here. VsCode enables you to create your own snippets, or import them from the extensions. But that's not all, you can create your own snippets available in all your projects, or create snippets for a specific project and accessible by all the team of that project. After all these words, let's see how the snippets work and how you can create your own snippets. First of all, to create a new snippet you have to open the Command Palette, type "Configure User snippets" and press ENTER. After that VsCode suggests you some options, two of these are:

New Global snippets file...
New Snippets file for 'name of your project'...

Chose your preference and press ENTER again, type the name of your snippet, and press ENTER for the last time. Voila, your first snippet configuration becomes reality.

As you see, you can choose between two types of configuration: Global snippet and Project snippets. It goes without saying that the first one creates a snippet file accessible only by you, the second one instead is accessible by all the project team if you commit the file in the repository. Based on the choice, VsCode creates the snippet file in two different folders. The global snippets are saved in this path Code/User/snippets/{snippet-name}.code-snippets and the Code folder is different in base of your platform:

Windows %APPDATA%\Code\User\
macOS $HOME/Library/Application\ Support/Code/User/
Linux $HOME/.config/Code/User/

you can find more about that configuration in this reference

Instead, the project snippets are saved inside of the .vscode folder in the project's root and the snippet file has this form {snippet-name}.code-snippets.

Apart from this difference between the two choices, after the creation stream VsCode create for file for you with this content

{
	// Place your global snippets here. Each snippet is defined under a snippet name and has a scope, prefix, body and 
	// description. Add comma separated ids of the languages where the snippet is applicable in the scope field. If scope 
	// is left empty or omitted, the snippet gets applied to all languages. The prefix is what is 
	// used to trigger the snippet and the body will be expanded and inserted. Possible variables are: 
	// $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. 
	// Placeholders with the same ids are connected.
	// Example:
	// "Print to console": {
	// 	"scope": "javascript,typescript",
	// 	"prefix": "log",
	// 	"body": [
	// 		"console.log('$1');",
	// 		"$2"
	// 	],
	// 	"description": "Log output to console"
	// }
}

This is an example of a snippet, particularly this example is the log snippet seen at the beginning of this article.

But let's go ahead and create a snippet to generate a fetch request.

{
  "Fetch Request": {
    "scope": "javascript,typescript",
    "prefix": "fetch",
    "body": [
      "fetch(\"$1\")",
      "	.then(response => response.json())",
      "	.then(data => $2)",
      "	.catch(error => console.error(error));"
    ],
    "description": "Fetch request"
  }
}

First of all let's see this snippet at work

As you can tell, typing fetch and pressing ENTER or TAB, VsCode inserts the code of the snippet in the file. But let's take a look at how the snippet file is composed. First and foremost, the snippet file is a JSON file. The first thing to do is to give a name of the snippet, in this case, Fetch Request and this is the property that identifies the snippet inside of this file. By here, you have to describe your snippet. The first property described is the scope, this property identifies the language relative to this snippet, in this case, the snippet is written for javascript and typescript (if you don't indicate this property your snippet appears in all the files). The prefix property identifies the word to type to find the snippet in the VsCode's IntelliSense, fetch for this example. The description property is used to describe the reason why of the snippet. The body property instead is the code generated by the snippet. As you can see, this property is an array, where every item is a row of the generated code. There are two "strange" symbols used inside of the body: $1 and $2. This particular syntax helps VsCode to understand that in this snippet the user has to indicate 2 things, the fetch's URL and the function to manipulate the fetch result. To jump between the parameters during the filling in the editor you have to use the TAB. As you can tell, it's not so difficult to create your snippets, but let's see another case to example other possibilities exposed by VsCode. In this example, the snippet creates a React Function component with the FC type and Props.

{
  "React Functional Component with Props": {
    "scope": "typescriptreact",
    "prefix": "rfcpt",
    "body": [
      "import { FC } from 'react'",
      "",
      "type ${1:$TM_FILENAME_BASE}Props = {",
      "  $2",
      "}",
      "",
      "const ${1:$TM_FILENAME_BASE}: FC<${1:$TM_FILENAME_BASE}Props> = (props) => {",
      "  return <>$3</>",
      "}",
      "",
      "export default ${1:$TM_FILENAME_BASE};"
    ],
    "description": "React.FC component with Props in TypeScript"
  }
}

In this example, one parameter has a special syntax ${1:$TM_FILENAME_BASE}, which indicates that the first parameter will be compiled only with the name of the file when the snippet appears but the user can edit it if necessary. There are many other special variables that you can indicate at VsCode to pre-fill a parameter and you can find all the possibilities in this reference.

You can indicate multiple snippets inside of a single file. To do that you have to create another section in your file starting from the name and filling this section with the info about another snippet. in the GitHub repository an example.

This feature is widely used in extensions, and you can find many extensions that create for you snippets, for instance: Angular Snippets, ES7+ React/Redux/React-Native snippets...

Now you know all the notions to create your snippets if it will be necessary. This feature often helps me to generate automatically the structure of some particular repeatable component in the application, for instance, a react component or an angular component or other things like these. I hope this feature can help you too to save time on writing repeatable code.

That's all from the snippets guys! Bye Bye! 👋

N.B. you can find the code relatives of this article in the GitHub repository

Visual Studio Code - Tips & Tricks - Command Palette and its friends

Mon, 21 Feb 2022 00:00:00 GMT

Visual Studio Code is one of the best code editors in this moment. Its Palette has many features but probably not all devs know them. Let’s look at the most important, to improve your productivity and use less the mouse.

Command Palette

The Command Palette is the bar that shows up when you use the short-cut ⇧+⌘+P (on window Ctrl+Shift+P).

This Palette enables you to run commands. Which commands? That depends. VsCode already has many commands out-off the box, like: save file, format file, git commands and many others. But Vscode doesn't end its power here. It allows you to create new ones, and see them in this list of possibile commands. More extensions use this feature to expose their commands and enable their features. The commands typically are grouped by topic, for instance, all the commands that work with the terminal have the prefix Terminal, those that work with git have the prefix Git and so on. This "rule" is a common best practice to improve the search of the commands.

It's important to remember that this Palette is working with the command if its first character is >. This char indicates you that the palette is in command mode.

It goes without saying that for some commands this flow can be a bit boring, but don't worry, the VsCode team took care about that too, they allow us to create short-cuts that run your commands. But we'll see that in another post.

Search Files and Symbols

If you use the short-cut ⌘+P (on window Ctrl+P) the Palette that appears has a different goal. In this case, it's ready to work with the files, or better, it's ready to search your files or to search inside of them.

By default when this palette appears it is ready to work with the current opened file, but you can also work with other files. Let's start with the commands to work in the current file.

Go to Line and Column Using the character : VsCode is ready to go to a line of the file, for example if you type :39 and you press ENTER, VsCode puts the cursor and focuses at the begin of the line 39. If you know the column of the line, you can indicate it too by adding another : and VsCode sets the focus to the column in the chosen line. For instance :39:3 corresponds to the line 39 at the column 3.
Search Symbols Using the character @ VsCode is ready to search methods, properties, classes, interfaces inside of the current file. As you can see, when you type the character @ VsCode tries to help you and it suggests you all the symbols in the file. That helps you to search the symbols and prevent infinitive searches using the scroll.

Now let's move on and see how to search files.

Search Files The easy pease way to search a file in VsCode is using the short-cut ⌘+P (on window Ctrl+P), type its name and press ENTER when you find it. This search works on the entire project.

But sometimes it can be necessary to search only inside of a folder. To make this, you need to start the search with the name of the folder flow by the char / and after that the name of the file.

But this method enables the search only in the first level of this folder and excludes all the subfolders. Thus the VsCode team took care about that too and by using the char * you can create a power condition to search your files. This char can be used either lonely or combined with another *. If you use the combination, it indicates that you want search both in that folder and in its subfolders. Instead if it is used alone you indicate that the search is only inside of the folder. Let's look at some examples to better understand this.

/src/**/File.ts In this case you want to search all the files called File.ts inside of the folder src and in its subfolders (***).
/src/***/components/Button.ts In this case you want to search all the files Button.ts inside of the folder src that it's placed inside of a subfolder called components.
/src/***/.ts In this case you want to search all the files with extension .ts inside of the folder src and in all its subfolder.

As you can see, combining the char * in different ways you can create a power search term.

I hope these notions could improve you daily work with VsCode.

That's all Guys.

Bye Bye 👋

Typescript - (ReadOnly)NotEmptyArray

Mon, 14 Feb 2022 00:00:00 GMT

Arrays are already well described in typescript, but sometimes we need to be more strict with our types. For instance, we need to have a not empty array. This type doesn't exist in the typescript definitions, but we can create it in this way.

type NotEmptyArray<T> = [T, ...T[]];

This type inherits all the characteristics of the array type and it adds another rule to it. This array must have at least one item. It can be used thus

const array: NotEmptyArray<number> = [1];

If you try to use it without any elements, typescript gives you an error, and it says us that a NotEmptyArray must have at least one element.

But this type could create some problems. If you use the arrays' methods that remove elements, you could have errors, because the arrays could become empty. To avoid this issue, we can work with read-only arrays that can be defined thus.

type ReadOnlyNotEmptyArray<T> = Readonly<NotEmptyArray<T>>;

This type prevents all the arrays' mutations so we can work with arrays with confidence.

The last point that I want to let you is how to convert an Array to a NotEmptyArray. To do that we need to create a type guard function. This function can be done in this way.

function isNotEmptyArray<T>(as: T[]): as is NotEmptyArray<T> {
  return as.length > 0;
}

Therefore you can check if an array has at least an element and if it respects this rule it's a NotEmptyArray.

I created a GitHub Gist with this code if you need it.

https://gist.github.com/Puppo/bc5287d32dbfeeba9f14862654cece9d

That's all, I hope it can be helpful in your daily work.

Bye Bye Guys 👋

It's Prisma Time - Seeding

Fri, 04 Feb 2022 00:00:00 GMT

Hello Folks 👋 Today we'll see how to handle seed with Prisma.

Seeding allows you to re-create consistently the same data in your database and it can be used to:

Populate your database with data that is required for your application to start - for example, a default language or a default currency.
Provide basic data for validating and using your application in a development environment. This is particularly useful if you are using Prisma Migrate, which sometimes requires to reset your development database.

Prisma exposes this feature out of the box. Creating a seed is not so difficult and now we'll see how to do it.

The first step is to create a file that contains our seeds. In this case we are creating the file index.ts inside of the folder prisma/seed. Now, we want that someone executes this file every time. Its code adds inside of the authors table a special author called "Super Admin". The contents of this file therefore could be so

import { PrismaClient } from "@prisma/client";

const run = async () => {
  const prisma = new PrismaClient();
  try {
    if ((await prisma.author.count()) === 0) {
      await prisma.author.create({
        data: {
          givenName: "Super",
          familyName: "Admin",
          age: 100,
        },
      });
    } else {
      console.log("Default author already created");
    }
  } finally {
    await prisma.$disconnect();
  }
};

run();

As you can notice, it's not so difficult to understand the code. We create a connection to the database and check if the author table is empty. If so, we add the "Super Admin" author. Now we have the file and it's time to execute it. Prisma is configurable to accept an instruction that can execute this code, and to do that we need to update our package.json file. The configuration is easy and we can instruct prisma in this way

...
"prisma": {
  "seed": "ts-node prisma/seed"
},
...

These three lines of code indicate to Prisma that we want to handle its seed command. When this command is executed the system uses the ts-node tool to build and execute the file prisma/seed/index.ts. But Prisma doesn't stop its work here. It executes this command after the migrate command too. Thus now we can execute this command

npx prisma migrate dev

As you can see, Prisma executes the migration and our seed file. As a double check, we can update our src/index.ts in this way

import { PrismaClient } from "@prisma/client";

async function main() {
  const prisma = new PrismaClient();
  try {
    const authors = await prisma.author.findMany();
    console.table(authors);
  } catch (error) {
    console.error(error);
    throw error;
  } finally {
    await prisma.$disconnect();
  }
}
main();

and after that run the command

npm run dev

the result will seem like this

Our database is ready with all migrations and our seeds. Now, I think you have all the notions to work with confidence with Prisma, so it's time to let you go for your steps. This is the last post of this series folks. I hope my posts helped you to view better this fantastic tool, surely they helped me a lot to understand it better. So, I hope Prisma can be your friend in your daily work and it can help you to work in the right way with our databases.

Before leaving you I wanted to thank the Prisma team for these fantastic swags.

And This is Learning for letting me publish this content in its space. I know, I could do more for you but I promise that in the next future the time to do something live will arrive too (I apologize for my bad English spoken😅). Thanks again This is Learning.

Now it's really time to leave you. I hope you'll miss this Prisma time, but now it's your prisma time. Get those keyboards ready and let's code!

Bye Bye Guys 👋

See you soon with new contents!

The code of this article is published in the GitHub repository

It's Prisma Time - Migrations

Wed, 02 Feb 2022 00:00:00 GMT

Hello Guys 👋, Today it's time to speak about migrations.

Migrations in Prisma are managed by Prisma Migrate. Prisma Migrate is an imperative database schema migration tool that enables you to:

Keep your database schema in sync with your Prisma schema as it evolves and
Maintain existing data in your database

To see how it works, today we'll recreate all the schema used in this series, so let's started.

First migration

Before creating our first migration, we need to create our schema, thus in the prisma/schema.prisma we will create the entities: Post, Author and AuthorsOnPost. To do that, we need to add in prisma/schema.prisma this code.

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model Post {
  id        Int @id @default(autoincrement())
  title     String
  content   String
  published Boolean  @default(false)
  createAt  DateTime @default(now())
  updatedAt DateTime @updatedAt

  authors   AuthorsOnPost[]

  @@map("posts")
}

model Author {
  id        Int @id @default(autoincrement())
  firstName String
  lastName  String
  age       Int
  posts     AuthorsOnPost[]

  @@map("authors")
}

model AuthorsOnPost {
  author    Author @relation(fields: [authorId], references: [id])
  authorId  Int
  post      Post @relation(fields: [postId], references: [id])
  postId    Int

  @@id([authorId, postId])
  @@map("authors_on_post")
}

Once this is done, we can generate our first migration using this command

npx prisma migrate dev

This command generates our first migration for us. If you take a look at your project, you can notice that you have a new folder called migration inside the Prisma folder. Inside this folder, there is another folder whose name is the timestamp of when you have executed the migration command. The format is YYYYmmDDhhMMss. If you open this folder, you find a file called migration.sql, where you can see inside the scripts to generate the schema of your database. In this case, in this file, there are 3 CREATE TABLE commands, each for every entity (Author, Post, AuthorsOnPost). Prisma allows us to indicate migration's name too by using the --name option. Therefore the previous command could be executed in this way

npx prisma migrate dev --name create_post_and_author_entities

By doing that, the migration's folder adds to its name this name immediately after the timestamp. Thus we have a migration with info about what it does.

Important When we run the migrate command, Prisma updates our local database too.

Second migration

Now we want to add the Comment entity to our schema. First of all we have to create it in the Prisma Schema adding this code in the prisma/schema.prisma file

model Comment {
  id        Int @id @default(autoincrement())
  text      String
  post      Post @relation(fields: [postId], references: [id], onDelete: NoAction, onUpdate: Cascade)
  postId    Int
  author    Author? @relation(fields: [authorId], references: [id], onDelete: SetNull, onUpdate: Cascade)
  authorId  Int?

  @@map("comments")
}

Once this is done, we need to update the entities Author and Post adding the collections of comments. To do this, you need to add these lines of code

model Post {
  ...
  comments  Comment[]
  ...
}

model Author {
  ...
  comments  Comment[]
  ...
}

Now it's time to create our second migration using the next command

npx prisma migrate dev --name add_comment_entity

As you can see, now we have another folder in the migration folder that contains the last migration.

Rename a field

How we can notice, updating our schema is not so difficult using the migrate command, unless we have to rename one or more fields. When we have to rename a field, the Prisma Migrate tool works in this way

CREATE a new column
DROP the existing column and the data in that column

as you can imagine, by doing that, we'll lose our data. But how can we handle these changes then? To handle these changes is possible using a single migration but in different steps.

Rename the column
Create the migration
Edit the migration
Execute the migration

But let's see that in action. Imagine we want to rename the field firstName and lastName of the Author entity with givenName and familyName. The first action to do is rename these fields to our schema. Then update the prisma/schema.prisma in this way.

model Author {
  ...
  givenName   String
  familyName  String
  ...
}

After that it's time to create our migration. This time though, we'll use a special option --create-only. This option allows us to create the migration script but this time the migration doesn't execute yet. Now execute the following command

npx prisma migrate dev --name rename_author_columns --create-only

This command generates the new migration file but now we have to edit it to avoid data loss. If we open this file, we'll find it in this situation.

PRAGMA foreign_keys=OFF;
CREATE TABLE "new_authors" (
    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    "givenName" TEXT NOT NULL,
    "familyName" TEXT NOT NULL,
    "age" INTEGER NOT NULL
);
INSERT INTO "new_authors" ("age", "id") SELECT "age", "id" FROM "authors";
DROP TABLE "authors";
ALTER TABLE "new_authors" RENAME TO "authors";
PRAGMA foreign_key_check;
PRAGMA foreign_keys=ON;

As you can notice, all the data inside of the columns firstName and lastName will be lost. To prevent this loss we need to update the insert command. We can rewrite our insert in this way

INSERT INTO "new_authors"
  ("id", "age", "givenName", "familyName")
SELECT
  "id", "age", "firstName", "lastName"
FROM "authors";

Now it's time to do the last step to make this migration real

npx prisma migrate dev

By running this command our migration will be executed and our database will be updated.

As you can see, Prisma Migrate is a powerful tool that can help us but if we don't pay attention we could get hurt.

If you are interested in going in-depth into migrations, I let you some links about it:

Ok Guys, it's all for today! In the next article we are going to speak about seeding.

See you soon Bye Bye 👋

The code of this article can be find in the GitHub repository

It's Prisma Time - Execute your own queries

Fri, 28 Jan 2022 00:00:00 GMT

Hello Folks 👋 Today it's time to see how we can execute our own queries.

In prisma we can run two kind of custom queries: "Actionable" queries (INSERT, UPDATE or DELETE) and "Retrievable" queries (SELECT). The first one can be executed using the $executeRaw method while the other one can be executed using the $queryRaw.

Method $executeRaw

This method enables us to create custom queries to insert update or delete records in the database. Using the tagged template we can write our query and Prisma runs it "magically". Let’s see it in action to understand it better

const result = await prisma.$executeRaw`
INSERT INTO posts (title, content, published, updatedAt)
VALUES (${"Post Title"}, ${"Post Content"}, ${false}, ${new Date()});`;
console.log(`Insert result: ${result}`);

As you can see, it's not so difficult to use this method. By using the Tagged Template we can write our query and pass all the parameters in complete safety. In complete safety? Yes, you are reading right. By using this method all the parameters passed with the syntax ${parameter} are safe from the SQL-Injection, so we won't worry about these attacks. You can read more about this in this reference The last thing that I want to leave you is the return value of this method. The method returns the number of records affected by our queries. Thus we can check if our queries are executed correctly.

Method $queryRaw

This method allows us to retrieve data using custom queries. Sometimes, we need more performance and the query created by Prisma must be rewritten, in this case the $queryRaw method is our lifeline. This method uses the Tagged Template and it prevents attack by SQL-injection too. The result of this method is always an array and the type of this array depends on the result of your query. To explain better this concept let me give an example.

const result: Post[] = await prisma.$queryRaw<Post[]>`
SELECT p.id, p.title, p.content, p.published, p.createAt, p.updatedAt
FROM posts p
WHERE p.published = ${true}
ORDER BY p.createAt DESC`;
result.forEach(post => {
  const { id, title, content, createAt, published, updatedAt } = post;
  console.log({
    id,
    title,
    content,
    createAt,
    published,
    updatedAt,
  });
});

If you look closely this piece of code, you can notice that the result variable is an array of type Post, and also the $queryRaw method indicates that as its return type. By doing so, we receive the right check by typescript in the following rows of code. But there is a thing to keep in mind. The conversion from the result of the query to your type is not guaranteed by Prisma, it's your business in this case. N.B. If you don't indicate your result type, by default Prisma returns the unknown type

Let's move on and see another feature that we can adopt when we are using these methods. Sometimes we have to use the IN operator in a custom query. Probably you are thinking that using the map method of the array is the right thing, unfortunately it's not so. To do this, Prisma exposes us a specific method Prisma.join. This method builds for us the IN clause in a safety mode, so we can use it in our custom queries. Let's see it in action

const posts = await prisma.$queryRaw<
  Post[]
>`SELECT * FROM posts WHERE id IN (${Prisma.join([1, 2, 3])})`;
console.log(`Posts in 1,2,3: ${JSON.stringify(posts, null, 2)}`);

As you can notice, in this piece of code the values in the IN clause are built using the join method, nothing so difficult but it's important to keep in mind to use it in these cases.

Two other good features exposed by Prisma are the Prisma.sql and Prisma.empty. These features enable us to create dynamic queries. Imagine that your query needs to do a WHERE clause only if there is a filter. By combining these two features you can create a custom query that depends on the data that you receive. Let's see an example

const author: string | undefined = "transaction";
const authors = await prisma.$queryRaw<Author[]>`
SELECT * FROM authors a ${
  !!author
    ? Prisma.sql`WHERE a.firstName || ' ' || a.lastName LIKE ${`%${author}%`}`
    : Prisma.empty
}`;

console.log(`Authors: ${JSON.stringify(authors, null, 2)}`);

As you can see, in this example we check the value of the author variable, and if it's defined the query will execute using the filter (Prisma.sql), otherwise the query will execute without the filter(Prisma.empty). Even here, nothing so difficult to understand but these are two really good methods to write our own queries better.

Ok Guys, it's all for today. In the next article we are going to see how to use the migrations with Prisma.

See you soon Bye Bye 👋

You can find the code of this article in the GitHub repository

It's Prisma Time - Logging

Wed, 26 Jan 2022 00:00:00 GMT

Hi Guys 👋 Today we are going to see how to enable logging in Prisma, so don't waste time and let's start!

In Prisma we have 4 type of logging

query: this level of log allows us to see the queries created by Prisma to perform our operations
info
warn
error

I think the last three levels of log don’t need a description if you’re a developer. We can enable all of them or only those are necessary. By default these logs are written in the stdout, but we can also send them in an event and handle them as we prefer.

P.S. if you are in development mode, you can enable all of these log levels setting the DEBUG environment variable to true

But let's see how to enable these logs.

const prisma = new PrismaClient({
    log: [
      {
        emit: "event",
        level: "query",
      },
      "info",
      "warn",
      "error",
    ],
  });
  prisma.$on("query", e => {
    console.log("Query: " + e.query);
    console.log("Duration: " + e.duration + "ms");
  });

The log option accepts an array of log levels that can be simple strings (query, info, warn, or error) or objects composed of two fields: level and emit. The level field can have query, info, warn, or error as values; whereas the emit field can have two values: stdout or event. If the "emit" value is equal to "stdout", the result of this log level will be written in the console, otherwise, if the value is "event", the result must be handled by a subscriber. But let’s clarify and see how to manage these logs.

const prisma = new PrismaClient({
  log: [
    {
      emit: "event",
      level: "query",
    },
    "info",
    "warn",
    "error",
  ],
});
prisma.$on("query", e => {
  console.log("Query: " + e.query);
  console.log("Duration: " + e.duration + "ms");
});

In this snippet of code, you can see how to enable the log levels and how to handle a subscriber of a specific type of log level. As you can see, it's not difficult to enable logs but it's important to remember to do it in the right way in base of the environment where our software is running. It's also possibile, as you can tell, to subscribe to the events of a log using the $on method. By using this method you can send where you want all your logs. The last thing that I want to leave you is an example of a query logged in the console.

SELECT `main`.`posts`.`id`, `main`.`posts`.`title`, `main`.`posts`.`content`, `main`.`posts`.`published`, `main`.`posts`.`createAt`, `main`.`posts`.`updatedAt` FROM `main`.`posts` WHERE `main`.`posts`.`published` = ? LIMIT ? OFFSET ?

As you can see, you can get the real SQL query executed by Prisma, and you can copy and past it in other SQL tool to check its plan or everything else. In this way, we can check if we have a slowdown and if we need to write our own query. The How is the goal of the next article 😁

So that's all for now folks. In the next article, we are going to see how to execute own queries using Prisma.

See you soon guys Bye Bye 👋

You can find the code of this article in the GitHub repository

It's Prisma Time - Transactions

Thu, 20 Jan 2022 00:00:00 GMT

Hello Guys 👋 Today it's time to speak about transactions.

Transactions are a pillar of the database world, and they help us to make consistency in the data when we work with multiple entities. So, can Prisma not handle them? Obviously the answer is no 😃

In this moment, Prisma handles the transactions in two ways, the first one is the official feature and the second one is in preview. Let's start from the first one. The first method to do a transaction in Prisma is using the $transaction method. This method accepts a list of operations that are performed in a single transaction. If all of these operations are successful the transaction does the commit otherwise it does the rollback. Let's see this method at work.

const result = await prisma.$transaction([
  prisma.author.create({
    data: {
      firstName: "Author from transaction",
      lastName: "Author from transaction",
      age: getRandomInt(16, 100),
    },
  }),
  prisma.post.create({
    data: {
      title: "Post from transaction",
      content: "Post from transaction",
      published: false,
    },
  }),
]);

The result of this operation is an array of elements, where the elements are the result of each operation in the transaction, in our example the result is composed in this way [Author, Post]. As you can imagine, this type of transaction is a good solution if you need to create a bulk insert or if you need to create a list of entities not relative to each other. Therefore, to solve this problem, the Prisma team is working to improve the transaction method. In this time, we can try this feature in preview, enabling it in the schema.prisma file. First of all, open the schema.prisma file and update the generator client in this way

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["interactiveTransactions"]
}

N.B. since 4.7.0, this feature has been production ready, so you can remove the "interactiveTransactions" flag.

after that it's necessary to update the prisma definitions, so run in your terminal this command

npx prisma generate

By doing this, we enabled the feature. Now, we'll see the previous example, rewritten in the way that the author and post are in relation. Let's see the result

const result = await prisma.$transaction(async prisma => {
  const authorData = {
    firstName: "Author from transaction",
    lastName: "Author from transaction",
    age: getRandomInt(16, 100),
  } as const;
  const author = await prisma.author.create({
    data: authorData,
  });
  const post = await prisma.post.create({
    data: {
      title: "Post from transaction",
      content: "Post from transaction",
      published: false,
      authors: {
        create: [
          {
            authorId: author.id,
          },
        ],
      },
    },
    include: {
      authors: {
        include: {
          author: true,
        },
      },
    },
  });
  return { author, post };
});

As you can see, this feature allows us to handle the transaction like a function, and in this function we can do all the operations that we want to guarantee under transaction. We can also create an entity by using the create method and await its result. After that we can use this result to create or update another entity always under transaction. If you want to roll back the transaction because there are some inconsistent data, you need to throw an exception.

I think for today that's all, but before I let you go, I suggest you this reading about transactions in the prisma site. It explains very well how this feature works and how to handle it in the best way.

In the next article, we are going to see how to log the queries executed by Prisma, but now it's time to say goodbye 😃

See you soon Guys Bye bye 👋

You can find the code of this article in the GitHub repository

It's Prisma Time - Aggregate and GroupBy

Tue, 18 Jan 2022 00:00:00 GMT

Welcome back Folks 👋 Today we are seeing how to aggregate and group data.

Let's start from the first one. To aggregate data in Prisma you have to use the aggregate method. Using this method, you can aggregate data of type number, and you can do these operations:

max
min
count
sum
avg

N.B. I won't spend time explaining what these operations do because I think their names speak for themselves

Therefore, let's give an example to see the aggregate method at work.

const aggregate = await prisma.author.aggregate({
  _avg: {
    age: true,
  },
  _max: {
    age: true,
  },
  _min: {
    age: true,
  },
});

As you can see, in this example, we aggregated the authors and we got as result the authors' ages average, the age of the older author and the age of the younger author. The result is composed in this way:

{
    _avg: {
        age: true;
    };
    _max: {
        age: true;
    };
    _min: {
        age: true;
    };
}

In addition, the aggregate method allows us to use these operations:

where
orderBy
take
skip
cursor

So as you can immagine, you can filter and sort your data before aggregate them. I think this feature might be clear that way, so let's move on to the groupBy feature.

The groupBy feature allows us to group data by one o more fields. Let’s see an example to start

const commentsGroupByPost = await prisma.comment.groupBy({
  by: ["postId"],
  _count: {
    authorId: true,
    _all: true,
  },
  orderBy: {
    _count: {
      authorId: "desc",
    },
  },
  having: {
    authorId: {
      _count: {
        gt: 1,
      },
    },
  },
});

In this example, we grouped the comments by post, and after that, we counted the number of comments with the author and the number of comments for that post. Moreover, we sorted the result by the authors' count and, using the having option, we took only the posts that have at least a comment with an author. As you can see, this method is not difficult to use and understand. It's also possibile to filter the data with the where option.

I think for today that's all. We saw how to aggregate and how to group data using Prisma and, if you want to deepen, the prisma team created this video to explain better the groupBy feature.

In the next article we will see how to run our queries under transaction, but for today it's time to close 😃

See you soon guys Bye bye 👋

To show the code of this article in action follow this in the GitHub repository

It's Prisma Time - Pagination

Thu, 13 Jan 2022 00:00:00 GMT

Hi Guys 👋 Today we are going to see how to paginate our results. So don't waste time and let's go!

With Prisma there are two ways to paginate results: Offset pagination or Cursor-based pagination. What are the differences though? The first one is used when we need to create a sequence of pages and get their datas according to the page. The second one, instead, is used when we want the items after a specific record, to continue the list after that element.

But let's see an example of both, starting with the first one skip and take

{
  const pageOnePosts = await prisma.post.findMany({
    take: 3,
    orderBy: {
      id: "asc",
    },
  });
  console.log(`Page 1: `, JSON.stringify(pageOnePosts, undefined, 2));

  const pageTwoPosts = await prisma.post.findMany({
    skip: 3,
    take: 3,
    orderBy: {
      id: "asc",
    },
  });
  console.log(`Page 2: `, JSON.stringify(pageTwoPosts, undefined, 2));
}

The result of this example is this

[
  {
    "id": 1,
    "title": "Post title 1",
    "content": "Post content 1",
    "published": false,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  },
  {
    "id": 2,
    "title": "Post title 8",
    "content": "Post content 8",
    "published": true,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  },
  {
    "id": 3,
    "title": "Post title 4",
    "content": "Post content 4",
    "published": true,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  }
]

[
  {
    "id": 4,
    "title": "Post title 10",
    "content": "Post content 10",
    "published": true,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  },
  {
    "id": 5,
    "title": "Post title 9",
    "content": "Post content 9",
    "published": false,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  },
  {
    "id": 6,
    "title": "Post title 6",
    "content": "Post content 6",
    "published": true,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  }
]

As you can see, the first findMany has the orderBy and the take options. The orderBy is used to give a sort to our results and the take option is used to get the first 3 elements of the results. In this case the skip option isn't indicated so its value is 0 (default value). Instead, in the second findMany method there is also the skip option, and it's indicated with the value 3. In this case, the findMany method returns 3 elements (take: 3) after the third element (skip: 3), so we can see the results of the second page. I think it's not so difficult to understand it, so let's go on to the cursor implementation. Let's start from the code

const pageOnePosts = await prisma.post.findMany({
  take: 3,
  orderBy: {
    id: "asc",
  },
});
console.log(`Page 1: `, JSON.stringify(pageOnePosts, undefined, 2));

const pageTwoPosts = await prisma.post.findMany({
  skip: 1,
  take: 3,
  cursor: {
    id: pageOnePosts[pageOnePosts.length - 1].id,
  },
  orderBy: {
    id: "asc",
  },
});
console.log(`Page 2: `, JSON.stringify(pageTwoPosts, undefined, 2));

The results

[
  {
    "id": 1,
    "title": "Post title 1",
    "content": "Post content 1",
    "published": false,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  },
  {
    "id": 2,
    "title": "Post title 8",
    "content": "Post content 8",
    "published": true,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  },
  {
    "id": 3,
    "title": "Post title 4",
    "content": "Post content 4",
    "published": true,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  }
]

[
  {
    "id": 4,
    "title": "Post title 10",
    "content": "Post content 10",
    "published": true,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  },
  {
    "id": 5,
    "title": "Post title 9",
    "content": "Post content 9",
    "published": false,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  },
  {
    "id": 6,
    "title": "Post title 6",
    "content": "Post content 6",
    "published": true,
    "createAt": "2022-01-03T10:14:51.274Z",
    "updatedAt": "2022-01-03T10:14:51.274Z"
  }
]

As you may notice, the results are the same of the previous example but the implementation is a little bit different in the second part. In this case, the second findMany has the same orderBy and take options as in the first example, but it has a different skip and uses the cursor option. First let's focus on the cursor option. This option allows us to indicate the last item returns by the previous search, so we can restart our pagination from this element and combining it with the skip: 1, we'll get the results after this element. It's important to indicate the skip option with the one value, otherwise the element indicates in the cursor is part of the results.

As you can tell, both implementations are correct but each of them resolve a different type of pagination. Now it's your job to take the right one.

Ok guys that's all! I hope now you have an idea of how you can paginate your datas using prisma. In the next article, we are going to see how to aggregate and group the datas.

See you soon! Bye Bye 👋

in the GitHub repository you can find the code of this article.

It's Prisma Time - Select

Tue, 11 Jan 2022 00:00:00 GMT

Welcome back Guys, Today it's time to get our record using the select command.

Let's start with a simple example (copy and paste the setup method in the repository if you want some record in your database).

const prisma = new PrismaClient();
const posts = await prisma.post.findMany();
console.log(JSON.stringify(posts, undefined, 2));

As you can see, to do the select in Prisma we need to use the findMany method. In this case, the code does a simple select without anything else (no where, no groupBy, no orderBy...), it's like doing this query

SELECT *
FROM POSTS

But let's move on and add a WHERE clause to our select.

...
const posts = await prisma.post.findMany({
  where: {
    id: {
      gte: 5,
    },
  },
});
...

The where clause is the same seen in the previous articles (delete and update), so I won't go in depth because I've already spent many words about it. Therefore let's see the order by command

const posts = await prisma.post.findMany({
  orderBy: {
    published: "desc",
  },
});

As you can see, the orderBy command is so simple, you need to create an object and indicate the column used for the sorting and its direction ("desc" or "asc"). But if you want to indicate multiple columns in your sorting, the syntax is a little bit different. Let's see it in this code.

const posts = await prisma.post.findMany({
  orderBy: [{ published: "desc" }, { createAt: "asc" }],
});

As you can tell, when you need to indicate multiple columns, the orderBy field wants an array of values, and each value must contains the column name and its direction.

But let's go on and see how to indicate only a subset of columns of our entity. Supposing that we want to select only the fields id, title and content of the Post Entity, how can we do that? Fortunately, in the findMany method there is a configuration to indicate that, let's see it the next code.

const posts = await prisma.post.findMany({
  select: {
    id: true,
    title: true,
    content: true,
  },
});

As you can notice, using the select option, we can indicate the column we want to extract, but Prisma doesn't end here its works. When we use the select option, Prisma returns an object that respects our selection, so the typescript compiler can detect the right fields of the objects. In this case the posts collection has this type

const posts: {
    id: number;
    title: string;
    content: string;
}[]

It's fantastic I think, isn't it?

Ok let's go on and see the include option. The include option is used to load the relative Entities too. Immagine you want get for each post its relative authors and its comments; using the include option it's possibile. Let's see how in the next code.

const posts = await prisma.post.findMany({
  include: {
    authors: {
      select: {
        author: true,
      },
    },
    comments: true,
  },
});

As you can see, the include option allows us to get the authors and the comments relative to each post. The result of this query is

[
  {
    "id": 1,
    "title": "Post title 2",
    "content": "Post content 2",
    "published": true,
    "createAt": "2022-01-03T08:52:30.690Z",
    "updatedAt": "2022-01-03T08:52:30.690Z",
    "authors": [
      {
        "author": {
          "id": 4,
          "firstName": "First name 2",
          "lastName": "Last name 2"
        }
      }
    ],
    "comments": []
  },
  {
    "id": 2,
    "title": "Post title 5",
    "content": "Post content 5",
    "published": false,
    "createAt": "2022-01-03T08:52:30.690Z",
    "updatedAt": "2022-01-03T08:52:30.690Z",
    "authors": [
      {
        "author": {
          "id": 3,
          "firstName": "First name 5",
          "lastName": "Last name 5"
        }
      }
    ],
    "comments": []
  },
  {
    "id": 3,
    "title": "Post title 1",
    "content": "Post content 1",
    "published": false,
    "createAt": "2022-01-03T08:52:30.690Z",
    "updatedAt": "2022-01-03T08:52:30.690Z",
    "authors": [
      {
        "author": {
          "id": 5,
          "firstName": "First name 1",
          "lastName": "Last name 1"
        }
      }
    ],
    "comments": []
  }
  ...
]

After the explanation of the findMany method, it's important to spend some words about other two methods: findUnique and findFirst. As you can immagine, these two methods allow us to retrieve a single record. The findFirst is like the findMany but it returns the first record of the result. The findUnique otherwise returns a record by its key. If they do not find any results return null. Let's see an example of both: - findFirst

const post = await prisma.post.findFirst({
  where: {
    published: true,
  },
});

_- findUnique

const post = await prisma.post.findUnique({
  where: {
    id: 1,
  },
});

Ok, I think that's all for today. In the next article we are going to see how to paginate the results.

See you soon guys! Bye Bye!

in the GitHub repository you can find the code of this article

It's Prisma Time - Update

Fri, 07 Jan 2022 00:00:00 GMT

Hi Folks 👋 Today it's time to learn something about the update operation, so don't waste time and let's go!

The update method in Prisma is not that different from the insert. Let's give an example. Starting from the code of the previous article, you can remove all the code relative to the delete operation and after the insert you can add the following code.

const updatedAuthor = await prisma.author.update({
  data: {
    firstName: "Updated first name",
    lastName: "Updated last name",
  },
  where: {
    id: authors[0].id,
  },
});
console.log({ updatedAuthor });

As you can see, the update method used the patter prisma.[entity].update, not so different from the insert and the delete, obviously the update method updates an existing row. And another thing, if the update method doesn't find the record, it throws an exception that you have to handle in your code. If you execute that code you get this result.

{
  updatedAuthor: {
    id: 3,
    firstName: 'Updated first name',
    lastName: 'Updated last name'
  }
}

I think this operation is easy to understand, but now let me show you some special features that the update method exposes. In some cases, when we want to update a row, we don't want to set a new value, but we want to increment, decrement, multiply or divide a field in a atomic update operation. To do this Prisma exposes us these commands in the type IntFieldUpdateOperationsInput

export type IntFieldUpdateOperationsInput = {
  set?: number
  increment?: number
  decrement?: number
  multiply?: number
  divide?: number
}

and we can use it in this way

const updatedAuthor = await prisma.author.update({
  data: {
    id: {
      increment: 1
    }
  },
  where: {
    id: authors[0].id,
  },
});

Obviously, incrementing the primary key doesn't have sense, but this is just a demonstrative example. Let's go on and see another important feature exposed by the update operation, to work with the relative collections. In the insert operation, we saw that when we want to insert a new record, we can use create, connect or connectOrCreate operation to create a relation between two records. In the update operation in addition we have:

upsert: update or create a related record
set: connect the record with an existing records, (if you set this field with an empty you disconnect all record)
disconnect: remove the relation with existing records
delete: delete the record in relation with it
update: update the related record
updateMany: update the related records
deleteMany: delete the related records

I let you the official document for each type, so you can deepen if you are interested.

As you can imagine, over the update operation there is the updateMany operation. In this article I prefer not to look into this operation because I have already left you many info about the update. But let me spend some words about it, so you can try it by yourself. The updateMany operation combine the where seen in the deleteMany operation with the features explained above, so it's obvious to understand that this operation allows you to update many records, using a complex filter.

It's all for today guys. In the next article it's time to see the select operation.

See you soon Bye Bye 👋

You can find the code of this article in the GitHub repository

It's Prisma Time - Delete

Wed, 05 Jan 2022 00:00:00 GMT

Hi Guys 👋 today we are going to see the delete operation.

Before moving to the delete operation, in the code of this article I added the next snippet of code at the beginning, so every time you run the code you have some records in your database.

const authors = await Promise.all(
  [1, 2, 3].map(
    async i =>
      await prisma.author.create({
        data: {
          firstName: `First name ${i}`,
          lastName: `Last name ${i}`,
        },
      })
  )
);

The delete operation in Prisma can be done in two ways: the deletion of one record and the deletion of multiple records. Let's start from the first one and let's see the next code

const deletedAuthor = await prisma.author.delete({
  where: {
    id: authors[0].id,
  },
});

As you can see, the delete method is quite simple, you need to follow this pattern prisma.[entity].delete, the where field must have the primary key of the record that has to be deleted. It's important to remember that if this method doesn't find a record to delete, throws an Exception that you can handle in this way

try {
  const deletedAuthor = await prisma.author.delete({
    where: {
      id: 1,
    },
  });
  console.log({ deletedAuthor });
} catch (error) {
  if (
    error instanceof Prisma.PrismaClientKnownRequestError &&
    error.code === "P2025"
  ) {
    console.log("Author not found");
  } else console.error(error);
}

If you are interested in seeing all the possibile errors returned by Prisma you can find the documentation in this reference

Let's bring the delete to the next level and let's see the deleteMany method. I think you already have understood that this method allows you to delete multiple records in one step, but let me show you an example.

const deletedAuthorsResult = await prisma.author.deleteMany({
  where: {
    id: {
      in: authors.map(a => a.id),
    }
  },
});

As you can see, this method isn't so different from the delete, but the differences are in the where field and in this method you can filter the datas like in a SQL where. In this particular case the code deletes the records that have the id contained in the array passed by the authors collection. Another difference between the deleteMany and the delete is the result's type. The deleteMany returns an object with a single property called count and it contains the amount of the records effected by the delete operation.

Now, I would spend some words about the "where" because it exposes a lot of possibilities to search the records that we want to delete. Thus I want to start this explanation from the "author where"'s typescript definition.

export type AuthorWhereInput = {
  id?: IntFilter | number
  firstName?: StringFilter | string
  lastName?: StringFilter | string
  comments?: CommentListRelationFilter
  posts?: AuthorsOnPostListRelationFilter
  AND?: Enumerable<AuthorWhereInput>
  OR?: Enumerable<AuthorWhereInput>
  NOT?: Enumerable<AuthorWhereInput>
}

As you can see, this type has some strange things, but if you are familiar with the SQL, I think you have an idea of what you can do. Don't waste time and let's start from the id. The id field can have two values, either a number or IntFilter. At this point, if you need to find your record using the id, you can pass your value to this field, else if you want to delete records using more complex search terms you can use the IntFilter, which is composed thus

export type IntFilter = {
  equals?: number
  in?: Enumerable<number>
  notIn?: Enumerable<number>
  lt?: number
  lte?: number
  gt?: number
  gte?: number
  not?: NestedIntFilter | number
}

As you can image this type represents the common operations that you can do in SQL with the numbers:

equals: checks if the value is equal to the passed value
in: checks if the value is inside of the list of numbers that you pass
notIn: is the opposite of in
lt: checks if the value is less than the passed value
lte: checks if the value is less or equal to the passed value
gt: checks if the value is greater than the passed value
gte: checks if the value is greater or equal to the passed value
not: checks if a value is not of the passed value, or you can also set it with the type NestedIntFilter, which is another type equal to the IntFilter, and it allows you to create your filters using the positive search terms and check if the records respect the opposite. As you may imagine, there are other three types similar to: StringFilter, BoolFilter and DateTimeFilter, and each one depends from the column's type that you are testing. DateTimeFilter is equal to the IntFilter expect that works with the Date. BoolFilter contains only the equals and the not operations for obvious reasons. The StringFilter in addition to the operations exposed by the IntFilter has other three operations: contains, startsWith and endsWith (I won't describe these operations because I think they speak by themselves). After this explanation, I think you have understood also the fields: firstName, lastName. Now I want to go on to the posts and comments fields, that have the same approach. These fields allow you to check some particular cases inside the posts or the comments related to the record. Each field allows you to do these three operations every, some and none

export type CommentListRelationFilter = {
  every?: CommentWhereInput
  some?: CommentWhereInput
  none?: CommentWhereInput
}

export type AuthorsOnPostListRelationFilter = {
  every?: AuthorsOnPostWhereInput
  some?: AuthorsOnPostWhereInput
  none?: AuthorsOnPostWhereInput
}

Using these filters you can check inside of the posts or the comments relative to the Author, so you can check:

if every post/comment has a particular value or more particular values
if some post/comment has a particular value or more particular values
if none post/comment has a particular value or more particular values It's not so difficult to understand it but I recommend you to play with them.

Now it's time to see the last three operations: AND, OR and NOT. I think you already understood their goals, but let me spend some words. These three operations let you to combine multiple filters using the operation AND OR NOT. You can combine together these operations and you can also nest them. For instance, you can use the AND and the OR in the first level of your filter, and use the NOT and the OR inside the AND filter. I think an example can give the idea.

const deletedAuthorsResult = await prisma.author.deleteMany({
  where: {
    AND: [
      {
        NOT: {
          id: 10,
        },
      },
      {
        OR: {
          firstName: {
            startsWith: "name",
          },
        },
      },
    ],
    OR: [
      {
        posts: {
          every: {
            post: {
              updatedAt: {
                lt: new Date(Date.now() - 1000 * 60 * 60 * 24 * 7),
              },
            },
          },
        },
      },
    ],
  },
});

As you can see, you can do every type of check in you delete using the deleteMany and I think the definition types created by the Prisma team are a good friends to prevent errors. It's obvious that they don't create the right query for you, that's your work. 💪

That's all for today guys! I hope I let you a good introduction about the delete in prisma and that now you are ready to go to try it by yourself. In the next article it's time to speak about the update operation, so see you soon folks!

Bye Bye! 👋

The code of this article is available in the GitHub repository

It's Prisma Time - Insert

Thu, 30 Dec 2021 00:00:00 GMT

Welcome Guys, Today it's time to add some records to the database 😁 so don't waste time and get your hand dirty.

Let's start from a simple insert that adds an author, in your src/index.ts copy the next example.

import { PrismaClient } from "@prisma/client";

async function main() {
  const prisma = new PrismaClient();
  try {
    const newAuthor = await prisma.author.create({
      data: {
        firstName: "John",
        lastName: "Doe",
      },
    });
    console.log({ newAuthor });
  } catch (error) {
    console.error(error);
    throw error;
  } finally {
    await prisma.$disconnect();
  }
}

main();

In this code you created a simple insert that adds an author. By using the patter prisma.[entity].create you can insert in your db your entities, but let's see this code in action executing the next two script

npx prisma db push
yarn dev

{ newAuthor: { id: 1, firstName: 'John', lastName: 'Doe' } }

As you can see it's not so hard to insert a record, but it's time to take the insert to the next level. Imagine that you want to insert a Post with one Comment in a single execution, how can you do that? Well, add to the previous code the next one, below the console.log({ newAuthor });.

...
const newPost = await prisma.post.create({
  data: {
    title: "First Post",
    content: "This is the first post",
    published: false,
    comments: {
      create: {
        text: "First comment",
        author: {
          connect: {
            id: newAuthor.id,
          },
        },
      },
    },
  },
  include: {
    comments: true,
  },
});

console.log("newPost", JSON.stringify(newPost, null, 4));
...

And now run the code using

npx prisma db push
yarn dev

after that you can see this result

newPost {
    "id": 7,
    "title": "First Post",
    "content": "This is the first post",
    "published": false,
    "createAt": "2021-12-18T12:29:20.982Z",
    "updatedAt": "2021-12-18T12:29:20.982Z",
    "comments": [
        {
            "id": 7,
            "text": "First comment",
            "postId": 7,
            "authorId": 7
        }
    ]
}

But what happened? By running this code you added in you database a post and a comment related to this post using a single command. I think you agree with me that it is a common feature in an ORM. But let's see better the create method and its parameters. Let's start from the data field, this field allows you to indicate all the fields related to your entity, in this case the Post Entity. When I say the entity's fields I am referring to the own fields but also to the fields of its related Entities as you did with the Comment Entity in the previous example. But let's move on and see another particularity in this example. To add the comment related to your post you used this snippet of code

...
comments: {
  create: {
    text: "First comment",
    author: {
      connect: {
        id: newAuthor.id,
      },
    },
  },
},
...

The first thing that comes to our attention is the create field. This field is not a field of the Comment Entity but is a command for Prisma. Using the create command you are indicating to Prisma that you want to insert a new record in the comment table. The data relative to the comment are indicated inside of the create object just described. Okay but let’s look into this object where there is another peculiarity inside the field author. As you can see inside it there is a field called connect, but what is it? The connect field is another command for Prisma. This command indicates to Prisma that the Author's record already exists in the database and it must not create it but it only needs to create the link between the comment record and the author record. There is another command for Prisma to manage the insert of an entities and it is connectOrCreate. This command allows us to check if the relative record exists and in this case Prisma creates the link between the entities, otherwise if it doesn't exist Prisma creates also this new record. To give you an example, here, the author connect command rewrites with the connectOrCreate.

author: {
  connectOrCreate: {
    create: {
      lastName: "Last name",
      firstName: "First name",
    },
    where: {
      id: newAuthor.id,
    },
  },
},

When you insert a new record, all the crud operations in your database are made under a transaction, so if in your insertion you have an entity with 3 sub-entities, you'll get the success result only if all operations will be successful, otherwise you'll get an error and your database will be left clean as before the execution.

There is also a createMany method that allows you to do a bulk insert inside a collection. It isn't so different from the create method. I leave you the link to the documentation in this reference. N.B. createMany isn't supported in SQLite, Prisma helps you on that and when generates the definitions of the client, it detects the current connector and generates only the definitions supported by the connector

Last but not least, Prisma exposes you a specific type for typescript that describes how you can call the create method in a type safe context. Next the author insert reviews with this type

import { Prisma, PrismaClient } from "@prisma/client";

...
const authorCreate: Prisma.AuthorCreateArgs = {
      data: {
        firstName: "John",
        lastName: "Doe",
      },
    };

    const newAuthor = await prisma.author.create(authorCreate);
...

Prisma does this work for all the entities that you described in the prisma.schema file and it doesn't just make this, but we will go deep into this in the next articles.

I think today you have got many notions about the insert with prisma. If you are interested in go in depth on the insert with prisma in this reference the link to the official documentation.

That’s it guys. In the next article we’re going to see the delete operation.

See you soon. Bye Bye 👋

You can find the code of this article in the GitHub repository

It's Prisma Time - Create Relations

Tue, 28 Dec 2021 00:00:00 GMT

Hi Folks 👋 today I'll show you how to create relations among your entities. So don't waste time and let's start!

Before moving on, let me explain what we are going to do today.

Create a relation 1-N among posts and comments
Create a relation N-N among posts and authors
Explain a relation 1-1

So get started from the first one.

1-N

To create the relation among Posts and Comments see the next code

model Post {
  ...
  comments  Comment[]
}

model Comment {
  id        Int @id @default(autoincrement())
  text      String
  post      Post @relation(fields: [postId], references: [id], onDelete: NoAction, onUpdate: Cascade)
  postId    Int
}

As you can see in this example there are 3 steps

Creation of the comment entity
Creation of the relation between Post and Comment (@relation)
Addition of the comments collection in the Post entity

Let's focus on the second point now

post      Post @relation(fields: [postId], references: [id], onDelete: NoAction, onUpdate: Cascade)

this line of code says Prisma that in Comment entity there is a field postId related to the field id in Post entity. In this way you described the relation between Post and Comment entities. It's also possibile to describe what to do when a foreign key is deleted or updated using the keyword onDelete and onUpdate. This two commands could have 5 possibile values:

Not all of them are guaranteed in all the databases connector, but you can find in this reference all the info about that. Let's move on to the third point where you added this line of code

comments  Comment[]

this line create a collection of comments inside the Post Entity like in every ORM that respects itself, so you can retrive by code the comments related to your post.

But let's move on and see the next relation.

N.B. it's possible to create a not mandatory foreign key too. In our context it makes no sense, but imagine that a comment should exist also without a Post. In order to map this relation you need to change the Comment entity in this way

model Comment {
  ...
  post      Post? @relation(fields: [postId], references: [id])
  postId    Int?
  ...
}

Using the ? character, you should indicate to Prisma that the field can be null.

N-N

See the following code

model Post {
  id        Int @id @default(autoincrement())
  title     String
  content   String
  published Boolean
  comments  Comment[]
  authors   AuthorsOnPost[]
}

model Author {
  id        Int @id @default(autoincrement())
  firstName String
  lastName  String
  comments  Comment[]
  posts     AuthorsOnPost[]
}

model AuthorsOnPost {
  author    Author @relation(fields: [authorId], references: [id])
  authorId  Int
  post      Post @relation(fields: [postId], references: [id])
  postId    Int

  @@id([authorId, postId])
}

As you can see there are 5 steps

Creation of the Author entity
Creation of the AuthorsOnPost entity
Creation of the relation between Posts and Authors using the AuthorsOnPost entity
Adding the collection of AuthorsOnPost in the Post Entity
Adding the collection of AuthorsOnPost in the Authors Entity Let's start to see the second point where you created a new Entity with two fields: authorId and postId. authorId is a foreign key related to the Author Entity whereas postId is a foreign key related to the Post Entity, I think if you understood the previous paragraph, you don't have any problem to understand this. Using the @@id you indicated to prisma that the AuthorsOnPost had a primary key composed by this two fields, so you can have the same author and the same post only once. By doing that, you have created a relation N-N between Authors and Posts, so in your database now, you can have a Post with multiple Authors and an Author can contribute to multiple Posts. The last two steps instead allow you to have the collection of Authors related to a Post and viceversa.

1-1

For this particular relation I hope you have understood the syntax so I'll leave a symbolic example. We can say that you have a Post that can be in relation only with an Author and viceversa, you have to describe that relation like this

model Post {
  ...
  author    Author @relation(fields: [authorId], references: [id])
  authorId  Int
}

model Author {
  .....
  post      Post?
}

I think it's not so hard to understand what I explained before, but it was necessary to bring this example too.

I think that's everything from the Relation's world with Prisma, but before updating the database, let me add to the project a package that creates the ER diagram of your database.

Install the package prisma-erd-generator

yarn add -D prisma-erd-generator

update the prisma/schema.prisma with the following code

generator client {
  provider = "prisma-client-js"
}

generator erd {
  provider = "prisma-erd-generator"
}

...

Now when you call the script npx prisma generate, Prisma generates for you also a file prisma/ERD.svg where you can see your ER Diagram.

Now it's time to upgrade your database and your types, so execute the next two scripts in your terminal

npx prisma generate
npx prisma db push

Now your db is up to date and you have a new file like the next where there is your ER Diagram.

That's all for today guys, in the next article it's time to see how you can insert data in you table.

Before the greetings, if you are interested in seeing the prisma-erd-generator package you can find the repository in the GitHub repository and if you want to leave a ⭐, press the button 😉

Ok, see you soon Guys Bye Bye 👋

The code relatives to this article is available in the GitHub repository

It's Prisma Time - Create Db

Thu, 23 Dec 2021 00:00:00 GMT

Hi Guys 👋 welcome back. Finally, today it's time to create our database, so don't waste time, and get started. How can you create your database? It's simple! You have to run the following script:

npx prisma db push

This script creates in your prisma folder a SQLite database called dev.db. The database's name is taken from the variable DATABASE_URL in the .env file and inside of the file you can find the next table. Ok, now you have your database so it's time to get back at the challenge left open last article. Run the script

yarn dev

{ posts: [] }

Ok, there aren't data but it works 🥳 So now you have a database and you can search data inside it, at this point, it's time to create relations between our entities, but it's the goal of the next article 🤪

That's all for today guys! See you soon Bye Bye 👋

You can find the code relative to this post in the GitHub repository

It's Prisma Time - Create Table

Tue, 21 Dec 2021 00:00:00 GMT

Hello Folks 👋 and welcome back to this series, today it's time to create your first table with prisma, are you ready? Then let's go 💪

Before starting, let me explain which type of tables we are going to create in this series. For this series we are going to create a simple db to manage a blog, ok.. not a big and strong blog but an easy blog to focus our learn on the main concepts of prisma. Since we’re talking about blogs, let's start from the post table obviously. Open the prisma/schema.prisma file and append the following snippet.

model Post {
  id        Int @id @default(autoincrement())
  title     String
  content   String
  published Boolean  @default(false)
  createAt  DateTime @default(now())
  updatedAt DateTime @updatedAt

  @@map("posts")
}

Great! But what did you do adding this code? 🤔 Writing this code you described the entity Post and you indicated to Prisma:

I want an entity called Post
This entity has 6 properties
The id property is of type Integer, it is the primary key of my entity (@id) and it must be auto-generated (@default(autoincrement()))
The title property is of type String
The content property is of type String
The published property is of type Boolean and its default value is false
The createAt is of type DateTime and when a new record is inserted, set it with the current date time
The updatedAt is of type DateTime and when a record is updated, update it with the current date time (@updatedAt)
Call the table "posts" (@@map("posts"))

Well, nothing so difficult, just some special syntax to remember. I don't want to go too deep but If you are interested in the Data model of Prisma in this reference the link to the documentation. N.B. It's important to know well the mapping between the Prisma's types and the native's types of the different database services

But let's go ahead, you described your entity now I think you want use it. To use this entity inside of your typescript code, you need to create its typescript definition. To do this, run the following code:

npx prisma generate

This command adds in you package.json a new dependence @prisma/client, and creates a folder .prisma inside of your node_modules folder. The @prisma/client is the package that contains the client to connect to your database, whereas, the .prisma folder contains a file index.d.ts that describes the post Entity and all the possible functions to work with this Entity. Ok, at this point, let's try to get data from this collection of posts and to do this let's create a file called index.ts inside the src folder and copy the following code. (src/index.ts)

import { PrismaClient } from "@prisma/client";

async function main() {
  const prisma = new PrismaClient();
  try {
    const posts = await prisma.post.findMany();
    console.log({ posts });
  } finally {
    prisma.$disconnect();
  }
}

main();

In this simple code, you created a connection to your database, found the posts inside the posts collections, and logged the result in the console. To run this code you have to add this section in your package.json file.

...
  "scripts": {
    "dev": "ts-node ./src/index.ts"
  },
...

This script permits you to run the code written above. Ok, it's time to show the result. Run in your terminal the following script.

yarn dev

Ok, maybe that's not the result that you expected but something's gone 😅 The error that you are seeing in your terminal appeared because we haven't a database.... we haven't a database yet 😃 In the next article, I'll show you how to create the database and we'll resolve this terrible mistake, I promise!

I think that could be all for today! See you soon Guys Bye Bye 👋

The code of this article is available in the GitHub repository

It's Prisma Time - Setup

Thu, 16 Dec 2021 00:00:00 GMT

Hi Guys, welcome to the second article of this series.

Today I'll show you how to setup a project with Prisma. This project in addition to prisma uses typescript, but let's start.

The first thing that you need to do is to initialize a folder as a node project. To do this you need to run the following command in your terminal. (I used yarn but if you prefer npm or something else feel free to use it)

yarn init -y

I suppose that if you are here you know what you did running this command. We go on and add now to our workspace some dependencies using the next command.

yarn add -d typescript @types/node ts-node prisma

The first three dependencies are related to typescript and they are necessary to use typescript in our project, the last one is the Prisma CLI. The Prisma CLI helps us to create, update or view our database, it is easy to use and it hasn't a lot of commands to remember. Now it's time to create our Prisma schema, for this series I decided to use SQLite as database service because it's the easiest to set up. Run the following command to generate the schema.

npx prisma init --datasource-provider sqlite

As you can see, this command created a file schema.prisma inside of the folder prisma. In this file, you can see two sections: client and db. The client section is used to identify the provider used to manage the connection with the source, whereas in the db section you can find the connection string to the database and the provider to identify the type of the source, in our case SQLite. The schema file is the single source of truth when we use Prisma, in this file, we add all the entities and all their relations. From this file, Prisma can generate our typescript types related to the entities and it can create our migration scripts to upgrade the schema of our source. As you can see, the schema file needs to access an environment variable(DATABASE_URL), so to do this, it was created a file .env in the root of the project where inside we can find this variable.

The last thing I want to leave you today is related to the parameter --datasource-provider in the script. By default, if you don't pass this parameter the script uses PostgreSQL as database service, so if you need to use a different service you need to specify it using the --datasource-provider parameter.

I think this is all for today. In the next article we are going to create our first table with Prisma and we are going to start playing with this tool.

Ok guys, see you soon 👋

You can find the code of this article in the GitHub repository

It's Prisma Time - Introduction

Tue, 14 Dec 2021 00:00:00 GMT

Hi Folks 👋 and welcome back, Today I want to start a new series about Prisma. But before starting I want to explain the reason why of this series. In the last months I spent more time using ORM in the node eco-system. Most of the time I used typeorm. In my opinion Typeorm is a great ORM but creates entities and managing them sometimes it's not so easy, especially if you love to use typescript without classes. But one day in my twitter's wall appeared this tweet of @Matteo Collina that spoke about prisma, so I decided to spend some of my free time to understand better this tool. As you can imagine, it left me good impressions so I decide to share them with you using this series.

What's in this series?

In this series, I'm going to show you how to set up a project with Prisma and how it can work in your codebase. I'm going to try to create shot articles with only one goal for each article, to permit you to understand better the goal and don't switch context during the reading.

What's not in this series?

In this series I am not going to show you how to create a repository to split the data access layer with the business logic layer or how to structure your project to have a clean code, that's not the goal of the series, and I know that already exist many books and articles that speak about it.

A little preamble: I don't love so much using ORM in my code, but sometimes they help the team to increase its velocity. Despite everything, it's important to check the queries generated by the ORM because sometimes they aren't optimized. In these cases, it's a good solution writing your query in order to improve the velocity of its execution.

Let's start with an introduction of Prisma. In this article I picked some infos about Prisma from its site. This helps you to have an idea of what it is and which are they goals.

Introduction

Prisma is an open source next-generation ORM. It consists of the following parts:

Prisma Client: Auto-generated and type-safe query builder for Node.js & TypeScript
Prisma Migrate: Migration system
Prisma Studio: GUI to view and edit data in your database

It's important to remember that if you prefer using javascript without typescript, you can choose this way without any problem because Prisma guarantees both solutions.

Prisma Goals

Prisma's main goal is to make application developers more productive when working with databases:

Thinking in objects instead of mapping relational data
Queries not classes to avoid complex model objects
Single source of truth for database and application models
Healthy constraints that prevent common pitfalls and antipatterns
An abstraction that makes the right thing easy ("pit of success")
Type-safe database queries that can be validated at compile time
Less boilerplate so developers can focus on the important parts of their app
Auto-completion in code editors instead of needing to look up documentation

Prisma Connectors

Prima allow us to connect to the major SQL and NOSQL services.

PostgreSQL
MySql
SQLite
MongoDB
Microsoft SQL Server

I think that as an introduction of the tool and to give you an idea about it, it may be all. If you are curious and you want to go deep inside about Prisma, in its documentation you can find more info.

I think for today it's all, but before ending this article, I wish to thank Prisma for the cover of this series, the original image is hosted in the Prisma facebook account at this in this reference

So see you in the next article where we'll start to setup our project. Bye bye 👋

RxJS - Marble Testing

Fri, 08 Oct 2021 00:00:00 GMT

Hello Folks 👋! Today it's time to speak about testing and how to test the code when we use RxJS. Before moving our focus to the testing, I need to explain two different types of Observables: cold and hot.

Hot and Cold

When you create an Observable, you can create a hot or a cold observable. This characteristic depends on where the producer of this Observable is set; when the producer is created by the Observable, the observable is "cold", instead when the producer is created out from the observable it is defined "hot". Let me shed some light on all these words. What's a producer? The producer is the source of the values of our observable. Cold Observables Cold Observables are functions that create the producer and manage it for all its life. The cold observable is in charge of these things:

create the producer
activate the producer
start listening to the producer
unicast
close the producer

Here's an example:

const source = new Observable((observer) => {
  const socket = new WebSocket('ws://someurl');
  socket.addEventListener('message', (e) => observer.next(e));
  return () => socket.close();
});

Hot Observables An observable is “hot” if its underlying producer is either created or activated outside of subscription.

shares a reference to a producer
starts listening to the producer
multicast (usually)

Here's an example:

const socket = new WebSocket('ws://someurl');
const source = new Observable((observer) => {
  socket.addEventListener('message', (e) => observer.next(e));
});

Ok, I think that now you have an idea of the difference between these two types and I can move to the topic of the day, but if you are interested in deepen this argument in this reference is a post about Hot and Cold written by Ben Lesh.

Marble Testing

To test our code in RxJS we use Marble testing. A method that combines the Marble Diagram with the code, and allows us to represent the behaviours of our observables and translate them to something that the Testing Framework can understand.

Marble Syntax

As you can imagine, the marble testing has its own syntax to represent the behaviours and here you can find its rules:

whitespace: horizontal whitespace is ignored, and can be used to help vertically align multiple marble diagrams.
- frame: 1 "frame" of virtual time passing (see above description of frames).
[0-9]+[ms|s|m] time progression: the time progression syntax lets you progress virtual time by a specific amount. It's a number, followed by a time unit of ms (milliseconds), s (seconds), or m (minutes) without any space between them, e.g. a 10ms b.
| complete: The successful completion of an observable. This is the observable producer signaling complete().
# error: An error terminating the observable. This is the observable producer signaling error().
[a-z0-9] e.g. 'a' any alphanumeric character: Represents a value being emitted by the producer signaling next().
() sync groupings: When multiple events need to be in the same frame synchronously, parentheses are used to group those events.
^ subscription point: (hot observables only) shows the point at which the tested observables will be subscribed to the hot observable. This is the "zero frame" for that observable, every frame before the ^ will be negative. Negative time might seem pointless, but there are in fact advanced cases where this is necessary, usually involving ReplaySubjects.

TestScheduler

The TestScheduler is the magician that translates the Marble Syntax to something that the Test Framework can understand. It's important to remember that we cannot use the TestScheduler to test our code all the time. For example, if the code consumes a Promise we cannot use it but we should use a traditional method. The TestScheduler exposes us some APIs that we can use to write our tests but we start from its initialization.

import { TestScheduler } from 'rxjs/testing';

describe('Marble Testing', () => {
    let testScheduler: TestScheduler;

    beforeEach(() => {
        testScheduler = new TestScheduler((actual, expected) => {
            expect(actual).toEqual(expected);
        });
    });
});

N.B. all the examples use jest as Testing Framework

As you can see, it's important to create a new TestScheduler for every test, this allows us to have a new instance for every test and create a clean case. But the weird thing in this code is the body of the code passing to the TestScheduler. This code is particular if you are confident with any test framework because in this function we have already indicated the expectations of the test, but we haven't written one yet. This, because the TestScheduler exposes some helpers to test the code and these helpers call the function indicated in the constructor of the TestScheduler to check the failure or the success of the test.

But let's see a concrete example:

import { TestScheduler } from 'rxjs/testing';

describe('Marble Testing', () => {
    let testScheduler: TestScheduler;

    beforeEach(() => {
        testScheduler = new TestScheduler((actual, expected) => {
            expect(actual).toEqual(expected);
        });
    });
    
    it('test', () => {
        testScheduler.run((helpers) => {
            const { cold, expectObservable } = helpers;
            const source$ = cold('-a-b-c|');
            const expected = '-a-b-c|';
        
            expectObservable(source$).toBe(expected);
        });
    });

});

In this example, we created a cold Observable that emits 3 values: a, b and c. Using the expectObservable helper we can test our observable by comparing it with the expectation passed to the toBe method. Now let's add some dynamism to our tests and see how to pass values to our observable inside of the tests.

import { TestScheduler } from 'rxjs/testing';

describe('Marble Testing', () => {
    let testScheduler: TestScheduler;

    beforeEach(() => {
        testScheduler = new TestScheduler((actual, expected) => {
            expect(actual).toEqual(expected);
        });
    });

    it('test with values', () => {
        testScheduler.run((helpers) => {
            const { cold, expectObservable } = helpers;
            const source$ = cold('-a-b-c|', { a: 1, b: 2, c: 3 });
            const expected = '-a-b-c|';
        
            expectObservable(source$).toBe(expected, { a: 1, b: 2, c: 3 });
        });
    });
});

In this example, you can see that we can pass another argument to the cold function. This argument is an object where the fields are the correspondents of the value passed in the marble string, so if you use a, b, and c in the marble string you have to use a, b, and c as fields of your argument. The values of these fields are the values used by the test and emitted by the observable. The same goes for the toBe method, it accepts another argument where we can pass the expected result values. Another important concept when you test your observables is the time, in these cases, it's possible to specify after how much time an observable emits a value or after how much time a value is expected. Here, an example using the concatMap operator combined with the delay operator that delays the result by 100ms.

import { concatMap, delay, of } from 'rxjs';
import { TestScheduler } from 'rxjs/testing';

describe('Marble Testing', () => {
    let testScheduler: TestScheduler;

    beforeEach(() => {
        testScheduler = new TestScheduler((actual, expected) => {
            expect(actual).toEqual(expected);
        });
    });
    
    it('test', () => {
        testScheduler.run((helpers) => {
            const { cold, expectObservable } = helpers;
            const source$ = cold('-a-b-c|');
            const final$ = source$.pipe(concatMap(val => of(val).pipe(delay(100))));
            const expected = '- 100ms a 99ms b 99ms (c|)';
            expectObservable(final$).toBe(expected);
        });
    });

});

In the previous examples I showed you how to test cold Observables, but you can test hot observables too. One of the important concepts, when you create a hot Observable, is that you can indicate when the observables are subscribed, and you can do that using the ^ character. When you indicate the subscription you might remember that your results start from the subscription and the values emitted before are ignored by the test. You can see an example below.

import { TestScheduler } from 'rxjs/testing';

describe('Marble Testing', () => {
    let testScheduler: TestScheduler;

    beforeEach(() => {
        testScheduler = new TestScheduler((actual, expected) => {
            expect(actual).toEqual(expected);
        });
    });
    
    it('test', () => {
        testScheduler.run((helpers) => {
            const { hot, expectObservable } = helpers;
            const source$ = hot('-a-b-^-c|');
            const expected = '--c|';
            expectObservable(source$).toBe(expected);
        });
    });

});

The last test case that I'll show you today is how to test the subscriptions. Sometimes could be necessary to test when an observable is subscribed and for how much time. Let me use an example: we have two observables combined together using a concat operator, in this case, we need to test if the first observable is subscribed and when it is completed we need to check if the second observable is subscribed. While you are before these cases, you need to use the expectSubscriptions helper. This helper allows you to check the subscriptions of an observable and detects when the observable is subscribed and when is unsubscribed. Here you can find the example explained above.

import { concat } from 'rxjs';
import { TestScheduler } from 'rxjs/testing';

describe('Marble Testing', () => {
    let testScheduler: TestScheduler;

    beforeEach(() => {
        testScheduler = new TestScheduler((actual, expected) => {
            expect(actual).toEqual(expected);
        });
    });
    
    it('test subscriptions', () => {
        testScheduler.run((helpers) => {
            const { cold, expectObservable, expectSubscriptions } = helpers;
            const source1$ = cold('-a-b-c|');
            const source2$ = cold('-d-e-f|');
            const final$ = concat(source1$, source2$);

            const expected = '-a-b-c-d-e-f|';
            const expectedSubscriptionsSource1 = '^-----!';
            const expectedSubscriptionsSource2 = '------^-----!';

            expectObservable(final$).toBe(expected);
            expectSubscriptions(source1$.subscriptions).toBe(expectedSubscriptionsSource1);
            expectSubscriptions(source2$.subscriptions).toBe(expectedSubscriptionsSource2);
        });
    });

});

Ok guys, I think that's enough for today. in the GitHub repository you can find the code of this article. But before I let you go, I have bad news unfortunately, this is the last article of the series, so today there will be some special regards. I hope you enjoyed this series and you understood better the RxJS world. Thanks for having read the series and if you have any doubts don't hesitate to contact me, I will be happy to help you.

I will be back soon with new contents, see you soon guys, stay subscribed, and bye-bye.

RxJS - Subjects

Wed, 06 Oct 2021 00:00:00 GMT

What's a Subject Luca? And why today do you want to speak about subjects? Is there a mistake in the publishing? Or are you simply drunk?

No guys, don't worry, It's the topic of the day :) I think that after this long trip in the RxJS world and after Observables, Observers, Subscriptions, and a number of Operators that I don't even remember, it's time to show you the Subjects, a powerful type of Observable, but not only. Let's start from the definition:

A Subject is like an Observable, but can multicast to many Observers. Subjects are like EventEmitters: they maintain a registry of many listeners.

Ok, I'm joking :) But let's continue with two notes present in the official documentation.

Every Subject is an Observable Given a Subject, you can subscribe to it, providing an Observer, which will start receiving values normally. From the perspective of the Observer, it cannot tell whether the Observable execution is coming from a plain unicast Observable or a Subject.
Every Subject is an Observer It is an object with the methods next(v), error(e), and complete(). To feed a new value to the Subject, just call next(theValue), and it will be multicasted to the Observers registered to listen to the Subject.

Ok, but what does it means? It means that you can create a Subject, subscribe to it with infinitive observers, multicast the values with great performance, emit new values using a simple method called next, emit errors using a method called error and complete your subject with a simple method called complete. The icing on that cake is that all these things can be done with a clean code and they are not enclosed into the body of a function as on the Observable constructor.

But let me show you an example.

import { Subject } from 'rxjs';
 
const subject = new Subject<number>();
 
subject.subscribe({
  next: (v) => console.log(new Date().toLocaleTimeString(), `observerA: ${v}`),
  complete: () => console.log(new Date().toLocaleTimeString(), 'observerA: complete')
});
 
subject.next(1);

setTimeout(() => {
  subject.subscribe({
  next: (v) => console.log(new Date().toLocaleTimeString(), `observerB: ${v}`),
  complete: () => console.log(new Date().toLocaleTimeString(), 'observerB: complete')
});
}, 2000);

setTimeout(() => {
  subject.next(2);
}, 3000);

setTimeout(() => {
  subject.complete();
}, 4000);

18:52:23 observerA: 1
18:52:26 observerA: 2
18:52:26 observerB: 2
18:52:27 observerA: complete
18:52:27 observerB: complete

As you can see, with a Subject we can emit new values, subscribe to its changes, and complete the subject. I recommend you to try this special observable because it can be powerful in many cases.

The RxJS library does not stop its power here. It exposes us four different types of subjects: Subject, BehaviorSubject, ReplaySubject and AsyncSubject. These four types have 4 different behaviour that can help us to resolve different cases. Let me show you these differences.

subject

A Subject is like an Observable, but can multicast to many Observers. Subjects are like EventEmitters: they maintain a registry of many listeners.

import { Subject } from 'rxjs';
 
const subject = new Subject<number>();
 
subject.subscribe({
  next: (v) => console.log(new Date().toLocaleTimeString(), `observerA: ${v}`),
  complete: () => console.log(new Date().toLocaleTimeString(), 'observerA: complete')
});
 
subject.next(1);

setTimeout(() => {
    subject.subscribe({
        next: (v) => console.log(new Date().toLocaleTimeString(), `observerB: ${v}`),
        complete: () => console.log(new Date().toLocaleTimeString(), 'observerB: complete')
    });
}, 1000);

setTimeout(() => {
  subject.next(2);
}, 3000);

setTimeout(() => {
  subject.complete();
}, 4000);

19:14:41 observerA: 1
19:14:44 observerA: 2
19:14:44 observerB: 2
19:14:45 observerA: complete
19:14:45 observerB: complete

This subject can be used when we need to emit values and notify some of these. This subject doesn't have an initial value and if an observer subscribes to this type of subject it receives only the values emitted after its subscription.

N.B. In some cases, we don't need to send a value when we call the next method of the subject, but we just need to call the method to notify some of these. In these cases, we can use the Void Subject, a special subject that does not need a value.

behaviorsubject

BehaviorSubjects are useful for representing "values over time". For instance, an event stream of birthdays is a Subject, but the stream of a person's age would be a BehaviorSubject.

import { BehaviorSubject } from 'rxjs';
 
const subject = new BehaviorSubject<number>(0);
 
subject.subscribe({
  next: (v) => console.log(new Date().toLocaleTimeString(), `observerA: ${v}`),
  complete: () => console.log(new Date().toLocaleTimeString(), 'observerA: complete')
});
 
subject.next(1);

setTimeout(() => {
    subject.subscribe({
        next: (v) => console.log(new Date().toLocaleTimeString(), `observerB: ${v}`),
        complete: () => console.log(new Date().toLocaleTimeString(), 'observerB: complete')
    });
}, 1000);

setTimeout(() => {
  subject.next(2);
}, 3000);

setTimeout(() => {
  subject.complete();
}, 4000);

19:15:57 observerA: 0
19:15:57 observerA: 1
19:15:58 observerB: 1
19:16:00 observerA: 2
19:16:00 observerB: 2
19:16:01 observerA: complete
19:16:01 observerB: complete

The BehaviorSubject is a subject that requires an initial value. When an observer subscribes to a BehaviorSubject it immediately receives the last emitted value and then it waits for the future values.

replaysubject

A ReplaySubject records multiple values from the Observable execution and replays them to new subscribers.

import { ReplaySubject } from 'rxjs';
 
const subject = new ReplaySubject<number>();
 
subject.subscribe({
  next: (v) => console.log(new Date().toLocaleTimeString(), `observerA: ${v}`),
  complete: () => console.log(new Date().toLocaleTimeString(), 'observerA: complete')
});
 
subject.next(1);

setTimeout(() => {
  subject.next(2);
}, 1000);

setTimeout(() => {
    subject.subscribe({
        next: (v) => console.log(new Date().toLocaleTimeString(), `observerB: ${v}`),
        complete: () => console.log(new Date().toLocaleTimeString(), 'observerB: complete')
    });
}, 2000);

setTimeout(() => {
  subject.next(3);
}, 3000);

setTimeout(() => {
  subject.complete();
}, 4000);

19:17:37 observerA: 1
19:17:38 observerA: 2
19:17:39 observerB: 1
19:17:39 observerB: 2
19:17:40 observerA: 3
19:17:40 observerB: 3
19:17:41 observerA: complete
19:17:41 observerB: complete

The ReplaySubject is a subject that doesn't require an initial value but when an observer subscribes to it, it receives immediately all the values already emitted and after that, it waits for the future values.

asyncsubject

The AsyncSubject is a variant where only the last value of the Observable execution is sent to its observers, and only when the execution completes.

import { AsyncSubject } from 'rxjs';
 
const subject = new AsyncSubject<number>();
 
subject.subscribe({
  next: (v) => console.log(new Date().toLocaleTimeString(), `observerA: ${v}`),
  complete: () => console.log(new Date().toLocaleTimeString(), 'observerA: complete')
});
 
subject.next(1);

setTimeout(() => {
    subject.subscribe({
        next: (v) => console.log(new Date().toLocaleTimeString(), `observerB: ${v}`),
        complete: () => console.log(new Date().toLocaleTimeString(), 'observerB: complete')
    });
}, 1000);

setTimeout(() => {
  subject.next(2);
}, 3000);

setTimeout(() => {
  subject.complete();
}, 4000);

19:19:01 observerA: 2
19:19:01 observerB: 2
19:19:01 observerA: complete
19:19:01 observerB: complete

The AsyncSubject is a subject that does not emit values until it is completed, at the time of its completion it emits the last value executed.

These are the differences between these subjects, it's important to remember these differences because if you choose the wrong subject you could do unexpected mistakes.

Before ending the article let me show you a best practice to expose our subject to the consumers. If you need to hide to your consumers that your Observable is a Subject, you need to expose the subject using its "asObservable" method. This method returns the subject as an Observable, so the consumer can't call the "next" and "complete" methods.

Ok guys, that's all for today, I recommend you to play with these subject to understand better their power and characteristics.

See you soon Bye Bye

RxJS - Custom Operators

Mon, 04 Oct 2021 00:00:00 GMT

Hi Folks 👋 after many articles in which I have illustrated the different types of operators already included in the RxJS library, today I show you how to create your own operators. You can create a new operator in two ways: mixing the different operators illustrated in the previous articles or from scratch. In common cases, when we need to create a new operator, all the behaviours that we need already exist in the operators exposed by the RxJS library. In these cases, we can use the "pipe" function to combine together the operators. With the "pipe" function you can create a new function that will be the new operator, and inside this function you can create the logic of your operator. Here's an example

import { delay, interval, Observable, pipe, take, tap, UnaryFunction } from 'rxjs';

function takeLogAndDelay<T>(takeNumber: number, message: string, time: number): UnaryFunction<Observable<T>, Observable<T>> {
  return pipe(
    tap(x => console.log(message, x)),
    take(takeNumber),
    delay(time),
  );
}

interval(1000).pipe(
    takeLogAndDelay(10, 'Source', 2000)
).subscribe();

Source 0
Source 1
Source 2
Source 3
Source 4
Source 5
Source 6
Source 7
Source 8
Source 9

As you can see, in the last example I created a new operator called "takeLogAndDelay". This operator combines together three operators: tap, take and delay. As you can see, it's easy to create a new operator of this type and you just need to flow these rules:

create a new function with the name of the new operator
return the pipe function
combine the operators in the pipe function

In 95% of your cases, you can resolve your problem and create a new operator using this method, while in the 5% of the cases not managed by this method you can create a new operator from scratch. Below an example of the delay operator created from scratch.

import { Observable, of } from 'rxjs';
import { tap } from 'rxjs/operators';

function delay<T>(delayInMs: number) {
  return (observable: Observable<T>) =>
    new Observable<T>((subscriber) => {
      const allTimerIDs = new Set<NodeJS.Timeout>();
      let hasCompleted = false;
      const subscription = observable.subscribe({
        next(value) {
          const timerID = setTimeout(() => {
            subscriber.next(value);
            allTimerIDs.delete(timerID);
            if (hasCompleted && allTimerIDs.size === 0) {
              subscriber.complete();
            }
          }, delayInMs);

          allTimerIDs.add(timerID);
        },
        error: subscriber.error,
        complete() {
          hasCompleted = true;
          if (allTimerIDs.size === 0) {
            subscriber.complete();
          }
        },
      });

      return () => {
        subscription.unsubscribe();
        allTimerIDs.forEach((timerID) => clearTimeout(timerID));
      };
    });
}

of(1, 2, 3).pipe(
    tap((value) => console.log(new Date().toLocaleTimeString(), "before", value)),
    delay(3000)
).subscribe({
    next: (value) => console.log(new Date().toLocaleTimeString(), "after", value),
});

22:11:01 before 1
22:11:01 before 2
22:11:01 before 3
22:11:04 after 1
22:11:04 after 2
22:11:04 after 3

As you can see, we can create a new operator and manage all the behaviours needed for our logic using the Observable constructor. It's rare to use this approach but if you find yourself in front of a case not yet solved by the existing operators, you can rely on it.

Ok guys, that's all for today.

See you soon Bye bye 👋

RxJS - Multicast Operator

Fri, 01 Oct 2021 00:00:00 GMT

Hi Folk 👋, in the previous articles we've seen that when we subscribe to an observable, the observable restarts every time and do not remember the last value emitted. In some cases, this behaviour can not be the right solution, so today I'll show you how to share the values using the Multicast Operators.

share

Returns a new Observable that multicasts (shares) the original Observable. As long as there is at least one Subscriber this Observable will be subscribed and emitting data. When all subscribers have unsubscribed it will unsubscribe from the source Observable. Because the Observable is multicasting it makes the stream hot.

/**
marble share
{
    source a:           +--0-1-2-3-4-#
    operator share:     {
        +--0-1-2-3-4-#
        ......+2-3-4-#
    }
}
*/
import { interval } from 'rxjs';
import { share, take, tap } from 'rxjs/operators';
 
const source1 = interval(1000)
.pipe(
    take(5),
    tap((x: number) => console.log('Processing: ', x)),
    share()
);

source1.subscribe({
    next: x => console.log('subscription 1: ', x),
    complete: () => console.log('subscription 1 complete'),
});

setTimeout(() => {
    source1.subscribe({
        next: x => console.log('subscription 2: ', x),
        complete: () => console.log('subscription 2 complete'),
    });
}, 3000);


setTimeout(() => {
    source1.subscribe({
        next: x => console.log('subscription 3: ', x),
        complete: () => console.log('subscription 3 complete'),
    });
}, 7000);

Processing:  0
subscription 1:  0
Processing:  1
subscription 1:  1
Processing:  2
subscription 1:  2
subscription 2:  2
Processing:  3
subscription 1:  3
subscription 2:  3
Processing:  4
subscription 1:  4
subscription 2:  4
subscription 1 complete
subscription 2 complete
Processing:  0
subscription 3:  0
Processing:  1
subscription 3:  1
Processing:  2
subscription 3:  2
Processing:  3
subscription 3:  3
Processing:  4
subscription 3:  4
subscription 3 complete

This operator can help us when we need to share the value of an observable during its execution. But what does it mean? It means that the first subscription starts the observable and all the next subscriptions that subscribe to this observable do not run a new instance of the observable but they receive the same values of the first subscription, thus losing all the previous values emitted before their subscription. It's important to remember that when the observable is completed, and another observer subscribes itself to the observable, the shared operator resets the observable and restarts its execution from the beginning. Anyway, sometimes our code needs to prevent the restarting of our observables, but what can we do in these cases? It's simple! The share operator exposes us some options: resetOnComplete, resetOnError, resetOnRefCountZero, and each of these options can help us to prevent the resetting of the observables in different cases. These options can work or with a simple boolean value that enables or disables the behaviour, or we can pass a notifier factory that returns an observable which grants more fine-grained control over how and when the reset should happen. The resetOnComplete option prevents the resetting after the observable's completion. So, if it is enabled when another observer subscribes to an observable already completed this observer receives immediately the complete notification. The resetOnError option prevents the resetting of the observable after an error notification. The resetOnRefCountZero option works with the number of observers subscribed instead. It prevents the resetting if there aren't any observer subscribed. To better understand, if all the subscriptions of our observable are unsubscribed, and this option is enabled, the observable isn't reset. otherwise, if this option is disabled, the observable restarts from the beginning at the next subscription. Here's an example using the resetOnRefCountZero option.

import { interval, timer } from 'rxjs';
import { share, take } from 'rxjs/operators';
 
const source = interval(1000).pipe(take(3), share({ resetOnRefCountZero: () => timer(1000) }));
 
const subscriptionOne = source.subscribe(x => console.log('subscription 1: ', x));
setTimeout(() => subscriptionOne.unsubscribe(), 1300);

setTimeout(() => source.subscribe(x => console.log('subscription 2: ', x)), 1700);

setTimeout(() => source.subscribe(x => console.log('subscription 3: ', x)), 5000);

subscription 1:  0
subscription 2:  1
subscription 2:  2
subscription 3:  0
subscription 3:  1
subscription 3:  2

shareReplay

Share source and replay specified number of emissions on subscription.

import { interval } from 'rxjs';
import { shareReplay, take, tap } from 'rxjs/operators';

const obs$ = interval(1000);
const shared$ = obs$.pipe(
  take(4),
  tap(console.log),
  shareReplay(3)
);
shared$.subscribe(x => console.log('sub A: ', x));

setTimeout(() => {
  shared$.subscribe(y => console.log('sub B: ', y));
}, 3500);

0
sub A:  0
1
sub A:  1
2
sub A:  2
sub B:  0
sub B:  1
sub B:  2
3
sub A:  3
sub B:  3

In some cases, when we share the values between multiple observers, if an observer subscribes to an already started observable, we also need to replay all the previous already emitted values. To resolve this problem we can use the shareReplay operator. This operator shares the emitted values and if another observer subscribes to the observable it replays the previous values. The number of values replayed can be configured: by default all the values already emitted are emitted again, but we can also indicate or a maximum number of elements to remember or a maximum time length.

Ok guys, that's all for today. If you are interested in trying the code of this article, you can find it in the GitHub repository.

In the next article, I'll show you how to create your custom operators.

See you soon!

RxJS - Error Handling Operators

Wed, 29 Sep 2021 00:00:00 GMT

One of the best practice in our work is handle the errors, so today I'll show you some operators in RxJS to handle the errors. Let's start :)

catchError

Catches errors on the observable to be handled by returning a new observable or throwing an error.

import { of } from 'rxjs';
import { catchError, map } from 'rxjs/operators';
 
of('a', 'b', 'c', 'd', 1, 3).pipe(
    map((n: any) => n.toUpperCase()),
    catchError(err => {
        console.error(err.message);
        return of('A', 'B', 'C', 'D')
    }),
  )
  .subscribe(x => console.log(x));

A
B
C
D
n.toUpperCase is not a function
A
B
C
D

This operator is used to catch the errors during the execution of the observables. This operator helps us to handle the errors and prevent a bad flow of our users.

retry

import { of } from 'rxjs';
import { map, retry } from 'rxjs/operators';

function toString(val: { toString: () => string }): string | never {
    console.log('toString of', val);
    if (Math.random() > 0.6)
        return val.toString()

    console.log('toString of', val, 'failed');
    throw new Error('toString failed')
}
 
of(1, 2, 3, 4, 5, 6, 7, 8, 9, 0).pipe(
    map(toString),
    retry(3)
  )
  .subscribe({
      next: x => console.log(x),
      error: error => console.error(error.message),
  });

toString of 1
toString of 1 failed
toString of 1
toString of 1 failed
toString of 1
1
toString of 2
toString of 2 failed
toString of 1
toString of 1 failed
toString failed

This operator is used to retry the execution of an observable if it raises an error. We can indicate the max number of retries. If during the execution an observable raises a number of errors greater than the indicated value, the retry operator doesn't try anymore but goes out and raise the error.

retryWhen

Returns an Observable that mirrors the source Observable with the exception of an error. If the source Observable calls error, this method will emit the Throwable that caused the error to the Observable returned from notifier. If that Observable calls complete or error then this method will call complete or error on the child subscription. Otherwise this method will resubscribe to the source Observable.

import { interval, timer } from 'rxjs';
import { delayWhen, filter, map, retryWhen, tap } from 'rxjs/operators';
 
interval(1000).pipe(
  map(val => {
    if (val > 5) {
      throw val;
    }
    return val;
  }),
  retryWhen(errors =>
    errors.pipe(
      tap(val => console.log(`Value ${val} was too high!`)),
      filter((_, index) => index < 3),
      delayWhen(val => timer(val * 1000))
    )
  )
).subscribe({
    next: x => console.log(x),
    error: error => console.error(error.message),
});

0
1
2
3
4
5
Value 6 was too high!
0
1
2
3
4
5
Value 6 was too high!
0
1
2
3
4
5
Value 6 was too high!
0
1
2
3
4
5
Value 6 was too high!

This operator is used to retry the execution of an observable and it allows us to indicate the strategy of the retry.

I hope you have all the means now to better handle errors in your code. It's all for today. You can find all the code of this article in the repository

See you soon, Bye Bye!

RxJS - Conditional & Mathematical Operators

Mon, 27 Sep 2021 00:00:00 GMT

Hi Guys and welcome back, today I'll illustrate you two simple types of the pipeable operators: Conditional Operators and Mathematical Operators. No time to waste, let's start.

Conditional Operators

These operators are useful to check if there are values in the observables or to find some specific value in them. Some of these operators are similar to some array methods, with the difference that they work with observables and not with arrays.

defaultIfEmpty

Emits a given value if the source Observable completes without emitting any next value, otherwise mirrors the source Observable.

import { EMPTY, Observer } from "rxjs";
import { defaultIfEmpty } from "rxjs/operators";

const observer: Observer<number> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

EMPTY.pipe(
    defaultIfEmpty(10)
).subscribe(observer);

value 10
complete

This operator, as you can see, permits us to receive a default value if the observable does not emit any value.

every

Returns an Observable that emits whether or not every item of the source satisfies the condition specified.

import { Observer, of } from "rxjs";
import { every } from "rxjs/operators";

const observer: Observer<boolean> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

of(1,2,3,4,5,6,7,8,9).pipe(
    every(val => val < 10)
).subscribe(observer);

value true
complete

This operator is like the every method in the arrays. We can use it when we need to check if all the values of our observable meet a condition.

find

Emits only the first value emitted by the source Observable that meets some condition.

import { Observer, of } from "rxjs";
import { find } from "rxjs/operators";

const observer: Observer<number | undefined> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

of(1,2,3,4,5,6,7,8,9).pipe(
    find(val => val === 5)
).subscribe(observer);

value 5
complete

This operator is like the find method in the arrays. We can use it to find a value that meets a condition in our observable. It's important to remember that when the operator finds a value that matches our condition it completes the observable.

findIndex

Emits only the index of the first value emitted by the source Observable that meets some condition.

import { Observer, of } from "rxjs";
import { findIndex } from "rxjs/operators";

const observer: Observer<number> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

of(1,2,3,4,5,6,7,8,9).pipe(
    findIndex(val => val === 5)
).subscribe(observer);

value 4
complete

This operator is like the findIndex method in the arrays. We can use it to find the index of a value that meets a condition in our observable. It's important to remember that when the operator finds a value that matches our condition it completes the observable.

isEmpty

Emits false if the input Observable emits any values, or emits true if the input Observable completes without emitting any values.

import { EMPTY, Observer } from "rxjs";
import { isEmpty } from "rxjs/operators";

const observer: Observer<boolean> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

EMPTY.pipe(
    isEmpty()
).subscribe(observer);

value true
complete

This operator is used to check if an observable has emitted at least a value.

Mathematical Operators

These operators are used to retrieve some special values in our observables or to reduce the values.

count

Counts the number of emissions on the source and emits that number when the source is completed.

import { Observer, of } from "rxjs";
import { count } from "rxjs/operators";

const observer: Observer<number | undefined> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

of("a", "b", "c", "d", "e").pipe(
    count()
).subscribe(observer);

value 5
complete

This operator is used to count the values of our observables.

max

The Max operator operates on an Observable that emits numbers (or items that can be compared with a provided function), and when source Observable completes it emits a single item: the item with the largest value.

import { Observer, of } from "rxjs";
import { max } from "rxjs/operators";

const observer: Observer<string> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

of("a", "b", "e", "d", "c").pipe(
    max()
).subscribe(observer);

value e
complete

This operator is used to get the maximum value emitted by our observables.

min

The Min operator operates on an Observable that emits numbers (or items that can be compared with a provided function), and when source Observable completes it emits a single item: the item with the smallest value.

import { Observer, of } from "rxjs";
import { min } from "rxjs/operators";

const observer: Observer<string> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

of("a", "b", "e", "d", "c").pipe(
    min()
).subscribe(observer);

value a
complete

This operator is used to get the minimum value emitted by our observables.

reduce

Applies an accumulator function over the source Observable, and returns the accumulated result when the source completes, given an optional seed value.

import { Observer, of } from "rxjs";
import { reduce } from "rxjs/operators";

const observer: Observer<number> = {
    next: x => console.log('value', x),
    error: err => console.error('error', err),
    complete: () => console.log('complete'),
};

of(1,2,3,4,5,6,7,8,9).pipe(
    reduce((acc, curr) => acc + curr, 0)
).subscribe(observer);

value 45
complete

This operator is like the reduce method of the array. It can be used to reduce all the emitted values. The reduced algorithm has to be implemented by us.

Ok, That's all for today. I hope these simple operators can help you in the future as they did me.

See you in the next article!

You can find the code of this article in the GitHub repository.

RxJS - Utility Operators

Fri, 24 Sep 2021 00:00:00 GMT

Welcome back Guys, Today I'll show you some utility operators. Let's start :)

tap

Used to perform side-effects for notifications from the source observable

import { of } from 'rxjs'
import { tap } from 'rxjs/operators'


of('a', 'b', 'c')
  .pipe(
      tap({
          next: x => console.log(`tap: ${x}`),
          complete: () => console.log('tap: complete'),
          error: err => console.log(`tap: error: ${err}`)
      })
  )
  .subscribe()

tap: a
tap: b
tap: c
tap: complete

This operator helps us to get some info about the observable during its execution. This operator is equal to the subscriber and it uses three methods to get info: next, complete, and error. What could happen in these three methods? Exactly what you want :) You can run a side-effect or log the values. Usually I prefer logging info in this operator and not run side effects because at times side effects are difficult to test.

delay

Delays the emission of items from the source Observable by a given timeout or until a given Date.

import { of } from 'rxjs'
import { delay, tap } from 'rxjs/operators'


of('a', 'b', 'c')
  .pipe(
      tap(x => console.log(`${new Date().toLocaleTimeString()} tap before delay: ${x}`)),
      delay(1000),
      tap(x => console.log(`${new Date().toLocaleTimeString()} tap after delay: ${x}`)),
  )
  .subscribe()

17:08:26 tap before delay: a
17:08:26 tap before delay: b
17:08:26 tap before delay: c
17:08:27 tap after delay: a
17:08:27 tap after delay: b
17:08:27 tap after delay: c

This operator is used to wait some specific time before emitting the value.

timestamp

Attaches a timestamp to each item emitted by an observable indicating when it was emitted

import { of } from 'rxjs'
import { timestamp } from 'rxjs/operators'

of('a', 'b', 'c')
  .pipe(
      timestamp()
  )
  .subscribe(console.log)

{ value: 'a', timestamp: 1629385746523 }
{ value: 'b', timestamp: 1629385746528 }
{ value: 'c', timestamp: 1629385746528 }

This operator is used to attach a timestamp to each emitted item. The timestamp indicates the time when the value was emitted. This operator can be helpful during debugging or if we need to have info about the time emission of the value.

timeout

Errors if Observable does not emit a value in given time span.

import { Observable, throwError } from 'rxjs';
import { timeout } from 'rxjs/operators';

const source$ = new Observable<number>(subscriber => {
    let id: NodeJS.Timeout | undefined
    (function next(count = 0) {
        if (count > 10) {
            subscriber.complete();
            return;
        }
        id = setTimeout(() => {
            subscriber.next(count)
            next(count + 1)
        }, Math.random() > 0.9 ? 2000 : 1000);
    })()

    return () => {
        if (id) {
            clearTimeout(id);
        }
    }

})

source$
  .pipe(
      timeout({ each: 1500, with: info => throwError(() => new Error(`Timeout ${1500}ms: info: ${JSON.stringify(info)}`)) }),
  )
  .subscribe({
      next: console.log,
      error: error => {
          console.error(`Something Wrong!`)
          console.error(error.message)
      }
  })

0
1
2
3
4
5
6
7
8
Something Wrong!
Timeout 1500ms: info: {"meta":null,"lastValue":null,"seen":9}

This operator checks the time of the execution of the observable, if the value is not emitted within the timeout time the operator throws an error.

toArray

Collects all source emissions and emits them as an array when the source completes.

import { of } from 'rxjs'
import { toArray } from 'rxjs/operators'


of('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h')
  .pipe(
      toArray()
  )
  .subscribe(console.log)

[
  'a', 'b', 'c',
  'd', 'e', 'f',
  'g', 'h'
]

This operator converts a sequence of values in one array, where all the array's items are the emitted values in sequence.

Ok Guys, from the Utilities Operators is all. in the GitHub repository you can find all the code of this article.

See you soon, Bye Bye!

RxJS - Join Operators

Wed, 22 Sep 2021 00:00:00 GMT

Hi Guys and Welcome Back, Today I'll speak about the Join Operators. Some of these operators are similar to other operators shown in the Creation Operators but they are used in different contexts, ok let's start!

combineLatestAll

Flattens an Observable-of-Observables by applying combineLatest when the Observable-of-Observables completes.

import { interval, timer } from 'rxjs';
import { combineLatestAll, map, take } from 'rxjs/operators';

const A_CHAR_CODE = 65
const createSource = (index: number) =>
    interval((index + 1) * 1000).pipe(
        take(3),
        map(value => `${String.fromCharCode(A_CHAR_CODE + index)}${String.fromCharCode(A_CHAR_CODE + value)}`)
    )

console.log(`${new Date().toLocaleTimeString()}: combineLatestAll start`)
const source$ = timer(0, 1000).pipe(
    take(3)
);
source$.pipe(
    map(createSource),
    combineLatestAll()
).subscribe({
    next: val => console.log(`${new Date().toLocaleTimeString()}: combineLatestAll`, val)
});

16:22:07: combineLatestAll start
16:22:12: combineLatestAll [ 'AB', 'BA', 'CA' ]
16:22:12: combineLatestAll [ 'AC', 'BA', 'CA' ]
16:22:13: combineLatestAll [ 'AC', 'BB', 'CA' ]
16:22:15: combineLatestAll [ 'AC', 'BB', 'CB' ]
16:22:15: combineLatestAll [ 'AC', 'BC', 'CB' ]
16:22:18: combineLatestAll [ 'AC', 'BC', 'CC' ]

As you can see, this operator is the brother of the combineLatest operator discussed in a previous article RxJS - Creation Operators. Its job is to convert an Observable of Observables to an array of values, where each item of this array is a value of an observable. When we use this operator we need to remember that the first value emitted by the operator is when all the observables have emitted at least one value. This operator is used when in the pipe chain we have an operator that emits a list of observables; using this operator we can flat the values in a single array including all the values emitted by these observables.

concatAll

Converts a higher-order Observable into a first-order Observable by concatenating the inner Observables in order.

import { interval, timer } from 'rxjs';
import { concatAll, map, take } from 'rxjs/operators';

const createSource = (index: number) => interval(index * 1000).pipe(
        take(3),
        map(value => `${index}-${value + 1}`)
    )

console.log(`${new Date().toLocaleTimeString()}: concatAll start`)
const source$ = timer(0, 1000).pipe(
    take(3)
);
source$.pipe(
    map(v => createSource(v + 1)),
    concatAll()
).subscribe({
    next: val => console.log(`${new Date().toLocaleTimeString()}: concatAll`, val)
});

15:38:29: concatAll start
15:38:30: concatAll 1-1
15:38:31: concatAll 1-2
15:38:32: concatAll 1-3
15:38:34: concatAll 2-1
15:38:36: concatAll 2-2
15:38:38: concatAll 2-3
15:38:41: concatAll 3-1
15:38:44: concatAll 3-2
15:38:47: concatAll 3-3

The concatAll operator concatenates an Observable of Observables and emits all the observables in sequence. It's important to remember that when we use this operator, the observables are running one after the other, so the operator executes the first observable until it isn't completed, then it passes to the second observable, and so on. This operator is used when we have in a pipe chain an operator that returns a list of observables and we need to execute them in sequence.

exhaustAll

Converts a higher-order Observable into a first-order Observable by dropping inner Observables while the previous inner Observable has not yet completed.

import { interval, timer } from 'rxjs';
import { exhaustAll, map, take } from 'rxjs/operators';

const createSource = (index: number) => interval(index * 1000).pipe(
        take(3),
        map(value => `${index}-${value + 1}`)
    )

console.log(`${new Date().toLocaleTimeString()}: exhaustAll start`)
const source$ = timer(0, 2500).pipe(
    take(3)
);
source$.pipe(
    map(v => createSource(v + 1)),
    exhaustAll()
).subscribe({
    next: val => console.log(`${new Date().toLocaleTimeString()}: exhaustAll`, val)
});

16:27:05: exhaustAll start
16:27:07: exhaustAll 1-1
16:27:08: exhaustAll 1-2
16:27:09: exhaustAll 1-3
16:27:14: exhaustAll 3-1
16:27:17: exhaustAll 3-2
16:27:20: exhaustAll 3-3

mergeAll

Converts a higher-order Observable into a first-order Observable which concurrently delivers all values that are emitted on the inner Observables.

import { interval, timer } from 'rxjs';
import { map, mergeAll, take } from 'rxjs/operators';

const createSource = (index: number) => interval(index * 1000).pipe(
        take(3),
        map(value => `${index}-${value + 1}`),
    )

console.log(`${new Date().toLocaleTimeString()}: mergeAll start`)
const source$ = timer(0, 1000).pipe(
    take(3),
);
source$.pipe(
    map(v => createSource(v + 1)),
    mergeAll()
).subscribe({
    next: val => console.log(`${new Date().toLocaleTimeString()}: mergeAll`, val)
});

15:41:46: mergeAll start
15:41:47: mergeAll 1-1
15:41:48: mergeAll 1-2
15:41:49: mergeAll 2-1
15:41:49: mergeAll 1-3
15:41:51: mergeAll 3-1
15:41:51: mergeAll 2-2
15:41:53: mergeAll 2-3
15:41:54: mergeAll 3-2
15:41:57: mergeAll 3-3

switchAll

Converts a higher-order Observable into a first-order Observable producing values only from the most recent observable sequence

import { interval, timer } from 'rxjs';
import { map, switchAll, take } from 'rxjs/operators';

const createSource = (index: number) => interval(index * 1000).pipe(
        take(3),
        map(value => `${index}-${value + 1}`)
    )

console.log(`${new Date().toLocaleTimeString()}: switchAll start`)
const source$ = timer(0, 1000).pipe(
    take(3)
);
source$.pipe(
    map(v => createSource(v + 1)),
    switchAll()
).subscribe({
    next: val => console.log(`${new Date().toLocaleTimeString()}: switchAll`, val)
});

15:42:48: switchAll start
15:42:49: switchAll 1-1
15:42:53: switchAll 3-1
15:42:56: switchAll 3-2
15:42:59: switchAll 3-3

startWith

Returns an observable that, at the moment of subscription, will synchronously emit all values provided to this operator, then subscribe to the source and mirror all of its emissions to subscribers.

import { of } from 'rxjs';
import { startWith } from 'rxjs/operators';

const source1$ = of(1, 2, 3).pipe(
    startWith(1000)
)

source1$.subscribe({
    next: val => console.log(`${new Date().toLocaleTimeString()}: startWith`, val)
});

15:43:47: startWith 1000
15:43:47: startWith 1
15:43:47: startWith 2
15:43:47: startWith 3

withLatestFrom

Combines the source Observable with other Observables to create an Observable whose values are calculated from the latest values of each, only when the source emits.


import { interval } from 'rxjs';
import { take, withLatestFrom } from 'rxjs/operators';

const source1$ = interval(1000).pipe(
    take(5)
)
const source2$ = interval(2500).pipe(
    take(5)
)

console.log(`${new Date().toLocaleTimeString()}: withLatestFrom start`)
source1$.pipe(
    withLatestFrom(source2$)
).subscribe({
    next: val => console.log(`${new Date().toLocaleTimeString()}: withLatestFrom`, val)
});

15:44:11: withLatestFrom start
15:44:14: withLatestFrom [ 2, 0 ]
15:44:15: withLatestFrom [ 3, 0 ]
15:44:16: withLatestFrom [ 4, 1 ]

Ok guys, that's all for today! You can find the code of this article in the GitHub repository

See you soon!

RxJS - Transformation Operators

Mon, 20 Sep 2021 00:00:00 GMT

Welcome back, Today I'll speak about the Transformation Operators. These operators are used to modify the value received. But cut the chatter, and let's start.

map

Applies a given project function to each value emitted by the source Observable, and emits the resulting values as an Observable.

import { interval } from 'rxjs';
import { map, take, tap } from 'rxjs/operators';

const source$ = interval(1000, ).pipe(
    take(5),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Generated`, val);
    }),
)

source$.pipe(
    map(value => Math.pow(value, 2))
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: map`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: map: complete`),
})

16:58:51: Generated 0
16:58:51: map 0
16:58:52: Generated 1
16:58:52: map 1
16:58:53: Generated 2
16:58:53: map 4
16:58:54: Generated 3
16:58:54: map 9
16:58:55: Generated 4
16:58:55: map 16
16:58:55: map: complete

The map operator is like the map function of the arrays. It transforms the value using the function passed as an argument.

mapTo

Emits the given constant value on the output Observable every time the source Observable emits a value.

import { interval } from 'rxjs';
import { mapTo, take, tap } from 'rxjs/operators';

const source1$ = interval(1000).pipe(
    take(5),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Source1 Generated`, val);
    }),
)

console.log(`${new Date().toLocaleTimeString()}: mapTo: start`)
source1$.pipe(
    mapTo(1000)
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: mapTo`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: mapTo: complete`),
})

17:03:01: mapTo: start
17:03:02: Source1 Generated 0
17:03:02: mapTo 1000
17:03:03: Source1 Generated 1
17:03:03: mapTo 1000
17:03:04: Source1 Generated 2
17:03:04: mapTo 1000
17:03:05: Source1 Generated 3
17:03:05: mapTo 1000
17:03:06: Source1 Generated 4
17:03:06: mapTo 1000
17:03:06: mapTo: complete

The operator is similar to the map operator, but it returns a fixed value that does not depend on the source.

Now I start to talk about the operators: concat, exhaust, merge and switch. These operators are similar to the others but they have some minimum differences that change their behaviour, and if you choose the wrong implementations you may not have the aspected result.

concatMap

Projects each source value to an Observable which is merged in the output Observable, in a serialized fashion waiting for each one to complete before merging the next.

import { interval, Observable, of } from 'rxjs';
import { concatMap, delay, take, tap } from 'rxjs/operators';

const powWithDelay$ = (value: number): Observable<number> => of(Math.pow(value, 2)).pipe(delay(2000))

const source$ = interval(1000).pipe(
    take(5),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Generated`, val);
    }),
)

source$.pipe(
    concatMap(value => powWithDelay$(value))
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: concatMap`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: concatMap: complete`),
})

17:54:07: Generated 0
17:54:08: Generated 1
17:54:09: Generated 2
17:54:09: concatMap 0
17:54:10: Generated 3
17:54:11: Generated 4
17:54:11: concatMap 1
17:54:13: concatMap 4
17:54:15: concatMap 9
17:54:17: concatMap 16
17:54:17: concatMap: complete

This operator is used to concatenate different observables. The first source starts to emit the values, and the concatMap operator runs another observable for every value. The result values of the last observables are emitted as results of the operator concat. You should remember that the concatMap operator runs only one value at a time. You can notice from the previous examples that the values 0,1 and 2 are emitted before the result of the first concatMap (0), and after that, you can notice the emission of the values 3 and 4 before the result of the second emitted value. The particular behaviour of the concatMap operator is better visible after the last generated value from the first source (4) because we can see all the concatMap results emitted every 2 seconds from each other.

Here's the marble diagram to explain better the behaviour:

concatMapTo

Projects each source value to the same Observable which is merged multiple times in a serialized fashion on the output Observable.

import { interval } from 'rxjs';
import { concatMapTo, skip, take, tap } from 'rxjs/operators';

const source1$ = interval(1000, ).pipe(
    skip(2),
    take(2),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Source1 Generated`, val);
    }),
)

const source2$ = interval(2000, ).pipe(
    take(2),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Source2 Generated`, val);
    }),
)

console.log(`${new Date().toLocaleTimeString()}: concatMapTo: start`)
source1$.pipe(
    concatMapTo(source2$)
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: concatMapTo`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: concatMapTo: complete`),
})

18:12:28: concatMapTo: start
18:12:31: Source1 Generated 2
18:12:32: Source1 Generated 3
18:12:33: Source2 Generated 0
18:12:33: concatMapTo 0
18:12:35: Source2 Generated 1
18:12:35: concatMapTo 1
18:12:37: Source2 Generated 0
18:12:37: concatMapTo 0
18:12:39: Source2 Generated 1
18:12:39: concatMapTo 1
18:12:39: concatMapTo: complete

This operator is like the concatMap apart from the fact that it returns another observable that does not depend on the value received. It can be used when an observable emit a value and we need to run another observable. For example, we have a source that is a timer, and on every tick, we need to call an API. If we use the concatMapTo we can implement this solution easier.

exhaustMap

Projects each source value to an Observable which is merged in the output Observable only if the previous projected Observable has completed.

import { interval, Observable, of } from 'rxjs';
import { delay, exhaustMap, take, tap } from 'rxjs/operators';

const powWithDelay$ = (value: number): Observable<number> => of(Math.pow(value, 2)).pipe(delay(2000))

const source$ = interval(1000, ).pipe(
    take(5),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Generated`, val);
    }),
)

source$.pipe(
    exhaustMap(value => powWithDelay$(value))
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: exhaustMap`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: exhaustMap: complete`),
})

18:17:47: Generated 0
18:17:48: Generated 1
18:17:49: Generated 2
18:17:49: exhaustMap 0
18:17:50: Generated 3
18:17:51: Generated 4
18:17:52: exhaustMap 9
18:17:52: exhaustMap: complete

The exhaustMap operator syntactically is equal to the concat operator, but it has a different behavior: this operator during the execution of a projection ignores all other values received until the execution is not ended. If you see the result in the console of the before example, you can notice that the power of the values 1, 2, and 4 has never been shown.

The marble diagram of the exhaustMap operator in the previous example:

mergeMap

Projects each source value to an Observable which is merged in the output Observable.

import { interval, Observable, of } from 'rxjs';
import { delay, mergeMap, take, tap } from 'rxjs/operators';

const powWithDelay$ = (value: number): Observable<number> => of(Math.pow(value, 2)).pipe(delay(2000))

const source$ = interval(1000, ).pipe(
    take(5),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Generated`, val);
    }),
)

source$.pipe(
    mergeMap(value => powWithDelay$(value))
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: mergeMap`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: mergeMap: complete`),
})

18:18:16: Generated 0
18:18:17: Generated 1
18:18:18: Generated 2
18:18:18: mergeMap 0
18:18:19: mergeMap 1
18:18:19: Generated 3
18:18:20: mergeMap 4
18:18:20: Generated 4
18:18:21: mergeMap 9
18:18:22: mergeMap 16
18:18:22: mergeMap: complete

The mergeMap operator is syntactically like concat and exhaust but it executes the projection as soon as a value arrives. This behaviour can open some strange cases, for example, it's not guaranteed the order of the result values with the order of the source values. Let me give an example: we have a source that emits some values every 500ms, in the mergeMap operator we call an http API; the first value calls the API and the response arrives after 1.5seconds, the second value calls the same api but the response arrives after 200ms. The mergeMap operator in this case emits the result of the second value primarily and the result of the first one secondly. As you can imagine, in some cases this behaviour can be wrong or unexpected, so, if you need to use the mergeMap operator, remember what I said before and ask yourself if it can produce some side effects or if it is the right solution of your problems.

Here is the MergeMap marble Diagram of the previous example:

mergeMapTo

Projects each source value to the same Observable which is merged multiple times in the output Observable.

import { interval } from 'rxjs';
import { mergeMapTo, skip, take, tap } from 'rxjs/operators';

const source1$ = interval(1000, ).pipe(
    skip(2),
    take(2),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Source1 Generated`, val);
    }),
)

const source2$ = interval(2000, ).pipe(
    take(2),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Source2 Generated`, val);
    }),
)

console.log(`${new Date().toLocaleTimeString()}: mergeMap: start`)
source1$.pipe(
    mergeMapTo(source2$)
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: mergeMap`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: mergeMap: complete`),
})

18:18:53: mergeMap: start
18:18:56: Source1 Generated 2
18:18:57: Source1 Generated 3
18:18:58: Source2 Generated 0
18:18:58: mergeMap 0
18:18:59: Source2 Generated 0
18:18:59: mergeMap 0
18:19:00: Source2 Generated 1
18:19:00: mergeMap 1
18:19:01: Source2 Generated 1
18:19:01: mergeMap 1
18:19:01: mergeMap: complete

This operator is like the mergeMap apart from the fact that it returns another observable that does not depend on the value received. It can be used when an observable emits a value and we need to run another observable. In simple words, it's like the concatMapTo with the behaviour of the mergeMap operator behind the scene.

switchMap

Projects each source value to an Observable which is merged in the output Observable, emitting values only from the most recently projected Observable.

import { interval, Observable, of } from 'rxjs';
import { delay, switchMap, take, tap } from 'rxjs/operators';

const powWithDelay$ = (value: number): Observable<number> => of(Math.pow(value, 2)).pipe(delay(2000))

const source$ = interval(1000, ).pipe(
    take(5),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Generated`, val);
    }),
)

source$.pipe(
    switchMap(value => powWithDelay$(value))
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: switchMap`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: switchMap: complete`),
})

18:19:16: Generated 0
18:19:17: Generated 1
18:19:18: Generated 2
18:19:19: Generated 3
18:19:20: Generated 4
18:19:22: switchMap 16
18:19:22: switchMap: complete

The switchMap operator is syntactically like concat, exhaust and merge. It executes the projection as soon as a value arrives, but when a new value arrives, if the projection of the previous value is in execution, it kills it and starts the execution of the projection for the new value. It can be used for example for searching the data of an autocomplete input. When the user types a new letter and emits a new value, with this operator we can stop the previous search if it's on execution and start the new one.

Here is the SwitchMap marble Diagram of the previous example:

switchMapTo

Projects each source value to the same Observable which is flattened multiple times with switchMap in the output Observable.

import { interval } from 'rxjs';
import { skip, switchMapTo, take, tap } from 'rxjs/operators';

const source1$ = interval(1000, ).pipe(
    skip(2),
    take(2),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Source1 Generated`, val);
    }),
)

const source2$ = interval(2000, ).pipe(
    take(2),
    tap(val => {
        console.log(`${new Date().toLocaleTimeString()}: Source2 Generated`, val);
    }),
)

console.log(`${new Date().toLocaleTimeString()}: switchMap: start`)
source1$.pipe(
    switchMapTo(source2$)
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: switchMap`, value),
    complete: () => console.log(`${new Date().toLocaleTimeString()}: switchMap: complete`),
})

18:19:38: switchMap: start
18:19:41: Source1 Generated 2
18:19:42: Source1 Generated 3
18:19:44: Source2 Generated 0
18:19:44: switchMap 0
18:19:46: Source2 Generated 1
18:19:46: switchMap 1
18:19:46: switchMap: complete

This operator is like the switchMap apart from the fact that it returns another observable that does not depend on the value received. It can be used when an observable emits a value and we need to run another observable. In simple words, it's like the concatMapTo or the mergeMapTo with the behaviour of the switchMap operator behind the scene.

with this operator, we have finish the explanation of the 4 "special" operators (concat, exhaust, merge and switch). As you can see they are similar to each other but if you choose the wrong one it can produces some unexpected side effects. I hope these examples can help you in future to choose the right operator for you

pairwise

Groups pairs of consecutive emissions together and emits them as an array of two values.

import { of } from 'rxjs';
import { pairwise } from 'rxjs/operators';

const source$ = of(1, 2, 3, 4, 5);

source$.pipe(
    pairwise()
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: pairwise`, value),
})

18:20:02: pairwise [ 1, 2 ]
18:20:02: pairwise [ 2, 3 ]
18:20:02: pairwise [ 3, 4 ]
18:20:02: pairwise [ 4, 5 ]

This operator is used to get as result a tuple where in the first index there is the previous value and in the second index there is the current value. As you can imagine, if your source emits only one value the pairwise operator will never emit a value.

scan

Useful for encapsulating and managing state. Applies an accumulator (or "reducer function") to each value from the source after an initial state is established -- either via a seed value (second argument), or from the first value from the source.

import { of } from 'rxjs';
import { scan } from 'rxjs/operators';

const source$ = of(1, 2, 3, 4, 5);

source$.pipe(
    scan((acc, curr) => acc + curr, 0)
)
.subscribe({
    next: value => console.log(`${new Date().toLocaleTimeString()}: scan`, value),
})

18:20:26: scan 1
18:20:26: scan 3
18:20:26: scan 6
18:20:26: scan 10
18:20:26: scan 15

This operator is similar to the reduce method of the array. We can create an accumulator and every time a new value is emitted from the source we can update this accumulator and return it as result.

Ok, that's all from the Transformation Operators, I hope this examples can help you in future and I hope you have achieved a clear idea of how and when to use these operators.

in the GitHub repository you can find all the code examples.

See you soon Guys Bye Bye!

RxJS - Filtering Operators

Fri, 17 Sep 2021 00:00:00 GMT

Welcome back Guys,

Today we'll start with the Filtering Operators. As you can imagine these operators are used to filter our sources. Well, let's get started.

auditTime

Ignores source values for duration milliseconds, then emits the most recent value from the source Observable, then repeats this process.

import { Observable } from "rxjs";
import { auditTime } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 10) {
      subscriber.next(++count);
    } else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

const result = input$.pipe(auditTime(2000));

result.subscribe({
  next: x =>
    console.log(
      `${new Date().toLocaleTimeString()} - [auditTime result]: ${x}`
    ),
});

11:15:25 - [auditTime result]: 2
11:15:27 - [auditTime result]: 4
11:15:29 - [auditTime result]: 6
11:15:31 - [auditTime result]: 8
11:15:33 - [auditTime result]: 10

This operator is particular: for the indicated time it ignores the emitted values, and when the time is passed, it emits the last value emitted from the source. It can be used when we have a source that emits a lot of values but we need to get only the value in a specific interval, for example, we have a temperature sensor that emits the temperature every second but we need to take the value every minute, using auditTime we can get the last value of every minute.

debounceTime

Emits a notification from the source Observable only after a particular time span has passed without another source emission.

import { Observable } from "rxjs";
import { debounceTime, tap } from "rxjs/operators";

const timesInSecond = [1, 0.5, 3, 1.5, 3, 1];

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  (function next() {
    const seconds = timesInSecond[count++];
    setTimeout(() => {
      subscriber.next(seconds);

      if (count > 5) {
        subscriber.complete();
        return;
      }

      next();
    }, seconds * 1000);
  })();
});

const result = input$.pipe(
  tap(x =>
    console.log(
      `${new Date().toLocaleTimeString()} - [before debounceTime]: ${x}`
    )
  ),
  debounceTime(2000)
);
result.subscribe({
  next: x =>
    console.log(
      `${new Date().toLocaleTimeString()} - [debounceTime result]: ${x}`
    ),
});

09:44:29 - [before debounceTime]: 1
09:44:29 - [before debounceTime]: 0.5
09:44:31 - [debounceTime result]: 0.5
09:44:32 - [before debounceTime]: 3
09:44:34 - [before debounceTime]: 1.5
09:44:36 - [debounceTime result]: 1.5
09:44:37 - [before debounceTime]: 3
09:44:38 - [before debounceTime]: 1
09:44:38 - [debounceTime result]: 1

After receiving a value, this operator waits for the indicated time before emitting the value. If during this time a new value is emitted, the operator ignores the previous value and waits again, otherwise, if nothing happens it emits the value. For example, this operator is used to manage the autocomplete text boxes that search items from an API; with this operator, we can prevent calling the API on every click on the keyboard but we can wait until the user finish writing some letters before executing the search.

throttleTime

Emits a value from the source Observable, then ignores subsequent source values for duration milliseconds, then repeats this process.

import { Observable } from "rxjs";
import { tap, throttleTime } from "rxjs/operators";

const timesInSecond = [1, 0.5, 3, 1.5, 3, 1];

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  (function next() {
    const seconds = timesInSecond[count++];
    setTimeout(() => {
      subscriber.next(seconds);

      if (count > 5) {
        subscriber.complete();
        return;
      }

      next();
    }, seconds * 1000);
  })();
});


const result = input$.pipe(
  tap(x =>
    console.log(
      `${new Date().toLocaleTimeString()} - [before throttleTime]: ${x}`
    )
  ),
  throttleTime(2000)
);
result.subscribe({
  next: x =>
    console.log(
      `${new Date().toLocaleTimeString()} - [throttleTime result]: ${x}`
    ),
});

10:41:46 - [before throttleTime]: 1
10:41:46 - [throttleTime result]: 1
10:41:46 - [before throttleTime]: 0.5
10:41:49 - [before throttleTime]: 3
10:41:49 - [throttleTime result]: 3
10:41:51 - [before throttleTime]: 1.5
10:41:54 - [before throttleTime]: 3
10:41:54 - [throttleTime result]: 3
10:41:55 - [before throttleTime]: 1

After receiving a value, this operator emits it and then waits for the indicated time. If during that time the source emits other values this operator ignores them, it repeats this process for life. This operator is commonly used to prevent multiple clicks in some buttons or to prevent many executions of an action in a small period.

distinct

Returns an Observable that emits all items emitted by the source Observable that are distinct by comparison from previous items.

import { Observable } from "rxjs";
import { distinct } from "rxjs/operators";

const input$ = new Observable<number | string>(subscriber => {
  let count = 0;
  const array = [1, 1, "1", 2, 2, 3, 3];
  const id = setInterval(() => {
    if (count < array.length) {
      subscriber.next(array[count++]);
    } else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

input$.pipe(distinct()).subscribe({
  next: x =>
    console.log(`${new Date().toLocaleTimeString()} - [distinct]: ${x}`),
});

12:22:58 - [distinct]: 1
12:23:00 - [distinct]: 1
12:23:01 - [distinct]: 2
12:23:03 - [distinct]: 3

This operator emits the value only if the value is different from the last value emitted. It's important to remember that the distinct operator checks the equality using the strict equal operator (===). It's also possible, if your source emits an object, to indicate the property used to check the equality distinct(p => p.id).

distinctUntilChanged

import { Observable } from "rxjs";
import { distinctUntilChanged } from "rxjs/operators";

type State = { id: number; value: string };

const createValue = (id: number): State => ({ id, value: String(id) });
const array = [
  createValue(1),
  createValue(1),
  createValue(1),
  createValue(2),
  createValue(2),
  createValue(2),
  createValue(3),
  createValue(3),
  createValue(3),
  createValue(4),
  createValue(4),
  createValue(4),
];

const input$ = new Observable<State>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < array.length) {
      subscriber.next(array[count++]);
    } else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

input$
  .pipe(distinctUntilChanged((prev, curr) => prev.id === curr.id))
  .subscribe({
    next: x =>
      console.log(
        `${new Date().toLocaleTimeString()} - [distinctUntilChanged]`,
        x
      ),
  });

11:45:39 - [distinctUntilChanged] { id: 1, value: '1' }
11:45:42 - [distinctUntilChanged] { id: 2, value: '2' }
11:45:45 - [distinctUntilChanged] { id: 3, value: '3' }
11:45:48 - [distinctUntilChanged] { id: 4, value: '4' }

This operator is similar to the distinct operator but you can indicate a function that accepts the previous and the current item as arguments and indicates the algorithm to determinate if the two items are equals.

distinctUntilKeyChanged

Returns an Observable that emits all items emitted by the source Observable that are distinct by comparison from the previous item, using a property accessed by using the key provided to check if the two items are distinct.

import { Observable } from "rxjs";
import { distinctUntilKeyChanged } from "rxjs/operators";

type State = { id: number; value: string };

const createValue = (id: number): State => ({ id, value: String(id) });
const array = [
  createValue(1),
  createValue(1),
  createValue(1),
  createValue(2),
  createValue(2),
  createValue(2),
  createValue(3),
  createValue(3),
  createValue(3),
  createValue(4),
  createValue(4),
  createValue(4),
];

const input$ = new Observable<State>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < array.length) {
      subscriber.next(array[count++]);
    } else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

input$.pipe(distinctUntilKeyChanged("id")).subscribe({
  next: x =>
    console.log(
      `${new Date().toLocaleTimeString()} - [distinctUntilKeyChanged]`,
      x
    ),
});

11:46:12 - [distinctUntilKeyChanged] { id: 1, value: '1' }
11:46:15 - [distinctUntilKeyChanged] { id: 2, value: '2' }
11:46:18 - [distinctUntilKeyChanged] { id: 3, value: '3' }
11:46:21 - [distinctUntilKeyChanged] { id: 4, value: '4' }

This operator is similar to the distinct operator but you can indicate the name of the property used to compare the equality.

filter

Filter items emitted by the source Observable by only emitting those that satisfy a specified predicate.

import { Observable } from "rxjs";
import { filter } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 10) {
      subscriber.next(++count);
    } else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

input$.pipe(filter(x => x % 2 === 0)).subscribe({
  next: x => console.log(`${new Date().toLocaleTimeString()} - [filter]: ${x}`),
});

11:46:43 - [filter]: 2
11:46:45 - [filter]: 4
11:46:47 - [filter]: 6
11:46:49 - [filter]: 8
11:46:51 - [filter]: 10

As you can imagine, this operator accepts a function that has an argument (the current item) and returns a boolean that indicates if the value can be emitted or must be ignored.

first

Emits only the first value (or the first value that meets some condition) emitted by the source Observable.

import { Observable } from "rxjs";
import { first } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 10) {
      subscriber.next(++count);
    } else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

console.log(`${new Date().toLocaleTimeString()} - [first] start`)
input$.pipe(first()).subscribe({
  next: x => console.log(`${new Date().toLocaleTimeString()} - [first]: ${x}`),
  complete: () => console.log(`${new Date().toLocaleTimeString()} - [first] complete`),
});

09:47:15 - [first] start
09:47:16 - [first]: 1
09:47:16 - [first] complete

This operator takes the first value and ignores the others. It's important to remember that when the first operator emits the value it completes the subscription too.

last

Returns an Observable that emits only the last item emitted by the source Observable. It optionally takes a predicate function as a parameter, in which case, rather than emitting the last item from the source Observable, the resulting Observable will emit the last item from the source Observable that satisfies the predicate.

import { Observable } from "rxjs";
import { last } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 10) {
      subscriber.next(++count);
    } else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

console.log(`${new Date().toLocaleTimeString()} - [last] start`)
input$.pipe(last()).subscribe({
  next: x => console.log(`${new Date().toLocaleTimeString()} - [last]: ${x}`),
  complete: () => console.log(`${new Date().toLocaleTimeString()} - [last] complete`),
});

09:48:14 - [last] start
09:48:25 - [last]: 10
09:48:25 - [last] complete

This operator takes the last value and ignores the others.

skip

Returns an Observable that skips the first count items emitted by the source Observable.

import { Observable } from "rxjs";
import { skip } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if(count < 5) subscriber.next(count++);
    else {
      clearInterval(id);
      subscriber.complete();
    } 
  }, 1000);
  return () => {
    clearInterval(id);
    subscriber.complete();
  };
});

input$.pipe(skip(2)).subscribe({
  next: x => console.log(`${new Date().toLocaleTimeString()} - [skip]: ${x}`),
  complete: () =>
    console.log(`${new Date().toLocaleTimeString()} - [skip]: complete`),
});

10:33:41 - [skip]: 2
10:33:42 - [skip]: 3
10:33:43 - [skip]: 4
10:33:44 - [skip]: complete

As you can see, this operator skips the first x items we indicate, if we write skip(1) the operator skips the first value, if we write skip(2) the operator skips the first two values and so on.

skipLast

Skip a specified number of values before the completion of an observable.

import { Observable } from "rxjs";
import { skipLast } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 5) subscriber.next(count++);
    else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

console.log(`${new Date().toLocaleTimeString()} - [skipLast]: start`)

input$.pipe(skipLast(3)).subscribe({
  next: x => console.log(`${new Date().toLocaleTimeString()} - [skipLast]: ${x}`),
  complete: () =>
    console.log(`${new Date().toLocaleTimeString()} - [skipLast]: complete`),
});

10:33:58 - [skipLast]: start
10:34:02 - [skipLast]: 0
10:34:03 - [skipLast]: 1
10:34:04 - [skipLast]: complete

This operator skips the last x items we indicate, if we write skipLast(1) the operator skips the last value, if we write skipLast(2) the operator skips the last two values and so on.

skipUntil

Returns an Observable that skips items emitted by the source Observable until a second Observable emits an item.

import { Observable } from "rxjs";
import { skipUntil } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 5) subscriber.next(count++)
    else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

const untilInput$ = new Observable<void>(subscriber => {
  setTimeout(() => {
    console.log(
      `${new Date().toLocaleTimeString()} - untilInput$ emit`
    );
    subscriber.next();
    subscriber.complete();
  }, 5000);
});

input$.pipe(skipUntil(untilInput$)).subscribe({
  next: x =>
    console.log(`${new Date().toLocaleTimeString()} - [skipUntil]: ${x}`),
  complete: () =>
    console.log(`${new Date().toLocaleTimeString()} - [skipUntil]: complete`),
});

10:34:37 - untilInput$ emit
10:34:37 - [skipUntil]: 4
10:34:38 - [skipUntil]: complete

This operator skips all the values until another observable doesn't emit a value.

skipWhile

Returns an Observable that skips all items emitted by the source Observable as long as a specified condition holds true, but emits all further source items as soon as the condition becomes false.

import { Observable } from "rxjs";
import { skipWhile } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 5) subscriber.next(count++);
    else {
      subscriber.next(count++);
      subscriber.complete();
    }
  }, 1000);
  return () => {
    clearInterval(id);
  };
});

input$.pipe(skipWhile(val => val < 3)).subscribe({
  next: x =>
    console.log(`${new Date().toLocaleTimeString()} - [skipWhile]: ${x}`),
  complete: () =>
    console.log(`${new Date().toLocaleTimeString()} - [skipWhile]: complete`),
});

10:36:34 - [skipWhile]: 3
10:36:35 - [skipWhile]: 4
10:36:36 - [skipWhile]: 5
10:36:36 - [skipWhile]: complete

This operator skips all the values until the predicate isn't true, after the first true result, the skipWhile operator doesn't eval anymore the predicate and emits all the values.

take

Emits only the first count values emitted by the source Observable.

import { Observable } from "rxjs";
import { take } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    subscriber.next(count++);
  }, 1000);
  return () => {
    clearInterval(id);
    subscriber.complete();
  };
});

input$.pipe(take(2)).subscribe({
  next: x => console.log(`${new Date().toLocaleTimeString()} - [take]: ${x}`),
  complete: () =>
    console.log(`${new Date().toLocaleTimeString()} - [take]: complete`),
});

10:39:39 - [take]: 0
10:39:40 - [take]: 1
10:39:40 - [take]: complete

The take operator is the opposite of the skip operator, if the skip ignores x values, the take operator emits x values. So if you write take(1) you get only the first value, if you write take(2) you get only the first two values. It's important to remember that when the operator emits the last value completes the subscription too.

takeLast

Waits for the source to complete, then emits the last N values from the source, as specified by the count argument.

import { Observable } from "rxjs";
import { takeLast } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 5) subscriber.next(count++);
    else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

console.log(`${new Date().toLocaleTimeString()} - [takeLast]: start`)

input$.pipe(takeLast(3)).subscribe({
  next: x => console.log(`${new Date().toLocaleTimeString()} - [takeLast]: ${x}`),
  complete: () =>
    console.log(`${new Date().toLocaleTimeString()} - [takeLast]: complete`),
});

10:40:08 - [takeLast]: start
10:40:14 - [takeLast]: 2
10:40:14 - [takeLast]: 3
10:40:14 - [takeLast]: 4
10:40:14 - [takeLast]: complete

This operator takes the last x items we indicate, if we write takeLast(1) the operator takes the last value, if we write takeLast(3) the operator takes the last three values, and so on.

takeUntil

Emits the values emitted by the source Observable until a notifier Observable emits a value.

import { Observable } from "rxjs";
import { takeUntil } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    if (count < 5) subscriber.next(++count);
    else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 1000);
});

const untilInput$ = new Observable<void>(subscriber => {
  setTimeout(() => {
    console.log(
      `${new Date().toLocaleTimeString()} - untilInput$ emit`
    );
    subscriber.next();
    subscriber.complete();
  }, 2500);
});

input$.pipe(takeUntil(untilInput$)).subscribe({
  next: x =>
    console.log(`${new Date().toLocaleTimeString()} - [takeUntil]: ${x}`),
  complete: () =>
    console.log(`${new Date().toLocaleTimeString()} - [takeUntil]: complete`),
});

10:40:38 - [takeUntil]: 1
10:40:39 - [takeUntil]: 2
10:40:42 - untilInput$ emit
10:40:42 - [takeUntil]: complete

This operator takes all the values until another observable doesn't emit a value, after that it complete the subscription.

takeWhile

Emits values emitted by the source Observable so long as each value satisfies the given predicate, and then completes as soon as this predicate is not satisfied.

import { Observable } from "rxjs";
import { takeWhile } from "rxjs/operators";

const input$ = new Observable<number>(subscriber => {
  let count = 0;
  const id = setInterval(() => {
    subscriber.next(count++);
  }, 1000);
  return () => {
    clearInterval(id);
    subscriber.complete();
  };
});

input$.pipe(takeWhile(val => val < 3)).subscribe({
  next: x =>
    console.log(`${new Date().toLocaleTimeString()} - [takeWhile]: ${x}`),
  complete: () =>
    console.log(`${new Date().toLocaleTimeString()} - [takeWhile]: complete`),
});

10:41:10 - [takeWhile]: 0
10:41:11 - [takeWhile]: 1
10:41:12 - [takeWhile]: 2
10:41:13 - [takeWhile]: complete

This operator emits all the values until the predicate is true, after that the takeWhile operator completes the subscription.

Ok Guys, I think that today it's enough for the Filter Operators. You can find all the code of this article in the GitHub repository.

See you in the next article. Bye Bye!

RxJS - Creation Operators

Wed, 15 Sep 2021 00:00:00 GMT

Welcome back guys, today I'll start to show you the Creation operators in RxJS.

The Creation Operators are used to create new observables. They are divided into Creation Operators and Join Creation Operators. The main difference between them consists in the fact that the Join Creation Operators create observable from other observables instead the Creation Operators create observables from objects which differ from observable.

Creation Operators

The Of operator is used to convert an argument to an observable.

import { of } from "rxjs";

of([1, 2, 3], 4, 5, 6).subscribe({
  next: res => console.log("[of]", res),
  complete: () => console.log("[of] complete"),
});

[of] [ 1, 2, 3 ]
[of] 4
[of] 5
[of] 6
[of] complete

As you can see, this operator takes a list of arguments and converts them to values of the observable.

from

This operator creates an Observable from an Array, an array-like object, a Promise, an iterable object, or an Observable-like object.

from array

from([1, 2, 3]).subscribe(res => console.log("[from]", res));

[from] 1
[from] 2
[from] 3

In this case we converted an array to an observable. The from operator converts all the items in the array to values of the observable. It's common to use this operator when we need to convert the items of an array to the values to react our system.

from promise

from(
  new Promise(res => setTimeout(() => res("Hello from promise"), 3000))
).subscribe(res => console.log(new Date().toLocaleTimeString(), `[from]`, res));

13:47:52 [from] Hello from promise

In this case we converted a promise to an observable. It is common to convert a promise to an observable, or because we have multiple subscribers which need to react to this promise or because we need to use these promise inside of a pipe chain.

from iterator

const wait = async (time: number) => new Promise(res => setTimeout(res, time));
async function* hello() {
  yield "Hello";
  await wait(1000);
  yield "from";
  await wait(1000);
  yield "iterator";
}
from(hello()).subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), `[from]`, res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), `[from] complete`),
});

13:48:42 [from] Hello
13:48:43 [from] from
13:48:44 [from] iterator
13:48:44 [from] complete

Here instead, the from operator converts an iterator to an observable. This is common when we need to react to every item of the iterator or when we need to use the generator inside of a pipe chain.

fromEvent

The fromEvent operator is usage to emit an observable in base of an event

Some examples: when a user clicks to a document element in HTML/JS or when a system emits an event in node.js eco system. Here a practise example

import * as events from "events";
import { fromEvent } from "rxjs";

console.log(new Date().toLocaleTimeString(), "[fromEvent] start");

const em = new events.EventEmitter();
fromEvent(em, "custom-event").subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), "[fromEvent]", res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), "[fromEvent] complete"),
});

setTimeout(() => {
  em.emit("custom-event", "Hello from event emitter");
}, 3000);

14:05:06 [fromEvent] start
14:05:09 [fromEvent] Hello from event emitter

EMPTY

Creates an Observable that emits no items to the Observer and immediately emits a complete notification.

import { EMPTY } from "rxjs";

EMPTY.subscribe({
  next: res => console.log("[EMPTY]", res),
  complete: () => console.log("[EMPTY] complete"),
});

[EMPTY] complete

This operator is used for scheduling the emission of the complete notification.

timer

Creates an observable that will wait for a specified time period, or exact date, before emitting the number 0.

import { timer } from "rxjs";

console.log(new Date().toLocaleTimeString(), "[timer] start");
timer(1000).subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), "[timer]", res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), "[timer] complete"),
});

14:14:34 [timer] start
14:14:35 [timer] 0
14:14:35 [timer] complete

This operator is similar to the setTimeout function in JS. It creates an observable and emits only a value after a time indicated as argument.

interval

Creates an Observable that emits sequential numbers every specified interval of time, on a specified SchedulerLike.

import { interval } from "rxjs";

console.log(new Date().toLocaleTimeString(), "[interval] start");
interval(1000).subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), "[interval]", res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), "[interval] complete"),
});

14:15:10 [interval] start
14:15:11 [interval] 0
14:15:12 [interval] 1
14:15:13 [interval] 2
14:15:14 [interval] 3
14:15:15 [interval] 4
...
...
...

This operator is similar to the setInterval function in JS. It creates an observable and emits a sequential number every specific time indicated as argument. N.B. it start from ZERO and not from ONE

timer as special interval Sometimes you need to create an interval with a specific period but you need to start it with a period different from the interval period. In these cases it is common to use the timer operator that accepts a period as second argument. So you can indicate the time before emitting the first value as first argument and the period of the interval as second argument.

timer(1000, 1000).subscribe({
  next: res =>
    console.log(new Date().toLocaleTimeString(), "[timer as interval]", res),
  complete: () =>
    console.log(
      new Date().toLocaleTimeString(),
      "[timer as interval] complete"
    ),
});

14:25:56 [timer as interval] start
14:26:00 [timer as interval] 0
14:26:01 [timer as interval] 1
14:26:02 [timer as interval] 2
...
...

Join Creation Operators

Before starting, I clarify that all the examples use these three observable as inputs.

import { from, Observable } from "rxjs";

async function* hello() {
  const wait = async (time: number) =>
    new Promise(res => setTimeout(res, time));
  yield "Hello";
  await wait(1000);
  yield "from";
  await wait(500);
  yield "iterator";
}

export const iterator$ = from(hello());
export const arrayFrom$ = from(["Hello", "from", "array"]);
export const arrayOfWithDelay$ = new Observable<number>(subscriber => {
  let counter = 10;
  const id = setInterval(() => {
    if (counter > 0) {
      subscriber.next(counter--);
    } else {
      clearInterval(id);
      subscriber.complete();
    }
  }, 500);
});

combineLatest

Combines multiple Observables to create an Observable whose values are calculated from the latest values of each of its input Observables.

import { combineLatest } from "rxjs";
import { arrayFrom$, arrayOfWithDelay$, iterator$ } from "../sources";

console.log(new Date().toLocaleTimeString(), `[combineLatest] start`);

combineLatest([iterator$, arrayFrom$, arrayOfWithDelay$]).subscribe({
  next: res =>
    console.log(new Date().toLocaleTimeString(), `[combineLatest]`, res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), `[combineLatest] complete`),
});

12:38:22 [combineLatest] start
12:38:22 [combineLatest] [ 'Hello', 'array', 10 ]
12:38:23 [combineLatest] [ 'from', 'array', 10 ]
12:38:23 [combineLatest] [ 'from', 'array', 9 ]
12:38:23 [combineLatest] [ 'iterator', 'array', 9 ]
12:38:23 [combineLatest] [ 'iterator', 'array', 8 ]
12:38:24 [combineLatest] [ 'iterator', 'array', 7 ]
12:38:24 [combineLatest] [ 'iterator', 'array', 6 ]
12:38:25 [combineLatest] [ 'iterator', 'array', 5 ]
12:38:25 [combineLatest] [ 'iterator', 'array', 4 ]
12:38:26 [combineLatest] [ 'iterator', 'array', 3 ]
12:38:26 [combineLatest] [ 'iterator', 'array', 2 ]
12:38:27 [combineLatest] [ 'iterator', 'array', 1 ]
12:38:27 [combineLatest] complete

In this example, you can see how this operator emits an array of value every time an observable emits one value. It's important to remember that the operator emits the first value when all the dependence observables emit the first value. As you can see, the result of the combineLatest operator is an array where items respect the order of the observables in the declaration.

forkJoin

Accepts an Array of ObservableInput or a dictionary Object of ObservableInput and returns an Observable that emits either an array of values in the exact same order as the passed array, or a dictionary of values in the same shape as the passed dictionary.

import { forkJoin } from "rxjs";
import { arrayFrom$, arrayOfWithDelay$, iterator$ } from "../sources";

console.log(new Date().toLocaleTimeString(), `[forkJoin] start`);

forkJoin([iterator$, arrayFrom$, arrayOfWithDelay$]).subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), `[forkJoin]`, res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), `[forkJoin] complete`),
});

14:38:58 [forkJoin] start
14:39:04 [forkJoin] [ 'iterator', 'array', 1 ]
14:39:04 [forkJoin] complete

forkJoin is similar to the combineLatest operator, the difference is that the forkJoin operator emits only one value when all the observables are completed. In simple words, the forkJoin operator emits only the last value of the combineLatest operator.

concat

Creates an output Observable which sequentially emits all values from the first given Observable and then moves on to the next.

import { concat } from "rxjs";
import { arrayFrom$, arrayOfWithDelay$, iterator$ } from "../sources";

console.log(new Date().toLocaleTimeString(), `[concat] start`);

concat(iterator$, arrayFrom$, arrayOfWithDelay$).subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), `[concat]`, res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), `[concat] complete`),
});

14:44:23 [concat] start
14:44:23 [concat] Hello
14:44:24 [concat] from
14:44:24 [concat] iterator
14:44:24 [concat] Hello
14:44:24 [concat] from
14:44:24 [concat] array
14:44:25 [concat] 10
14:44:25 [concat] 9
14:44:26 [concat] 8
14:44:26 [concat] 7
14:44:27 [concat] 6
14:44:27 [concat] 5
14:44:28 [concat] 4
14:44:28 [concat] 3
14:44:29 [concat] 2
14:44:29 [concat] 1
14:44:30 [concat] complete

As you can see, this operator emits all the values of the observables in sequences. Concat unlike of combineLatest does not run all observables in concurrency, but it runs the observables in sequence, it starts from the first and doesn't go to the next until the current is not completed.

merge

Creates an output Observable which concurrently emits all values from every given input Observable.

import { merge } from "rxjs";
import { arrayFrom$, arrayOfWithDelay$, iterator$ } from "../sources";

console.log(new Date().toLocaleTimeString(), `[merge] start`);

merge(iterator$, arrayFrom$, arrayOfWithDelay$).subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), `[merge]`, res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), `[merge] complete`),
});

14:58:48 [merge] start
14:58:48 [merge] Hello
14:58:48 [merge] from
14:58:48 [merge] array
14:58:48 [merge] Hello
14:58:48 [merge] 10
14:58:49 [merge] from
14:58:49 [merge] 9
14:58:49 [merge] iterator
14:58:49 [merge] 8
14:58:50 [merge] 7
14:58:50 [merge] 6
14:58:51 [merge] 5
14:58:51 [merge] 4
14:58:52 [merge] 3
14:58:52 [merge] 2
14:58:53 [merge] 1
14:58:53 [merge] complete

The merge operator is similar to the concat operator unlike that the merge operator runs all observables in concurrency mode, so, in this case, all the observables start together and every time an observable emits a value the merge operator emits this last value.

race

Returns an observable that mirrors the first source observable to emit an item.

import { race } from "rxjs";
import { arrayFrom$, arrayOfWithDelay$, iterator$ } from "../sources";

console.log(new Date().toLocaleTimeString(), `[race] start`);

race([iterator$, arrayFrom$, arrayOfWithDelay$]).subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), `[race]`, res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), `[race] complete`),
});

15:09:03 [race] start
15:09:03 [race] Hello
15:09:03 [race] from
15:09:03 [race] array
15:09:03 [race] complete

This operator is particular, it emits the first observable that emits the first value. In other words, it takes the faster observable and ignores the others.

zip

Combines multiple Observables to create an Observable whose values are calculated from the values, in order, of each of its input Observables.

import { zip } from "rxjs";
import { arrayFrom$, arrayOfWithDelay$, iterator$ } from "../sources";

console.log(new Date().toLocaleTimeString(), `[zip] start`);

zip([iterator$, arrayFrom$, arrayOfWithDelay$]).subscribe({
  next: res => console.log(new Date().toLocaleTimeString(), `[zip]`, res),
  complete: () =>
    console.log(new Date().toLocaleTimeString(), `[zip] complete`),
});

15:09:27 [zip] start
15:09:27 [zip] [ 'Hello', 'Hello', 10 ]
15:09:28 [zip] [ 'from', 'from', 9 ]
15:09:28 [zip] [ 'iterator', 'array', 8 ]
15:09:28 [zip] complete

This operator may seem strange, but it can use to combine in order the values of difference observables. In this example we have 3 observables:

iterator$: ['Hello', 'from', 'iterator', '!']
arrayFrom$: ['Hello', 'from', 'array', '!']
arrayOfWithDelay$: [10, 9, 8, 7, 6, 5, 4, 3, 2, 1]

With the zip operator we combine the values in order of them index:

['Hello', 'Hello', 10]
['from', 'from', 9]
['iterator', 'array', 8]

As you can see, the operator stops emitting values at the index of the first completed observable.

That's it for today. You can find the code of these examples at this in the GitHub repository

See you soon Guys!

RxJS - Marble Diagrams

Mon, 13 Sep 2021 00:00:00 GMT

Hi guy, before continuing with the operators, today I want to explain the Marble Diagrams. The Marble Diagrams is a timeline where you can illustrate the state of your observable during its execution. The actors in this diagram are timeline and values(circle). The timeline is used to represent the time during the execution of the observable though the circles indicate the values emitted. But let me show you an example:

This example is based on this code

import { Observable } from "rxjs";
import { map } from "rxjs/operators";

const source$ = new Observable<number>(observer => {
  let count = 0;
  const id = setInterval(() => {
    if (count++ < 3) {
      observer.next(count);
    } else {
      clearInterval(id);
      observer.complete();
    }
  }, 1000);
});

source$.pipe(map(value => value * 2)).subscribe({
  next: console.log,
});

As you can notice, in the diagram there are two timelines, one for the source and the other for the map operator. In the first timeline you can see when the source emits the value, in the second timeline you can see the result of the transformation after the execution of the map operator.

To build a Marble diagram you need to keep in mind some easy rules: there is always a timeline that represents the source observable, there are N timelines as many operators as you need to display, every timeline illustrates the state of the values after the execution of the operator indicated in the timeline and finally, you need to use a circle to represent the values.

This tool is very convenient to illustrate the transformation of the observable during its execution and it helps us to have an image of the state of the observable execution.

In addition to the Marble Diagram you can use the Marble Testing to test the execution of you Observable. The Marble testing uses a special format to represent the timeline and the value during the execution, but I will speak about it in the future.

To reinforce the Marble Diagram concept let me show you another example

import { Observable } from "rxjs";
import { delay, map } from "rxjs/operators";

const source$ = new Observable<number>(observer => {
  let count = 0;
  const id = setInterval(() => {
    if (count++ < 3) {
      observer.next(count);
    } else {
      clearInterval(id);
      observer.complete();
    }
  }, 1000);
});

source$
  .pipe(
    map(value => value * 2),
    delay(1500)
  )
  .subscribe({
    next: console.log,
  });

In this example you can see how the observable in the first operator doubles the value and then it waits 1.5 seconds before emitting the result. To represent this case the marble diagram has 3 timelines, one with the source, one with the map operator and one with the delay operator. Every timeline indicates the value during the execution of its operator so you can see the behaviour of this implementation.

It's all from the marble diagram.

See you soon guys!

RxJS - Operators

Fri, 10 Sep 2021 00:00:00 GMT

Hi Guys and welcome back, today I introduce the concepts of Operators. Operators are functions. Isn't it easy? Operators are functions of two types in RxJS: Creation or Pipeable.

Creation

Creation operators are simple functions and their scope is to create new observables.

import { of } from "rxjs";

of(1, 2, 3, 4).subscribe(x => console.log("[of] result", x));

[of] result 1
[of] result 2
[of] result 3
[of] result 4

The most commons creation operators are: ajax, empty, from, fromEvent, interval, of, throwError, timer, combineLatest, concat, forkJoin, merge and zip.

In the next article I'll deepen these types of operators, today I just make an overview of the operator's types.

Pipeable

Pipeable operators are functions that take an Observable as input and return another observable. These functions are pure, so the input observable does not change but the function returns a new one. The main scopes of these operators are: transform, filter, and work with the input observable. An example of pipeable operators:

import { Observable } from "rxjs";
import { map, tap } from "rxjs/operators";

new Observable<number>(observer => {
  observer.next(1);
  observer.next(2);
  observer.next(3);
  observer.next(4);

  observer.complete();
})
  .pipe(
    map(val => val * 2),
    tap(res => {
      console.log("[pipeable tap]", res);
    })
  )
  .subscribe();

[pipeable tap] 2
[pipeable tap] 4
[pipeable tap] 6
[pipeable tap] 8

The pipeable operators are divided by scopes and the scopes are: Transformation, Filtering, Join, Multicasting, Error Handling, Utility, Conditional and Boolean and Mathematical and Aggregate.

As you can understand you can combine Creation operators with Pipeable operators to manage your business logic like here

import { timer } from "rxjs";
import { take } from "rxjs/operators";

timer(0, 1000)
  .pipe(take(10))
  .subscribe(x => console.log("[timer] result", x));

[timer] result 0
[timer] result 1
[timer] result 2
[timer] result 3
[timer] result 4
[timer] result 5
[timer] result 6
[timer] result 7
[timer] result 8
[timer] result 9

With this last article, I have introduced all the pillars to the base of the RxJS library and the Reactive Programming. In the next article, we'll start to explore the operator's world.

That's all guys, See you soon!

in the GitHub repository you can find the code of this article.

RxJS - Observer and Subscription

Wed, 08 Sep 2021 00:00:00 GMT

Welcome back guys, today the topics of the article are Observers and Subscriptions.

Observer

An observer is a consumer of values. An observer is something that is interested to the emitted values by the observable. In RxJS an Observer is simply a set of callbacks (next, error, complete). Here's a simple example of an observer

import { Observer } from "rxjs";

const observer: Observer<string> = {
  next: (value: string) =>
    console.log(`[observer] next`, value),
  error: (error: Error) =>
    console.error(`[observer] error`, error),
  complete: () =>
    console.log(`[observer] complete!`),
};

As you can see an observer has three callbacks, one for each type of notification that an Observable may emit. Every callback can react in the base of the observable event notification. An observer could have not all the three callbacks defined because maybe it doesn't want to react to all the notifications. In these cases, you can create an observer with the only callbacks you need.

import {
  NextObserver,
  ErrorObserver,
  CompletionObserver,
} from "rxjs";

const nextObserver: NextObserver<string> = {
  next: (value: string) =>
    console.log(`[nextObserver] next`, value),
};

const errorObserver: ErrorObserver<string> = {
  error: (error: Error) =>
    console.error(`[errorObserver] error`, error),
};

const completeObserver: CompletionObserver<string> = {
  complete: () =>
    console.log(`[completeObserver] complete!`),
};

It's possible to define a NextObserver without the next property but indicating only the body of the next method, in this case, the observer by default is of the type NextObserver.

const defaultNextObserver: (value: string) => void = (value: string) =>
    console.log(`${new Date().toISOString()} - [defaultNextObserver] next`, value)

Subscription

A Subscription is an actor that decides when an Observable must be listened and when we can stop listening to it. Until an observable is not subscribed in your code nothing happens, but as soon as you create a subscription, the magic starts. A Subscription in RxJS is an object created using the method "subscribe" and it has one main method: "unsubscribe"; this method allows you to stop listening the observable event. In your code is important to call the "unsubscribe" when you no longer need the subscription, this prevent problems as the memory leaks. An example of a Subscription

import { Subscription } from "rxjs";

const observer = (value: string) => console.log(`[unsubscribe method] next`, value)

const subscription: Subscription = observable.subscribe(observer);
subscription.unsubscribe();

Another pretty feature in RxJS Subscription is the "add" method; this method allows you to collect more subscriptions inside of one Subscription instance and after that, you can unsubscribe all the subscriptions at once time.

import { Subscription } from "rxjs";

const subscription: Subscription = observable.subscribe((value: string) =>
  console.log(
    `[unsubscribe 1 method] next`,
    value
  )
);
subscription.add(
  observable.subscribe((value: string) =>
    console.log(
      `[unsubscribe 2 method] next`,
      value
    )
  )
);

subscription.unsubscribe();

In some cases when you call the unsubscribe method you need to run some special code in your observable: RxJS let us do this using a special syntax inside of the observable declaration. When you create the observable you can return a function that the library invokes in the future during the unsubscription. Below a simple example to understand better the problem and the solution:

import {
  Observable,
  Subscriber,
  Subscription,
} from "rxjs";

const observableWithCallback = new Observable<string>(
  (subscriber: Subscriber<string>) => {
    let count = 0;
    const id = setInterval(() => {
      subscriber.next(`Count: ${++count}`);
    }, 300);

    return () => {
      console.log("On UnSubscription");
      clearInterval(id);
    };
  }
);

const subscriptionObservableWithCallback: Subscription = observableWithCallback.subscribe({
  next: (value: string) =>
    console.log(`[observableWithCallback] Next: ${value}`),
});
setTimeout(() => {
  subscriptionObservableWithCallback.unsubscribe();
}, 3000);

[observableWithCallback] Next: Count: 1
[observableWithCallback] Next: Count: 2
[observableWithCallback] Next: Count: 3
[observableWithCallback] Next: Count: 4
[observableWithCallback] Next: Count: 5
[observableWithCallback] Next: Count: 6
[observableWithCallback] Next: Count: 7
[observableWithCallback] Next: Count: 8
[observableWithCallback] Next: Count: 9
On UnSubscription

Ok, guys, that's all for today. In the next article we'll see the last fundamental of RxJS: the Operator and later, we can move to see the features of this Library.

You can find the examples of this article in the GitHub repository.

See you soon guys!

RxJS - Observable

Mon, 06 Sep 2021 00:00:00 GMT

Hi Guys, Today I want to start a little series about Reactive Programming with RxJS. I start from the basic core concepts behind of this Programming Paradigm to move after and show the potentialities of the RxJS library.

The idea of this series was born some weeks ago during a refactor in an Angular application, because I noticed a lot of errors in the codebase about RxJS. The problem behind this code unfortunately is that the developers begin using the angular framework without the basics of the RxJS library and the Reactive Programming. So I decided to write some articles to show the basics behind the RxJS library and Reactive Programming in general.

A little preamble before passing on the topic of this article: RxJS is a library for composing asynchronous and event-based programs by using observable sequences. So RxJS and Reactive Programming are not the solution for all your problems, but they are good solutions in contexts where asynchronous and events are the stars. I've preferred to clarify that because sometimes programmers believe that but after having introduced the Reactive Programming, they come across with other problems because the library and the paradigm are very simple but at the same time it's easy to get hurt if you don't know how it works.

The last info about the series: the code is written in Typescript, but you can use RxJS also in vanilla javascript if you prefer.

Now let's start with the first argument, the star behind the Reactive Programming, the Observable.

Observables (the one who is observed) are one of the key concepts behind Reactive Programming along with Observers and Subscribers (those who observes, controls). Observables can be a stream or a collection of datas, but you could imagine an observable like a lazy Push collection of multiple values. To understand better the concept let me show you an example

import { Observable, Subscriber } from "rxjs";

const observable = new Observable<string>((subscriber: Subscriber<string>) => {
  subscriber.next("Hello World");
  subscriber.error(new Error("Something went wrong!"));
  subscriber.complete();
});

As you can see the Observable is a class that accept a subscriber (a callback function). This subscriber has 3 main possible action:

next: The next method emits the value passing as parameter to all the subscriptions, so the system can react accordingly.
error: The error method emits an error during the execution of the observable.
complete: The complete method sets the observable closed. When this happens, all the future methods (next and error) emitted for the closed observable will be ignored.

To better understand here's another example, with its result in the console

import { Observable, Observer, Subscriber } from "rxjs";

const observer: Observer<string> = {
  next: (value: string) => console.log("next", value),
  error: (error: Error) => console.error("error", error),
  complete: () => console.log("complete!"),
};

const observable = new Observable<string>((subscriber: Subscriber<string>) => {
  subscriber.next("Hello");
  subscriber.next("World");

  subscriber.complete();

  // this will never be logged

  subscriber.error(new Error("Something went wrong!"));

  subscriber.next("Hello");
  subscriber.next("World");
});

observable.subscribe(observer);

next Hello
next World
complete!

p.s. don't pay attention to the observer in this moment, to simplify it think that when the subscriber calls the next method, the next function in the observer will be called and the same goes for the error and complete methods

You can notice how the subscriber calls the next method twice: first with "Hello" and after with "World" and the result is logged into the console. Next, the subscriber calls the complete method and it is registered in the console too. After that, the subscriber calls the error method and the next method twice, but in the console nothing happens. This behaviour is due to the fact that the observable is ended by the complete method so the observable no longer emits any events. When we complete the observable, it's important to remember that all the next methods called (next, error or complete) are ignored.

That's all for now. You can find the example at this in the GitHub repository

See you soon guys!

Typescript - Tips & Tricks - Rest Parameters & Rest Arguments

Fri, 02 Apr 2021 00:00:00 GMT

Hi guy and welcome back :) Today I'll talk about the Rest Parameters and the Rest Arguments. Sometimes we need to write a simple code like this:

function multiply(a: number, b: number): number {
  return a * b;
}

const result1 = multiply(2, 2); // 4
const result2 = multiply(2, 3); // 3

but after a while the customer asks us to multiply for unbounded numbers, so we need to change our code. In these cases, typescript helps us with a feature called Rest Parameters. This feature permits us to identify this list of parameters as an array type so we can leave our consumer to call the method with the correct number of items he needs, and we can manipulate these parameters more easily. Therefore the previous example can be transformed in this way

function multiply(a: number, ...args: number[]): number {
  return args.reduce((acc, curr) => acc * curr, a);
}

const result1 = multiply(2, 2, 2); // 8
const result2 = multiply(2, 3, 2, 2); // 24

As you can see, now the consumer can call the "multiply" method as he prefers and our code responds correctly in all cases. In this example, we have called the "multiply" method with a fixed number of elements, 3 in the first case and 4 in the second one. But in some cases, we don't know the correct number of elements and maybe they are in an array. To resolve these cases, typescript has another important feature tied to the Rest Parameters, the Rest Arguments. This feature helps us to convert the array elements to a list of parameters. Thus, we can call the "multiply" method in this way too.

const result1 = multiply(2, ...[2, 2]); // 8
const result2 = multiply(2, ...[3, 2, 2]); // 24

I think that these two features are really powerful, and can help you to manipulate large numbers of parameters and take your code simple and flexible.

And now a special greeting. This is the last post of this series Typescript - Tips & Tricks, I hope you enjoyed the series and it will help you in your daily work.

Many Thanks to have read the series. It's not a goodbye, I'll get back soon with other topics.

Bye, Bye Guys!

Typescript - Tips & Tricks - Advanced Types

Wed, 31 Mar 2021 00:00:00 GMT

Hi Guys, Today I'll show you some advanced utilities exposed by the typescript language. Let's start!

Utilities for Types

Partial

This utility allows you to add the optional modifier to all the properties of your type.

type PartialPoint = Partial<{ x: number; y: number }>; // { x?: number | undefined; y?: number | undefined; }

Required

This utility allows you to remove the optional modifier to all the properties of your type.

type RequiredPoint = Required<{ x?: number; y?: number }>; // { x: number; y: number; }

ReadOnly

This utility allows you to add the read-only modifier to all the properties of your type.

type ReadOnlyPoint = ReadOnly<{ x: number; y: number }>; // { readonly x: number; readonly y: number; }

Pick

This utility allows you to get a subset of properties from another type.

type PickPoint = Pick<{ x: number; y: number }, "x">; // { x: number; }

Omit

This utility allows you to exclude some properties from another type.

type OmitPoint = Omit<{ x: number; y: number }, "x">; // { y: number; }

Record

This utility allows you to map the properties of a type to another type.

type Point = {
  x: number;
  y: number;
};
type PointRecord = Record<keyof Point, number | null>; // { x: number | null; y: number | null; }

Exclude

This utility allows you to remove some types from a union type.

type ExcludeType = Exclude<"x" | "y", "x">; // "y"

Extract

This utility allows you to get some types from a union type.

type ExtractType = Extract<"x" | "y", "x">; // "x"

NonNullable

This utility allows you to remove the undefined and null types from a union type.

type NonNullableType = NonNullable<string | number | undefined | null>; // string | number

Utilities for Function and Class

Parameters

This utility allows you to extract from a function its parameters.

function createPoint(x: number, y: number) {
  return { x, y };
}
type ParametersType = Parameters<typeof createPoint>; // [x: number, y: number]

ConstructorParameters

This utility allows you to extract from a class its constructor parameters.

class Point {
  constructor(x: number, y: number) {}
}
type ConstructorParametersType = ConstructorParameters<typeof Point>; // [x: number, y: number]

ReturnType

This utility allows you to get the return type from a function.

function createPoint(x: number, y: number) {
  return { x, y };
}
type CreatePointReturnType = ReturnType<typeof createPoint>; // { x: number; y: number; }

InstanceType

This utility allows you to construct a type consisting of the instance type of a construction function type.

class Point {
  constructor(x: number, y: number) {}
}
type InstanceTypePoint = InstanceType<typeof Point>; // Point
type InstanceTypeString = InstanceType<string>; // Error: Type 'string' does not satisfy the constraint 'new (...args: any) => any'

ThisParameterType

This utility allows you to extract the this parameter from a function type, or unknown if the function type has no this parameter.

function toHex(this: Number) {
  return this.toString(16);
}
function numberToString(n: ThisParameterType<typeof toHex>) {
  return toHex.apply(n);
}
numberToString(12)

OmitThisParameter

This utility allows you to remove the this parameter from a function type.

function toHex(this: Number) {
  return this.toString(16);
}
const fiveToHex: OmitThisParameter<typeof toHex> = toHex.bind(5);
fiveToHex()

Utilities to Manipulation String Types

Uppercase

This utility allows converting your types to uppercase format.

type StringUppercase = Uppercase<"getX" | "getY" | "setX" | "setY">; // "GETX" | "GETY" | "SETX" | "SETY"

Lowercase

This utility allows you to convert your types to lowercase format.

type StringLowercase = Lowercase<"getX" | "getY" | "setX" | "setY">; // "getx" | "gety" | "setx" | "sety"

Capitalize

This utility allows you to convert your types to capitalize format.

type StringCapitalize = Capitalize<"getX" | "getY" | "setX" | "setY">; // "GetX" | "GetY" | "SetX" | "SetY"

Uncapitalize

This utility allows you to convert your types to uncapitalize format.

type StringUncapitalize = Uncapitalize<"GetX" | "GetY" | "SetX" | "SetY">; // "getX" | "getY" | "setX" | "setY"

I hope these utilities will help you in the future. That's all for today. See you soon Guys!

Typescript - Tips & Tricks - Mapped Types

Mon, 29 Mar 2021 00:00:00 GMT

In some cases, we need to manipulate some types to create new types. In these cases, we have to use the Mapped Types. Let's start explaining the structure of the mapped types.

type MappedTypeExample = {
    [Key in "x" | "y" | "z"]: number;
};

As you can see, a mapped type is a type composed of defined keys and their values, but the power of the mapped types goes out when we want to joke with a generic type.

type Point = {
    readonly x: number;
    y: number;
    z?: number;
};

type MappedType<T> = {
    [K in keyof T]: T[K];
};

type mappedPoint = MappedType<Point>;
/**
 type mappedPoint = {
    readonly x: number;
    y: number;
    z?: number | undefined;
}
*/

In this simple example, I show you how to replicate the same object using the mapped type. Now let's add two simple bits to transform our type into new "different" types. The mapped type permits you to add(+) or remove(-) the read-only modifier from your type but also to add(+) or remove(-) the optional modifier. I leave you two simple examples to show these cases.

type MappedPointPlusModifier<T> = {
    +readonly [K in keyof T]: T[K];
};

type mappedPointPlusModifier = MappedPointPlusModifier<Point>;
/**
type mappedPointPlusModifier = {
    readonly x: number;
    readonly y: number;
    readonly z?: number | undefined;
}
*/

type MappedPointMinusModifier<T> = {
    [K in keyof T]-?: T[K];
};
type mappedPointMinusModifier = MappedPointMinusModifier<Point>;
/**
type mappedPointMinusModifier = {
    readonly x: number;
    y: number;
    z: number;
}
*/

N.B. The add(+) modifier isn't indicated in common cases because it is implied

The mapped types are a powerful feature to manipulate our types and they are used by the typescript team to expose to us some advanced types, but this is a topic of a future post. Before ending I leave you another example to show what you can do with the mapped type. In this example, I transform the Point type to another Point type where the fields aren't exposed directly but they are wrapped by a "get" and "set" method.

type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};
type Setters<T> = {
  [K in keyof T as `set${Capitalize<string & K>}`]: (value: T[K]) => void;
};
type WithGetterAndSetter<T> = Getters<T> & Setters<T>;

type Point = {
  x: number;
  y: number;
};

type WithGetterAndSetterPoint = WithGetterAndSetter<Point>;
/**
type WithGetterAndSetterPoint = {
  getX(): number;
  setX(value: number): void;
  getY(): number;
  setY(value: number): void;
}
*/

It's all for today! See you soon guy!

Typescript - Tips & Tricks - infer keyword

Fri, 26 Mar 2021 00:00:00 GMT

Today I talk about the infer keyword. Sometimes, we need to get the value type of an array or get the return type of a function. To do this I need to introduce the infer keyword. To explain this feature I show you an example

type UnboxingArray<T> = T extends Array<infer Member> ? Member : T;

type UnboxingArrayString = UnboxingArray<string[]>; // string
type UnboxingArrayNumber = UnboxingArray<number[]>; // number
type UnboxingString = UnboxingArray<string>; // string

As you can see, in the UnboxingArray type, we can detect if the T type extends an array and if so we can infer the element type or else we return the T type. As a demonstration, if you see the type of the UnboxingArrayString and the UnboxingArrayNumber you can note how the UnboxingArray infers the string and the number type. In contrast, in the UnboxingString, the UnboxingArray can't infer the type of the elements because the type doesn't extend an array so it returns the string type. Now I show you the infer keyword applied to the function result.

type ReturnType<T> = T extends (...args: unknown[]) => infer R ? R : never;
function getPerson() {
  return {
    name: "name",
    surname: "surnmae",
  };
}
type Person = ReturnType<typeof getPerson>;
/**
type Person = {
  name: string;
  surname: string;
}
*/
type StringResult = ReturnType<string>; // never

In this example, you can note that if the T type extends a function, the ReturnType infers the type of the function result otherwise it returns the never type. To demonstrate it, you can see how the Person type is composed of a name and a surname fields on the contrary the StringResult is of the never type.

Great news for us, the ReturnType is already included inside of the Typescript types.

It's all guys. Bye bye

Typescript - Tips & Tricks - Conditional Type

Wed, 24 Mar 2021 00:00:00 GMT

In some cases, we need to detect if an object/type has specific properties or characteristics. Let me show you a simple case

type TypeName<T> =
    T extends string ? "string" :
    T extends number ? "number" :
    T extends bigint ? "bigint" :
    T extends boolean ? "boolean" :
    T extends undefined ? "undefined" :
    T extends symbol ? "symbol" :
    T extends Function ? "function" :
    T extends null ? "null" :
    "object";

const typeName = <T>(obj: T): TypeName<T> => {
  if (obj === null) return "null" as TypeName<T>;
  return typeof obj as TypeName<T>;
};

const stringType = typeName('string'); // "string"
const numberType = typeName(10); // "number"
const bigIntType = typeName(10n); // "bigint"
const booleanType = typeName(true); // "boolean"
const undefinedType = typeName(undefined); // "undefined"
const symbolType = typeName(Symbol()); // "symbol"
const functionType = typeName(() => 'result'); // "function"
const nullType = typeName(null); // "null"
const objectType = typeName({ name: 'name'}); // "object"

In this example, we return the type of the parameter as a string, but I want to focus on the TypeName type. This type as you can see, returns the values based on some conditions. In this case, the conditions are based on the parameter's type, but my goal is to show you that you could check if a type respects some conditions or not and act accordingly. This feature is called Conditional Types. To show you the power of this feature here a funny example found in the net :)

type SnackBars = {
  name: "Short Chocolate Bars";
  amount: 4;
  candy: true;
};

type Gumballs = {
  name: "Gooey Gumballs";
  color: "green" | "purples";
  candy: true;
};

type Apples = {
  name: "Apples";
  candy: true;
};

type Cookies = {
  name: "Cookies";
  candy: true;
  peanuts: true;
};

type SnickersBar = {
  name: "Snickers Bar";
  candy: true;
  peanuts: true;
};

type Toothpaste = {
  name: "Toothpaste";
  minty: true;
  trick: true;
};

type Pencil = {
  name: "Pencil";
  trick: true;
};

type HalloweenTricksAndSweets =
  | SnackBars
  | Gumballs
  | Apples
  | SnickersBar
  | Cookies
  | Toothpaste
  | Pencil;

type AllCandies<T> = T extends { candy: true } ? T : never;
type AllTricks<T> = T extends { trick: true } ? T : never;
type AllCandiesWithoutPeanuts<T> = T extends { candy: true } ? (T extends { peanuts: true } ? never : T) : never;

type Candies = AllCandies<HalloweenTricksAndSweets>; // SnackBars | Gumballs | Apples | SnickersBar | Cookies
type Tricks = AllTricks<HalloweenTricksAndSweets>; // Toothpaste | Pencil
type CandiesWithoutPeanuts = AllCandiesWithoutPeanuts<HalloweenTricksAndSweets>; // SnackBars | Gumballs | Apples

In this example, you can see how the AllCandies type creates a new type (Candies) composed of all the HalloweenTricksAndSweets that contain the candy property with the true value. The AllTricks type creates a new type (Tricks) composed of all the HalloweenTricksAndSweets that contain the trick property with the true value. The last case AllCandiesWithoutPeanuts is interesting: we get all the candies that don't contain the peanuts property with the true value. I think this funny example can express best the potential of the Conditional Type, and it can help you to understand better all the benefits it can lead to.

It's all for today. I hope this feature will help you in the future as it helped me in some cases.

See you soon Guys!

Typescript - Tips & Tricks - Type Guard

Mon, 22 Mar 2021 00:00:00 GMT

There are some cases, where we need to detect the type of the object to get the correct implementation of our method. Let me show you a case

type Square = {
  size: number;
};

type Rectangle = {
  with: number;
  height: number;
};

type Circle = {
  radius: number;
};

type Shape = Square | Rectangle | Circle;

const area = (shape: Shape) => {
  if ("size" in shape) return shape.size * shape.size;
  if ("with" in shape) return shape.with * shape.height;
  if ("radius" in shape) return shape.radius * 2 * Math.PI;
};

In this case, in the area method, we need to detect the type of the shape to return the correct result. Here we detect the type of the shape in the if condition but typescript permits us to create a special function that identifies if a type is of a specific type or not. These functions are created to have Type Guards that help the compiler, the intellisense, and us to understand the correct type of the object. To show you this function in action, the previous example can be rewritten in this way.

Square = {
  size: number;
};

type Rectangle = {
  with: number;
  height: number;
};

type Circle = {
  radius: number;
};

type Shape = Square | Rectangle | Circle;

function isSquare(shape: Shape): shape is Square {
  return "size" in shape;
}

function isRectangle(shape: Shape): shape is Rectangle {
  return "with" in shape;
}

function isCircle(shape: Shape): shape is Circle {
  return "radius" in shape;
}

const area = (shape: Shape) => {
  if (isSquare(shape)) return shape.size * shape.size;
  if (isRectangle(shape)) return shape.with * shape.height;
  if (isCircle(shape)) return shape.radius * 2 * Math.PI;
};

As you can see, the methods: isSquare, isRectangle, and isCircle get a shape as parameter and return a boolean value. If the result is true the shape parameter corresponds to the type indicated to the right of the is keyword, otherwise, it corresponds to another type.

I hope this feature will help you in the future and improve the reading of your code.

It's all Guy! See you soon!

Typescript - Tips & Tricks - Assert Function

Fri, 19 Mar 2021 00:00:00 GMT

There are times that we need to create some assertions to be sure an object respects some rules. A common case is to check if an object is defined; to do this you can create a simple assertion function like this

function assert(condition: unknown, message: string): asserts condition {
  if (!condition) throw new Error(message);
}

To leave you a simple case of use, I write this simple example

type Person = {
  name: string;
  email?: string;
};

function loadPerson(): Person | null {
  return null;
}

let person = loadPerson();

function assert(condition: unknown, message: string): asserts condition {
  if (!condition) throw new Error(message);
}

assert(person, "Person is not defined"); // Error: Person is not defined
console.log(person.name);

As you can see, in this example, the assert function detects if the person is defined and if the person isn't defined the assert function throws an error with the message that you pass in the parameters. To level up, and explain better the power of the assert function, here another example

type Square = {
  kind: "square";
  size: number;
};

function ensureSquare(obj: unknown): asserts obj is Square {
  if (
    typeof obj === "object" &&
    !!obj &&
    "kind" in obj &&
    (obj as Square).kind === "square"
  )
    return;

  throw new Error("Object isn't a Square type");
}

const square = { kind: "square", size: 10 };
ensureSquare(square);
// const square: Square
console.log("shape", square.kind);
console.log("size", square.size);

const rectangle = { kind: "rectangle", width: 10, height: 15 };
ensureSquare(rectangle); // throw new Error("Object isn't a Square type");
console.log("shape", rectangle.kind);
console.log("size", rectangle.size);

In this case, you can see how the "ensureSquare" function creates an assertion to detect if the object passed as parameter is of type Square or not. If you see the part of the example where I created the square field, you can note that the type of the square field is { kind: string; size: number; }. If you observe the type of the square field after the "ensureSquare(square);" you can see how typescript converts the type of the field from { kind: string; size: number; } to Square. This conversion is done because if the code passes the "ensureSquare" function you are sure that the "square" field is of type Square. On the contrary, in the second part of the example, the "rectangle" field, on runtime, throws an error, and the code after the "ensureSquare" function will never be executed. I think you have understood the power of the assertion functions, and I hope they will help you to prevent some future mistakes.

It's all guys, Bye Bye!

Typescript - Tips & Tricks - Never type

Wed, 17 Mar 2021 00:00:00 GMT

Today I want to talk about the never type. As you can understand, this type identifies a piece of code that will never be executed or represents a state that shouldn’t exist. Here an example

const throwException: () => never = () => {
    throw new Error();
};
throwException()
console.log('never called');

In this simple example, you can see how the "throwException" method never permits the code execution of the console.log. In this case, the "throwException" method returns the never type because the method doesn't return any value but throws an error. To better understand the never type I show you another simple example

type Square = {
    kind: "square";
    size: number;
};

type Rectangle = {
    kind: "rectangle";
    with: number;
    height: number;
};

type Circle = {
    kind: "circle";
    radius: number;
};

type Shape = Square | Rectangle | Circle;

const area = (shape: Shape): number => {
    if (shape.kind === "square") return shape.size * shape.size;
    if (shape.kind === "rectangle") return shape.with * shape.height;
    // if (shape.kind === "circle") return shape.radius * 2 * Math.PI;

    const _exhaustiveCheck: never = shape; // Type 'Circle' is not assignable to type 'never'.
    return _exhaustiveCheck;
};

In this example, you can see how the "area" method detects the kind of the shape and it calculates the relative area. I leave the circle type comment voluntarily, so I can show you the power of the never type. At the end of the area method, you can see how the code assigns the shape to the field "_exhaustiveCheck" of type never. In this case, the typescript language detects that if you pass a circle shape at the area method, the line "const _exhaustiveCheck: never = shape;" will be executed, so it notifies you raising an error. The typescript language detects that the never type could be executed at runtime so it tries to prevent this problem. To fix this problem the previous method can be reviewed in this way

type Square = {
    kind: "square";
    size: number;
};

type Rectangle = {
    kind: "rectangle";
    with: number;
    height: number;
};

type Circle = {
    kind: "circle";
    radius: number;
};

type Shape = Square | Rectangle | Circle;

const area = (shape: Shape): number => {
    if (shape.kind === "square") return shape.size * shape.size;
    if (shape.kind === "rectangle") return shape.with * shape.height;
    if (shape.kind === "circle") return shape.radius * 2 * Math.PI;

    const _exhaustiveCheck: never = shape;
    return _exhaustiveCheck;
};

Now the code is compiled successfully and the never type is assigned correctly.

From the never type it's all. See you soon guys

Typescript - Tips & Tricks - Non-null assertion operator

Mon, 15 Mar 2021 00:00:00 GMT

In some cases, you have a field that you initialize in a method, and if you follow the flow of the code you are sure that this field is initialized but typescript doesn't understand it. An example

type Person = {
  name: string;
};

let person: Person;

function initialize() {
  person = { name: "name" };
}

initialize();
console.log("Hello", person.name); // Variable 'person' is used before being assigned.

In this case, you can see how the typescript compiler doesn't understand that the "person" field isn't null but it's initialized. To resolve this problem, the typescript language exposes us the "Non-null assertion operation"(!). This operator says to the compiler that the field isn't null or undefined but it's defined. The previous example can be reviewed in this way

type Person = {
  name: string;
};

let person: Person;

function initialize() {
  person = { name: "name" };
}

initialize();
console.log("Hello", person!.name);

As you can see, in this case, the code doesn't have errors and the compilation ends with success.

That's all for today! Bye-bye guys!

Typescript - Tips & Tricks - Tuple

Fri, 12 Mar 2021 00:00:00 GMT

Tuple types allow you to express an array with a fixed number of elements whose types are known, but need not be the same. This definition is picking from the typescript documentation. The tuple type is a powerful type that helps you to identify the types of elements in an array, you can create special types where the elements of the array can have different types. A simple example

type Point = [number, number];

const point1: Point = [10, 10];
const point2: Point = [10, "10"]; // Type 'string' is not assignable to type 'number'
const point3: Point = [10, 10, 20]; // Type '[number, number, number]' is not assignable to type 'Point'. Source has 3 element(s) but target allows only 2.

In this case, you can see how the point type is composed by a fixed array of two elements of type number. You can see how typescript detects this constraint and it raises an error when you try to create a point with the second element of type string or you try to create a point with 3 elements. To show you the power of this type, here's another example

type QueryStringItem = [string, number | string | boolean];
const queryStringItem1: QueryStringItem = ["key1", 10];
const queryStringItem2: QueryStringItem = ["key2", "value2"];
const queryStringItem3: QueryStringItem = ["key3", false];
const queryStringItem4: QueryStringItem = ["key3", { value: "value" }]; // Type '{ value: string; }' is not assignable to type 'string | number | boolean'.

In this case, you can see how the second element of the Tuple can be a union type of the types: number, string, or boolean; so typescript let you set the second element of the Tuple with one of these last three types. If you try to set the second element with a different type from number, string or boolean the typescript compiler raises an error.

That's all from the Tuple type. See you soon guys!

Typescript - Tips & Tricks - Readonly Array

Wed, 10 Mar 2021 00:00:00 GMT

function sortAndReverse(list: number[]): number[] {
  return list.sort().reverse();
}

const list = [1, 4, 5, 2];
sortAndReverse(list);
console.log(list);

What's the result of the final console log?

[ 1, 4, 5, 2 ]
[ 5, 4, 2, 1 ]
[ 2, 5, 4, 1 ]

Unfortunately, the correct answer is the second one.

In this stupid example, you can see how some array methods can have some side effects. The sort and the reverse methods return a new array with the result but also they change the initial array. Typescript can help us to prevent these side effects using read-only arrays. The read-only arrays identify the methods that modify the initial array and raise an error when you call these methods. But now, how can you use the read-only array? It's easy guys, you need to indicate the readonly modifier before the type of your array. So, the previous example can change in this way

function sortAndReverse(list: readonly number[]): number[] {
  return list.slice().sort().reverse();
}

const list = [1, 4, 5, 2];
sortAndReverse(list);
console.log(list);

In this case, the sortAndReverse method returns as result "[ 5, 4, 2, 1 ]" like in the first example, but more important is that the final console log returns "[ 1, 4, 5, 2 ]", the initial value of the "list" array. If in this case, you try to remove the "slice" method, you can see how typescript indicates an error (Property 'sort' does not exist on type 'readonly number[]'), and it helps you to prevent strange side effects.

It's all for today! Bye Bye Guys!

Typescript - Tips & Tricks - readonly modifier

Mon, 08 Mar 2021 00:00:00 GMT

How many times we expect an object property to have a value but it isn't? In these cases, unfortunately, we spend a lot of time searching for who changes the value of this property. Today I want to show you a special modifier that helps you to prevent this problem and preserve your time. This modifier is the readonly. The readonly modifier helps you to prevent someone can change your property, so, the object's property can set only in the object initialization. A simple example

type Point = {
  x: number;
  y: number;
};
const point: Point = {
  x: 10,
  y: 10,
};
point.x = 20;
point.y = 20;

type ReadOnlyPoint = {
  readonly x: number;
  readonly y: number;
};
const readOnlyPoint: ReadOnlyPoint = {
  x: 10,
  y: 10,
};
readOnlyPoint.x = 20; // Cannot assign to 'x' because it is a read-only property
readOnlyPoint.y = 20; // Cannot assign to 'y' because it is a read-only property

In this example you can see how in the first case you can change the value of the properties 'x' and 'y'; on the contrary, in the second case, you can't change the properties because they are marked as readonly. As you can see, the readonly modifier can prevent the change of the values of the properties and save your code from annoying bugs. Typescript also exposes a special type to convert your types to full readonly types; this type is called ReadOnly. So we can review the previous example in this way

type Point = {
  x: number;
  y: number;
};
const point: Point = {
  x: 10,
  y: 10,
};
point.x = 10;
const readOnlyPoint: ReadOnly<Point> = {
  x: 10,
  y: 10,
};
readOnlyPoint.x = 10; // Cannot assign to 'x' because it is a read-only property
readOnlyPoint.y = 20; // Cannot assign to 'y' because it is a read-only property

From the readonly modifier, it's all! Goodbye guys!

Typescript - Tips & Tricks - Index Signature

Fri, 05 Mar 2021 00:00:00 GMT

Welcome back guys, today I'll speak about the "Index Signature". In some cases, we need to create some special types like dictionaries. These special types have some keys that identifies the elements and the datas. A simple example:

export type User = {
    name: string,
    email: string;
    session: string
}

export type UserDictionary = {
    [username: string]: User
}

const userDictionary: UserDictionary = {
  'myusername': { email: "myemail@email.it", name: "myname", session: "session" },
  'myusername1': {
    email: "myemail1@email.it",
    name: "myname1",
    session: "session",
  },
};

console.log(userDictionary.myusername); // { email: 'myemail@email.it', name: 'myname', session: 'session' }
console.log(userDictionary["myusername"]); // { email: 'myemail@email.it', name: 'myname', session: 'session' }
console.log(userDictionary.myusername1); // { email: 'myemail1@email.it', name: 'myname1', session: 'session' }
console.log(userDictionary["myusername1"]); // { email: 'myemail1@email.it', name: 'myname1', session: 'session' }
delete userDictionary.myusername;

In this case, the UserDictionary is a special type where the usernames are the keys of the objects and the user data are the values. This type is powerful because it permits the consumer to access directly to the data if it knows the keys and it permits to store a unique value of a specific key. With the index signature, we can create special types where the keys can be string or number. An important thing that you must remember is that the keys of these objects can be iterated with the for-in loop or with the Object.keys method.

console.log(Object.keys(userDictionary)); // [ 'myusername', 'myusername1' ]
for (const key in userDictionary) {
  console.log(key);
}
/*
'myusername'
'myusername1'
*/

It's all from the Index Signature for today. Bye-bye guys!

Typescript - Tips & Tricks - Optional modifier

Wed, 03 Mar 2021 00:00:00 GMT

Hi guys and welcome back, Today I'll talk about the optional modifier. Sometimes we have objects that have some optional properties. In these cases, we need to identify the optional and the required properties, so the consumers can know what is required and what not. To do this in typescript we have a special modifier named "optional" and it is identified by a question mark (?). Let's see an example:

export type Person = {
  name: string;
  surname: string;
  email: string;
  phone?: string;
};

const person1: Person = {
  name: "name1",
  surname: "surname1",
  email: "email1@email1.it",
};

const person2: Person = {
  name: "name2",
  surname: "surname2",
  email: "email2@email2.it",
  phone: "123",
};

In this example we can see the optional modifier in action, the "phone" property is marked as optional so in the "person1" object we can avoid setting the "phone" property. This modifier, also, could be used in the functions' parameters if we have one or more optional parameters. A simple example.

function printPerson(name: string, email: string, phone?: string): void {
  console.log(`Name: ${name}`);
  console.log(`Email: ${email}`);
  if (phone) console.log(`Phone: ${phone}`);
}

printPerson("name1", "email1@email1.it");
/*
  Name: name1
  Email: email1@email1.it
*/
printPerson("name2", "email2@email1.it", "123");
/*
  Name: name2
  Email: email2@email1.it
  Phone: 123
*/

We can see how in the first example we can avoid setting the phone parameter because it's optional.

From the optional modifier, it's all. See you soon guy!

Typescript - Tips & Tricks - any vs. unknown

Mon, 01 Mar 2021 00:00:00 GMT

Hi guys, today I'll talk about the difference between any and unknown.

Any Any type is a particular type in typescript. If you use this type, the compiler doesn't check your code, and the power is in your hands, but from great powers comes great responsibilities. In this case, the compiler doesn't check your code, but maybe your code could have bugs; these bugs will most likely be found by a user during his operations.

Unknown Unknown type is another particular type in typescript, it's similar to Any type but it helps us to prevent bugs at build time. The unknown type helps us to force the check of its type before using it.

Now let's turn to some examples.

Any Type

let myAny: any = true
myAny.trim().reverse().split(',');
let myAnyNumeric: number = myAny;
const sum = myAnyNumeric + 3;

In this case, we can see a problem right away; in the second line, we try to call the trim method on a boolean type. This code at runtime throws an exception, but we need to run this code to detect this bug. In the third line instead, I set a boolean type to a numeric type, and in the next line, I add three to this value. Ok, I think you have understood the possible problems you could have if you overuse any type.

Unkown Type

let myUnknown: unknown = true;
myUnknown.trim(); // Property 'trim' does not exist on type 'unknown'.ts(2339)
let myAnyNumeric: number = myUnknown; // Type 'unknown' is not assignable to type 'number'.ts(2322)
if (typeof myUnknown === 'string') myUnknown.trim();
if (typeof myUnknown === "number") {
  let myAnyNumeric: number = myUnknown;
  const sum = myAnyNumeric + 3;
}

In this example, we can see the power of using unknown type instead of any type. This type doesn't stop the compiler check but it helps us to check our type to prevent bugs at runtime. Typescript understands what you want to do, and it indicates you the correct way to prevent bugs.

After this post, I think that from now on you will prefer to use unknown instead of any and I know the reason ;)

That's all! Bye-bye guy!!

Typescript - Tips & Tricks - this parameter

Fri, 26 Feb 2021 00:00:00 GMT

Hello everybody and welcome back, today I'll talk about this parameter.

Sometimes we need to create functions that have to know the context to run correctly. A simple example, the mathematical power must know the base and the exponent number to run correctly. So we could create a simple method like this:

function pow(exponent: number) {
  return Math.pow(this.number, exponent);
}

const basePow = {
  base: 2,
  pow,
};

console.log(basePow.pow(2));

If we build and run this code, the console log's result will be "NaN", because in the pow method the value of the field "this.number" is undefined. N.B. if you build this code with the strict mode on true, the compiler detects the problem at build time and so the build fails

But now I explain the solution. In this case, the problem is the "number" field that doesn't exist in this context. Typescript helps us to prevent this error, it allows us to indicate the "this" type as a parameter. To do this, we need to declare the "this" context as the first parameter of the function, so typescript detects the "this" type and it helps us to prevent errors and bugs. So the code in the previous example should be rewritten like this:

function pow(this: { base: number }, exponent: number) {
  return Math.pow(this.base, exponent);
}

const basePow = {
  base: 2,
  pow,
};

console.log(basePow.pow(2));

In this case, the result at runtime is "4" as expected. If by chance we write the "basePow" object like this:

const basePow = {
  value: 2,
  pow,
};

when we try to call the method "basePow.pow(2)", the typescript language detects the error, and in this case, when we try to build the code the build fails.

That's all! See you soon guys!

Typescript - Tips & Tricks - Overloaded Functions

Wed, 24 Feb 2021 00:00:00 GMT

Welcome back, guys! The topic of today is Overloaded Functions.

All self-respecting programming languages have overloaded functions, so typescript has this feature too. To use this feature in typescript, we have to declare all the signatures of this function, and at the end, we have to write a single function that includes all these signatures. The last function is the only one with the implementation. The peculiarity of this function is that it must include all the possible implementations of the previous signatures. Here's a simple example that is more exhaustive than all these words.

function reverse(value: string): string;
function reverse(value: string[]): string[];
function reverse(value: string | string[]): string | string[] {
  if (typeof value === "string") return value.split("").reverse().join("");

  return value.slice().reverse();
}

console.log(reverse("Tips")); // 'spiT'
console.log(reverse(["T", "i", "p", "s"])); // [ 's', 'p', 'i', 'T' ]

As we can see, there are 2 signatures of the "reverse" function, one gets a string and returns a string as result, the second one gets a string array and returns a string array as result. The third function is the real implementation of this function. As we can see the parameter type is a literal-type that includes a string or a string array (the combination of the type in the signatures' parameters), we can make the same considerations for the result's type. In the function implementations, we detect the parameter's type at runtime and manipulate the parameter to return the correct type according to the function we are overloading.

An important thing to remember is that the implementation function is not exposed.

That's all for today! See you soon guys!

Typescript - Tips & Tricks - Union and Intersection

Mon, 22 Feb 2021 00:00:00 GMT

Hi and welcome back! Today I talk about Union and Intersection.

In some cases, we have to combine different types to create new types, or sometimes we have parameters that could be of different types. Typescript helps us with two powerful features: Union(|) and Intersection(&).

Union

A union type describes a value that can be one of several types.

type Padding = number | string
let paddingNumber: Padding = 1
let paddingString: Padding = '----';
let paddingError: Padding = true // Type 'boolean' is not assignable to type 'Padding'.

In this case, the padding can be a number or a string, and the compiler detects if you set different types; this feature can be used also with custom types.

type Fish = {
  name(): string;
  swim(): true;
};
type Cat = {
  name(): string;
  meows(): true;
};
type Pet = Fish | Cat; // { name(): string; }
declare function createPet(): Pet;
let pet = createPet();
pet.name()
pet.swim() // Property 'swim' does not exist on type 'Pet'
pet.meows(); // Property 'meows' does not exist on type 'Pet'

In this example we can see how the union type creates the Pet type; the Pet type is composed by a single method "name". This method is the only one present in the two initial types: Fish and Cat.

Intersection

An intersection type combines multiple types into one.

type Point2D = {
  x: number;
  y: number;
};
type Point3D = Point2D & {
  z: number;
};
let point2d: Point2D = { x: 0, y: 0 };
let point3d: Point3D = { x: 0, y: 0, z: 0 };

We can see that the Point3D type is the union of the Type Point2D and the type { z: number; }.

That's all for today! See you soon guys!

Typescript - Tips & Tricks - keyof

Fri, 19 Feb 2021 00:00:00 GMT

Welcome back! Today I'll talk about the keyof operator.

This operator helps us to extract the object's properties such as Literal-types

type Person = {
  firstName: string;
  surName: string;
  age: number;
  location: string;
};

type PersonKeys = keyof Person; // "firstName" | "surName" | "age" | "location"

This operator can help us to create new methods that should depend of other types; e.g.

function get<T, K extends keyof T>(obj: T, prop: K): T[K] {
  return obj[prop];
}

function set<T, K extends keyof T>(obj: T, prop: K, value: T[K]): void {
  obj[prop] = value;
}

but also to create new types from other types e.g

type ReadOnly<T> = {
  readonly [K in keyof T]: T[K];
};

type ReadOnlyPerson = ReadOnly<Person>
/*
type ReadOnlyPerson = {
    readonly firstName: string;
    readonly surName: string;
    readonly age: number;
    readonly location: string;
}
*/

How we can see this operator is more powerful and it can help us to create new strict type or new strict methods.

That's all for today. See you soon guys!

Typescript - Tips & Tricks - Literal Types

Wed, 17 Feb 2021 00:00:00 GMT

Welcome back! Today I show you the Literal Types.

This feature permits you to create a set of relationship values.

type Direction = "North" | "South" | "East" | "West";

Literal types in this case create also a Type Guard of your field, so the compiler can detect your errors or your typos.

let directionError: Direction = "east" // Type '"east"' is not assignable to type 'Direction'
let direction: Direction = "East" // OK

You can create Literal Types from different types such as booleans, numbers, and strings, and you can combine together different types too.

type Valid = false | 0 | true | 1;

That's all for today See you soon guys!

Typescript - Tips & Tricks - typeof

Mon, 15 Feb 2021 00:00:00 GMT

Today I want to start a series of tips and tricks about Typescript. I will try to publish two/three tips & tricks a week. Before start, I want to explain why I start this series. I start this series because every day I see too many any types in the typescript files and so I want to help the developers to learn better the typescript language.

typeof

Today I start with the typeof operator. Typeof is an operator used to detect the type of our variables. A little preamble, typeof is also a javascript operator, but with typescript, it has superpowers.

Typeof in javascript has these behaviors:

const valueString = "string";
const valueNumber = 1;
const valueBoolean = true;
const valueBigInt = 1n;
const valueFunction = () => true;
const valueUndefined = undefined;
const valueNull = null;
const object = {
  prop1: "value1",
  prop2: "value2",
};

console.log(typeof valueString); // string
console.log(typeof valueNumber); // number
console.log(typeof valueBoolean); // boolean
console.log(typeof valueBigInt); // bigint
console.log(typeof valueFunction); // function
console.log(typeof valueUndefined); // undefined
console.log(typeof valueNull); // object
console.log(typeof object); // object

How we can see some things are strange: e.g. when we get the typeof of a null variable javascript returns an object type.

But here we see the same example in typescript:

type valueStringType = typeof valueString; // "string"
type valueNumberType = typeof valueNumber; // 1
type valueBooleanType = typeof valueBoolean; // true
type valueBigIntType = typeof valueBigInt; // 1n
type valueFunctionType = typeof valueFunction; // () => boolean
type valueUndefinedType = typeof valueUndefined; // undefined
type valueNullType = typeof valueNull; // null
type objectType = typeof object; // { prop1: string; prop2: string; }

The first impact is friendlier for us developers because the typeof operator converts the type exactly as expected. The best advantages can be seen in the types: function, null, object.

But now an advanced example:

const item = {
  id: '0000',
  name: 'Item',
  unit: {
    id: '1',
    code: 'PZ'
  },
  variants: [{
    id: '1',
    code: '001',
    color: 'FFFFFF'
  }]
};

type Item = typeof item;
type Unit = typeof item["unit"];
type Variant = typeof item.variants[number];

In this example, we can see how we can extract simple types from a complex object.

I leave you the in this reference of the official documentation of this operator.

For today is all. See you soon!

Typescript read-only object to an Enum type

Sat, 06 Feb 2021 00:00:00 GMT

Sometimes I need to convert a read-only object to an enum type; so I created a simple function utility that helps me to convert this object to an "enum" type. This is the code to build the type. Some examples of use.

Gits URL

Why TDD is not only code that tests your code

Wed, 30 Dec 2020 00:00:00 GMT

In this strange year, at the end of the summer, I decided to change my work experience. I had some new ambitions and a willingness to learn new things and improve others. One of the things I wanted to improve is unit testing, an argument that I couldn't practice in my past jobs, so I started to search for a new experience.

After some job interviews, I made my decision, and in mid-November, I started my new experience. In the first period, my time was divided in half between work and study. The study was divide into two sections: corporate culture and technical culture. Today I want to write some thoughts about a single point presents in the technical culture: Test-Driven Development (TDD).

What is TDD?

Test-driven development is a software development process relying on software requirements being converted to test cases before the software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. For more developer is only a process known as "write tests before your code" (also for me until recently) The method bases its power on a simple repeatable flow "Red Green Refactor". In the red step, the developer must write the test for the next development feature; obviously, this test the first time fails because the code isn't present. In the green step, the developer must change the test spy from red to green with the minimum code possible. In the Refactor step, the developer can improve, review and organize the code if it's necessary.

My study about TDD

Before starting my new work experience I had read some articles about this topic and a famous book known as the guide of the method Test Driven Development. By Example, the author is Kent Beck, I think introductions are unnecessary. The book is very interesting and illustrates how to implement the method in the best way. It explains the bases of the method, it illustrates how to implement the method and it shows some best practices to improve the implementation during our work. After this reading, I had to try to implement this method in my daily work but with greater difficulty, I didn't understand why but for me TDD started to be a difficult methodology to implement in my daily work. The time spent implementing the method reduced my productivity drastically and the time to release the new feature increased, so I decided to put it aside (I'm talking about the period before changing my job).

TDD after changing my job

During my onBoarding, as I said before, I spent some time studying and practicing TDD. In this period I approached the method from a different point of view: Agile. Agile is a practice that I studied much during my school period but I couldn't implement it in my previous jobs. So I started to change my mind about TDD, from "write tests before typing code" to "write the business requirement before typing the implementation". This new approach helps me to move my development from the output to the outcome and improves my velocity to implement the TDD method. Before this approach my mind spent too much time to discover all the possible failure of the code before start implement the feature, now my mind spends the right time to write the outcome of the code and after that, I type the code to change the test spy from red to green and then I refactor the code to review or organize it. Only after that, my mind spends not too much time to add tests that represent the extreme cases and if necessary I refactor the code to pass these cases as well. Writing my tests by basing them on the outcome instead of the output changed also my idea about the TDD method, it's a powerful tool to improve our velocity and the consistency of our code. It helps us to rest assured during refactoring, it helps us to be sure of the delivery code, and our outcomes respect the business requirements. The flow "Red Green Refactor" followed by us during the development helps us to follow the correct way and leave our mind free to create new features, when we break something the test suite notify us and we can fix the error before this goes live.

Conclusion

TDD is a powerful method for me and I think also for thousands of developers in the world. In my opinion, in an agile context, but not only, it's an extraordinary tool to improve the confidence of the code but also to create powerful outcome documentations. It helps developers to think about the outcome of their work before typing a single raw of code, it helps them to write their code without fear of breaking something else, and I think these pros are not limited to developers but these are pros also for the stakeholders, the sponsors and all the members of the project. It's a powerful tool also to have continuous feedback from our code, it helps us to stay confident and review our code in serenity. Also, it helps us to increase our team with new developers because if a development breaks the code outcome the test suite notifies us and we can fix it quickly.

Luca Del Puppo — Run, Code & Learn

Automating my Codemotion Badge with Antigravity

Small intro about the board

Antigravity

Let’s start cooking

CMNode v0 WiFi Configuration & Dual Screen Setup

User Review Required

Ideas for the "Fantastic" Second Screen:

Proposed Changes

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Verification Plan

Manual Verification

CMNode v0 WiFi Configuration & Dual Screen Setup

Design Choice: "Hacker Terminal"

Proposed Changes

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Verification Plan

Manual Verification

The implementation

The refine

Conclusion

Take control of your job with GitLens Launchpad

The first useful extensions to the migration

The Final Solution

Conclusion

The Mood Mirror App - My Antigravity first experience

Antigravity Intro

"The Mood Mirror" Setup

Commit linting into the project

The Gemini 3.0 integration

Conclusion

Improve Your Git Commit Messages with GitLens Tips

How to generate messages

Custom Instructions

Conclusions

Do you really need the Cloud to work with AI?

Features available

Let's talk about features

Language Detector

Translator API

Summarizer API

Recipe Radar with AI App

Conclusion

A Promise is forever

Section 1: Understanding Promises

What is a Promise?

Creating a Promise

Promise States

Section 2: Working with Promises

then, catch, and finally

Chaining Promises

Error Handling in Promises

Real-world Examples

Section 3: Advanced Promise Concepts

Async/Await Syntax

Error Handling in Async/Await

Handling Multiple Promises

Promise.all

Promise.race

Promise.allSettled

Promise.any

Understanding Promise.withResolvers

Section 4: Under the Hood

Event Loop and Promises

Creating Custom Promises

Best Practices and Pitfalls

Conclusion

The Reflect API: The Swiss Army Knife Every JavaScript Developer Needs

🎯 Core Objectives of Reflect

🛠 Reflect Methods

1. Reflect.apply()

2. Reflect.get()

3. Reflect.set()

4. Reflect.defineProperty()

5. Reflect.deleteProperty()

6. Reflect.ownKeys()

🚀 Why Use Reflect?

1. Functional Paradigm

[MODIFY] `src/main.cpp` (or `NodeV0.ino`)

[MODIFY] `src/main.cpp` (or `NodeV0.ino`)

1. `Reflect.apply()`

2. `Reflect.get()`

3. `Reflect.set()`

4. `Reflect.defineProperty()`

5. `Reflect.deleteProperty()`

6. `Reflect.ownKeys()`

1. Accessing Descriptors with `Object.getOwnPropertyDescriptor()`

2. Defining Descriptors with `Object.defineProperty()`

3. Batch Operation with `Object.defineProperties()`

4. Computed property with `Object.defineProperty()`