DEV Community: José Miguel Álvarez Vañó

Facade pattern in TypeScript

José Miguel Álvarez Vañó — Sun, 08 Jan 2023 18:57:46 +0000

Introduction

The facade pattern is a structural pattern which allows you to communicate your application with any complex software (like a library or framework) in a simpler way. It is used to create a simplified interface to a complex system.

Applicability

you don't want your application to be tightly coupled to a 3rd party library or framework
you want to simplify the interaction of your application with a complex system

Implementation

You can find the full example source code here. As an example of the implementation I'm going to create an application that uploads files to a cloud storage service.

Let's imagine that the 3rd-party code is something like the following:

class CloudProviderService {
  public isLoggedIn(): boolean {
    // Checks if the user is logged in
  }

  public logIn(): void {
    // Logs the user in
  }

  public convertFile(file: string): string {
    // Converts the file to a format that the cloud provider accepts
  }

  public uploadFile(file: string): void {
    // Uploads the file to the cloud provider
  }

  public getFileLink(file: string): string {
    // Returns the link to the uploaded file
  }
}

As we don't want to couple our application with this 3rd-party code we are going to create a facade that will hide the complexity of it. This facade will be the only class that our application will interact with.

class CloudProviderFacade {
  private service: CloudProviderService;

  constructor() {
    this.service = new CloudProviderService();
  }
}

Now we have to implement the functions that our application will use to interact with the 3rd-party code. For the example I'm going to only implement one function:

class CloudProviderFacade {
  private service: CloudProviderService;

  constructor() {
    this.service = new CloudProviderService();
  }

  public uploadFile(file: string): string {
    if (!this.service.isLoggedIn()) {
      this.service.logIn();
    }

    const convertedFile = this.service.convertFile(file);
    this.service.uploadFile(convertedFile);

    return this.service.getFileLink(convertedFile);
  }
}

And that's it! Like this we have implemented the Facade pattern. It's very simple and very useful at the same time. A simple example of how the client would use this code:

const facade = new CloudProviderFacade();
const fileLink = facade.uploadFile("file.txt");
console.log("File link:", fileLink);

/*  
  Output:

  Logging in...
  Converting file... file.txt
  Uploading file... file.txt.converted
  File link: https://example.com/file.txt.converted
*/

Resources

Decorator pattern in TypeScript

José Miguel Álvarez Vañó — Sun, 18 Dec 2022 20:02:41 +0000

Introduction

The Decorator pattern is a structural design pattern that allows you to dynamically add new behavior to objects. It does so by wrapping them in special objects called decorators, which contain the added behavior. This is an alternative to inheritance.

The Decorator pattern is useful when you want to add behavior to individual objects, rather than to an entire class of objects. It is also useful when you want to add behavior without affecting the existing hierarchy, or when you want to add behavior that can be changed dynamically at runtime.

In this article, we will discuss the benefits of using the Decorator pattern, and how it can be implemented in practice.

Applicability

The Decorator pattern can be useful when you want to:

add new behavior to an existing object, but you don't want or can't to modify its class.
add new behavior to a set of objects, but you don't want to create a new subclass for each object.
add new behavior that can be changed dynamically at runtime. The Decorator pattern allows you to add or remove the behavior by adding or removing decorator objects.

Implementation

You can find the full example source code here.

1. Define the interface for the objects that will be decorated. This interface should specify the methods that will be available to the clients of these objects.

In our example I'm going to create the interface DataSource.



interface DataSource {
  writeData(data: string): void;
  readData(): string;
}

2. Create a concrete implementation of the interface defined in the previous step. This class will be the base class for the objects that will be decorated.

In our example I'm going to create the class FileDataSource.



class FileDataSource implements DataSource {
  private fileName: string;
  private data: string;

  constructor(fileName: string) {
    this.fileName = fileName;
  }

  writeData(data: string): void {
    console.log(
      `[FileDataSource] Writing to file: ${this.fileName}, data: ${data}`
    );
    this.data = data;
  }

  readData(): string {
    console.log(
      `[FileDataSource] Reading from file: ${this.fileName}, data: ${this.data}`
    );
    return this.data;
  }
}

3. Create a decorator class that implements the interface. This class will contain a reference to the object being decorated, and will delegate all method calls to the decorated object. This class will be the base class for the decorators.



class DataSourceDecorator implements DataSource {
  protected source: DataSource;

  constructor(source: DataSource) {
    this.source = source;
  }

  writeData(data: string): void {
    this.source.writeData(data);
  }

  readData(): string {
    return this.source.readData();
  }
}

4. Create a new class for each additional behavior that you want to add to the objects. These classes will extend the base decorator class and will add the new behavior to the decorated object before or after passing the request to the target object.

