DEV Community: Daniel Guglielmi

Redux Toolkit with Typescript and Next.js 14

Daniel Guglielmi — Wed, 27 Dec 2023 17:12:23 +0000

Installing Redux

yarn add @reduxjs/toolkit
yarn add react-redux

Folder Structure

In the root directory, let's establish the following folder structure:

lib: This folder will encompass all the Redux files and folders.
features: This section holds the files containing slices that will be integrated into our global store. Here, we can create as many slices as necessary to segment the state per feature.
bookSlice.ts: This file comprises the structure with the state and actions that impact the state.
hooks.ts: Within this file, we will set up new hooks for use with TypeScript in Redux.
store.ts: In this file, we will configure the global store and consolidate the various slices created to make them accessible globally.

Creating the Slice

The following content is an example of the structure; ensure you can adapt this example to your needs.

bookSlice.ts

import { createSlice } from '@reduxjs/toolkit';
import type { PayloadAction } from '@reduxjs/toolkit';

interface BookState {
  floor: number | null;
  unit: string;
}

const initialState: BookState = {
  floor: null,
  unit: '',
};

export const bookSlice = createSlice({
  name: 'booking',
  initialState,
  reducers: {
    updateFloor: (state, action: PayloadAction<number>) => {
      state.floor = action.payload;
    },
    updateUnit: (state, action: PayloadAction<string>) => {
      state.unit = action.payload;
    },
  },
});

export const { updateFloor, updateUnit } = bookSlice.actions;
export default bookSlice.reducer;

Creating the Store

In the following example, I intentionally added two slices: the previously created bookSlice.ts and a new one named apartmentSlice. This is to illustrate how to incorporate new slices into the store.

store.ts

import { configureStore } from '@reduxjs/toolkit';
import bookSlice from './features/bookSlice';
import apartmentSlice from './features/apartmentSlice';

export const bookStore = () => {
  return configureStore({
    reducer: {
      booking: bookSlice,
      apartment: apartmentSlice,
    },
  });
};

export type AppStore = ReturnType<typeof bookStore>;

export type RootState = ReturnType<AppStore['getState']>;
export type AppDispatch = AppStore['dispatch'];

Creating the Hooks file

In this file, we will create the hooks to access the useSelector and dispatch.

hooks.ts

import { useDispatch, useSelector, useStore } from 'react-redux';
import type { TypedUseSelectorHook } from 'react-redux';
import type { RootState, AppDispatch, AppStore } from './store';

export const useAppDispatch: () => AppDispatch = useDispatch;
export const useAppSelector: TypedUseSelectorHook<RootState> = useSelector;
export const useAppStore: () => AppStore = useStore;

Adding the Store Provider to our project

As we are implementing Redux in our project with Next.js 14, the folder structure we are using is within the app directory.

Inside the app folder, we will create a file called StoreProvider.tsx with the following content:

StoreProvider.tsx

'use client';
import { useRef } from 'react';
import { Provider } from 'react-redux';
import { bookStore, AppStore } from '@/lib/store';

export default function StoreProvider({ children }: { children: React.ReactNode }) {
  const storeRef = useRef<AppStore>();
  if (!storeRef.current) {
    // Create the store instance the first time this renders
    storeRef.current = bookStore();
  }
  return <Provider store={storeRef.current}>{children}</Provider>;
}

Once this file is created, open the app\layout.tsx file to integrate the store provider:
layout.tsx

import type { Metadata } from 'next';
import { Inter } from 'next/font/google';
import StoreProvider from './StoreProvider';
import './globals.css';

const inter = Inter({ subsets: ['latin'] });

export const metadata: Metadata = {
  title: 'Create Next App',
  description: 'Generated by create next app',
};

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang='en'>
      <body className={inter.className}>
        <StoreProvider>{children}</StoreProvider>
      </body>
    </html>
  );
}

We have modified the content within the <body> by encapsulating the {children} with <StoreProvider></StoreProvider>, as evident in the code snippet above.

