DEV Community: Carlos Azaustre

SOLID Principles in JavaScript

Carlos Azaustre — Tue, 17 Oct 2023 09:49:45 +0000

TL;DR:

Prefers video content? Here are the 5 SOLID programming principles explained, applied to JavaScript (in Spanish)

Introduction to SOLID - What They Are and Why They Matter

The SOLID principles are an acronym of five design values:

Single Responsibility Principle (S)
Open-Closed Principle (O)
Liskov Substitution Principle (L)
Interface Segregation Principle (I)
Dependency Inversion Principle (D)

We'll delve into each of these principles applying them to our favorite programming language: JavaScript. We begin with the first principle.

Single Responsibility Principle (S)

According to this principle, a class should have only one reason to change, that is, it should have only one task or responsibility.

To illustrate this principle, let’s think of an orchestra. Each musician has an instrument they know how to play perfectly. The violinist knows how to play the violin, but if we also put them to play the drum, surely something would not work well.

Applying this example to programming, each class or function should have a single responsibility. This simplifies understanding, maintenance, and modification of the code in the future.



function calculateSalary(employee) {
    let salary = employee.hoursWorked * employee.hourlyRate;
    let report = /*...*/;
    console.log(report);
    return salary;
}

Example provided with a calculateSalary() function, which is refactored to adhere to the single responsibility principle.



function calculateSalary(employee) {
    return employee.hoursWorked * employee.hourlyRate;
}

function generateReport(employee, salary) {
    let report = /*...*/;
    console.log(report);
}

Open-Closed Principle (O)

The second SOLID principle is the open-closed principle. Its official definition holds that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.



function processPayment(price, cardDetails) {
    /*...*/
    console.log('Payed with Card.');
}

Example provided with a processPayment() function and how it can be extended to handle different payment methods without modifying the existing code.



function processPaymentWithPayPal(price, accountDetails) {
    /*...*/
    console.log('Payed with PayPal.');
}

Liskov Substitution Principle (L)

The Liskov substitution principle states that "objects of a superclass should be replaceable by objects of a subclass without affecting the correctness of the program".



// example function to make HTTP requests
function makeRequest(url, errorHandler) {
    fetch(url)
        .then(response => response.json())
        .catch(error => errorHandler.handle(error))
    }

// We can have several functions to handle errors
const consoleErrorHandler = function handle(error){
    console.log(error)
}

const externalErrorHandler = function handle(error){
    sendErrorToExternalService(error)
}

makeRequest(url, consoleErrorHandler);
makeRequest(url, externalErrorHandler);

Example provided with a makeRequest() function and how different error handler objects can be used interchangeably without causing errors in the program.

Interface Segregation Principle (I)

The fourth SOLID principle, "I," refers to the Interface Segregation Principle. Based on this principle, no class should be forced to implement interfaces or methods that it will not use.

It's better to have specific interfaces, rather than a single general interface. And this also applies to functions in JavaScript.



class Product {
    constructor() { /* */ }

    getDetails() { /* */ }
    saveToDb() {/* */ }
    displayInFrontEnd() { /* */ }
}

class DigitalProduct extends Product{
    // saveToDb() is extended but not necessary }
}

// ---- //
// Refactor

class Product {
    constructor() { /* */ }

    getDetails() { /* */ }
    displayInFrontEnd() { /* */ }
}

class PhysicalProduct extends Product {
    constructor() {
        super()
    }
    saveToDb() { /* */ }
}

class DigitalProduct extends Product{
    // saveToDb() is not extended
}

Example provided with a Product class, illustrating the violation of this principle when a DigitalProduct class extends Product but doesn't need one of its methods. The example then shows the refactoring following this principle to have a PhysicalProduct class extending Product where the unnecessary method is moved.

Dependency Inversion Principle (D)

The last principle, "D," is the Dependency Inversion Principle. This principle holds that high-level modules, i.e., the modules that contain strategic decisions and high-level directives, should not depend on low-level modules, which are the modules that contain detailed and low-level logic.

Both, high-level and low-level modules, should depend on abstractions.



class MySqlConnection {
    connect() { /* */ }
}

class PasswordReminder {
    constructor() {
        this.dbConnection = new MySQLConnection();
    }
}

// Refactor
class MySqlConnection {
    connect() { /* */ }
}
class PostgreSqlConnection {
    connect() { /* */ }
}

class PasswordReminder {
    constructor(connection) {
        this.dbConnection = connection
    }
}

Example provided with a PasswordReminder class initially depending directly on a MySQLConnection class. The refactoring follows the principle by having PasswordReminder receive an instance of a class implementing a common "database connection" interface, showing both MySQLConnection and PostgreSqlConnection classes.