In our example I want to add two new behaviors. The first one is to encrypt the data before writing it to the file and decrypting it after reading it from the file.



class EncryptionDecorator extends DataSourceDecorator {
  writeData(data: string): void {
    const base64Data = btoa(data);
    console.log(`[EncryptionDecorator] Encrypted data: ${base64Data}`);
    super.writeData(base64Data);
  }

  readData(): string {
    const base64Data = super.readData();
    const data = atob(base64Data);
    console.log(`[EncryptionDecorator] Decrypted data: ${data}`);
    return data;
  }
}

The second one is to reverse the data before writing it to the file and unreversing it after reading it from the file.



class ReverseDecorator extends DataSourceDecorator {
  writeData(data: string): void {
    const compressedData = data.split("").reverse().join("");
    console.log(`[ReverseDecorator] Reversed data: ${compressedData}`);
    super.writeData(compressedData);
  }

  readData(): string {
    const compressedData = super.readData();
    const data = compressedData.split("").reverse().join("");
    console.log(`[ReverseDecorator] Unreversed data: ${data}`);
    return data;
  }
}

5. To use the Decorator pattern, create an instance of the concrete implementation of the interface, and then wrap it in one or more decorator objects. The decorator objects can be created and added dynamically at runtime, allowing you to add or remove behavior as needed.

An example of how client code would use the Decorator pattern with the EncryptionDecorator:



const file = new FileDataSource("file.txt");
const encryptedFile = new EncryptionDecorator(file);

encryptedFile.writeData("Hello world!");
encryptedFile.readData();

/* Output:

  [EncryptionDecorator] Encrypted data: SGVsbG8gd29ybGQh
  [FileDataSource] Writing to file: file.txt, data: SGVsbG8gd29ybGQh
  [FileDataSource] Reading from file: file.txt, data: SGVsbG8gd29ybGQh
  [EncryptionDecorator] Decrypted data: Hello world!
*/

Another example but using the ReverseDecorator:



const file = new FileDataSource("file.txt");
const compressedFile = new ReverseDecorator(file);

compressedFile.writeData("Hello world!");
compressedFile.readData();

/* Output:

  [ReverseDecorator] Reversed data: !dlrow olleH
  [FileDataSource] Writing to file: file.txt, data: !dlrow olleH
  [FileDataSource] Reading from file: file.txt, data: !dlrow olleH
  [ReverseDecorator] Unreversed data: Hello world!
*/

Both decorators can also be used together:



const file = new FileDataSource("file.txt");

const encryptedFile = new EncryptionDecorator(file);

const compressedEncryptedFile = new ReverseDecorator(encryptedFile);

compressedEncryptedFile.writeData("Hello world!");

compressedEncryptedFile.readData();

/* Output:

[ReverseDecorator] Reversed data: !dlrow olleH

  [EncryptionDecorator] Encrypted data: IWRscm93IG9sbGVI

  [FileDataSource] Writing to file: file.txt, data: IWRscm93IG9sbGVI

  [FileDataSource] Reading from file: file.txt, data: IWRscm93IG9sbGVI

  [EncryptionDecorator] Decrypted data: !dlrow olleH

  [ReverseDecorator] Unreversed data: Hello world!

*/

Resources

Equality of values in JavaScript

José Miguel Álvarez Vañó — Sun, 11 Dec 2022 18:54:41 +0000

I'm currently doing the JustJavascript course, which I highly recommend, and I've learned how equality of values works in JavaScript.

There are 3 kinds of equality in JavaScript.

Same value equality: Object.is(a, b).
Strict equality: a === b (triple equals).
Loose equality: a == b (double equals).

Same value equality

Object.is(a, b) tells us if a and b are the same value:

Object.is(2, 2); // 🟢 true
Object.is(undefined, undefined); // 🟢 true
Object.is(null, null); // 🟢 true
Object.is(true, true); // 🟢 true
Object.is(1, 1); // 🟢 true
Object.is(-1, -1); // 🟢 true
Object.is("Hello", "Hello"); // 🟢 true
Object.is({}, {}); // 🔴 false
Object.is([], []); // 🔴 false

Strict equality

Strict equality works like Object.is but there are two exceptions.

1. NaN === NaN is false, although they are the same value in JavaScript.

There are some ways to safely check if two values are NaN:

Number.isNaN(variable)
Object.is(variable, NaN)
variable !== variable

NaN === NaN; // 🔴 false
Object.is(NaN, NaN); // 🟢 true
Number.isNaN(NaN); // 🟢 true
NaN !== NaN; // 🟢 true

2. -0 === 0 and 0 === -0 are true, although they are different values in JavaScript.

In the common math that we all learn at school negative zero does not exist, but it exists in floating-point math for practical reasons.

