DEV Community: Will T.

⚛️ Demystifying React's Types: Ref types

Will T. — Wed, 01 May 2024 12:27:23 +0000

When working with TypeScript in ReactJS, using refs in functional components requires a bit of extra care to ensure type safety. In this article, we'll explore the most popularly used and relevant types of refs available in TypeScript-based functional components.

1️⃣ `React.RefObject`

The React.RefObject type is the most common way to work with refs in functional components. It's used when you create a ref using the useRef hook and want to access the current value of the ref. A readonly ref container where the current property cannot be mutated.

Here's an example of using React.RefObject:



import { useRef } from 'react';

export const MyComponent = () => {
  const inputRef = useRef<HTMLInputElement>(null);

  const handleClick = () => {
    inputRef.current?.focus();
  };

  return (
    <div>
      <input type="text" ref={inputRef} />
      <button onClick={handleClick}>Focus Input</button>
    </div>
  );
};

In this example, we create a ref called inputRef using the useRef hook and specify the type as HTMLInputElement.

Do not here that when using useRef, if the initially passed value is null, TypeScript will automatically understand it as a React.RefObject. If you want it to be React.MutableRefObject AND the initial value to be null, the simple trick is to simply define it as:



const inputRef = useRef<HTMLInputElement | null>(null);

2️⃣ `React.MutableRefObject`

The React.MutableRefObject type is similar to React.RefObject, but it allows the current property of the ref to be mutable. This can be useful in scenarios where you need to update the ref's value directly, without triggering a re-render.

Here's an example of using React.MutableRefObject:



import { useRef } from 'react';

export const MyComponent = () => {
  const counterRef = useRef<number>(0);

  const handleClick = () => {
    counterRef.current++;
    console.log('Counter value:', counterRef.current++);
  };

  return (
    <div>
      <button onClick={handleClick}>Increment Counter</button>
    </div>
  );
};

3️⃣ `React.RefCallback`

The React.RefCallback type is used when you need to access the DOM element or React component at a specific point in time, such as when the component mounts or unmounts. This can be particularly useful when you're working with third-party libraries that require direct DOM access, or when you need to perform complex DOM manipulations, or when you need to manage a list of refs. Its type is defined as:



type RefCallback<T> = (instance:  T  |  null) =>  void;

Below is an example of using React.RefCallback to measure the size of an element and update the component's state accordingly. This can be useful in scenarios where you need to implement responsive layouts or dynamic UI elements.



import { useState, useCallback } from 'react';

export const MyComponent = () => {
  const [elementSize, setElementSize] = useState<{ width: number; height: number }>({
    width: 0,
    height: 0,
  });

  const handleElementRef: React.RefCallback<HTMLDivElement> = useCallback((element) => {
    if (!element) return;

    const { offsetWidth, offsetHeight } = element;

    setElementSize({ width: offsetWidth, height: offsetHeight });
  }, []);

  return (
    <div ref={handleElementRef}>
      <p>Element size: {elementSize.width} x {elementSize.height}</p>
    </div>
  );
};

4️⃣ `React.Ref`

React.Ref is basically a union type of all possible shapes for React refs. You can understand it as:



type  Ref<T> = RefCallBack<T> |  RefObject<T> |  null;

5️⃣ `React.ForwardedRef`

The React.ForwardedRef type is used when you need to forward a ref from a parent component to a child component. This is particularly useful when you're working with reusable components and need to access the underlying DOM element or React component, or if there's a custom ref object created in the child component using useImperativeHandle.

Here's an example of using React.ForwardedRef:



import { forwardRef, Ref } from 'react';

interface InputProps {
  value: string;
  onChange: (value: string) => void;
}

const InputBase = ({ value, onChange }: InputProps, ref: React.ForwardedRef<HTMLInputElement>) => {
  return (
    <input
      type="text"
      value={value}
      onChange={(e) => onChange(e.target.value)}
      ref={ref}
    />
  );
});

export const Input = forwardRef(InputBase);

In this example, we use the forwardRef function to create a ref-forwarding component, which allows the parent component to access the underlying input element.

6️⃣ `React.LegacyRef`

The React.LegacyRef type is used when you need to work with refs in a way that is compatible with older versions of React. This type is primarily used for class-based components, which are less common in modern React development.

It's important to note that the ref property of every primitive HTML element in React currently has the type React.LegacyRef<HTMLElementType>. This means that if you're working with a div element, the type of the ref property will most likely be React.LegacyRef<HTMLDivElement>.

You actually wouldn't have to care about this type at all in your React projects.

🏁 Conclusion

In this article, we've explored the most popular types of refs available in React, including React.RefObject, React.MutableRefObject, React.RefCallback, React.Ref, React.ForwardedRef, and React.LegacyRef. By understanding these types, you'll be more confident navigating a React project written in TypeScript. Stay tuned for more articles on React and TypeScript, where we'll dive into the latest features and best practices for building robust and scalable applications.

In case you think it was a good read, you'll probably find my previous post useful as well:

⚛️ Organizing Code in a React Component

Will T. ・ Apr 7

#webdev #react #typescript #javascript

If you're interested in Frontend Development and Web Development with ReactJS in general, follow me and check out my articles in the profile below.

Will T.Follow

I'm a Frontend enthusiast who is specialized in ⚛️. I love sharing my knowledge and experience within my area of expertise.

⚛️ Organizing Code in a React Component

Will T. — Sun, 07 Apr 2024 07:23:58 +0000

Organizing code in a React component is often overlooked sometimes, but things can get complex when dealing with Higher-Order Components (HoCs), forwardRef, and memo. It can lead to cluttered and hard-to-maintain code if not handled properly. This article aims to address these issues by proposing a more manageable way to structure your code and improve your productivity.

1️⃣ Managing HoCs, `forwardRef`, and `memo` in a React Component

Problem Statement

As a React developer, I used to struggle often with organizing my components, especially when incorporating memo and forwardRef. The example below, taken from the React TypeScript Cheatsheet, demonstrates this challenge:



import { forwardRef } from 'react';

interface FancyButtonProps {
  type: 'submit' | 'button';
  children?: React.ReactNode;
}

export const FancyButton = forwardRef<HTMLButtonElement, FancyButtonProps>((props, ref) => (
  <button ref={ref} className="MyClassName" type={props.type}>
    {props.children}
  </button>
));

From my own experience, this code presents several problems:

The code appears cluttered compared to a "bare" component due to the wrapping of the component within forwardRef.
Types are not really in the optimal places. The generics of forwardRef have a reversed order compared to the actual parameters used in the component: <HTMLButtonElement, FancyButtonProps> vs (props, ref).
Refactoring becomes cumbersome, as it requires careful attention to brackets and parentheses. Say you no longer need forwardRef. Even with the help of something like Rainbow Brackets, dealing with those brackets and parentheses can be frustrating sometimes, especially when the component is large.
What if you want to add memo or some kinds of custom HoCs to the component, and some states or functions inside it? It'll become even more of a mess:



import { forwardRef, memo } from 'react';

import { useStyles } from '@/modules/core/styles';

interface FancyButtonProps {
  type: 'submit' | 'button';
  children?: React.ReactNode;
}

export const FancyButton = memo(
  forwardRef<HTMLButtonElement, FancyButtonProps>(({ type, children }, ref) => {
    const classes = useStyles();

    return <button ref={ref} className={classes.button} type={props.type}>
      {children}
    </button>
  })
);

Proposed Solution

After getting fed up with all the trouble when organizing my component code that way, I eventually came up with a way to tackle those issues. Consider the following approach:



import { forwardRef, memo } from 'react';

import { useStyles } from '@/modules/core/styles';

interface FancyButtonProps {
  type: 'submit' | 'button';
  children?: React.ReactNode;
}

const FancyButtonBase = (
  { type, children }: FancyButtonProps,
  ref: React.ForwardedRef<HTMLButtonElement>
) => {
  const classes = useStyles();

  return (
    <button ref={ref} className={classes.button} type={type}>
      {children}
    </button>
  );
};

export const FancyButton = memo(forwardRef(FancyButtonBase));

The code is self-explanatory. The actual code of the component lives in a function component whose name has a Base suffix to it. Then we export the component below, with all the HoCs, memo, and forwardRef.

This solution offers several benefits:

The actual component code is separated from the HoCs, memo, and forwardRef, making it resemble a "bare" component.
Types are where they should be: (props: FancyButtonProps, ref: React.ForwardedRef<HTMLButtonElement>.
Should you need to refactor this code, as in you no longer use ref, you simply have to remove the second parameter and forwardRef without having to deal with brackets and parentheses.
If nested HoCs are required, adding or modifying them is straightforward and the code still remains readable:



import { forwardRef, memo } from 'react';

import { useStyles } from '@/modules/core/styles';
import { withWhatever } from '@/modules/core/hocs';

interface FancyButtonProps {
  type: 'submit' | 'button';
  children?: React.ReactNode;
}

const FancyButtonBase = (
  { type, children }: FancyButtonProps,
  ref: React.ForwardedRef<HTMLButtonElement>
) => {
  const classes = useStyles();

  return (
    <button ref={ref} className={classes.button} type={type}>
      {children}
    </button>
  );
};

export const FancyButton = memo(forwardRef(withWhatever(FancyButtonBase)));

This approach adds a single line of code to your component but significantly improves readability and maintainability. Even without using any HoCs, memo, or forwardRef, I still do this for "bare" components: export const FancyButton = FancyButtonBase.

We can take this a step further and try to improve our productivity with a very useful but not well-known VSCode extension.

2️⃣ Improving Productivity with the "Folder Templates" Extension

The GIF below demonstrates the power of the "Folder Templates" extension in VSCode (the GIF might take a bit long to load):

You only have to enter the name of the component, and voila!

Basically, you can also tell AI to write this boilerplate code for you, but I find using this extension much quicker, and it's highly customizable.

If you need me to share my pre-defined React-specific folder template settings, please let me know in the comments.

🏁 Conclusion

Organizing code in a React component, especially when using memo, forwardRef, and HoCs, can be a daunting task. However, by separating the actual component code from the HoCs and ensuring proper type declarations, you can create cleaner, more maintainable code. Additionally, using tools like the "Folder Templates" extension in VSCode can help streamline your development process and boost productivity.

In case you think it was a good read, you'll probably find my previous post useful as well:

⚛️ Folder Structures in React Projects

Will T. ・ Mar 20

#react #webdev #javascript #typescript

If you're interested in Frontend Development and Web Development in general, follow me and check out my articles in the profile below.

Will T.Follow

I'm a Frontend enthusiast who is specialized in ⚛️. I love sharing my knowledge and experience within my area of expertise.

⚛️ Demystifying React's Types: Component types

Will T. — Thu, 28 Mar 2024 04:57:09 +0000

React's type system, when used with TypeScript, provides developers with a robust framework for building type-safe applications. Understanding the nuances between various React types is crucial for making informed decisions about their usage. Let's dive into a detailed comparison of these types in pairs to understand their differences and appropriate use cases.

1️⃣ React.FC vs React.ElementType

React.FC (React.FunctionComponent)

React.FC is a type specifically used for defining function components in React. It started to become more popular when React Hooks were introduced and widely adopted.

Prior to React 18, it used to include an implicit children prop, making it suitable for components expected to have children. For a long time, though, the implicit children prop type has been removed according to React 18's type changes.

Here's a usage example:



interface SomeComponentProps {
  title: string;
  children?: React.ReactNode;
}

export const SomeComponent: React.FC<SomeComponentProps> = ({ title, children }) => {
  return (
    <article>
      <h2>{title}</h2>

      {children}
    </article>
  );
};

However, since the removal of the implicit children prop type, much fewer people use React.FC now as it's clunky and provides no real benefits compared to directly assigning the interface to the props object:



interface SomeComponentProps {
  title: string;
  children?: React.ReactNode;
}

export const SomeComponent = ({ title, children }: SomeComponentProps) => {
  return (
    <article>
      <h2>{title}</h2>

      {children}
    </article>
  );
};

React.ElementType

React.ElementType, on the other hand, is a broader type that represents any component type that can be rendered by React. This includes not only React functional and class components but also string tags for HTML elements (e.g., 'div', 'span'). React.ElementType is particularly useful when you want to accept a component as a prop and render it, allowing for dynamic component usage.



const DynamicComponent: React.ElementType = 'div';

export const Container = () => (
  <DynamicComponent className="container">Hello, world!</DynamicComponent>
);

Here, DynamicComponent is typed as React.ElementType, allowing it to be dynamically assigned to different types of components or HTML elements.

Comparison notes

React.FC is mainly for defining functional components. Since React 18, it is not that useful anymore.
React.ElementType offers more flexibility in accepting various kinds of renderable entities. Use React.ElementType when you need something that can dynamically accept different types of React components or HTML elements.

2️⃣ React.ReactNode vs React.ReactElement vs JSX.Element

React.ReactElement

React.ReactElement is an object with type, props, and key properties, created by the React.createElement() function. It's a more specific type compared to React.ReactNode, representing elements that can be rendered directly by React.



const elementContent: React.ReactElement = <div>Hello, React.ReactElement!</div>;

export const Container = () => <>{elementContent}</>;

React.ReactNode

React.ReactNode is the most inclusive type, representing anything that can be rendered by React. This includes primitive types (strings, numbers, booleans), JSX.Elements, React.ReactElements, arrays of these types, and more. It's the go-to type for props that can accept a wide variety of content, such as children.



const multiElementContent: React.ReactNode = (
  <div>
    <p>This is a paragraph.</p>
    {'This is a text node.'}
    {null}
  </div>
);

const primitiveTypeContent: React.ReactNode = "I'm a primitive-type React.ReactNode";

export const Container = () => {
  return (
    <>
      {multiElementContent}
      {primitiveTypeContent}
    </>
  );
};

This Venn diagram below depicts the relation between React.ReactNode and React.ReactElement:

JSX.Element

JSX.Element is essentially a React.ReactElement with a broader definition, allowing various libraries to implement JSX in their own way. It's the type used internally by TypeScript to represent the return type of JSX expressions.



const jsxElement: JSX.Element = <span>Hello, JSX.Element!</span>;

export const Container = () => <>{jsxElement}</>;

Comparison notes

React.ReactNode is the most flexible and inclusive, suitable for typing props like children that can accept diverse content.
React.ReactElement and JSX.Element are more specific, with React.ReactElement being suitable for elements created by React and JSX.Element for elements defined using JSX syntax.

💡 Fun facts

The returned value of a function component a.k.a. the result of the rendering process is always either React.ReactNode or React.ReactElement/JSX.Element. Basically, a function component can be understood as:



type ReactFC<P = {}> = (props: P) => React.ReactNode;

Calling the function component just like any regular function gives us the same result as using the JSX syntax, meaning:



const MyComponent = ({ children }: { children: React.ReactNode }) => {
  return <div>{children}</div>;
};

export const App = () => {
  return (
    <div>
      <MyComponent>
        Rendering MyComponent with <strong>JSX Syntax</strong>
      </MyComponent>
    </div>
  );
}

is the same as:



const MyComponent = ({ children }: { children: React.ReactNode }) => {
  return <div>{children}</div>;
};

export const App = () => {
  return (
    <div>
      {MyComponent({
        children: (
          <>
            Rendering MyComponent by&nbsp;
            <strong>Invoking Function Component</strong>
          </>
        ),
      })}
    </div>
  );
}

Check out the codesandbox below for the demo:

🏁 Conclusion

Understanding the differences between these React types and interfaces allows developers to make more informed decisions, leading to cleaner, more maintainable code. Whether you're defining components, accepting dynamic content, or handling children, choosing the right type is crucial for leveraging React and TypeScript's full potential.

If you want to explore how to optimally organize the code in a React Component, make sure to check this this article:

⚛️ Organizing Code in a React Component

Will T. ・ Apr 7

#webdev #react #typescript #javascript

Please look forward to my upcoming articles that dive deeper into the patterns that utilize the understanding of these types.

If you're interested in Frontend Development and Web Development in general, follow me and check out my articles in the profile below.

Will T.Follow

I'm a Frontend enthusiast who is specialized in ⚛️. I love sharing my knowledge and experience within my area of expertise.

⚛️ Folder Structures in React Projects

Will T. — Wed, 20 Mar 2024 14:20:52 +0000

Organizing files and directories within a React project is crucial for maintainability, scalability, and ease of navigation. This article explores the general architecture and folder structures across different scales of React projects, providing clear demonstrations for each level.

1️⃣ Level 1: Grouping by "File Types"

This structure is characterized by its simplicity - grouping files by their type:



└── src/
    ├── assets/
    ├── api/
    ├── configs/
    ├── components/
    │   ├── SignUpForm.tsx
    │   ├── Employees.tsx
    │   ├── PaymentForm.tsx
    │   └── Button.tsx
    ├── hooks/
    │   ├── usePayment.ts
    │   ├── useUpdateEmployee.ts
    │   ├── useEmployees.ts
    │   └── useAuth.tsx
    ├── lib/
    ├── services/
    ├── states/
    └── utils/

Project Size: Small to Medium
Advantages: Simple & straightforward
Disadvantages:
- Will inflate quickly and become hard to maintain
- No separation of business concerns

Let's say you have a lot of code revolving around payment. One day the whole business changes or is no longer needed, how easy is it to replace or remove it? With this folder structure, you'll have to go through every folder and the files inside it to make the necessary changes. And if the project keeps growing larger, it'll soon grow into a maintenance hell that will only get worse over time.

2️⃣ Level 2: Grouping by "File Types" and Features

As projects grow, the "Level 2" structure introduces grouping by feature within each type:



└── src/
    ├── assets/
    ├── api/
    ├── configs/
    ├── components/
    │   ├── auth/
    │   │   └── SignUpForm.tsx
    │   ├── payment/
    │   │   └── PaymentForm.tsx
    │   ├── common/
    │   │   └── Button.tsx
    │   └── employees/
    │       ├── EmployeeList.tsx
    │       └── EmployeeSummary.tsx
    ├── hooks/
    │   ├── auth/
    │   │   └── useAuth.ts
    │   ├── payment/
    │   │   └── usePayment.ts
    │   └── employees/
    │       ├── useEmployees.ts
    │       └── useUpdateEmployee.ts
    ├── lib/
    ├── services/
    ├── states/
    └── utils/

Project Size: Medium to Large
Advantages:
- Simple & straightforward
- Stuff are grouped by features
Disadvantages:
- Logic related to a feature is still spread across multiple folder types

Now let's come back to the problem statement where the payment module needs to be modified or removed. With this structure, it's a lot easier to do that now.

The "Level 2" folder structure is the one that I'd recommend if you don't know what to choose.

3️⃣ Level 3: Grouping by Features/Modules

For larger projects, the "Level 3" structure offers a highly modular approach, defining clear boundaries for different aspects of the application within each module:



└── src/
    ├── assets/
    ├── modules/
    |   ├── core/
    │   │   ├── components/
    │   │   ├── design-system/
    │   │   │   └── Button.tsx
    │   │   ├── hooks/
    │   │   ├── lib/
    │   │   └── utils/
    │   ├── payment/
    │   │   ├── components/
    │   │   │   └── PaymentForm.tsx
    │   │   ├── hooks/
    │   │   │   └── usePayment.ts
    │   │   ├── lib/
    │   │   ├── services/
    │   │   ├── states/
    │   │   └── utils/
    │   ├── auth/
    │   │   ├── components/
    │   │   │   └── SignUpForm.tsx
    │   │   ├── hooks/
    │   │   │   └── useAuth.ts
    │   │   ├── lib/
    │   │   ├── services/
    │   │   ├── states/
    │   │   └── utils/
    │   └── employees/
    │       ├── components/
    │       │   ├── EmployeeList.tsx
    │       │   └── EmployeeSummary.tsx
    │       ├── hooks/
    │       │   ├── useEmployees.ts
    │       │   └── useUpdateEmployee.ts
    │       ├── services/
    │       ├── states/
    │       └── utils/
    └── ...

Project Size: Large and Complex
Advantages:
- Stuff are clearly grouped by features/modules
- Features/Modules are clear representations of objects in the real world
Disadvantages:
- You'll have to be well-aware of the business logic to make the right grouping decisions

With this, if you are to remove or modify the payment logic, you'll know right away where to start.

Give Consistent Meanings to Folder Names

Regardless of the structure level, certain folder names should carry specific meanings. What a folder name means may vary based on your preferences or the project's conventions.

Here's what I usually think about folder names:

UI Components

components: React components - the main UI building blocks.
design-system: Fundamental UI elements and patterns based on the design system.
icons: SVG icons that are meant to be used inline.

React Specific

hooks: Custom React hooks for shared logic.
hocs: React Higher-order Components.
contexts/providers: Contains React Contexts and Providers.

Utilities & External Integrations

utils: Utilities for universal logic that is not related to business logic or any technologies, e.g. string manipulations, mathematic calculations, etc.
lib: Utilities that are related to certain technologies, e.g. DOM manipulations, HTML-related logic, localStorage, IndexedDB, etc.
plugins: Third-party plugins (e.g. i18n, Sentry, etc.)

Business Logic

services: Encapsulates main business & application logic.
helpers: Provides business-specific utilities.

Styles

styles: Contains (global) CSS or CSS-in-JS styles.

TypeScript and Configurations

types: For general TypeScript types, enums and interfaces.
configs: Configs for the application (e.g. environment variables)
constants: Constant, unchanged values (e.g. export const MINUTES_PER_HOUR = 60).

Server Communication

api: For logic that communicates with the server(s).
graphql: GraphQL-specific code.

State Management

states/store: Global state management logic (Zustand, Valtio, Jotai, etc.)
reducers, store, actions, selectors: Redux-specific logic

Routing

routes/router: Defining routes (if you're using React Router or the like).
pages: Defining entry-point components for pages.

Testing

tests: Unit tests and other kinds of tests for your code.

🏁 Conclusion

Choosing the right folder structure in React projects is essential and should be based on the project's size and complexity. While "Level 1" may suffice for small projects, "Level 2" and "Level 3" offer more organized and modular structures for medium and large projects. Personally, I'd often recommend the "Level 2" folder structure. Also, Understanding common folder names helps maintain a consistent and intuitive architecture across React applications.

In case you think it was a good read, you'll probably find this useful as well:

⚛️ Demystifying React's Types: Component types

Will T. ・ Mar 28

#typescript #react #webdev #frontend

If you're interested in Frontend Development and Web Development in general, follow me and check out my articles in the profile below.

Will T.Follow

I'm a Frontend enthusiast who is specialized in ⚛️. I love sharing my knowledge and experience within my area of expertise.

⚛️ Applying Strategy Pattern in React (Part 2)

Will T. — Sat, 09 Mar 2024 10:23:47 +0000

In the first part, we explored the significance of the Strategy pattern in React projects and outlined its implementation. However, the approach presented might have be a little bit of an overkill. This article aims to introduce a more simple and practical way of applying the Strategy pattern.

Example 1️⃣: Unit Conversion

Problem Statement

Consider a scenario where you need to convert weight units (e.g. converting 1000g to 1kg). A straightforward solution involves a recursive function, as shown below:

export enum Weight {
  Gram = 'g',
  Kilogram = 'kg',
  Tonne = 't',
  Megatonne = 'Mt',
  Gigatonne = 'Gt',
}

const WEIGHT_UNIT_ORDER = Object.values(Weight);
const WEIGHT_UNIT_CONVERSION_THRESHOLD = 1_000;

export const convertWeightUnit = (weightInGram: number, unit = Weight.Gram): ConvertUnitResult => {
  if (weightInGram < WEIGHT_UNIT_CONVERSION_THRESHOLD ||
  unit === WEIGHT_UNIT_ORDER.at(-1)) {
    return { newValue: weightInGram, newUnit: unit };
  }

  const nextUnit = WEIGHT_UNIT_ORDER[
    Math.min(
      WEIGHT_UNIT_ORDER.indexOf(unit) + 1, 
      WEIGHT_UNIT_ORDER.length - 1
    )
  ];
  
  return convertWeightUnit(weightInGram / WEIGHT_UNIT_CONVERSION_THRESHOLD, nextUnit);
};

This example sets the stage for our discussion but let's not dwell on the recursive algorithm itself. Instead, let's explore how to apply this logic to another unit set, such as file size, without duplicating code. Here, the Strategy pattern offers an elegant solution.

Applying the Strategy Pattern

First, we'll have to define the additional TypeScript enum and interfaces that are needed for adding the new set of units:

unit.utils.types.ts:

export enum Weight {
  Gram = 'g',
  Kilogram = 'kg',
  Tonne = 't',
  Megatonne = 'Mt',
  Gigatonne = 'Gt',
}

export enum FileSize {
  Byte = 'B',
  Kilobyte = 'KB',
  Megabyte = 'MB',
  Gigabyte = 'GB',
  Terabyte = 'TB',
  Petabyte = 'PB',
}

export type GeneralUnit = Weight | FileSize;

export interface ConvertUnitResult {
  newValue: number;
  newUnit: GeneralUnit;
}

export interface UnitConversionStrategy {
  [key: string]: {
    unitOrder: GeneralUnit[];
    threshold: number;
  };
}

Now we need to modify the code to apply the Strategy pattern. At the heart of every implementation of the Strategy pattern, there has to be an object that defines the strategies. In this case, it's UNIT_CONVERSION_STRATEGY:

unit.utils.ts:

import { ConvertUnitResult, FileSize, GeneralUnit, UnitConversionStrategy, Weight } from './unit.utils.types';

const UNIT_CONVERSION_STRATEGY: UnitConversionStrategy = {
  [Weight.Gram]: {
    unitOrder: Object.values(Weight),
    threshold: 1_000
  },
  [FileSize.Byte]: {
    unitOrder: Object.values(FileSize),
    threshold: 1_000
  },
};

// Populate the strategy for each unit in each category
Object.values(UNIT_CONVERSION_STRATEGY).forEach((unitStrategy) => {
  unitStrategy.unitOrder.forEach((unit) => {
    UNIT_CONVERSION_STRATEGY[unit] = unitStrategy;
  });
});

export const convertUnit = (value: number, unit: GeneralUnit): ConvertUnitResult => {
  const unitConversionStrategy = UNIT_CONVERSION_STRATEGY[unit];

  if (!unitConversionStrategy) throw new Error('Unit not supported');

  const { unitOrder, threshold } = unitConversionStrategy;

  if (value < threshold || unit === unitOrder.at(-1)) {
    return { newValue: value, newUnit: unit };
  }

  const nextUnit = unitOrder[
    Math.min(
      unitOrder.indexOf(unit) + 1,
      unitOrder.length - 1
    )
  ];

  return convertUnit(value / threshold, nextUnit);
};

You can try it in the live codesandbox:

By leveraging the Strategy pattern as demonstrated, we circumvent the Shotgun Surgery anti-pattern. This approach keeps the number of conditional statements constant and simplifies the addition of new unit sets by merely extending the UNIT_CONVERSION_STRATEGY object without altering any existing logic, adhering to the Open/Closed Principle in SOLID.

Example 2️⃣: Design Systems in CSS-in-JS Projects

Another great example where the Strategy pattern can be applied in frontend projects is when you have to implement components in a design system.

Problem Statement

Consider implementing a button with various variants, colors, and sizes in a design system:

Button.types.ts:

export type ButtonVariant = 'contained' | 'outlined' | 'text';

export type ButtonColor = 'primary' | 'secondary' | 'error' | 'success' | 'warning' | 'info';

export type ButtonSize = 'xs' | 'sm' | 'md';

export interface ButtonProps {
  color?: ButtonColor;
  variant?: ButtonVariant;
  size?: ButtonSize;
  children: React.ReactNode;
}

An implementation with simple conditionals might result in a messy component:

Button.tsx (Before Strategy Pattern):

import { memo } from 'react';
import { Button as ThemeUIButton } from 'theme-ui';

import { ButtonProps } from './Button.types';

const ButtonBase = ({ color = 'primary', variant = 'contained', size = 'sm', children }: ButtonProps) => {
  return (
    <ThemeUIButton
      sx={{
        outline: 'none',
        borderRadius: 4,
        transition: '0.1s all',
        cursor: 'pointer',
        ...(variant === 'contained'
          ? {
              backgroundColor: `${color}.main`,
              color: 'white',
              '&:hover': {
                backgroundColor: `${color}.dark`,
              },
            }
          : {}),
        ...(variant === 'outlined'
          ? {
              backgroundColor: 'transparent',
              color: `${color}.main`,
              border: '1px solid',
              borderColor: `${color}.main`,
              '&:hover': {
                backgroundColor: `${color}.light`,
              },
            }
          : {}),
        ...(variant === 'text'
          ? {
              backgroundColor: 'transparent',
              color: `${color}.main`,
              '&:hover': {
                backgroundColor: `${color}.light`,
              },
            }
          : {}),
        ...(size === 'xs'
          ? {
              fontSize: '0.75rem',
              padding: '8px 12px',
            }
          : {}),
        ...(size === 'sm'
          ? {
              fontSize: '0.875rem',
              padding: '12px 16px',
            }
          : {}),
        ...(size === 'md'
          ? {
              fontSize: '1rem',
              padding: '16px 24px',
            }
          : {}),
      }}
    >
      {children}
    </ThemeUIButton>
  );
};

export const Button = memo(ButtonBase);

Applying the Strategy Pattern

Now let's try applying the Strategy pattern and see how it helps us to clear the mess:

Button.utils.ts:

import { ButtonColor } from './Button.types';

export const getButtonVariantMapping = (color: ButtonColor = 'primary') => {
  return {
    contained: {
      backgroundColor: `${color}.main`,
      color: 'white',
      '&:hover': {
        backgroundColor: `${color}.dark`,
      },
    },
    outlined: {
      backgroundColor: 'transparent',
      color: `${color}.main`,
      border: '1px solid',
      borderColor: `${color}.main`,
      '&:hover': {
        backgroundColor: `${color}.light`,
      },
    },
    text: {
      backgroundColor: 'transparent',
      color: `${color}.main`,
      '&:hover': {
        backgroundColor: `${color}.light`,
      },
    },
  };
};

export const BUTTON_SIZE_STYLE_MAPPING = {
  xs: {
    fontSize: '0.75rem',
    padding: '8px 12px',
  },
  sm: {
    fontSize: '0.875rem',
    padding: '12px 16px',
  },
  md: {
    fontSize: '1rem',
    padding: '16px 24px',
  },
};

Button.tsx (After Strategy Pattern):

import { memo } from 'react';
import { Button as ThemeUIButton } from 'theme-ui';

import { ButtonProps } from './Button.types';
import { getButtonVariantMapping, BUTTON_SIZE_STYLE_MAPPING } from './Button.utils';

const ButtonBase = ({ color = 'primary', variant = 'contained', size = 'sm', children }: ButtonProps) => {
  const buttonVariantStyle = getButtonVariantMapping(color)[variant];

  return (
    <ThemeUIButton
      sx={{
        outline: 'none',
        borderRadius: 4,
        transition: '0.1s all',
        cursor: 'pointer',
        ...buttonVariantStyle,
        ...BUTTON_SIZE_STYLE_MAPPING[size],
      }}
    >
      {children}
    </ThemeUIButton>
  );
};

export const Button = memo(ButtonBase);

This refactoring significantly improves code readability and gives us a clear separation of concerns.

Example 3️⃣: Verification Badge

Problem Statement

We need to create a very simple verification badge component. The requirement is as follows:

Low: "?" in red, showing "Low verification level" when hovered
Medium: "?" in orange, showing "Medium verification level" when hovered
High: "✓" in green, showing "High verification level" when hovered

Without using a strategy object, we can implement the component like this:

VerificationLevelBadge.tsx:

import { Box, Tooltip } from '@mantine/core';

interface VerificationLevelBadgeProps {
  verificationLevel: 'high' | 'medium' | 'low';
}

export const VerificationLevelBadge = ({ verificationLevel }: VerificationLevelBadgeProps) => {
  return (
    <Tooltip
      label={
        verificationLevel === 'low'
          ? 'Low verification level'
          : verificationLevel === 'medium'
          ? 'Medium verification level'
          : 'High verification level'
      }
    >
      <Box
        component="span"
        sx={(theme) => ({
          display: 'inline-flex',
          alignItems: 'center',
          justifyContent: 'center',
          color: theme.white,
          width: 16,
          height: 16,
          fontStyle: 'normal',
          borderRadius: '50%',
          fontSize: verificationLevel === 'high' ? '0.625rem' : '0.75rem',
          background:
            verificationLevel === 'low'
              ? theme.colors.red[5]
              : verificationLevel === 'medium'
              ? theme.colors.orange[5]
              : theme.colors.teal[5],
        })}
      >
        {verificationLevel === 'high' ? '✓' : '?'}
      </Box>
    </Tooltip>
  );
};

This looks terrible. Imagine the scenario where we have to modify something, or when we have to add a new verification level.

Applying the Strategy Pattern

By introducing the strategy object, the code readability will significantly improve, and we have paved the way for future changes:

VerificationLevelBadge.utils.ts:

export const VERIFICATION_LEVEL_UI_MAPPING = {
  high: {
    backgroundColor: 'teal',
    text: '✓',
    tooltip: 'High verification level',
    fontSize: '0.625rem',
  },
  medium: {
    backgroundColor: 'orange',
    text: '?',
    tooltip: 'Medium verification level',
    fontSize: '0.75rem',
  },
  low: {
    backgroundColor: 'red',
    text: '?',
    tooltip: 'Low verification level',
    fontSize: '0.75rem',
  },
};

VerificationLevelBadge.tsx:

import { Box, Tooltip } from '@mantine/core';

import { VERIFICATION_LEVEL_UI_MAPPING } from './VerificationLevelBadge.utils';

interface VerificationLevelBadgeProps {
  verificationLevel: 'high' | 'medium' | 'low';
}

export const VerificationLevelBadge = ({ verificationLevel }: VerificationLevelBadgeProps) => {
  const { tooltip, backgroundColor, text, fontSize } = VERIFICATION_LEVEL_UI_MAPPING[verificationLevel];

  return (
    <Tooltip label={tooltip}>
      <Box
        component="span"
        sx={(theme) => ({
          display: 'inline-flex',
          alignItems: 'center',
          justifyContent: 'center',
          color: theme.white,
          width: 16,
          height: 16,
          fontStyle: 'normal',
          borderRadius: '50%',
          fontSize,
        })}
        bg={backgroundColor}
      >
        {text}
      </Box>
    </Tooltip>
  );
};

Conclusion

This article showcased a simplified application of the Strategy pattern in frontend projects. By adopting this pattern, we can avoid code duplication, improve code readability, and easily extend functionality without modifying existing logic.

Please look forward to the next part of the series where I'll be sharing my personal experience with applying useful design patterns in frontend projects.

If you're interested in Frontend Development and Web Development in general, follow me and check out my articles in the profile below.

Will T.Follow

I'm a Frontend enthusiast who is specialized in ⚛️. I love sharing my knowledge and experience within my area of expertise.

Using EventTarget and CustomEvent to build a web-native event emitter

Will T. — Sat, 04 Nov 2023 03:40:18 +0000

Web development often involves creating dynamic and interactive user interfaces. To achieve this, developers rely on various design patterns and JavaScript features to handle events and user interactions effectively. One such example is the Publisher-Subscriber pattern that can easily be implemented by using the EventTarget interface.

In this article, we'll explore how to use the EventTarget interface to easily and properly implement the Publisher-Subscriber pattern to handle events in the Web environment.

Wait... what exists before `EventTarget`?

Before EventTarget came to the browser land, when one needed to implement the Publisher-Subscriber pattern, they would probably have to build everything from scratch. A common code example is to create a PubSub class that manages its internal events like this:

type EventCallback<T> = (data: T) => void;

class PubSub<T> {
  #events: Record<string, EventCallback<T>[]> = {};

  addEventListener(event: string, callback: EventCallback<T>): void {
    if (!this.#events[event]) {
      this.#events[event] = [];
    }

    this.#events[event].push(callback);
  }

  dispatchEvent(event: string, data: T): void {
    const eventCallbacks = this.#events[event];

    if (eventCallbacks && eventCallbacks.length > 0) {
      eventCallbacks.forEach((callback) => {
        callback(data);
      });
    }
  }

  removeEventListener(event: string, callback: EventCallback<T>): void {
    const eventCallbacks = this.#events[event];

    if (eventCallbacks && eventCallbacks.length > 0) {
      this.#events[event] = eventCallbacks.filter((cb) => cb !== callback);
    }
  }
}

However, that would be a little bit cumbersome, and perhaps each programmer will likely implement it slightly differently, which can be error-prone.

Introducing `EventTarget`

EventTarget is now supported by literally every browser. The EventTarget interface represents an object that can receive events and have listeners for those events. Most DOM elements in a web page, such as buttons, forms, and input fields, implement the EventTarget interface. This allows developers to add event listeners to these elements and respond to user interactions, like clicks or keypresses. However, what's even cooler is that you can use it separately without attaching it to any DOM element.

In TypeScript, the EventTarget interface is defined as follows:

interface EventTarget {
  addEventListener(type: string, callback: EventListenerOrEventListenerObject | null, options?: AddEventListenerOptions | boolean): void;
  dispatchEvent(event: Event): boolean;
  removeEventListener(type: string, callback: EventListenerOrEventListenerObject | null, options?: EventListenerOptions | boolean): void;
}

addEventListener: Appends an event listener for events with the equivalent type, which can be any arbitrary name or pre-defined types like click, keydown, etc. The callback argument sets the callback that will be invoked when the event is dispatched.
dispatchEvent: Dispatches a custom event on the target element.
removeEventListener: Removes the event listener in target's event listener list with the same type, callback, and options.

How `EventTarget` and `CustomEvent` work together

You can always create a custom EventTarget of your own by simply creating a class that extends EventTarget and then instantiate it:

class CustomEventTarget extends EventTarget {}

const customEventTarget = new CustomEventTarget();

This (customEventTarget) acts as a bridging component (a.k.a. a broker) where the data exchange happens. And with CustomEvent, we can include additional data however we want through its detail property:

const data = { whatever: 'you want' };
const customEvent = new CustomEvent('someCustomEventName', { detail: data });

customEventTarget.dispatchEvent(customEvent);

And then we can easily get that data in the event handler:

const eventHandler = (event) => {
  const data = event.detail;

  // do whatever next here
};

customEventTarget.addEventListener('someCustomEventName', eventHandler);

And don't forget to remove the event listener using removeEventListener.

Make it less verbose and easily reusable

Creating a new event may seem like a hassle sometimes. Therefore, we can have this small piece of code to reduce the boilerplate:

class CustomEventTarget extends EventTarget {}

export const createPubsub = <T = Record<string, unknown>>(eventName: string) => {
  const customEventTarget = new CustomEventTarget();

  const subscribe = (eventHandler: (data: T) => void) => {
    const scriptContentResizedEventHandler = (event: Event) => {
      const data = (event as CustomEvent).detail as T;

      eventHandler(data);
    };

    customEventTarget.addEventListener(eventName, scriptContentResizedEventHandler);

    return () => {
      customEventTarget.removeEventListener(eventName, scriptContentResizedEventHandler);
    };
  };

  const publish = (data: T) => {
    customEventTarget.dispatchEvent(new CustomEvent(eventName, { detail: data }));
  };

  return { subscribe, publish };
};

Now it only takes one line of code whenever we want to create a new pubsub:

export const customPubsubA = createPubsub<{ whatever: string }>('someCustomEvent');

And using the pubsub is also straightforward:

// Dispatch an event with some custom data
customPubsubA.publish({ whatever: 'you want' });

// To subscribe to the event:
const unsubscribe = customPubsubA.subscribe(({ whatever }) => {
  // do whatever here
});

// ...and remember to unsubscribe when it is no longer needed
unsubscribe();

Conclusion

The simple yet powerful combination makes it a valuable tool in various scenarios. In some ReactJS projects, this pattern can often be used to avoid having to rely on unnecessary and complex state management or prop drilling.

In summary, the use of the EventTarget interface and CustomEvent provides a "standardized" way to manage events and listeners. It has greatly simplified the implementation of the Publisher-Subscriber pattern in web development.

⚛️ Applying Strategy Pattern in React (Part 1)

Will T. — Wed, 14 Dec 2022 07:56:23 +0000

This article is about a problem many of us encounter in React & Frontend development (sometimes even without realizing that it's a problem): Having a piece of logic implemented throughout different components, hooks, utils, etc.

Let's dive into the problem details and how to solve it. As the title suggests, we're going to use the Strategy Pattern to solve it.

The problem: Shotgun Surgery

Shotgun Surgery is a code smell where making any modifications requires making many small changes to many different places.

(image source: https://refactoring.guru/smells/shotgun-surgery)

How can this happen in a project? Let's imagine we need to implement pricing cards for a product, and we adjust the price, the currency, the discount strategy and the messages based on where the client is coming from:

In this contrived example, without the existence of localization, the pricing card might be implemented as follows:

Components: PricingCard, PricingHeader, PricingBody.
Utility functions: getDiscountMessage (in utils/discount.ts), formatPriceByCurrency (in utils/price.ts).
The PricingBody component also calculates the final price.

Here's the full implementation:

Now let's imagine we need to change the pricing plan for a country, or add a new pricing plan for another country. What will you have to do with the above implementation? You'll have to at least modify 3 places and add more conditionals to the already messy if-else blocks:

Modify the PricingBody component.
Modify the getDiscountMessage function.
Modify the formatPriceByCurrency function.

If you've already heard of S.O.L.I.D, we're already violating the first 2 principles: The Single Responsibility Principle & The Open-Closed Principle.

The solution: Strategy Pattern

The Strategy Pattern is quite straightforward. We can simply understand that each of our pricing plans for the countries is a strategy. And in that strategy class, we implement all the related logic for that strategy.

Suppose you are familiar with OOP, we can have an abstract class (PriceStrategy) that implements the shared/common logic, and then a strategy with different logic will inherit that abstract class. The PriceStrategy abstract class looks like this:



import { Country, Currency } from '../../types';

abstract class PriceStrategy {
  protected country: Country = Country.AMERICA;
  protected currency: Currency = Currency.USD;
  protected discountRatio = 0;

  getCountry(): Country {
    return this.country;
  }

  formatPrice(price: number): string {
    return [this.currency, price.toLocaleString()].join('');
  }

  getDiscountAmount(price: number): number {
    return price * this.discountRatio;
  }

  getFinalPrice(price: number): number {
    return price - this.getDiscountAmount(price);
  }

  shouldDiscount(): boolean {
    return this.discountRatio > 0;
  }

  getDiscountMessage(price: number): string {
    const formattedDiscountAmount = this.formatPrice(
      this.getDiscountAmount(price)
    );

    return `It's lucky that you come from ${this.country}, because we're running a program that discounts the price by ${formattedDiscountAmount}.`;
  }
}

export default PriceStrategy;

And we simply pass the instantiated strategy as a prop to the PricingCard component:



<PricingCard price={7669} strategy={new JapanPriceStrategy()} />

with the props of PricingCard defined as:



interface PricingCardProps {
  price: number;
  strategy: PriceStrategy;
}

Again, if you know OOP, not only we're using Inheritance, but we're also using Polymorphism here.

Here's the full implementation of the solution:

And let us ask the same question again: How do we add a new pricing plan for a new country? With this solution, we simply need to add a new strategy class, and we don't need to modify any of the existing code. By doing so, we're satisfying S.O.L.I.D as well.

Conclusion

So, by detecting a code smell - Shotgun Surgery - in our React codebase, we have applied a design pattern - Strategy Pattern - to solve it. Our code structure went from this:

to this:

Now our logic lives in one place and is no longer spread throughout many places anymore. Do note that this whole article revolves around a contrived example. Practically, the Strategy Pattern can be implemented in simpler ways (using objects instead of classes). Please check out part 2 of this series:

⚛️ Applying Strategy Pattern in React (Part 2)

Will T. ・ Mar 9

#javascript #react #webdev #typescript

If you're interested in design patterns & architectures and how they can be used to solve problems in the Frontend world, make sure to give me a like & a follow.

Will T.Follow

I'm a Frontend enthusiast who is specialized in ⚛️. I love sharing my knowledge and experience within my area of expertise.

The components of a browser

Will T. — Wed, 19 Oct 2022 09:05:05 +0000

In this series, we are going to explore the components of a browser and go over the details of each component. The purpose of this series is to help you understand what's going on under the hood of a browser and improve your understandings of the web.

The overall structure of a browser

In this first part of the series, we're going to explore the overall structure of a browser. The basic components of a browser are as follows:

User Interface: This unit includes things that are specific to each type of browsers and are not created by the web. It defines the layout of elements available for user to interact in the browser window except for the web page itself. The elements for interaction includes the address bar, the refresh, back, forward buttons, the bookmark bar, etc.
Browser Engine: This unit handles the interactions between the user interface and the rendering engine. The browser engine is the part that receives the input from the UI and processes it to command the render engine. It’s a middle man who sits between UI and Render Engine to connect those 2 parts.
Rendering Engine: It is the unit responsible for rendering/displaying the requested content on the browser window, which is one of the most expensive operations in the browser. For example, if an HTML page is requested, then it is responsible for parsing HTML and CSS, and display the parsed and formatted content on the screen. The most popular rendering engines are:
- Blink – Used in Google Chrome, Microsoft Edge, and Opera browsers. Blink is based on Webkit.
- WebKit – Used in Safari browsers.
- Gecko – Used in Mozilla Firefox browsers.
Networking: This unit handles HTTP calls and other network-related tasks.
JavaScript Interpreter: It is a unit used to parse and execute the JavaScript code in a web page. There are different types of JS engines used by different browsers to analyse, parse and execute. The most popular ones are:
- V8 (C++) – Used in Google Chrome and Microsoft Edge.
- SpiderMonkey (C/C++) – Used by Mozilla Firefox.
- JavaScriptCore (Nitro) – Used by Safari.
UI Backend: This unit uses the user interface methods of the underlying operating system. It is mainly used for drawing basic widgets like a select box, an input box, a check box, etc.
Data Persistence: A web browser needs to store various types of data locally, for example, cookies, localStorage, local cache, etc. As a result, browsers must be compatible with data storage mechanisms such as WebSQL, IndexedDB, FileSystem, etc.

A deep dive into each component

In the upcoming parts of this series, we're going to explore each component in depth. As a web developer, the 4 most significant components that you need to care about are Browser Engine, Rendering Engine, and JavaScript Interpreter, Data Persistence. For the other components, I will be brief because most of the time, a web developer doesn't even have to care about them.

Exploring Vue 3’s reactivity: ref and watchEffect

Will T. — Thu, 06 Oct 2022 13:28:05 +0000

In this second part of the series, let's look into how Vue 3's reactivity works with ref and watchEffect.

Vue 3's reactivity

Within the scope of this article, we'll only explore ref and watchEffect for now. The other reactivity functions will be explored in the next part of the series.

We're talking about reactivity a lot here, so what is it really? It's actually not a new paradigm. The typical example is an Excel spreadsheet:

In the example above, cell B1 is defined as = A1 + A2. When you update A1 or A2, B1 will also be reactively updated.

However, in JavaScript, variables don't work that way:

let A1 = 1
let A2 = 4
let B1 = A1 + A2

console.log(B1) // 5

A1 = 3

console.log(B1) // still 5

If our purpose is only to log the sum of A1 and A2 when either A1 or A2 changes, we can write something like this in Vue 3:

const A1 = ref(1)
const A2 = ref(4)

watchEffect(() => {
  console.log('B1 =', A1.value + A2.value)
})

But how does it work? How does watchEffect magically know when A1 or A2 changes? To answer this question, let's build ref from scratch. It begins with an object with only 1 property - value - with its getter and setter:

export function ref(value) {
  return new RefImpl(value)
}

class RefImpl {
  private _value

  constructor(value) {
    this._value = value
  }

  get value() {
    return this._value
  }

  set value(newVal) {
    this._value = newVal
  }
}

Nothing happens here yet. The magic trick we're going to use here is when the value property of the ref object is read (the getter method is called), we will automatically add the caller as the subscriber of the ref object. We also call this subscriber an effect (short for side effect). The ref object now becomes a dependency of the effect.

export function ref(value) {
  return new RefImpl(value)
}

class RefImpl {
  private _value
  public dep = undefined // Ironically, in the Vue's codebase, the subscribers/effects of a ref object seem to also be called its dependencies.

  constructor(value) {
    this._value = value
  }

  get value() {
    trackRefValue(this)

    return this._value
  }

  set value(newVal) {
    this._value = newVal;
  }
}

export function trackRefValue(ref) {
  if (!activeEffect) return;

  if (!ref.dep) ref.dep = new Set() // We must use Set here to avoid duplication

  ref.dep.add(activeEffect) // Add the active (currently running) effect as one of the ref object's subscribers
}

Now there's 2 problems left:

Where does the value of activeEffect come from? In other words, how do we know which effect is currently running?
We need to trigger/inform all of a ref object's subscribers/dependencies when its value property changes.

Let's deal with the second problem first because it's quite straightforward:

export function ref(value) {
  return new RefImpl(value)
}

class RefImpl {
  private _value
  public dep = undefined // Ironically, in the Vue's codebase, the subscribers/effects of a ref object seem to also be called its dependencies.

  constructor(value) {
    this._value = value
  }

  get value() {
    trackRefValue(this)

    return this._value
  }

  set value(newVal) {
    this._value = newVal

    triggerRefValue(this)
  }
}

export function trackRefValue(ref) {
  if (!activeEffect) return;

  if (!ref.dep) ref.dep = new Set() // We must use Set here to avoid duplication

  ref.dep.add(activeEffect) // Add the active (currently running) effect as one of the ref object's subscribers
}

export function triggerRefValue(ref) {
  if (!ref.dep) return;

  for (const effect of ref.dep) {
    effect() // run the effect
  }
}

Now the most important question left is: Where does the value of activeEffect come from? Let's take a look at the rawest implementation of watchEffect:

export let activeEffect = undefined

export function watchEffect(effectHandler) {
  const effect = () => {
    activeEffect = effect

    effectHandler()
    // The above function call will read the value property of any ref object inside it
    // and trigger the getter method of the value property,
    // which in turn adds this effect as one of the subscribers of that ref object.

    activeEffect = undefined
  }

  effect() // watchEffect triggers the effect (handler) immediately
}

Because watchEffect always runs immediately, the first time it runs will always trigger the getter methods of the value property of ref objects inside it, and registers the effect as a subscriber of these ref objects. This is why you don't need to explicitly specify the dependencies for watchEffect.

Here's a working code example of ref and watchEffect:

For now, we have a roughly working version of ref and watchEffect. It is nowhere near usable because we've left out too many cases where it might fail, plus there's no batching, and the flow of control is a little bit messed up here. But it serves its purpose as an oversimplified example of what's happening behind the scenes, hopefully.

Conclusion

In this part of the series, we've tapped into the gist of Vue 3's ref and watchEffect. In the next part, we'll continue to improve the oversimplified version of ref and watchEffect to match the real implementation more closely, and we'll also explore reactive, computed, and watch.

I hope that you find this useful somehow. If you have any suggestion or advice, please don't hesitate to reach out to me in the comment section.

The basic structure of Frontend frameworks

Will T. — Wed, 15 Jun 2022 17:46:13 +0000

This is a series about exploring Frontend frameworks' internals. Its purpose is to shed some light on the way these frameworks operate under the hood. It may not be suitable for beginners or those who don't often need to know what's happening underneath their code.

Motivation

Depending on which land you come from:

Vue 3: Have you ever wondered why watchEffect can magically re-run every time the reactive states inside it change without explicitly being told? In React, you have to explicitly tell useEffect of its dependencies.
React: Have you ever wondered why stale states/closures happen when using hooks? Why does the order of hooks matter and you are forced to always use Hooks at the top level of your React function?
Solid: Why does this React-like component function only run once and still manage to have the same (or even better) functionalities? Why is the signal getter a function? And why the hell is it so fast?
etc.

If you have asked yourself such questions and want to dig deeper to find the answers, you will find this series interesting.

This series will tap into the internals of these libraries/frameworks, part by part, until we can understand and build a simplified version of each library/framework by ourselves. We might not be able to reach that end goal, but we'll surely learn a lot in the process.

And in this first part of the series, let's look into the basic structure of Frontend frameworks.

The basic structure of Frontend frameworks

The currently popular Frontend frameworks can be divided into two categories: those with Virtual DOM and those without.

First, we'll go with the Frontend libraries/frameworks that use Virtual DOM (e.g. Vue, React). The basic structure of these frameworks can be depicted as such:

At a high level, the roles of each unit in the structure is as follows:

Compiler: Templates or JSX are fed into the compiler, which then outputs render function code.
Virtual DOM Renderer/Reconciler: This unit is in charge of invoking the render functions and managing the virtual DOM tree (e.g. "reacting" to state changes and updating the virtual DOM accordingly). React calls this component the reconciler (the source code is here), while Vue calls it the runtime renderer. It is called the reconciler because one of its main job is to perform Virtual DOM "diffing", or "reconciliation".
Reactivity (State): This unit handle reactivity and states in each component and throughout the whole application. It is often decoupled from every other unit in this structure, which is why you can create reusable "hooks" without the presence of any render functions.
Native Renderer: This unit "takes render instructions" from the virtual DOM renderer/reconciler and then decides how to actually render according to its targeted environment. For example, if its target is the Web, it will render and update the actual DOM. When targeting the Web, Vue uses @vue/runtime-dom which is "abstracted away" most of the time, and React uses react-dom which is not abstracted away and requires you to explicitly import and use it. Both allow creating a custom renderer when targeting non-DOM environments:
- Vue's Custom Renderer API
- React Reconciler's examples of building a custom renderer (React Native and React Three Fiber are two really great custom renderer examples).

What about the frameworks that don't use Virtual DOM? Well, the virtual DOM renderer/reconciler and the virtual DOM tree simply no longer exist:

There's a few points worth noting here:

Don't let the directions of the arrows fool you. Looking at the diagram above, you might think that the reactivity unit needs to directly call the renderer, and the renderer needs to know about the methods of the reactivity system. But that's not how reactivity works. We'll continue to explore and understand this later in the series.

In fact, you can completely replace the reactivity system with another without changing the renderer and vice versa. For example:

mobx-jsx is using MobX as the reactivity system together with Solid's DOM renderer.

vuerx-jsx is using Vue's reactivity system (@vue/reactivity) with Solid's DOM renderer. Both offer blazingly fast performance, (much) faster than their original usage.

The template/JSX unit, the compiler, and the native renderer are the ones that will most definitely be affected when the targeted environments change. For example, you can't write <div>Hello World</div> in the template/JSX when your targeted environment is Canvas or native mobile apps.
This is still a simplified structure. For instance, we haven't taken into account the scheduler, which is a very important part of these frontend frameworks. Later in the series, when we've discussed the motivation behind a scheduler, we'll have an updated diagram which includes the scheduler.

Now that we've explored the basic structure of frontend frameworks, we'll proceed to explore each of the units inside the structure for each library/framework. My plan is to explore those aforementioned units in Vue 3 as it is currently the framework I'm using extensively for my projects (though I have also used React, Solid, and Svelte to a large degree and I do plan to include them in this series).

Conclusion

In this part of the series, we've explored the basic structure of Frontend frameworks. In the next part, we'll continue to explore Vue 3's reactivity with an oversimplified versions of ref and watchEffect.

I hope that you find this useful somehow. If you have any suggestion or advice, please don't hesitate to reach out to me in the comment section.

UI/UX Tips for Frontend Developers (Part 1)

Will T. — Wed, 30 Jun 2021 10:57:55 +0000

This is Part 1 in the series called "UI/UX for Frontend Developers". A new article will be published every few weeks.
In each part, I will talk about a general topic, some UI/UX tips about an element, and a practical UI/UX pattern.

In this part, I will share with you tips about color, buttons and the auto-save pattern. Let's get started.

General Topic: Color

Color itself is a broad topic that deserves several detailed articles. It will be broken down into many aspects to be more digestible.

The color system

Every application should have its own defined color system. The most common structure of a color system nowadays is usually as follows:

The primary color: The color that speaks your brand
The secondary/accent color: The complementary color to the primary color
Other colors for states: Red-ish (Error), Green-ish (Success), Yellow-ish (Warning)
The primary text color: Often black-ish
The secondary text color: Often lighter than the primary text color

Notes: In practice, there might be more elements to the structure of a color system, depending on the needs of the application.

There are also extremely useful tools to help you build the color system (e.g. they let you know which colors are complementary to which):

Adobe Color: https://color.adobe.com (this one also lets you build the whole color system from a colored logo you already have)
Color Scheme Designer: http://colorschemedesigner.com/csd-3.5
Coolors: https://coolors.co/generate

Color branding

Suppose you are going to build an application of some sort, you might be wondering what color you should pick for it. Basically, you are free to choose what color you like. However, having a guideline might be better than none, so I'll give you one:

Red

Characteristics: Power, Excitement, Hunger, Passion
Commonly seen types of applications: Food, Entertainment
Brand examples: Coca-cola, KFC, Youtube, Netflix, Pinterest, Nintendo, MSI

Green

Characteristics: Health, Relief, Growth, Freshness, Eco-friendliness
Commonly seen types of applications: Health, Environment, Stress relief, Education
Brand examples: Starbucks, Spotify, Heineken, Tropicana, Grab, Duolingo

Blue

Characteristics: Reliabity, Trust, Loyalty, Calm, Peace, Security
Commonly seen types of applications: Social networks, Banking, Money-related, Business, Education
Brand examples: Facebook, LinkedIn, Quizlet, Paypal, Skype, HP, Intel

Yellow

Characteristics: Optimism, Positivity, Energy, Warmth, Youthfulness, Creativity
Commonly seen types of applications: Food, Shipping/Delivery
Brand examples: McDonalds, Cheetos, Lay's, DHL, Snapchat, IMDb

Orange

Characteristics: Motivation, Cheerfulness, Creativity, Dynamic
Commonly seen types of applications: Sound, Music, Audio-related
Brand examples: Soundcloud, Audible, Audacity, VLC, Blogger, Ubuntu, Fanta

Purple

Characteristics: Feminine, Beauty, Luxury, Romance, Loyalty
Commonly seen types of applications: Beauty, Women/Girls, Dating, Romance
Brand examples: Twitch, Yahoo, Instagram, Hily, Meetme, Hallmark, Taco Bell

Brown

Characteristics: Protection, Durability, Seriousness, Down to earth
Commonly seen types of applications: Natural products (esp. coffee & chocolate), Leather products
Brand examples: Nespresso, M&M's, Hershey's, Dreyer's, Ups, Cracker Barrel

Pink

Characteristics: Love, Feminine, Beauty, Sweetness
Commonly seen types of applications: Beauty, Women/Girls, Dating, Romance
Brand examples: Tinder, OkCupid, Airbnb, LG, BeautyPlus, Hello Kitty, Barbie

Black

Characteristics: Power, Luxury, Seriousness, Elegance
Commonly seen types of applications: News, Luxury products
Brand examples: Apple, Gucci, Adidas, Chanel, Nike, The New York Times, Daily.dev, DEV.to, Medium

Element: Button

Types of buttons

There are 3 main types of buttons: Primary buttons, Secondary buttons, and Text buttons.

Based on the level of emphasis of each action, you should use the appropriate type of button.

Button states

Each button should have these states:

Enabled: The normal state of the button
Disabled: The disabled state of the button
Hover: The state when the button is hovered by a cursor
Focused: The state when the button is focused
Pressed (optional): The state when the button is pressed

UI/UX Pattern: Auto-save

Let's say you are building a page to configure settings for a user. You will probably have the tendency to design a form and then place the "Cancel" and "Save" buttons at the end of it.

Now when the user changes anything, he/she will have to remember to press the "Save" button before leaving. There shouldn't be any problems until you have a lot of fields and the "Save" button is way at the bottom and out of the current viewport. Then, the user will likely not notice the presence of the "Save" button and forget to press it. DEV.to itself encounters such a problem:

In such cases where the changes are unimportant and non-breaking, you can ditch the "Save" button and whenever a change is made, it is saved immediately (with a notification).

A lot of applications nowadays are applying this "auto-save" pattern for a better user experience. For example, Google Calendar:

Conclusion

This is the end for UI/UX Tips for Frontend Developers (Part 1). Do not hesitate to leave a comment if you have some feedback. I will try to publish Part 2 next week, and I'll be more motivated to do so if you guys react to this article to show that it's useful.

Thank you so much ❤️.

A different approach to frontend architecture

Will T. — Mon, 12 Apr 2021 11:08:59 +0000

This article aims to introduce a frontend architecture (for applications built with Vue, React, Svelte, etc.) that is easy to reason about and has high maintainability. If you are building a medium/large application and often find yourself wondering about where things should be, this article might be of use to you.

The benefits of a good architecture

Before diving into any technical stuff, let's solve a small problem first:

(image source: https://pusher.com/tutorials/clean-architecture-introduction)

In the image above, can you tell me how to replace the stapler with a tape at a glance? Some of you might come up with an interesting way to do so, but for most of us, we can't immediately figure out how to solve this problem. It looks like a mess to our eyes, and it confuses our brain.

Now look at this:

(image source: https://pusher.com/tutorials/clean-architecture-introduction)

Can you now immediately tell me how to replace the stapler? We simply have to untie the string connected to it and put the tape in its place. You need a near-zero mental effort to do it.

Imagine all the items in the images above are modules or parts in your software. A good architecture should look more like the second arrangement. The benefits of such an architecture are:

Reducing your cognitive load/mental effort when working on the project.
Making your code more modular, loosely coupled, thus more testable and maintainable.
Easing up the process of replacing a particular part in the architecture.

The common frontend architecture

The most basic and common way to separate a frontend application nowadays can be something like this:

There is nothing wrong with the architecture above at first. But then, a common pattern emerges from this kind of architecture where you tightly couple some parts of the architecture together. For example, this is a simple counter application written in Vue 3 with Vuex 4:



<template>
  <p>The count is {{ counterValue }}</p>
  <button @click="increment">+</button>
  <button @click="decrement">-</button>
</template>

<script lang="ts">
import { computed } from 'vue';
import { useStore } from 'vuex';

export default {
  name: 'Counter',
  setup() {
    const store = useStore();
    const count = computed<number>(() => store.getters.count);

    const increment = () => {
      store.dispatch('increment');
    };

    const decrement = () => {
      store.dispatch('decrement');
    };

    return {
      count,
      increment,
      decrement
    };
  }
}
</script>

You will see that this is a quite common pattern in applications written with Vue 3 and Vuex because it is in Vuex 4's guide. Actually, it is also a common pattern for React with Redux or Svelte with Svelte Stores:

Example with React and Redux:



import React, { useCallback } from 'react';
import { useSelector, useDispatch } from 'react-redux';

export const CounterComponent = () => {
  const count = useSelector(state => state.count);
  const dispatch = useDispatch();

  const increment = () => {
    dispatch({ type: 'increment' });
  };

  const decrement = () => {
    dispatch({ type: 'decrement' });
  };

  return (
    <div>
      <p>The count is {count}</p>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </div>
  );
};

Example with Svelte and Svelte Stores:



<script>
  import { count } from './stores.js';

  function increment() {
    count.update(n => n + 1);
  }

  function decrement() {
    count.update(n => n - 1);
  }
</script>

<p>The count is {$count}</p>
<button on:click={increment}>+</button>
<button on:click={decrement}>-</button>

There is nothing inherently wrong with these. In fact, most of the medium to large applications out there are probably written like these. They are the recommended ways in the official guides/tutorials.

However, everything is a trade-off. So, what are the advantages and the disadvantages of this pattern?

The most obvious benefit is probably simplicity.

But for that, what have you sacrificed?

You have tightly coupled the stores to the components. Now what if one day your team finds out that Redux is not the best fit for the application anymore (probably because it is overly complicated) and wants to switch to something else? Not only will you have to rewrite all your stores, you will also need to rewrite the logic of the React components that have been tightly coupled to Redux.

The same problems happen to all the other layers in your application. In the end, you cannot easily replace a part of your application with something else because everything has been tightly coupled to each other. It would just be better to leave it be and rewrite everything from scratch.

But it does not have to be that way. A truly modular architecture can allow you to replace your React + Redux application with React + MobX (or Valtio), or even crazier, React + Vuex or Vue + Redux (for whatever reason) without impacting other parts of your application.

So how do we replace a part of our application without impacting the rest, or in other words, how do we decouple every part of our application from each other?

Introducing a different approach

The characteristics of the layers are as follows:

Presentation: This layer is basically made of UI components. For Vue, they are Vue SFcs. For React, they are React Components. For Svelte, they are Svelte SFCs. And so on. The Presentation Layer is directly coupled to the Application Layer.
Application: This layer contains application logic. It knows of the Domain Layer and the Infrastructure Layer. This layer, in this architecture, is implemented via React Hooks in React or Vue "Hooks" in Vue 3.
Domain: This layer is for domain/business logic. Only business logic lives in the Domain layer, so there is just pure JavaScript/TypeScript code with no frameworks/libraries whatsoever here.
Infrastructure: This layer is responsible for communications with the outside world (sending requests/receiving responses) and storing local data. This is an example of the libraries you would use in a real-world application for this layer:
- HTTP Requests/Responses: Axios, Fetch API, Apollo Client, etc.
- Store (State Management): Vuex, Redux, MobX, Valtio, etc.

Applying the architecture

If you apply this architecture to an application, it looks like this:

The following characteristics are referred from the above diagram of the architecture:

When you replace the UI library/framework, only the Presentation & Application layers are impacted.
In the Infrastructure layer, we have a Facade so that when you replace the implementation details of the store (e.g. replacing Redux with Vuex), only the store itself is impacted. The same goes for replacing Axios with Fetch API or vice versa. The Application layer does not know about the implementation details of the store or the HTTP Client. In other words, we have decoupled React from Redux/Vuex/MobX. The logic of the store is also generic enough that it can be used with not just React but also Vue or Svelte.
If the business logic changes, the Domain Layer will have to be modified accordingly, and that will impact the other parts in the architecture.

What is more interesting about this architecture is you can even further modularize it:

Caveats

Even though the architecture can decouple the parts of your application from each other, it does come with a cost: increased complexity. Therefore, if you are working on a small application, I would not recommend using this. Don't use a sledgehammer to crack a nut.

For a more complex application, this architecture might probably help you achieve something like this:

(image source: https://www.simform.com/react-architecture-best-practices)

An example

I have built a simple counter app that demonstrates the merits of this architecture. You can check the source code here: https://github.com/itswillta/flexible-counter-app.

In this application, I have included Vue, React and Vue with Vuex, Redux, MobX, Valtio and even localStorage. They can all be replaced without impacting each other. Follow the simple instructions from the README file and try switching a part of the application with another one.

I know that for this counter app, I'm using a sledgehammer to crack a nut, but building a complex application is a little bit out of the question for me right now.

Questions & discussions are more than welcomed 😊.

If you're interested in Frontend Development and Web Development in general, follow me and check out my articles in the profile below.

Will T.Follow

I'm a Frontend enthusiast who is specialized in ⚛️. I love sharing my knowledge and experience within my area of expertise.

DEV Community: Will T.

⚛️ Demystifying React's Types: Ref types

1️⃣ React.RefObject

2️⃣ React.MutableRefObject

3️⃣ React.RefCallback

4️⃣ React.Ref

5️⃣ React.ForwardedRef

6️⃣ React.LegacyRef

🏁 Conclusion

⚛️ Organizing Code in a React Component

Will T. ・ Apr 7

Will T.Follow

⚛️ Organizing Code in a React Component

1️⃣ Managing HoCs, forwardRef, and memo in a React Component

Problem Statement

Proposed Solution

2️⃣ Improving Productivity with the "Folder Templates" Extension

🏁 Conclusion

⚛️ Folder Structures in React Projects

Will T. ・ Mar 20

Will T.Follow

⚛️ Demystifying React's Types: Component types

1️⃣ React.FC vs React.ElementType

React.FC (React.FunctionComponent)

React.ElementType

Comparison notes

2️⃣ React.ReactNode vs React.ReactElement vs JSX.Element

React.ReactElement

React.ReactNode

JSX.Element

Comparison notes

💡 Fun facts

🏁 Conclusion

⚛️ Organizing Code in a React Component

Will T. ・ Apr 7

Will T.Follow

⚛️ Folder Structures in React Projects

1️⃣ Level 1: Grouping by "File Types"

2️⃣ Level 2: Grouping by "File Types" and Features

3️⃣ Level 3: Grouping by Features/Modules

Give Consistent Meanings to Folder Names

UI Components

React Specific

Utilities & External Integrations

Business Logic

Styles

TypeScript and Configurations

Server Communication

State Management

Routing

Testing

🏁 Conclusion

⚛️ Demystifying React's Types: Component types

Will T. ・ Mar 28

Will T.Follow

⚛️ Applying Strategy Pattern in React (Part 2)

Example 1️⃣: Unit Conversion

Problem Statement

Applying the Strategy Pattern

Example 2️⃣: Design Systems in CSS-in-JS Projects

Problem Statement

Applying the Strategy Pattern

Example 3️⃣: Verification Badge

Problem Statement

Applying the Strategy Pattern

Conclusion

Will T.Follow

Using EventTarget and CustomEvent to build a web-native event emitter

Wait... what exists before EventTarget?

Introducing EventTarget

How EventTarget and CustomEvent work together

Make it less verbose and easily reusable

Conclusion

⚛️ Applying Strategy Pattern in React (Part 1)

The problem: Shotgun Surgery

The solution: Strategy Pattern

Conclusion

⚛️ Applying Strategy Pattern in React (Part 2)

Will T. ・ Mar 9

Will T.Follow

1️⃣ `React.RefObject`

2️⃣ `React.MutableRefObject`

3️⃣ `React.RefCallback`

4️⃣ `React.Ref`

5️⃣ `React.ForwardedRef`

6️⃣ `React.LegacyRef`

1️⃣ Managing HoCs, `forwardRef`, and `memo` in a React Component

Wait... what exists before `EventTarget`?

Introducing `EventTarget`

How `EventTarget` and `CustomEvent` work together