Accessing to the Store from our components

Import the hooks

import { useAppSelector, useAppDispatch, useAppStore } from '@/lib/hooks';

Create the objects to utilize those hooks:

export default function MyComponent() {

  const store = useAppStore();
  const floor= useAppSelector((state) => state.booking.floor);
  const dispatch = useAppDispatch();

….
  return (</div>)
}

When utilizing the useAppSelector hook and specifying state.<nameOfTheSlice>.<field>, we gain access to that specific field. In the example above, you can observe that we are accessing the state.booking.floor. 'booking' is the name assigned in the store (booking: bookSlice), and floor is the field found within the initialState, which contains the structure of the slice.

Updating the State

To update the state, we need to utilize the dispatch function to execute our actions.

Let's examine the bookSlice.ts file to review where we place our actions:

bookSlice.ts

…
export const bookSlice = createSlice({
  name: SupabaseTableName.BOOKING,
  initialState,
  reducers: {
    updateFloor:  (state, action: PayloadAction<number>) => {
      state.floor = action.payload;
    },
    updateUnit: (state, action: PayloadAction<string>) => {
      state.unit = action.payload;
    },
  },
});

export const { updateFloor, updateUnit } = bookSlice.actions;
export default bookSlice.reducer;

As you can see, we have updateFloor and updateUnit as the functions inside the reducers object. Therefore, to update our state, we need to make use of these functions.

To do so, let's go back to our React component, as that is where we need to implement these changes.

MyComponent.tsx
Import the function that we want to use

import { updateFloor } from '@/lib/features/bookSlice';

The usage of updateFloor is updateFloor(5) since the PayloadAction<number> indicates that it will receive a number. Therefore, we send the number 5 to update the floor field.

How to use it

In our MyComponent.tsx file, we can create a function to execute this action. So, when you need to update this state, you have to pass the reducer function to the dispatch function to affect the store in this manner:

dispatch(updateFloor(5))

References

Redux Toolkit - Typescript Quick Start
Redux Tookit - Usage with Typescript

Conclusion

In this brief document, we explored the configuration of Redux Toolkit State Management using Typescript in Next.js version 14. We included only some basic operations to avoid making things more complicated, as the purpose of this document is to share the foundational structure required for setting up our configuration to use Redux.

I hope you find this information useful. If you come across any errors or wish to contribute with comments to enhance this document, I would be more than happy to review your feedback.

Happy coding!

Changelog File

Daniel Guglielmi — Tue, 05 Dec 2023 13:52:18 +0000

CHANGELOG - Structure Example

When we update our project, the Changelog should have the history of what we added, changed, removed, fixed, etc.

In order to do that, we attach in this section, an example of the Changelog Structure.

Labels used:

Added: This label is used in the Changelog file to indicate new features, functionalities, or elements that have been introduced to the project. It typically highlights additions that enhance the project's capabilities or introduce new components.
Chores: The "Chores" label is used in the Changelog file to denote tasks related to maintenance, organization, or housekeeping of the project. These tasks may include code refactoring, documentation updates, or other non-functional improvements.
Removed: The "Removed" label in the Changelog file signifies the removal or elimination of specific features, functionalities, or elements from the project. It indicates that certain components or aspects are no longer present or supported in the current version.
Fixed: The "Fixed" label is used to indicate the resolution of bugs, issues, or errors in the project. It signifies that problems reported or identified by users or developers have been addressed and resolved.
Changed: The "Changed" label is used in the Changelog file to describe modifications or alterations made to existing features, functionalities, or elements in the project. It suggests that certain aspects have been updated or modified, often providing more details about the specific changes.
Task: The "Task" label is used in the Changelog file to denote general tasks or activities performed as part of the project. It can encompass various types of work, such as implementation of new functionalities, improvements, or maintenance tasks.
Security: The "Security" label in the Changelog file highlights changes related to security enhancements or fixes. It typically indicates updates made to address vulnerabilities, strengthen security measures, or implement best practices to safeguard the project.
Deprecated: The "Deprecated" label is used to indicate features, functionalities, or elements that have been marked as outdated or discouraged. It implies that certain components are no longer recommended for use and may be removed in future versions of the project. Developers are advised to avoid using deprecated elements and instead transition to alternative solutions or approaches.