0 === -0; // 🟢 true
Object.is(0, -0); // 🔴 false

Loose equality

Loose equality is very confusing and that's why it's recommended not to use it. As an example, see these cases:

[[]] == ""; // true
true == [1]; // true
false == [0]; // true

If you still want to learn how it works, you can read more about it here.

Resources

Composite pattern in TypeScript

José Miguel Álvarez Vañó — Mon, 05 Dec 2022 08:34:45 +0000

Introduction

The composite pattern is a structural pattern which allows you to create tree structures of objects and treat them as a single object. The tree can contain individual or groups of objects which can be treated in the exact same way. This pattern is useful to represent a hierarchy of objects.

Applicability

your model can be represented as a tree structure
you want to simplify the interaction of the client code with your model

Implementation

You can find the full example source code here. As an example of the implementation I'm going to create an application that represents a Text Editor.

1. The first step would be to define the objects of the model of your application. Initially, in the example we are going to have:

the SimpleText object, which will be used to render text on the UI.
the SimpleImage object, which will be used to render images on the UI.
the Block component, which represents a group of objects. I will use this object to create paragraphs.

2. Once we have defined our objects we have to create a common interface for them. All of my objects will have the function render.

interface Component {
  render: () => void;
}

3. Now we have to create the classes of the different objects defined in the first step. These classes have to implement the interface we just defined.

class SimpleText implements Component {
  private text: string;

  constructor(text: string) {
    this.text = text;
  }

  public render() {
    console.log("Rendering text:", this.text);
  }
}

class SimpleImage implements Component {
  private src: string;

  constructor(src: string) {
    this.src = src;
  }

  public render() {
    console.log("Rendering image:", this.src);
  }
}

class Block implements Component {
  private children: Component[] = [];

  public add(child: Component): void {
    this.children.push(child);
  }

  public render() {
    this.children.forEach((child) => child.render());
  }
}

As you can see, if we render the simple objects like SimpleText or SimpleImage they will execute some logic implemented in those classes. But if we render the Block component it will call the render function of all of it's children. We can interact with the tree of objects as it was a single object if we interact with the root object.

4. And that's it! Like this we have implemented the Composite pattern. A simple example of how the client would use this code creating just one block containing a line of text and an image:

const block = new Block();
block.add(new SimpleText("Hello"));
block.add(new SimpleImage("https://example.com/image.png"));

block.render();

/*  
  Output:

  Rendering text: Hello
  Rendering image: https://example.com/image.png
*/

A more complex example of nested blocks would be:

const nestedBlock = new Block();
nestedBlock.add(new SimpleText("Hello, check the following image:"));
nestedBlock.add(new SimpleImage("https://example.com/image.png"));

const mainBlock = new Block();
mainBlock.add(nestedBlock);
mainBlock.add(new SimpleText("Thanks for reading!"));

mainBlock.render();

/*  
  Output:

  Rendering text: Hello, check the following image:
  Rendering image: https://example.com/image.png
  Rendering text: Thanks for reading!
*/

Advantages

Work with complex object structures in a simpler way, making it easier to manipulate and interact with the tree of objects.
Open/Closed Principle. You can introduce new types of objects to the application without modifying the existing code.

Resources

Bridge pattern in TypeScript

José Miguel Álvarez Vañó — Sun, 27 Nov 2022 10:03:47 +0000

Introduction

The Bridge pattern is a structural design pattern that allows you to separate a big class or set of related classes into two different domains: abstraction (also called interface) and implementation (also called platform).

The abstraction layer is the one that the client will use to interact with our application. This layer is not going to contain the business logic of our application. Instead, it will delegate the work to the implementation layer.

Imagine that you have a class that represents a vehicle. The vehicles can have different engines. You could start with a Mercedes and a BMW vehicles with V6 and V8 as possible engines. Initially you would have 4 combinations of vehicles (each one being a class in your application):

Mercedes V6
Mercedes V8
BMW V6
BMW V8

Imagine now that you want to add a new engine type: V12. You would have to create 2 new classes:

Mercedes V6
Mercedes V8
Mercedes V12
BMW V6
BMW V8
BMW V12

If now you add a new vehicle, you would have to create 3 new classes. This is not a big deal if you have only 2 or 3 vehicles, but what if you have 100 vehicles? You would have to create 100 new classes for each different engine.

As you can see, this problem grows exponentially. The Bridge pattern allows you to solve this in an easy way separating both domains and being able to develop them independently.

Applicability

Use the Bridge pattern when:

you want to split a big class that has several variants of some functionality into two different layers.
you need to switch between different variants at runtime.

Implementation

You can find the full example source code here.

In my example I have an application that contains the user interface for different kind of platforms and the backend implementation for each user interface.