Final Thoughts

SOLID rules are a very useful tool for programming. However, like any tool, they should not be applied blindly in all cases. The advice is to follow these principles where it makes sense and can help you maintain and improve your code in the long term.

"Software is a cycle in which you are developing code, new features or functionalities are needed, bugs appear unintentionally or intentionally, and you will need to refactor. You don't necessarily always have to be writing new code. Most of your time you will be reading code from others or even yours and you will be able to see that there are parts that you can refactor to improve maintenance and even the performance of your application."

See you next time!

You have a spanish version of this article here

React Tutorial: How to develop an application from scratch with modern libraries

Carlos Azaustre — Tue, 26 Sep 2023 17:09:46 +0000

Introduction

In this step-by-step tutorial, we are going to learn how to develop a React web application from scratch using some of the most popular tools in the React ecosystem.

Specifically, we will use:

Zustand for global state management
React Query for data fetching and caching
React Hook Form for form handling
React Router for navigation
React Hot Toast for showing notifications

The application we will build will simulate a hotel booking system, with a page to list hotels and a details page to book rooms in a specific hotel.

Here are some of the features we will implement:

Fetch and display a list of hotels from an API
Navigate to the detail page of a specific hotel
Form to select dates and book a room
Global state management for bookings
Notifications on errors or successful bookings
Form validations

So without further ado, let's get started!

Preparing the project

The first thing we need to do is prepare our React project. For this, we will use create-react-app which will allow us to bootstrap quickly:

npx create-react-app hotel-reservations

This will generate the basic React project structure in a folder called hotel-reservations.

Next, we install the dependencies by running npm install inside that folder.

The dependencies we will use in this project are:

zustand
react-query
react-hook-form
react-router-dom
react-hot-toast

So we install them by running:

npm install zustand react-query react-hook-form react-router-dom react-hot-toast

Our project is now setup and ready! We can now start coding.

Global state with Zustand

First we are going to configure our global state using Zustand.

Zustand is a lightweight library for managing global state in React. It allows us to have a centralized store that can be accessed from any component to read and update state.

For this, we create a store.js file and add the following:

import { create } from 'zustand'const useStore = create(() => ({reservations: [],addReservation: (hotel, dates) => {set(state => ({reservations: [...state.reservations, { hotel, dates }]}))}}))export default useStore

Basically we are creating a useStore hook that gives us access to the reservations global state and an addReservation action to add new bookings.

We can import and use this hook from any component in our app.

Data fetching with React Query

Now we are going to take care of fetching data from an API. For this we will use React Query.

React Query allows us to perform data fetching, caching, and updating. It also handles loading, error and automatic revalidation states.

First, we create a db.json file with mock data:

{"hotels": [{"id": 1,"name": "Hotel Sunshine","description": "Beachfront hotel with pool","image": "hotel-1.jpg"},{"id": 2,"name": "Hotel Mountain Spa","description": "Luxury hotel in the mountains","image": "hotel-2.jpg"}]}

Then, we create a script in package.json to spin up a dev server with that data:

"server": "json-server --watch db.json --port 3001"

Now we can create our fetching function:

// hotels.js
const fetchHotels = async () => {const response = await fetch('http://localhost:3001/hotels')if (!response.ok) {throw new Error('Network error')}return response.json()}export { fetchHotels }

And use it in our HotelsList component:

// HotelsList.js
import { fetchHotels } from './hotels'import { useQuery } from 'react-query'export default function HotelsList() {const { data, error, isLoading } = useQuery('hotels', fetchHotels)// display data or loading/error statereturn (// JSX to display hotels)}

That's all we need to implement data fetching with React Query!

Forms with React Hook Form

Now let's implement the booking form with React Hook Form.

React Hook Form allows us to build forms easily in React, with validations, error handling and state management.

First we create our BookingForm component:

// BookingForm.js
import { useForm } from 'react-hook-form'function BookingForm() {const { register, handleSubmit, formState: { errors } } = useForm()const onSubmit = (data) => {// submit form}return (<form onSubmit={handleSubmit(onSubmit)}><input{...register('checkinDate', { required: true })}/>{errors.checkinDate && (<p>Checkin date required</p>)}// ...more inputs and validations</form>)}

We are registering the inputs so React Hook Form controls them, handling submit, and displaying any validation errors.

And that's all we need for powerful form handling with React Hook Form!

Navigation with React Router

Now we are going to configure navigation between different views using React Router.

First, we wrap our app with a <BrowserRouter> in index.js.

Then, we create the routes in App.js:

import { Routes, Route } from 'react-router-dom'function App() {return (<Routes><Route path="/" element={<h1>Hotels</h1>} /><Route path="/hotel/:id" element={<HotelDetails />} /></Routes>)}

Finally, we use the useNavigate hook inside our HotelsList to navigate to a hotel's detail view when clicked.

And that's all we need for navigation with React Router!

Notifications with React Hot Toast

Lastly, we are going to add notifications using React Hot Toast.

React Hot Toast allows us to show popup messages very easily.

We import it in our BookingForm component:

import { toast } from 'react-hot-toast'

And show a success notification when booking:

// inside onSubmit
toast.success('Booking successful!')

We also wrap it in <Toaster> to make it work app-wide.

And that's all we need to show notifications! React Hot Toast handles the UI.

Summary

In this article we have seen how to develop a React web application from scratch using:

Zustand for global state
React Query for data fetching
React Hook Form for forms
React Router for navigation
React Hot Toast for notifications

We have learned how to:

Setup a global store with Zustand
Fetch data from an API with React Query
Create a form with validations using React Hook Form
Add navigation between views with React Router
Show notifications to the user with React Hot Toast

These tools have allowed us to quickly build a React application in a straightforward, declarative way with great practices.

You can find the code in this GitHub Repository (You can give a Star ⭐️ if you like it)

carlosazaustre / hotel-reservation-app

Hotel booking application, using React along with some of the most popular and powerful libraries in the ecosystem: React/TanStack Query, Zustand, Wouter, React Hooks Forms, React Hot Toast, and Material UI

hotel-reservation-app

Code from the ReactJS Video Tutorial on YouTube

You will learn:

How to set up a React JS project from scratch.
Integration and use of React/TanStack Query to manage queries and mutations.
Global state with Zustand.
Navigation with Wouter.
Forms with React Hooks Forms.
Notifications with React Hot Toast.
Design and styles with Material UI.

This tutorial is perfect for both beginners looking for a detailed "react js tutorial" and experienced developers wanting to expand their knowledge and learn about new libraries.

You don't need to download anything beforehand; I'll show you how to do everything from the beginning.

So, prepare your development environment and join me on this exciting journey through the world of React JS!

View on GitHub

Also, you can find this tutorial in video format (in spanish)

TUTORIAL REACT JS desde cero | Crea una aplicación paso a paso | React Query, Zustand, Wouter. - YouTube

En este tutorial de React JS desde cero te guiaré paso a paso en la creación de una aplicación de reservas de Hotel, utilizando React junto con algunas de la...

youtube.com

I hope you found this tutorial useful! Don't forget to share it and follow me for more web development content. See you next time!

Conventional Commits - Specification for Your Commit Messages

Carlos Azaustre — Thu, 02 Feb 2023 11:18:31 +0000

This content was originally published in spanish on my blog

What are Commit Messages?

Commit messages are a way of documenting changes made in a code repository.

These messages are very useful for understanding what changes were made in a project and why they were made.

When working in a development team, it is very important that all team members can understand what changes were made to the code and why they were made.

Conventional Commits

As stated on their official page: It is a specification
for giving meaning to commit messages making them understandable both for machines and for people.

It provides a simple set of rules for creating an explicit commit history; which makes it easier to write automated tools.

This convention fits with SemVer, since we can explain in the commit messages if it's a feature, bugfix, even if there are Breaking Changes.

If you were unfamiliar with the term Semantic Versioning, in this short video I'll explain it to you:

The structure of a commit message following the specification would be as follows:

<type>[optional scope]: <commit description>

[message body, optional]

[footer(s), optional]

Commit Types

The commit types are as follows:

feat: A new feature or functionality. It would have correlation with a MINOR version following SemVer.
fix: A corrected error. It would have correlation with a PATCH version following SemVer.
BREAKING CHANGE: A change that contains this word in the message footer or a ! sign after the type or scope,
breaks compatibility with previous versions. It would have correlation with a MAJOR version following SemVer.

The following types are also allowed:

build: Changes that affect the build system or external dependencies (e.g. changes to the package.json).
ci: Changes to our continuous integration configuration files and scripts.
docs: Changes to documentation.
chore: Other changes that do not affect source code.
perf: A code change that improves performance.
refactor: A code change that does not correct an error or add a feature.
style: Changes that do not affect the meaning of the code (whitespace, format, missing commas, etc).
test: Add missing tests or correct existing tests.

Scope

The scope is optional and serves to specify the scope of the commit. For example, if we are working on a monorepo project, we can specify the package we are modifying.

Examples

Let's see some examples of commit messages following the specification:

Commit that adds a new feature, without a specific scope.

feat: add support for TypeScript

Commit that fixes a bug, within the ui package of our project.

fix(ui): bugfix on Button component

Commit that breaks compatibility with previous versions, although it doesn't add new features or fix bugs.

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Commit that adds missing tests.

test(ui): add missing tests for Button component

Commit that adds a task for the continuous integration/deployment system.

ci: add GitHub Actions workflow

Commit with a long descriptive message and multiple footers.

fix(api): prevent duplicate users from being created

This commit fixes a bug where the API would allow duplicate users to be created with the same email address. This commit also adds a new `unique` constraint to the `users` table to prevent this from happening in the future.

Paired with: X
Fixes #123

Why use Conventional Commits?

It allows for automatic generation of the CHANGELOG file.
Automatically determines version changes following SemVer (based on the types of commits used).
Communicates the nature of changes to other team members or anyone interested.
Activates build and deployment or publishing processes.
Makes it easier for others to contribute to the project by allowing them to explore the commit history in a more structured way.

Tools to use Conventional Commits

VSCode Plugin

The first one I use is the VSCode extension or plugin, Conventional Commit. It helps me choose the type of commit, the scope, write the message,... all based on dialog windows.

Gitemoji

To make our commits more colorful, we can use the Gitemoji convention. It's a convention where
emojis represent the type of commit. For example, the emoji 🐛 represents a bugfix, ✨ a new feature, etc... So with a quick glance you can see what type of change has been made.

Commitlint

Commitlint is a tool that allows us to configure rules to validate commit messages.
Just like we use a linter to check if we follow certain style rules in our code, we can use it for commit messages.

For this, you need to install the @commitlint/cli and @commitlint/config-conventional libraries in your project.

npm install --save-dev @commitlint/cli @commitlint/config-conventional

Once installed, you must create a configuration file called commitlint.config.js in the root of your project with the following content:

module.exports = {
  extends: ["@commitlint/config-conventional"],
};

Husky

We already saw what Husky was used for in a previous post. Now we will add a new rule to the pre-commit hook to verify and validate if the commit message complies with the Conventional Commits rules.

If you already have Husky configured, all you have to do is run the following command in the root of your project to add the command to the commit-msg hook:

npx husky add .husky/commit-msg  'npx --no -- commitlint --edit ${1}'

And that's it, every time you make a commit, it will verify that it follows the rules.

CHANGELOG

Finally, it is also interesting to be able to automatically generate the CHANGELOG file from the commit messages. There are various tools for this, one of them is Conventional Changelog

Hope this is helpful ✨

Do Like 💛 & Save 🔖

Do Follow me on Twitter and Linkedin for more content related to Web Programming and JavaScript

How to deploy a webapp to Google Cloud Run with Cloud Build

Carlos Azaustre — Thu, 11 Jul 2019 08:34:57 +0000

This article was originally published in spanish on my blog.

In the past Cloud Next event, Google announced a new product of its services: Cloud Run. This is an evolution of App Engine which let us run any backend language on a Docker container.

In this article, I will describe how to start with this service and run your first Node.js app with it. Let's go!

Create a project on Google Cloud.

Go to Google Cloud Console and create a new project. I'm named hello-cloud-run but you can name it as you want. Keep in mind the ProjectID which we are using later.

To be able to use Google Cloud Platform you will need a Gmail/GSuite account, and to activate the billing. If it is the first time you sign up, you have $300 free in credits to use for one year.

API Activation

We need to activate some APIs to have not problems. One is the Cloud Run API and another one is Cloud Build API which we will use later.

Click on Enable APIs and Services and look for Cloud Run

Activate the Cloud Run API and do the same with Cloud Build API

Our App code

I have created this example code. It is a Node.js application that in the root path returns a JSON object with two properties: The today date and the time that the application is running up.

Create a Node project with the following command (remember to have Node.js installed):

$ npm init -y

Then, install express as dependence:

$ npm i express

Create an index.js file with the following content:

const express = require('express');
const app = express();
const port = process.env.PORT || 3000;

const dateStart = Date.now();

app.get('/', (req, res) => {
  const today = new Date();

  res.json({
    date: today,
    up: `${(Date.now() - dateStart) / 1000} seg.` 
  });
});

app.listen(port, () => {
  console.log(`Server running on port: ${port}`);
  console.log('Press CTRL + C to quit');
})

Let's update the package.json file to add the start script:

...
"scripts": {
   "start": "NODE_ENV=production node index.js"
  },
...

On this way, when we execute npm start command the app will run. We can testing locally.

Next step is to create the Dockerfile with this we define the container which contains the application code. Here you have the content:

FROM node:10

WORKDIR /usr/src/app

ENV PORT 8080
ENV HOST 0.0.0.0

COPY package*.json ./

RUN npm install --only=production

# Copy the local code to the container
COPY . .


# Start the service
CMD npm start

With this file we are configuring an environment with Node v10 as a base, the working directory will be /usr/src/app. We are defining as environment variables the PORT: 8080and HOST: 0.0.0.0. We are copying the package.json and package-lock.json to the working directory and installing the dependencies with RUN npm install --only=production.
Finally, we are moving the app code to the container working directory with COPY . . And with the last one CMD npm start the app is run.

We can try if everything is ok so far, generating the image and the start the docker container. Write the following commands on your terminal:

$ docker build --tag hello-cloud-run:01 .
$ docker run -p 8080:8080 hello-cloud-run:01

Keep in mind you need to have Docker installed on your system.

The build command you have created an image following the Dockerfile steps with the name hello-cloud-run:01. The run command let you run the app on http://localhost:8080

If all is ok you should see the following on your browser:

Automate the container deploying

Once our project is configurated on Google Cloud and the application code is written and containerized, the following step is to upload it to Google Container Registry.

We are going to create a YAML file with the steps to build and deploy the code using Google Cloud Build. This service is similar to TravisCI but customized to Google Cloud.

On this way, every time we push our code to Github (for example) Cloud Build will build the Docker image and upload the new code to Cloud Container Registry and deploy it into Cloud Run. So awesome!

First, we need to create a trigger on Cloud Build:

Once created, we choose Github as source repository option

We need to authenticate on the service chosen (in this case Github) and to choose the repository.

You need to store the application code on it. If you prefer other option like Bitbucket or Cloud Source, go ahead.

You can use this repository as the base project.

On settings, to choose Cloud Build Configuration file (yaml or json) as Build configuration, putting the name cloudbuild.yaml which we write later.

All right! On the options, you can choose if you want to dispatch the trigger every time you push to a specific branch repo or with a tag.

Add roles and permissions

Once you have activated the Cloud Run API we need to follow the next steps to bring access from outside to our application.

Grant Cloud Run Admin role to Cloud Build Service account
1. From Cloud Console, access to IAM Menu
2. On the members' list, locate and select [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com
3. Click on EDIT button (pencil icon) to approve the new role.
4. Click on Add another role
5. Select Cloud Run and then Cloud Run Admin
6. Click on Save
Grant IAM Service Account User to Cloud Build Service Account from Cloud Run Runtime service account
1. From Google Cloud Console, access to Service Accounts
2. On the members' list, locate and select [PROJECT_NUMBER]-compute@developer.gserviceaccount.com
3. Click on Show Info Panel up on the right corner.
4. On Permissions panel, click on Add Member button.
5. Introduce the Cloud Build service account [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com in the New Member new field.
6. On the Role dropdown, select Service Accounts and then Service Account User.
7. Click on Save.

Now in our code, we are going to create the cloudbuild.yaml file which executes the necessary commands to build the docker image, upload it to container registry and deploy it to Cloud Run:

steps:
  # build the container image
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/hello-cloud-run:${SHORT_SHA}', '.']
  # push the container image to Container Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/hello-cloud-run']
  # deploy container image to Cloud Run
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['beta', 'run', 'deploy', 'hello-cloud-run', '--image', 'gcr.io/$PROJECT_ID/hello-cloud-run:${SHORT_SHA}', '--region', 'us-central1', '--allow-unauthenticated']
  env:
  - 'PORT=8080'
images:
- gcr.io/$PROJECT_ID/hello-cloud-run

Keep in mind that <PROJECT_ID> is your project identifier.

Checking all is working

So now, we will deploy our application code to a repository, in my case I chose Github. (this is my repo for this example). When we made a change and we will push it to master branch, the build configuration will trigger and it will follow all the steps to upload it to Container Registry and then deploy it to Cloud Run!

When you made push to your repo, check inside Google Cloud Console if Cloud Build has triggered an event

If it is Ok, you can go to Container Registry section and check if the Docker image has been created:

And the last, check if in Cloud Run section you have an application running:

One last thing is to let external invocations to the service because for default is private.

Add allUsers to the new members and the Cloud Run > Cloud Run Invoker role.

You can see a more detail explanation on this post in Dev.to

And yes! You finish! Click on the URL associated to your Cloud Run deployment and if all is OK you can see something similar to this on your browser