Changelog Example

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

Unreleased

Added

Added Dutch translation

Fixed

Fixed foldouts in Dutch translation

v1.1.0 - 2019-02-15

Added

Danish translation from @frederikspang.

Georgian translation from @tatocaster.

Changelog inconsistency section in Bad Practices

Changed

Fixed typos in Italian translation from @lorenzo-arena.

Fixed typos in Indonesian translation from @ekojs.

High Cohesion, Low Coupling

Daniel Guglielmi — Tue, 05 Dec 2023 13:47:13 +0000

Photo by Jackson Simmer on Unsplash

High cohesion and low coupling are two important design principles in software engineering.

High cohesion refers to the degree to which the elements within a module or component of software are related to each other and work together to achieve a common purpose. In other words, it measures the degree to which the parts of a module or component are closely related and work towards a single goal. A module or component with high cohesion is easier to understand, maintain, and modify because the code is more self-contained and has fewer dependencies on other parts of the system.

Low coupling, on the other hand, refers to the degree to which modules or components are independent of each other and can function separately without relying on other parts of the system. It measures the degree to which a module or component depends on other modules or components. A system with low coupling is more modular, flexible, and easier to change or update, as changes made to one module or component do not affect the others.

In summary, high cohesion and low coupling are both design principles that aim to create code that is more maintainable, understandable, and flexible. High cohesion ensures that the parts of a module or component work together towards a common goal, while low coupling ensures that modules or components are independent and can be changed or updated without affecting other parts of the system.

High Cohesion and Low Coupling for React JS Developers

Here are some examples of how high cohesion and low coupling can be achieved in React.js:
High Cohesion

Keeping related states and behavior together in a component. For example, a component that displays a list of items should also contain the logic for rendering each item.
Breaking up large components into smaller ones that are focused on a specific task. For example, a complex form can be broken down into smaller components that handle individual fields or sections of the form.
Using a consistent naming convention for files and components that reflect their functionality. For example, a component that displays a header can be named Header.js, making it easy to locate and understand its purpose.

Low Coupling

Using props to pass data and behavior between components instead of relying on shared state. This allows components to be more independent and easier to test.
Using a state management library such as Redux to manage shared states between components. This reduces the dependencies between components and makes it easier to reason about the state of the application.
Using event-driven programming to handle communication between components. For example, a component can emit an event when a certain action is performed, and other components can listen to that event and update accordingly.

By following these practices, developers can create React applications that are more modular, maintainable, and scalable. This makes it easier to make changes to the codebase over time and reduces the risk of introducing bugs or unexpected behavior.

High Cohesion and Low coupling for Node JS Backend Developers

Here are some examples of how high cohesion and low coupling can be achieved in Node.js:
High Cohesion

Grouping related functionality into separate modules or files. For example, a module that handles database access should contain only functions related to database operations.
Using consistent naming conventions for modules and functions that reflect their purpose. For example, a function that generates a random string can be named generateRandomString.
Separating business logic from implementation details. For example, a function that processes payment information should not be tightly coupled to a specific payment processing library.

Low Coupling

Using dependency injection to provide modules with the resources they need to function, rather than requiring them to access those resources directly. This reduces the dependencies between modules and makes it easier to test them in isolation.
Using interfaces to define the contract between modules. This allows modules to be replaced or modified without affecting the rest of the system, as long as they adhere to the same interface.
Using event-driven programming to handle communication between modules. For example, a module can emit an event when a certain action is performed, and other modules can listen to that event and update accordingly.

By following these practices, developers can create Node.js applications that are modular, maintainable, and scalable. This makes it easier to make changes to the codebase over time and reduces the risk of introducing bugs or unexpected behavior.