1. Define the two different layers (abstraction and implementation) of your classes. In my example the abstraction layer is going to be the user interface and the implementation layer is going to be the backend.

Once the two different layers have been clearly defined we can create abstract classes for each layer. The abstraction layer will contain a dependency to the implementation layer. This dependency will be used to delegate the work to the implementation layer.

In these abstract classes you can already define the methods that you want to expose to the client.

abstract class UI {
  protected backend: Backend;

  constructor(backend: Backend) {
    this.backend = backend;
  }

  abstract render(): void;
}

abstract class Backend {
  abstract getData(): string;
}

2. Now we can create the concrete classes for each layer. I will start by adding a UI for the Android and iOS platforms and a backend for both.

class AndroidUI extends UI {
  public render() {
    const data = this.backend.getData();
    console.log("AndroidUI: Rendering data from the backend ->", data);
  }
}

class IPhoneUI extends UI {
  public render() {
    const data = this.backend.getData();
    console.log("IPhoneUI: Rendering data from the backend ->", data);
  }
}

class MobileBackend implements Backend {
  public getData() {
    return "MobileBackend: Data from the backend";
  }
}

3. The client could already use these classes. Notice how the client is responsible of injecting the implementation class in the abstraction class.

Example of client code:

const mobileBackend = new MobileBackend();
const androidUI = new AndroidUI(mobileBackend);
androidUI.render();

// Output:
// AndroidUI: Rendering data from the backend -> MobileBackend: Data from the backend

const iphoneUI = new IPhoneUI(mobileBackend);
iphoneUI.render();

// Output:
// IPhoneUI: Rendering data from the backend -> MobileBackend: Data from the backend

4. Now we can very easily add new variants to our layers. For example, I'm going to add a variant for the Web platform. For this, I only have to add two new classes, without having to modify the existing code (meeting the Open/Closed principle).

class WebUI extends UI {
  public render() {
    const data = this.backend.getData();
    console.log("WebUI: Rendering data from the backend ->", data);
  }
}

class WebBackend implements Backend {
  public getData() {
    return "WebBackend: Data from the backend";
  }
}

And now the client could use this new variant like this:

const webBackend = new WebBackend();
const webUI = new WebUI(webBackend);
webUI.render();

// Output:
// WebUI: Rendering data from the backend -> WebBackend: Data from the backend

It would be possible that we wanted to use the Web backend for the Android and iOS platforms because we wanted to render the application in the mobile browser instead of using the native UI. We wouldn't need to introduce new changes for this, the client could just inject the Web backend in the Android and iOS UIs.

const androidBrowserUI = new AndroidUI(webBackend);
androidBrowserUI.render();

// Output:
// AndroidUI: Rendering data from the backend -> WebBackend: Data from the backend

Resources

Singleton pattern in TypeScript

José Miguel Álvarez Vañó — Sun, 20 Nov 2022 11:28:03 +0000

Introduction

The singleton pattern is a creational pattern that allows you to make sure that only one instance of a class is created.

Applicability

Use the Singleton pattern when:

it's important that your application only creates an instance of a class.
the same instance of a class should be use globally.

Implementation

You can find the full example source code here.

1. Declare a static property to hold the instance of the class. Remember that static properties are shared across all instances of a class.

In the example I'm going to apply the Singleton pattern to a class that represents a database connection.

class Database {
  private static instance: Database;
}

2. Make the constructor of the class private so that it cannot be called from outside the class.

For the example, the constructor won't have any parameters. In a real-world scenario, you might want to pass some configuration to the constructor.

class Database {
  private static instance: Database;

  private constructor() {}
}

3. Declare a static method that will be used to get the Singleton instance of the class. When the method is called for the first time,
it will create an instance of the class and store it in the static property. On subsequent calls, it will return the instance stored in the static property.

class Database {
  private static instance: Database;

  private constructor() {}

  public static getInstance(): Database {
    if (!Database.instance) {
      Database.instance = new Database();
    }

    return Database.instance;
  }
}

4. The singleton instance can now be used from anywhere in the application. But first, I'll ad some business logic for the example.

class Database {
  private static instance: Database;

  private constructor() {}

  public static getInstance(): Database {
    if (!Database.instance) {
      Database.instance = new Database();
    }

    return Database.instance;
  }

  public query(sql: string): void {
    console.log(`Querying database: ${sql}`);
  }
}

An example of how client code would use the Singleton instance:

const database = Database.getInstance();
database.query("SELECT * FROM users");

// Output:
// Querying database: SELECT * FROM users

const database2 = Database.getInstance();
if (database === database2) {
  console.log(
    "The same instance of Database was returned. The Singleton pattern works!"
  );
} else {
  console.log(
    "A new instance of Database was returned. The Singleton pattern failed."
  );
}

// Output:
// The same instance of Database was returned. The Singleton pattern works!

Resources

Adapter pattern in TypeScript

José Miguel Álvarez Vañó — Sun, 20 Nov 2022 11:26:18 +0000

Introduction

The adapter pattern (also known as the Wrapper pattern) is a structural design pattern that allows your code to communicate with other interfaces that are initially incompatible.

This pattern is great to use when you need to integrate third-party libraries that you can't change, or when you need to integrate legacy code that you can't change.

Imagine that your application works using strings. However, you need to integrate a third-party library that works with JSON objects that contain the strings that you need. You can't change the library's code, but you can apply the adapter pattern to transform those JSON objects into strings to make them compatible with your application. Following this example, if you later had to integrate a new third-party library that was using a different format (for example, XML), you could create a new adapter to make it compatible with your application in a easy way.

Another advantage of this pattern is that your code is decoupled from external libraries. This means that you can replace the library that you are using or add new ones without having to change your code.

Implementation

As an example I'm going to build an application that gets books data from third-party libraries. My app works using a concrete data type but the third-party libraries use different types. I'm going to use the adapter pattern to make them compatible with my application.

You can find the full example source code here.

1. Declare an interface for the adapters of the third-party libraries. This will be the interface used by your application. The adapter will implement this interface and will be responsible for transforming the data from the third-party library into the format that your application uses.

In the example I'm going to define a method to get the books data and I'm going to also specify the structure of the data that the method will return, which is the data structure that my application works with.

interface LibraryAdapter {
  getBooks(): { title: string; author: string }[];
}

Initially, I'm going to integrate a third-party library that returns the books data in the CSV format. This is the code of the third-party library:

class LibraryCSV {
  getBooks() {
    const books = [
      { title: "Book 1", author: "Author 1" },
      { title: "Book 2", author: "Author 2" },
      { title: "Book 3", author: "Author 3" },
    ];

    return (
      "title,author\r\n" +
      books.map((book) => `${book.title},${book.author}`).join("\r\n")
    );
  }
}

2. The next step is to create the adapter for the third-party library. This adapter will implement the interface defined in the previous step and will be responsible for transforming the data from the CSV format to the format that my application uses.

class LibraryCSVAdapter implements LibraryAdapter {
  private library: LibraryCSV;

  constructor(library: LibraryCSV) {
    this.library = library;
  }

  getBooks() {
    const books = this.library.getBooks();
    const booksArray = books.split("\r\n");
    const booksData = booksArray.slice(1);

    return booksData.map((book) => {
      const bookData = book.split(",");
      return {
        title: bookData[0],
        author: bookData[1],
      };
    });
  }
}

3. Now we can already use the adapter with our application:

const library = new LibraryCSV();
const libraryAdapter = new LibraryCSVAdapter(library);
console.log(libraryAdapter.getBooks());

/* Output:
[
  { title: 'Book 1', author: 'Author 1' },
  { title: 'Book 2', author: 'Author 2' },
  { title: 'Book 3', author: 'Author 3' }
]
*/

4. If I wanted to integrate a new third-party library, it would be as easy as defining a new adapter for the new library. For example, I'm going to integrate a library which returns the data in a stringified JSON format.

This would be the library code:

class LibraryJSON {
  getBooks() {
    const books = [
      { title: "Book 1", author: "Author 1" },
      { title: "Book 2", author: "Author 2" },
      { title: "Book 3", author: "Author 3" },
    ];

    return JSON.stringify(books);
  }
}

And this would be my adapter:

class LibraryJSONAdapter implements LibraryAdapter {
  private library: LibraryJSON;

  constructor(library: LibraryJSON) {
    this.library = library;
  }

  getBooks() {
    const books = this.library.getBooks();
    return JSON.parse(books);
  }
}

And this is how I would use the new adapter with my application:

const libraryJSON = new LibraryJSON();
const libraryJSONAdapter = new LibraryJSONAdapter(libraryJSON);
console.log(libraryJSONAdapter.getBooks());

/* Output:
[
  { title: 'Book 1', author: 'Author 1' },
  { title: 'Book 2', author: 'Author 2' },
  { title: 'Book 3', author: 'Author 3' }
]
*/

Notice that I didn't have to change my existing application code to integrate the new library. I just had to create a new adapter for the new library and use it.

Resources

Factory Method pattern in TypeScript

José Miguel Álvarez Vañó — Mon, 07 Nov 2022 19:18:13 +0000

Introduction

The factory method pattern is a creational pattern which provides an interface to create objects in a parent class. Subclasses of that class can override the method that creates the objects to change the type of object that will be created.

This way the creation of the objects is decoupled from the rest of the code.