Root Cause Analysis Template

Daniel Guglielmi — Tue, 05 Dec 2023 13:39:00 +0000

Summary
References
Raised by	Event Date	mm-dd-yyy
RCA Team Members	RCA Completed date	mm-dd-yyyy

Problem Statement

Brief description of how the problem was found and reported


What?	Incident description
When?	Date and time when the incident happened
How?	Description of the scenario that causes the incident
Where?	Environment and/or services affected
Impact	High/Medium/Low

Investigation

Steps taken to find the source of the problem

Commit that introduced

Repository and commit hash that introduced the problem

Root Cause

Why was this issue introduced and why was not it found by QA.

Corrective Actions

What actions were taken to fix the problem?

Action	Expected Result	Owner	Start Date	End date	ticket #

Preventive Actions

What actions were taken to ensure this, or a similar problem will not be introduced again in the future?

Action	Expected Result	Owner	Start Date	ticket #

Solid Principles

Daniel Guglielmi — Tue, 05 Dec 2023 13:20:10 +0000

What is SOLID?

SOLID is an acronym for five software design principles introduced by Robert C. Martin in the 2000s, that aim to help us structure our code in order to:

Tolerate change.
Ease code understanding.
Write components that can be used in many software systems.

SOLID stands for:

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

S - Single Responsibility

A Class should have one, and only one reason to change.

If our classes assume multiple responsibilities, they will be highly coupled thus making them more difficult to maintain.

What’s a reason to change?

Uncle Bob states that this principle is about people. This means that when you write a software module, and changes are requested on that module, those changes can only originate from a single person or a tightly group of people representing a single narrowly defined business function.

Another definition for this principle is:

Gather together those things that change for the same reason, and separate those things that change for different reasons.

This can also be considered the definition of Separation of Concerns.

The following piece of code shows a violation of the SRP in which the book class is both a representation of an entity and also implements the persistence of such an entity.

(S) - Wrong Approach

class Book {
  constructor(private _author: string, private _title: "string) {}"

  get author(): string {
    return this._author;
  }

  get title(): string {
    return this._title;
  }

  save(): void {
    // Save book in the database.
  }
}

(S) - Better Approach

class Book {
  constructor(private _author: string, private _title: "string) {}"

  get author(): string {
    return this._author;
  }

  get title(): string {
    return this._title;
  }
}

interface RepositoryInterface<T> {
  save(entity: T): void;
}

class BookRepository<T extends Book> implements RepositoryInterface<T> {
  save(book: Book): void {
    // Save book in the database
  }
}

O - Open for Extension - Closed for Modification

Software entities should be open for extension but closed for modification.

This principle states that software entities must be extensible without modifying the existing code. In order to achieve this, we need to make abstractions. By doing this, we’ll be able to extend the behavior of a class without changing a single line of code.

(O) - Wrong Approach

class Rectangle {
  constructor(private _width: number, private _height: number) {}

  get height(): number {
    return this._height; 
  }

  get width(): number {
    return this._width;
  }
}

class Square {
  constructor(private _height: number) {}

  get height(): number {
    return this._height; 
  }
}

class AreaCalculator {
  private shapes: any[];

  constructor(shapes: any[]) {
    this.shapes = shapes;
  }

  public sum() {
    return this.shapes.reduce((acc, shape) => {
      if (shape instanceof Square) {
        acc += Math.pow(shape.height, 2);
      }
      if (shape instanceof Rectangle) {
        acc += shape.height * shape.width;
      }
      return acc;
    }, 0);
  }
}

(O) - Better Approach

interface Shape {
  area() : number;
}

class Rectangle implements Shape {
  constructor(private _width: number, private _height: number) {}

  public area() : number {
    return this._height * this._width;
  }
}

export class Square implements Shape {
  constructor(private _height: number) {}

  public area() : number {
    return Math.pow(this._height, 2);
  }
}

class AreaCalculator {
  private shapes: Shape[];

  constructor(shapes: Shape[]) {
    this.shapes = shapes;
  }

  public sum() : number {
    return this.shapes
      .reduce((acc, shape) => acc += shape.area(), 0);
  }
}

L - Liskov Substitution Principle

Inherit from a Parent Class but without modifying the parent’s method behavior.

This principle states that objects must be replaceable by instances of their subtypes without altering the correct functioning of the system.

A classic example of a violation of this principle is the Rectangle-Square problem. The Square class extends the Rectangle class and assumes that the width and height are equal. When calculating the area of a square, we’d get the wrong value.

(L) - Wrong Approach

class Rectangle {
  constructor(private _width: number, private _height: number) {}

  public area() : number {
    return this._height * this._width;
  }
}

class Square extends Rectangle {}

(L) - Better Approach

interface Shape {
  area() : number;
}

class Rectangle implements Shape {
  constructor(private _width: number, private _height: number) {}

  public area() : number {
    return this._height * this._width;
  }
}

class Square implements Shape {
  constructor(private _height: number) {}

  public area() : number {
    return Math.pow(this._height, 2);
  }
}

I - Interface Segregation

Many client-specific interfaces are better than one general-purpose interface.

This principle states that classes should never implement interfaces that they don’t need to use. If they do, we’ll end up having not implemented methods in our classes. This can be solved by creating specific interfaces instead of general-purpose interfaces.

(I) - Wrong Approach

interface VehicleInterface {
  drive(): string;
  fly(): string;
}

class FutureCar implements VehicleInterface {
  public drive() : string {
    return 'Driving Car.';
  }

  public fly() : string {
    return 'Flying Car.';
  }
}

class Car implements VehicleInterface {
  public drive() : string {
    return 'Driving Car.';
  }

  public fly() : string {
    throw new Error('Not implemented method.');
  }
}

class Airplane implements VehicleInterface {
  public drive() : string {
    throw new Error('Not implemented method.');
  }

  public fly() : string {
    return 'Flying Airplane.';
  }
}

(I) - Better Approach

interface CarInterface {
  drive() : string;
}

interface AirplaneInterface {
  fly() : string;
}

class FutureCar implements CarInterface, AirplaneInterface {
  public drive() {
      return 'Driving Car.';
  }

  public fly() {
      return 'Flying Car.'
  }
}

class Car implements CarInterface {
  public drive() {
      return 'Driving Car.';
  }
}

class Airplane implements AirplaneInterface {
  public fly() {
      return 'Flying Airplane.';
  }
}

D - Dependency Inversion

Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.

This principle states that a class should not depend on another class, but instead on an abstraction of that class. It allows loose coupling and more reusability.

(D) - Wrong Approach

class MemoryStorage {
  private storage: any[];

  constructor() {
    this.storage = [];
  }

  public insert(record: any): void {
    this.storage.push(record);
  }
}

class PostService {
  private db = new MemoryStorage();

  createPost(title: string) {
    this.db.insert(title);
  }
}

(D) - Better Approach

interface DatabaseStorage {
  insert(record: any): void;
}

class MemoryStorage implements DatabaseStorage {
  private storage: any[];

  constructor() {
    this.storage = [];
  }

  public insert(record: any): void {
    this.storage.push(record);
  }
}

class PostService {
  private db: DatabaseStorage;

  constructor(db: DatabaseStorage) {
    this.db = db;
  }