Applicability

Use the factory method pattern when:

you cannot anticipate the type of the object that will be created
you want to localize the creation of the objects
you want to provide an easy way of extending the type of objects that can be created

Implementation

You can find the full example source code here.

1. Define an abstract interface for the object that will be created.

In the example I'm going to handle payments so I'm going to use the following interface:



interface Payment {
  creditCard: number;
}

2. Define an abstract class which will have an abstract method to create the objects. In this class you can include any common logic that the objects created by the subclasses will need.

In this example, createPayment is the abstract method that will be implemented by the subclasses. It could also be possible to have a default implementation of this method in the abstract class if you want to have some default setup.

Apart from this, I'm including the method completePayment which will be common to all the objects created by the subclasses.



abstract class PaymentGateway {
  public abstract createPayment(creditCard: number, ...args: any[]): Payment;

  public completePayment(payment: Payment): void {
    console.log(
      `Payment with credit card ${payment.creditCard} successfully completed using the PaymentGateway`
    );
  }
}

3. Define concreted implementations of the object interface that was defined in the first step.

In the example I will have PhysicalPayment and OnlinePayment.



interface PhysicalPayment extends Payment {
  storeLocation: string;
}

interface OnlinePayment extends Payment {
  email: string;
}

4. Finally, define the subclasses of the abstract class that will implement the createPayment method.

As I have two different object types, I will create two new classes: PhysicalPaymentGateway and OnlinePaymentGateway.



class PhysicalPaymentGateway extends PaymentGateway {
  public createPayment(
    creditCard: number,
    storeLocation: string
  ): PhysicalPayment {
    return {
      creditCard,
      storeLocation,
    };
  }
}

class OnlinePaymentGateway extends PaymentGateway {
  public createPayment(creditCard: number, email: string): OnlinePayment {
    return {
      creditCard,
      email,
    };
  }
}

5. The factory method is now ready to be used.

An example of how client code would create objects for the online variant:



const onlinePaymentGateway = new OnlinePaymentGateway();
const onlinePayment = onlinePaymentGateway.createPayment(
  987654321,
  "test@example.com"
);
onlinePaymentGateway.completePayment(onlinePayment);

An this is how the client would use the physical variant:



const physicalPaymentGateway = new PhysicalPaymentGateway();

const physicalPayment = physicalPaymentGateway.createPayment(

  123456789,

  "New York"

);

physicalPaymentGateway.completePayment(physicalPayment);

Advantages

Client code is decoupled from concrete implementations.
Single Responsibility Principle: All the object creation code is placed together.
Open/Closed Principle: New types of objects can be introduced without breaking client code.

As always, make sure it makes sense to use this pattern in your application. Otherwise you could be introducing unnecessary complexity.

Resources

How to cherry-pick a commit from another repository

José Miguel Álvarez Vañó — Tue, 11 Oct 2022 09:26:36 +0000

To cherry-pick a commit from another repository you have to first add the other repository as a remote (a remote is a repository whose branches you are tracking). You have to give the remote a name.

git remote add <name> https://github.com/example.git

Then, you have to fetch the branches of the remote.

git fetch <name>

Now that you are tracking the other repository and have fetched the changes you can list the commits of a specific branch and cherry-pick a commit.

git log otherRepo/<branch>
git cherry-pick <commit>

In case that you don't want to track the remote anymore you can remove it with:

git remote remove <name>

More info about working with remotes here.

Resources

Builder pattern in TypeScript

José Miguel Álvarez Vañó — Sat, 08 Oct 2022 17:42:08 +0000

Introduction

The builder pattern is a creational pattern which allows to create complex objects in an easy way. You can create multiple representations of the objects step by step using the same construction code.

Applicability

you want to simplify the construction process of a complex object
different representations of the same object are required

Implementation

You can find the full example source code here.

In our example we are going to define a Builder which will create cars and motorcycles. The example has been simplified to focus on the pattern.

First, we are going to create a interface for the Builder which will define the different operations needed to create our object. Then, we will create a concrete builder which will implement the interface and will implement the operations.

It would be possible to have multiple concrete builders in case that we wanted to create different types of objects with the same construction process. For example, following our example we could have a CarBuilder and a MotorcycleBuilder.

As a last step, we will see how we can add a Director class where we can define the different construction processes so that they have to be defined only once. The Director is not necessary, you can always use the builder directly from the
client code.

Diagram of the builder pattern. Credit: Wikimedia Commons

1. Create the Builder interface and define the different steps needed to build the objects.

In our case, the Builder will create cars and motorcycles. The construction process will have only two steps: setSeats and setEngine. Reminder: this example has been simplified to focus on learning the pattern. In a real world example, the creation process would have more steps and it would be much more complex.



interface Builder {
  setSeats(seats: number): this;
  setEngine(engine: string): this;
}

2. Create a concrete builder which will implement the Builder interface and will implement the steps. Do this for each type of object you want to create.

In our example we are only going to have two concrete Builders, the CarBuilder and the MotorcycleBuilder.

You can have a look at the definition of the Car and Motorcycle classes here.



class CarBuilder implements Builder {
  private car: Car;

  constructor() {
    this.car = new Car();
  }

  public setSeats(seats: number): this {
    this.car.setSeats(seats);
    return this;
  }

  public setEngine(engine: string): this {
    this.car.setEngine(engine);
    return this;
  }

  public getResult(): Car {
    return this.car;
  }
}

class MotorcycleBuilder implements Builder {
  private motorcycle: Motorcycle;

  constructor() {
    this.motorcycle = new Motorcycle();
  }

  public setSeats(seats: number): this {
    this.motorcycle.setSeats(seats);
    return this;
  }

  public setEngine(engine: string): this {
    this.motorcycle.setEngine(engine);
    return this;
  }

  public getResult(): Motorcycle {
    return this.motorcycle;
  }
}

Just with this code it would be enough to implement the Builder pattern. We could create a Car or a Motorcycle using the CarBuilder or the MotorcycleBuilder directly from the client code.



const car = new CarBuilder().setSeats(2).setEngine("V-12").getResult();

const motorcycle = new MotorcycleBuilder()
  .setSeats(2)
  .setEngine("V-4")
  .getResult();

3. We are going to go one step further and create the Director class. The Director will contain the different construction processes of the object representations that we need in our app.

In our example we are going to define 2 construction processes for the car and 2 for the motorcycle.



class Director {
  public buildFerrari(): Car {
    return new CarBuilder().setSeats(2).setEngine("V-12").getResult();
  }

  public buildToyota(): Car {
    return new CarBuilder().setSeats(7).setEngine("V-6").getResult();
  }

  public buildHonda(): Motorcycle {
    return new MotorcycleBuilder().setSeats(2).setEngine("V-4").getResult();
  }

  public buildYamaha(): Motorcycle {
    return new MotorcycleBuilder().setSeats(1).setEngine("V-2").getResult();
  }
}

And the Director can be used like this:



const director = new Director();

director.buildFerrari();

director.buildToyota();

director.buildHonda();

director.buildYamaha();

Advantages

You can create complex objects step by step in an easy way.
The same construction code can be reused to create different representations of objects.
Single Responsibility Principle: Complex construction processes can be isolated and separated from the object's representation.

As always, make sure it makes sense to use this pattern in your application.
Otherwise you could be introducing unnecessary complexity.

Resources

Abstract Factory pattern in TypeScript

José Miguel Álvarez Vañó — Sat, 01 Oct 2022 08:36:55 +0000

Introduction

The abstract factory pattern is a creational pattern which provides you with an interface for creating families of related objects without specifying their concrete classes. As long as the objects are created using the factory, you don't have to worry about creating the wrong combination of objects.

Applicability

When a set of objects should be used together
When the application should be independent of how the objects are created
If you have a class with multiple Factory Methods, consider switching to an Abstract Factory
If the types of the products are unknown beforehand or can change dynamically

Implementation

You can find the full example source code here.

1. Define an abstract interface for each object of the family of objects that the factory will create.

In our example we have two kinds of objects: Orders and Payments.

interface Order {
  id: number;
  addProduct(productId: string): void;
  addShippingAddres(address: string): void;
}

interface Payment {
  addCreditCardNumber(ccNumber: number): void;
  completePayment(order: Order): boolean;
}

2. Define all the variants of each object. These variants will implement the interfaces defined on the previous step.

For our example we have two variants: Online and Physical. So we have to create the following classes: OnlineOrder, OnlinePayment, PhysicalOrder and PhysicalPayment.

/**
 * Order object + Online variant
 */
class OnlineOrder implements Order {
  id: number;

  constructor(id: number) {
    this.id = id;
  }

  addProduct(productId: string): void {
    console.log(`Product ${productId} added to the online order`);
  }

  addShippingAddres(address: string): void {
    console.log(`Shipping address ${address} added to the online order`);
  }
}

/**
 * Order object + Physical variant
 */
class PhysicalOrder implements Order {
  id: number;

  constructor(id: number) {
    this.id = id;
  }

  addProduct(productId: string): void {
    console.log(`Product ${productId} added to the physical order`);
  }
  addShippingAddres(address: string): void {
    console.log(`Shipping address ${address} added to the physical order`);
  }
}

/**
 * Payment object + Online variant
 */
class OnlinePayment implements Payment {
  addCreditCardNumber(ccNumber: number): void {
    console.log(`Credit card number ${ccNumber} added to the online payment`);
  }