  createPost(title: string) {
    this.db.insert(title);
  }
}

Using Redux toolkit in React

Daniel Guglielmi — Tue, 05 Dec 2023 13:06:35 +0000

Here is a concise example of how to implement redux-toolkit in a project using a few simple steps. In this instance, we generated a store utilizing multiple reducers in a straightforward scenario.

Installing redux-toolkit in our project

# NPM
npm install @reduxjs/toolkit

# Yarn
yarn add @reduxjs/toolkit

Create the reducers:

counterSlice: This code will be updating the state of the ‘counter’

import { createSlice } from "@reduxjs/toolkit";

export const counterSlice = createSlice({
  name: "counter",
  initialState: {
    value: 0,
  },
  reducers: {
    increment: (state) => {
      state.value += 1;
    },
    decrement: (state) => {
      state.value -= 1;
    },
    incrementByAmount: (state, action) => {
      state.value += action.payload.amount;
    },
  },
});

// Actions: Functions created inside the reducer property above.
//          Actions are used to update the state of the current Slice.
export const { increment, decrement, incrementByAmount } = counterSlice.actions;

export default counterSlice.reducer;

testSlice: This code will update the state of ‘test’

import { createSlice } from "@reduxjs/toolkit";

export const testSlice = createSlice({
  name: "test",
  initialState: {
    plugin: "empty",
    isWorking: true,
  },
  reducers: {
    workingStatus: (state, action) => {
      state.isWorking = action.payload;
    },
    plugin: (state, action) => {
      state.plugin = action.payload;
    },
  },
});

export const {workingStatus,plugin} = testSlice.actions;

export default testSlice.reducer;

Creating The store

In the previous step, we created reducers that are now imported in this step.

import { configureStore } from "@reduxjs/toolkit";
import counterReducer from "./features/reducers/counterSlice";
import testReducer from "./features/counter/testSlice";

export default configureStore({
  reducer: {
    counter: counterReducer,
    test: testReducer,
  },
});

Configuring Your Project to Use Redux

We wrap the primary component of our App with the Redux Provider, passing our store as a prop.

import store from "./store";
import { Provider } from "react-redux";

render(  
   <Provider store={store}>
      <App />
    </Provider>
)

How to Access and Manipulate the Store

To demonstrate how this works, we have created a component named 'Counter' that modifies the store using both reducers.

import React from "react";

import { useSelector, useDispatch } from "react-redux";

import { decrement, increment, incrementByAmount } from "../reducers/counterSlice";
import { plugin, workingStatus } from "../reducers/testSlice";

export function Counter() {
  const count = useSelector((state) => state.counter.value);
  const pluginName = useSelector((state) => state.test.plugin);
  const isWorking = useSelector((state) => state.test.isWorking);
  const dispatch = useDispatch();

  return (
    <div>
      <div>
        <button
          aria-label="Increment value"
          onClick={() => dispatch(increment())}
        >
          Increment
        </button>
        <span>{count}</span>
        <button
          aria-label="Decrement value"
          onClick={() => dispatch(decrement())}
        >
          Decrement
        </button>
        <button
          aria-label="Increment by Amount"
          onClick={() => dispatch(incrementByAmount({ amount: 10 }))}
        >
          Increment by 10
        </button>

        <button
          aria-label="Change Plugin Name"
          onClick={() => dispatch(plugin("Pepe"))}
        >
          Change Plugin Name
        </button>

        <button
          aria-label="Turn Off working"
          onClick={() => dispatch(workingStatus(false))}
        >
          Turn Off Working
        </button>
        <h4>Is Working status:</h4>
        <span>{String(isWorking)}</span>
        <h4>Plugin Name</h4>
        <span>{pluginName}</span>
      </div>
    </div>
  );
}

Code explained in fragments:

Importing

import { useSelector, useDispatch } from "react-redux";
import { decrement, increment, incrementByAmount } from "../reducers/counterSlice";
import { plugin, workingStatus } from "../reducers/testSlice";

useSelector: We retrieve the values of the state declared in the 'initialStatus: {}' of each slice.
useDispatch: This hook includes the 'dispatch' function, which is utilized to update the state of each slice.
../reducers/Slice: We import reducer functions that include actions to modify the state.

Getting the actual state value

  const count = useSelector((state) => state.counter.value);
  const pluginName = useSelector((state) => state.test.plugin);
  const isWorking = useSelector((state) => state.test.isWorking);
  const dispatch = useDispatch();

By using useSelector, we can access the value of our state.
We obtain the dispatch function from 'useDispatch' to invoke the actions for updating the state.

Showing and Updating the state