  completePayment(order: OnlineOrder): boolean {
    console.log(`Payment completed for the online order ${order.id}`);
    return true;
  }
}

/**
 * Payment object + Physical variant
 */
class PhysicalPayment implements Payment {
  addCreditCardNumber(ccNumber: number): void {
    console.log(`Credit card number ${ccNumber} added to the physical payment`);
  }
  completePayment(order: PhysicalOrder): boolean {
    console.log(
      `Physical payment completed for the physical order ${order.id}`
    );
    return true;
  }
}

3. Define the Abstract Factory which is an interface with a list of methods that will create the objects. These methods should have as a return type the interfaces of the products that we defined in the first step.

Our abstract factory has to define two methods: one to create orders and another one to create payments.

interface CommerceFactory {
  createOrder(id: number): Order;
  createPayment(): Payment;
}

4. A new class that implements the Abstract Factory has to be created for each variant of the family of objects.

In our example we have to create one factory for the online variant and another one for the physical variant.

/**
 * Factory for the Online variant
 */
class OnlineCommerceFactory implements CommerceFactory {
  createOrder(id: number): Order {
    return new OnlineOrder(id);
  }

  createPayment(): Payment {
    return new OnlinePayment();
  }
}

/**
 * Factory for the Physical variant
 */
class PhysicalCommerceFactory implements CommerceFactory {
  createOrder(id: number): Order {
    return new PhysicalOrder(id);
  }

  createPayment(): Payment {
    return new PhysicalPayment();
  }
}

5. The factories are ready to be used. An instance of a factory has to be passed to the client code to start creating new objects.

An example of how client code would create objects for the online variant:

const onlineCommerceFactory = new OnlineCommerceFactory();
const onlineOrder = onlineCommerceFactory.createOrder(1);
const onlinePayment = onlineCommerceFactory.createPayment();

onlineOrder.addProduct("123");
onlineOrder.addShippingAddres("123 Main St");
onlinePayment.addCreditCardNumber(123456789);
onlinePayment.completePayment(onlineOrder);

An this is how the client would use the physical variant:

const physicalCommerceFactory = new PhysicalCommerceFactory();
const physicalOrder = physicalCommerceFactory.createOrder(2);
const physicalPayment = physicalCommerceFactory.createPayment();

physicalOrder.addProduct("456");
physicalOrder.addShippingAddres("456 Main St");
physicalPayment.addCreditCardNumber(987654321);
physicalPayment.completePayment(physicalOrder);

It's important that the client code uses the abstract interfaces and not the concrete classes. This lets us change the family of objects that are returned dynamically without modifying or breaking client code and it isolates the client from concrete implementations. The client can work with any family of objects as longs as it uses the abstract interfaces.

Advantages

Improves consistency making sure that the products that are created using a factory will always be compatible with each other.
Client code is isolated from concrete implementations.
Single Responsibility Principle: All the object creation code is placed together.
Open/Closed Principle: New families of objects can be introduced without breaking client code.

As always, make sure it makes sense to use this pattern in your application. Otherwise you could be introducing unnecessary complexity.

Resources

How to create your own blog in Remix in a few minutes

José Miguel Álvarez Vañó — Wed, 14 Sep 2022 13:17:27 +0000

I've ported my personal website to Remix to experiment with this new technology. I also wanted to contribute back to the community so I decided to offer it as a Remix template. You can build a blog like mine and deploy it in just a few minutes. You can navigate through my website to see the final result.

simple-remix-blog is built using remix.run and TailwindCSS. I recommend going to the repository to read the details about the project.

If you face any issues or have any suggestions, please open an issue in the repository or contact me on Twitter!

You can follow the next steps or go to the simple-remix-blog repository and follow the instructions there.

Tutorial

Run the following command to create a project using this blog template:

npx create-remix@latest --template josemiguel-alvarez/simple-remix-blog

Run the dev script in the project folder that was created in the previous step:

yarn dev

Your blog should now be running on localhost:3000. There are some example posts in the template that you can remove when you're ready to start adding your own posts.

Then you have to update the app/siteMetadata.js file with your own information.

To create a new post you have to add a new markdown or MDX file in app/routes/posts. The project supports frontmatter, so you can add the post metadata formatted as YAML at the top of the file. Check the posts in the template if you need an example.

Finally, include the new post in the POSTS constant in the app/utils/posts.server.ts file. The post should be available now in your blog.

Deployment

I've used Vercel to deploy the app. You only have to import the project from here and it will be deployed automatically.

In case that you need more help you can find the instructions here.

Resources

It would be great to receive your feedback, so please contact me on Twitter or open an issue in the repository if you have any suggestions.