        <button
          aria-label="Increment value"
          onClick={() => dispatch(increment())}
        >
          Increment
        </button>
        <span>{count}</span>

dispatch(increment()): we execute the increment() function by passing it as a parameter to the dispatch() function.
{count}: this variable is associated with state.counter.value, which represents the current value in the store obtained when we invoke useSelector((state) => state.counter.value).

Pass in a value as a parameter for updating the state

<button
  aria-label="Increment by Amount"
  onClick={() => dispatch(incrementByAmount({ amount: 10 }))}
>
  Increment by 10
</button>

dispatch(actionFunction(parameter)): We utilize dispatch by providing an action function with a parameter. For clarification, below is the definition of the incrementByAmount() function employed in the aforementioned code snippet.

incrementByAmount: (state, action) => {
      state.value += action.payload.amount;
},

This is merely a simple example, so please do not hesitate to contribute if you come across any errors or omissions in this document.

I hope you find this summary useful.
Thanks!!

Coding Conventions

Daniel Guglielmi — Wed, 07 Jun 2023 15:17:16 +0000

This document provides comprehensive guidelines to foster alignment in development practices within the team. It encompasses various topics including the application of Semantic Versioning, branch naming conventions, different types of commits, and best practices for composing commit comments. The guide incorporates illustrative examples of both exemplary and subpar comments, serving as a valuable resource to promote consistency and maintain high-quality standards.

Semantic Versioning
How to Update the Version
Branch Naming Convention
Type of Commits
Git-commit-msg-linter
Bad and Good comments example

Semantic Versioning

Version Format	Description
1.0.0-alpha	May does not contain all of the features that are planned for the final version.
1.0.0-beta	Feature complete, may have bugs, it is useful for demonstration and preview
1.0.0-rc	(Release Candidate) - ready to release unless significant bugs emerge. All product features have been designed, coded, and tested. No known showstopper-class bugs.
1.0.0-stable	The last 'RC' has passed all verifications/tests.

How to Update a new Version

Branch Naming Convention

In order to adhere to the development team's branch naming convention, we will provide the following guidelines: Branch names must consist of the work type, the Jira ticket number, and a concise, descriptive name that accurately represents the addressed issue.

That being said, we will now provide a few examples of branch naming to further illustrate the guidelines:

Branch name structure:
<ProblemType>/<JiraTicket#>/<ShortDescriptiveName>

Feature/TK-XXX/problem-to-solve
Hotfix/TK-XXX/name-of-the-issue
Bug/TK-XXX/bug-to-fix
Rollback/TK-XXX/rollback-release-v1.0.0
Defect/TK-XXX/defect-to-correct
Spike/TK-XXX/spike-to-solve
Refactor/TK-XXX/enhancement-in-the-project

You can find the full list of Problem Type in the next section (Type of Commits) column Problem Type.

Type of Commits

Depending on the type of commit, we will use the second column for commit messages.

Ex.: git commit -m “feat(TK-1234): add the comment for this commit"

Problem Type	Short Type	Description
Feature	feat	New feature to our project.
Fixes	fix	Bug fixing.
Documentation	docs	Documentation only changes
Styles	style	Changes that do not affect the meaning of the code. Indentation corrected. Removed white spaces. Added missing semi-colons.
Refactors	refactor	Code changes don’t affect the behavior of any feature. We are not adding a new feature, we’re just improving the existing code, being sure that we are not modifying the result of a function, method, etc.. Changed the enigmatic function’s name by meaningful names. Changed an algorithm code for a more efficient one delivering the same result as before. Split code into several files to reduce lines of code for help to decouple. Removing commented code. Removing code duplication by making a unique and reusable function.
Tests	test	Adding missing tests or correcting existing ones to the project.
Chores	chore	The commit includes a technical or preventative maintenance task that is necessary for managing the product or the repository, but it is not tied to any specific feature or user story. For example, releasing the product can be considered a chore. Regenerating generated code that must be included in the repository could be a chore.
Performance	perf	A code change that improves performance.
CI	ci	Changes to your CI configuration files and scripts.
Build	build	Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
Temp	temp	Temporary commit that won't be included in your CHANGELOG.
Remove	remove	The commit removes a feature from the product. Typically features are deprecated first for a period of time before being removed. Removing a feature from the product may be considered a breaking change that will require a major version number increment.
Revert	revert	The commit reverts one or more commits that were previously included in the product, but were accidentally merged or serious issues were discovered that required their removal from the main branch.
Security	security	The commit improves the security of the product or resolves a security issue that has been reported.

Git-commit-msg-linter

This extension serves as a valuable tool to ensure that we adhere to the correct format when writing commit messages. You can easily download it from NPM Git Commit Msg Linter.

How to Install

$npm install git-commit-msg-linter --save-dev

Below you will find a short explanation of how to write these commit messages:

We will use the scope to specify the Jira Ticket number in our commit message.

Comments on git commit -m

Comments	Wrong/Good
docs: Documentation updates
docs(TK-XXX): add documentation for new API endpoints to improve developer experience
feat: New feature added
feat(TK-XXX): Implement OAuth2 authentication for user login to enhance security and improve user experience
fix: Bug fixes
fix(TK-XXX): Fixed issue with form validation for registration process to prevent invalid user registrations
style: UI updates
style(TK-XXX): Updated CSS for consistent styling across the website and improve usability
chore: Maintenance updates
chore(TK-XXX): Updated deployment process for better scalability and maintainability of the application

The comment should answer 2 questions:

WHAT changed?
WHY did it change?

The objective behind crafting comments in this manner is to produce succinct and streamlined messages, resulting in cleaner and more legible commit messages.

In conclusion, this document provides a comprehensive guide to some of the Coding Conventions used on a daily basis. I hope you find it both informative and practical, serving as a valuable resource for maintaining good coding practices. Should you have any further questions or require additional assistance, please don't hesitate to reach out. Happy coding!

DEV Community: Daniel Guglielmi

Redux Toolkit with Typescript and Next.js 14

Installing Redux

Folder Structure

Creating the Slice

Creating the Store

Creating the Hooks file

Adding the Store Provider to our project

Accessing to the Store from our components

Import the hooks

Updating the State

How to use it

References

Conclusion

Changelog File

CHANGELOG - Structure Example

Changelog

Unreleased

Added

Fixed

v1.1.0 - 2019-02-15

Added

Changed

High Cohesion, Low Coupling

High Cohesion and Low Coupling for React JS Developers

High Cohesion and Low coupling for Node JS Backend Developers

Root Cause Analysis Template

Problem Statement

Investigation

Commit that introduced

Root Cause

Corrective Actions

Preventive Actions

Solid Principles

What is SOLID?

SOLID stands for:

S - Single Responsibility

What’s a reason to change?

(S) - Wrong Approach

(S) - Better Approach

O - Open for Extension - Closed for Modification

(O) - Wrong Approach

(O) - Better Approach

L - Liskov Substitution Principle

(L) - Wrong Approach

(L) - Better Approach

I - Interface Segregation

(I) - Wrong Approach

(I) - Better Approach

D - Dependency Inversion

(D) - Wrong Approach

(D) - Better Approach

Using Redux toolkit in React

Installing redux-toolkit in our project

Create the reducers:

Creating The store

Configuring Your Project to Use Redux

How to Access and Manipulate the Store

Code explained in fragments:

Importing

Getting the actual state value

Showing and Updating the state

Pass in a value as a parameter for updating the state

Coding Conventions

Table of Contents

Semantic Versioning

How to Update a new Version

Branch Naming Convention

Type of Commits

Git-commit-msg-linter

How to Install

Below you will find a short explanation of how to write these commit messages:

Comments on git commit -m