Forem: Anton Zamay

11-20 Сustom Utility Types for TypeScript Projects

Anton Zamay — Sun, 02 Jun 2024 18:45:21 +0000

In the second part of our exploration into TypeScript development, we introduce ten more custom utility types that expand the capabilities of your code, providing additional tools for managing types more effectively. These utility types help keep your codebase clean, efficient, and robust.

First part: 1-10 Сustom Utility Types for TypeScript Projects

`NonNullableDeep`

The NonNullableDeep type is a utility that removes null and undefined from all properties of a given type T, deeply. This means that not only are the top-level properties of the object made non-nullable, but all nested properties are also recursively marked as non-nullable. This type is particularly useful in scenarios where ensuring that no properties of an object, including those deeply nested, are null or undefined is essential, such as when dealing with data that must be fully populated.

type NonNullableDeep<T> = {
  [P in keyof T]: NonNullable<T[P]> extends object 
    ? NonNullableDeep<NonNullable<T[P]>> 
    : NonNullable<T[P]>;
};

Example

The following example demonstrates how the NonNullableDeep type can be applied to ensure that neither the Person object itself nor any of its nested properties can be null or undefined, ensuring that the entire object is fully populated.

interface Address {
  street: string | null;
  city: string | null;
}

interface Person {
  name: string | null;
  age: number | null;
  address: Address | null;
}

const person: NonNullableDeep<Person> = {
  name: "Anton Zamay",
  age: 26,
  address: {
    street: "Secret Street 123",
    city: "Berlin",
  },
};

// Error: Type 'null' is not assignable to type 'string'.
person.name = null;
// Error: Type 'undefined' is not assignable to type 'number'.
person.age = undefined;
// Error: Type 'null' is not assignable to type 'Address'.
person.address = null;
// Error: Type 'null' is not assignable to type 'string'.
person.address.city = null;

`Merge`

The Merge<O1, O2> type is useful for creating a new type by combining the properties of two object types, O1 and O2. When properties overlap, the properties from O2 will override those in O1. This is particularly useful when you need to extend or customize existing types, ensuring that specific properties take precedence.

type Merge<O1, O2> = O2 & Omit<O1, keyof O2>;

Example

In this example, we define two object types representing default settings and user settings. Using the Merge type, we combine these settings to create a final configuration, where userSettings overrides defaultSettings.

type DefaultSettings = {
  theme: string;
  notifications: boolean;
  autoSave: boolean;
};

type UserSettings = {
  theme: string;
  notifications: string[];
  debugMode?: boolean;
};

const defaultSettings: DefaultSettings = {
  theme: "light",
  notifications: true,
  autoSave: true,
};

const userSettings: UserSettings = {
  theme: "dark",
  notifications: ["Warning 1", "Error 1", "Warning 2"],
  debugMode: true,
};

type FinalSettings = Merge<DefaultSettings, UserSettings>;

const finalSettings: FinalSettings = {
  ...defaultSettings,
  ...userSettings
};

`TupleToObject`

The TupleToObject type is a utility that converts a tuple type into an object type, where the elements of the tuple become the keys of the object, and the associated values are extracted based on the position of these elements within the tuple. This type is particularly useful in scenarios where you need to transform a tuple into a more structured object form, allowing for more straightforward access to elements by their names instead of their positions.

type TupleToObject<T extends [string, any][]> = {
    [P in T[number][0]]: Extract<T[number], [P, any]>[1];
};

Example

Consider a scenario where you are working with a database that stores table schema information as tuples. Each tuple contains a field name and its corresponding data type. This format is often used in database metadata APIs or schema migration tools. The tuple format is compact and easy to process, but for application development, it's more convenient to work with objects.

type SchemaTuple = [
  ['id', 'number'],
  ['name', 'string'],
  ['email', 'string'],
  ['isActive', 'boolean']
];

const tableSchema: SchemaTuple = [
  ['id', 'number'],
  ['name', 'string'],
  ['email', 'string'],
  ['isActive', 'boolean'],
];

// Define the type of the transformed schema object
type TupleToObject<T extends [string, string | number | boolean][]> = {
  [P in T[number][0]]: Extract<
    T[number],
    [P, any]
  >[1];
};

type SchemaObject = TupleToObject<SchemaTuple>;

const schema: SchemaObject = tableSchema.reduce(
  (obj, [key, value]) => {
    obj[key] = value;
    return obj;
  },
  {} as SchemaObject
);

// Now you can use the schema object
console.log(schema.id);       // Output: number
console.log(schema.name);     // Output: string
console.log(schema.email);    // Output: string
console.log(schema.isActive); // Output: boolean

`ExclusiveTuple`

The ExclusiveTuple type is a utility that generates a tuple containing unique elements from a given union type T. This type ensures that each element of the union is included only once in the resulting tuple, effectively transforming a union type into a tuple type with all possible unique permutations of the union elements. This can be particularly useful in scenarios where you need to enumerate all unique combinations of a union's members.

type ExclusiveTuple<T, U extends any[] = []> = T extends any
    ? Exclude<T, U[number]> extends infer V
    ? [V, ...ExclusiveTuple<Exclude<T, V>, [V, ...U]>]
    : []
    : [];

Example

Consider a scenario where you are working on a feature for a travel application that generates unique itineraries for tourists visiting a city. The city offers three main attractions: a museum, a park, and a theater.

type Attraction = 'Museum' | 'Park' | 'Theater';

type Itineraries = ExclusiveTuple<Attraction>;

// The Itineraries type will be equivalent to:
// type Itineraries = 
// ['Museum', 'Park', 'Theater'] | 
// ['Museum', 'Theater', 'Park'] | 
// ['Park', 'Museum', 'Theater'] | 
// ['Park', 'Theater', 'Museum'] | 
// ['Theater', 'Museum', 'Park'] | 
// ['Theater', 'Park', 'Museum'];

`PromiseType`

The PromiseType type is a utility that extracts the type of the value that a given Promise resolves to. This is useful when working with asynchronous code, as it allows developers to easily infer the type of the result without explicitly specifying it.

type PromiseType<T> = T extends Promise<infer U> ? U : never;

This type uses TypeScript's conditional types and the infer keyword to determine the resolved type of a Promise. If T extends Promise<U>, it means that T is a Promise that resolves to type U, and U is the inferred type. If T is not a Promise, the type resolves to never.

Example

The following example demonstrates how the PromiseType type can be used to extract the resolved type from a Promise. By using this utility type, you can infer the type of the value that a Promise will resolve to, which can help in type-checking and avoiding errors when handling asynchronous operations.

type PromiseType<T> = T extends Promise<infer U> ? U : never;

interface User {
  id: number;
  name: string;
}

interface Post {
  id: number;
  title: string;
  content: string;
  userId: number;
}

async function fetchUser(userId: number): Promise<User> {
  return { id: userId, name: "Anton Zamay" };
}

async function fetchPostsByUser(userId: number): Promise<Post[]> {
  return [
    {
      id: 1,
      title: "Using the Singleton Pattern in React",
      content: "Content 1",
      userId
    },
    {
      id: 2,
      title: "Hoisting of Variables, Functions, Classes, Types, " + 
             "Interfaces in JavaScript/TypeScript",
      content: "Content 2",
      userId
    },
  ];
}

async function getUserWithPosts(
  userId: number
): Promise<{ user: User; posts: Post[] }> {
  const user = await fetchUser(userId);
  const posts = await fetchPostsByUser(userId);
  return { user, posts };
}

// Using PromiseType to infer the resolved types
type UserType = PromiseType<ReturnType<typeof fetchUser>>;
type PostsType = PromiseType<ReturnType<typeof fetchPostsByUser>>;
type UserWithPostsType = PromiseType<ReturnType<typeof getUserWithPosts>>;

async function exampleUsage() {
  const userWithPosts: UserWithPostsType = await getUserWithPosts(1);

  // The following will be type-checked to ensure correctness
  const userName: UserType["name"] = userWithPosts.user.name;
  const firstPostTitle: PostsType[0]["title"] = 
    userWithPosts.posts[0].title;

  console.log(userName); // Anton Zamay
  console.log(firstPostTitle); // Using the Singleton Pattern in React
}

exampleUsage();

Why do we need UserType instead of just using User?

That's a good question! The primary reason for using UserType instead of directly using User is to ensure that the type is accurately inferred from the return type of the asynchronous function. This approach has several advantages:

Type Consistency: By using UserType, you ensure that the type is always consistent with the actual return type of the fetchUser function. If the return type of fetchUser changes, UserType will automatically reflect that change without needing manual updates.
Automatic Type Inference: When dealing with complex types and nested promises, it can be challenging to manually determine and keep track of the resolved types. Using PromiseType allows TypeScript to infer these types for you, reducing the risk of errors.

`OmitMethods`

The OmitMethods type is a utility that removes all method properties from a given type T. This means that any property of the type T that is a function will be omitted, resulting in a new type that only includes the non-function properties.

type OmitMethods<T> = Pick<T, { [K in keyof T]: T[K] extends Function ? never : K }[keyof T]>;

Example
This type is particularly useful in scenarios where you want to exclude methods from an object's type, such as when serializing an object to JSON or sending an object through an API, where methods are irrelevant and should not be included. The following example demonstrates how the OmitMethods can be applied to an object type to remove all methods, ensuring that the resulting type only includes properties that are not functions.

interface User {
  id: number;
  name: string;
  age: number;
  greet(): void;
  updateAge(newAge: number): void;
}

const user: OmitMethods<User> = {
  id: 1,
  name: "Alice",
  age: 30,
  // greet and updateAge methods are omitted from this type
};

function sendUserData(userData: OmitMethods<User>) {
  // API call to send user data
  console.log("Sending user data:", JSON.stringify(userData));
}

sendUserData(user);

`FunctionArguments`

The FunctionArguments type is a utility that extracts the types of the arguments of a given function type T. This means that for any function type passed to it, the type will return a tuple representing the types of the function's parameters. This type is particularly useful in scenarios where you need to capture or manipulate the argument types of a function, such as in higher-order functions or when creating type-safe event handlers.

type FunctionArguments<T> = T extends (...args: infer A) => any 
  ? A 
  : never;

Example

Suppose you have a higher-order function wrap that takes a function and its arguments, and then calls the function with those arguments. Using FunctionArguments, you can ensure type safety for the wrapped function's arguments.

function wrap<T extends (...args: any[]) => any>(fn: T, ...args: FunctionArguments<T>): ReturnType<T> {
  return fn(...args);
}

function add(a: number, b: number): number {
  return a + b;
}

type AddArgs = FunctionArguments<typeof add>;
// AddArgs will be of type [number, number]

const result = wrap(add, 5, 10); // result is 15, and types are checked

`Promisify`

The Promisify type is a utility that transforms all properties of a given type T into promises of their respective types. This means that each property in the resulting type will be a Promise of the original type of that property. This type is particularly useful when dealing with asynchronous operations where you want to ensure that the entire structure conforms to the Promise-based approach, making it easier to handle and manage asynchronous data.

type Promisify<T> = {
  [P in keyof T]: Promise<T[P]>
};

Example
Consider a dashboard that displays a user's profile, recent activity, and settings. These pieces of information might be fetched from different services. By promisifying separate properties, we ensure that each part of the user data can be fetched, resolved, and handled independently, providing flexibility and efficiency in dealing with asynchronous operations.

interface Profile {
  name: string;
  age: number;
  email: string;
}

interface Activity {
  lastLogin: Date;
  recentActions: string[];
}

interface Settings {
  theme: string;
  notifications: boolean;
}

interface UserData {
  profile: Profile;
  activity: Activity;
  settings: Settings;
}

// Promisify Utility Type
type Promisify<T> = {
  [P in keyof T]: Promise<T[P]>;
};

// Simulated Fetch Functions
const fetchProfile = (): Promise<Profile> =>
  Promise.resolve({ name: "Anton Zamay", age: 26, email: "antoniezamay@gmail.com" });

const fetchActivity = (): Promise<Activity> =>
  Promise.resolve({
    lastLogin: new Date(),
    recentActions: ["logged in", "viewed dashboard"],
  });

const fetchSettings = (): Promise<Settings> =>
  Promise.resolve({ theme: "dark", notifications: true });

// Fetching User Data
const fetchUserData = async (): Promise<Promisify<UserData>> => {
  return {
    profile: fetchProfile(),
    activity: fetchActivity(),
    settings: fetchSettings(),
  };
};

// Using Promisified User Data
const displayUserData = async () => {
  const user = await fetchUserData();

  // Handling promises for each property (might be in different places)
  const profile = await user.profile;
  const activity = await user.activity;
  const settings = await user.settings;

  console.log(`Name: ${profile.name}`);
  console.log(`Last Login: ${activity.lastLogin}`);
  console.log(`Theme: ${settings.theme}`);
};

displayUserData();

`ConstrainedFunction`

The ConstrainedFunction type is a utility that constrains a given function type T to ensure its arguments and return type are preserved. It essentially captures the parameter types and return type of the function and enforces that the resulting function type must adhere to these inferred types. This type is useful in scenarios where you need to enforce strict type constraints on higher-order functions or when creating wrapper functions that must conform to the original function's signature.

type ConstrainedFunction<T extends (...args: any) => any> = T extends (...args: infer A) => infer R
    ? (args: A extends any[] ? A : never) => R
    : never;

Example

In scenarios where the function signature is not known beforehand and must be inferred dynamically, ConstrainedFunction ensures that the constraints are correctly applied based on the inferred types. Imagine a utility that wraps any function to memoize its results:

function memoize<T extends (...args: any) => any>(fn: T): ConstrainedFunction<T> {
  const cache = new Map<string, ReturnType<T>>();
  return ((...args: Parameters<T>) => {
    const key = JSON.stringify(args);
    if (!cache.has(key)) {
      cache.set(key, fn(...args));
    }
    return cache.get(key)!;
  }) as ConstrainedFunction<T>;
}

const greet: Greet = (name, age) => {
  return `Hello, my name is ${name} and I am ${age} years old.`;
};

const memoizedGreet = memoize(greet);

const message1 = memoizedGreet("Anton Zamay", 26); // Calculates and caches
const message2 = memoizedGreet("Anton Zamay", 26); // Retrieves from cache

Here, memoize uses ConstrainedFunction to ensure that the memoized function maintains the same signature as the original function fn, without needing to explicitly define the function type.

`UnionResolver`

The UnionResolver type is a utility that transforms a union type into a discriminated union. Specifically, for a given union type T, it produces an array of objects where each object contains a single property type that holds one of the types from the union. This type is particularly useful when working with union types in scenarios where you need to handle each member of the union distinctly, such as in type-safe Redux actions or discriminated union patterns in TypeScript.

type UnionResolver<T> = T extends infer U ? { type: U }[] : never;

Example
The following example demonstrates how the UnionResolver type can be applied to transform a union type into an array of objects, each with a type property. This allows for type-safe handling of each action within the union, ensuring that all cases are accounted for and reducing the risk of errors when working with union types.

type ActionType = "ADD_TODO" | "REMOVE_TODO" | "UPDATE_TODO";

type ResolvedActions = UnionResolver<ActionType>;

// The resulting type will be:
// {
//   type: "ADD_TODO";
// }[] | {
//   type: "REMOVE_TODO";
// }[] | {
//   type: "UPDATE_TODO";
// }[]

const actions: ResolvedActions = [
  { type: "ADD_TODO" },
  { type: "REMOVE_TODO" },
  { type: "UPDATE_TODO" },
];

// Now you can handle each action type distinctly
actions.forEach(action => {
  switch (action.type) {
    case "ADD_TODO":
      console.log("Adding a todo");
      break;
    case "REMOVE_TODO":
      console.log("Removing a todo");
      break;
    case "UPDATE_TODO":
      console.log("Updating a todo");
      break;
  }
});

Approaches to Styling React Components, Best Use Cases

Anton Zamay — Wed, 24 Apr 2024 07:00:20 +0000

In this article, we revisit the varied approaches for styling components in React, an extensively covered topic. However, this article is distinctively structured to outline the methods and dissect the advantages, disadvantages, and optimal use cases for each.

Inline Styling

Description

Inline styling refers to directly assigning styles to elements as attributes within the JSX markup. This is achieved using the style attribute, which takes an object with style properties written in camelCase notation.

Example

Button.jsx

function Button() {
  const buttonStyle = {
    backgroundColor: 'blue',
    color: 'white',
    padding: '10px 20px',
    border: 'none',
    borderRadius: '5px',
    fontSize: '16px',
    cursor: 'pointer'
  };

  return (
    <button style={buttonStyle}>
      Click Me
    </button>
  );
}

Advantages

Immediate Scope and Isolation: Inline styles are scoped directly to the element they are applied to, which avoids conflicts with other styles across the application.
Dynamic Styling Simplicity: It is straightforward to dynamically adjust styles based on the component's state or props directly within the JSX. This allows for real-time style updates, which are beneficial for interactive elements that react to user inputs.
Reduced Overhead for Small Components: For small scale projects or components with minimal styling needs, inline styling eliminates the need for additional files or styling systems, simplifying the development process.
Useful in Prototyping: It allows for rapid prototyping and visual adjustments directly within the code, which can speed up the development and design process when experimenting with layouts and styles.

Disadvantages

Limited Styling Capabilities: Inline styles do not support pseudo-classes such as :hover or :active, media queries, or keyframe animations, which limits their use in more sophisticated design requirements.
Maintenance Challenges: As applications scale, maintaining inline styles can become cumbersome and lead to cluttered code, making it harder to manage and refactor compared to centralized styling solutions.
Performance Concerns: Using inline styles excessively can lead to slower rendering times because each element needs to process its style attributes individually, which is less efficient than stylesheet-based CSS which is parsed once and applied universally.
Lack of Global Styling: Inline styles do not lend themselves well to global styling strategies (e.g. theming), where changes are made centrally and propagated throughout the application. Each style change needs to be applied individually, which can be labor-intensive.

Best Use Cases

Rapid Prototyping and Development: Inline styling is excellent for quick prototyping and development where speed is critical, and the focus is on functionality rather than long-term maintainability. It allows developers to apply styles directly within JavaScript code, reducing the need to manage separate CSS files and speeding up the iteration process.
Dynamic Styling Based on State or Props: Applications that require styles to change dynamically based on component state or props are well-suited for inline styling. Since styles are applied directly within the component's logic, it's straightforward to modify them based on runtime conditions, such as changing colors, sizes, or animations in response to user interactions.
Conditional Rendering Scenarios: Inline styling is particularly useful in scenarios where conditional rendering is frequent. For instance, displaying different styles based on user permissions, device capabilities, or other environmental conditions can be easily handled within the component’s render logic.
Small Scale Applications with Minimal Styling Needs: For small-scale applications or individual components that don't require complex stylesheets, inline styling can be a simple and effective solution. It avoids the overhead of setting up and maintaining a styling system that might be unnecessary for small projects.
Isolating Critical Styles to Prevent FOUC (Flash of Unstyled Content): When critical styles need to be applied immediately to ensure components render correctly on initial load (for instance, to prevent layout shifts or a flash of unstyled content), inline styles can be very useful. They are processed directly with HTML, making them faster to render than external stylesheets.

Normal CSS

Description

When using normal CSS for styling React components, styles are defined in separate CSS files and linked to components using className properties or standard CSS selectors that target HTML elements within the component.

Example

Button.css

.my-button {
  background-color: blue;
  color: white;
  padding: 10px 20px;
  border: none;
  border-radius: 5px;
  font-size: 16px;
  cursor: pointer;
}
.my-button:hover {
  background-color: darkblue;
}

Button.jsx

import './Button.css';

function Button() {
  return <button className="my-button">Click Me</button>;
}

Extending to SCSS

I am currently utilizing Vite:

Vite does provide built-in support for .scss, .sass, .less, .styl, and .stylus files. There is no need to install Vite-specific plugins for them, however, the corresponding pre-processor itself must be installed.

Given this built-in support, the only setup required on my part is to install the pre-processor. For SCSS and Sass, this is done simply by running the following command:

bun add -D sass

Advantages

Clear Separation of Concerns: Normal CSS maintains a distinct separation between the styling and the JavaScript logic, which helps in organizing code better. This separation simplifies collaboration, allowing designers to focus on CSS and developers on JavaScript, thereby enhancing productivity and reducing the chances of code entanglement.
Comprehensive CSS Features: Utilizing Normal CSS enables the full use of CSS features including pseudo-classes, media queries, and animations. These features are critical for creating responsive, interactive, and visually engaging websites.
Efficiency through Caching: Browsers can cache CSS files independently of HTML and JavaScript, which can significantly speed up load times during subsequent visits. This not only improves performance but also conserves bandwidth.
Scalability and Maintainability: With methodologies like BEM (Block, Element, Modifier), CSS becomes more manageable and scalable in large-scale projects. These methodologies organize CSS to minimize conflicts and maximize reusability.
Integration with Preprocessors: CSS preprocessors (like SASS or LESS) enhance the capabilities of Normal CSS by allowing variables, mixins, nested rules, and more. This increases the maintainability and modularity of stylesheets.

Disadvantages

Global Scope Issues: The global nature of CSS can lead to styling conflicts and maintenance challenges. Styles defined in one part of the application can unintentionally affect other parts, necessitating careful management and naming conventions like BEM to avoid conflicts.
Initial Load Overhead: Large CSS files can slow down the initial page load time, impacting user experience and performance, especially if the styles are not optimized or if the CSS isn't split into smaller chunks relevant to the rendered components.
Dynamic Styling Limitations: Compared to CSS-in-JS or inline styles, Normal CSS is less adept at handling dynamic styling that depends on JavaScript states or props. Implementing reactive styles typically requires more complex solutions, such as employing CSS variables that are manipulated via JavaScript.
Less Isolation: Unlike CSS-in-JS, which scopes styles tightly around components, Normal CSS has a broader impact which might lead to unintended side effects if not properly managed. This requires a disciplined approach to stylesheet organization to ensure styles are applied as intended.

Best Use Cases

Static Sites and Simple User Interfaces: Normal CSS is particularly useful for projects that feature static content and simple user interfaces. When components do not require frequent stylistic changes based on state or real-time user interactions, normal CSS provides a straightforward, efficient styling approach.
Large-Scale Applications with Structured Stylesheets: For large applications that benefit from a clear and organized stylesheet architecture, normal CSS, especially when paired with methodologies like BEM, offers an excellent solution. It allows teams to maintain consistency and scalability in the design, making it easier to manage large amounts of styles without much overlap or conflicts.
Projects with Separate Design and Development Teams: When project roles are clearly divided between designers and developers, using normal CSS can enhance workflow efficiency. Designers can focus on CSS files to implement visual design independently of the JavaScript code, facilitating a more parallel and segmented approach to development.
Applications that Require Extensive Use of CSS Features: Applications that make heavy use of CSS features such as animations, pseudo-classes, and media queries are ideal scenarios for using normal CSS. These features are fully supported and can be more cumbersome to implement correctly with other styling methods like inline styles or CSS-in-JS.
Sites Where SEO is a Priority: For projects where search engine optimization (SEO) is crucial, such as landing pages and content-focused websites, normal CSS is advantageous. Since CSS files can be cached by the browser independently of the JavaScript, this can lead to faster loading times upon return visits, enhancing the user experience and potentially boosting SEO performance.

CSS-in-JS

Description

CSS-in-JS is a styling technique wherein CSS is composed using JavaScript instead of defined in external files. This method allows CSS to be scoped locally to components rather than globally, reducing the probability of style conflicts. Utilizing JavaScript also enables dynamic styling easily aligned with the component's state or props. Libraries like Styled Components and Emotion are popular choices in the React ecosystem for adopting this method.

Example

Button.jsx

import styled from 'styled-components';

const StyledButton = styled.button`
  background-color: blue;
  color: white;
  padding: 10px 20px;
  border: none;
  border-radius: 5px;
  font-size: 16px;
  cursor: pointer;

  &:hover {
    background-color: darkblue;
  }
`;

function Button() {
  return <StyledButton>Click Me</StyledButton>;
}

Extending to Adopt TypeScript

When using CSS-in-JS with TypeScript, types are used to ensure that the props and style rules are correctly applied. For instance, Styled Components can be set up with TypeScript as follows:

import styled from 'styled-components';

interface ButtonProps {
  primary: boolean;
}

const Button = styled.button<ButtonProps>`
  background-color: ${props => props.primary ? 'blue' : 'gray'};
  color: white;
  /* other styles */
`;

function App() {
  return <Button primary>Primary Button</Button>;
}

This example demonstrates how TypeScript interface is used to ensure that the primary prop is properly typed.

Advantages

Component-Level Scope: CSS-in-JS tightly scopes styles to components, greatly reducing the risk of style leakage and conflicts across the application. This local scoping ensures that styles do not inadvertently affect unrelated parts of your project.
Dynamic and Conditional Styling: Leveraging JavaScript's capabilities allows CSS-in-JS to apply styles dynamically based on the component's state, props, or context changes.
Developer Experience and Tooling: Many CSS-in-JS libraries provide advanced development features such as automatic vendor prefixing, critical CSS generation, and server-side rendering capabilities. These features can enhance the development workflow and optimize the performance of the final application.

Disadvantages

Performance Considerations: Since styles are processed at runtime, CSS-in-JS can introduce a performance penalty, particularly with server-side rendering or in complex dynamic applications. The computational cost to parse and inject CSS via JavaScript can be significant compared to static CSS files.
Increased Bundle Size: Incorporating CSS in JavaScript often results in larger bundle sizes, as style information must be included alongside component logic. This can lead to longer load times and reduced performance, especially in network-limited scenarios.
Complexity and Overhead: While CSS-in-JS offers powerful capabilities, it also adds complexity to the project. Developers must understand both CSS and JavaScript intricacies, manage additional dependencies, and potentially deal with frequent updates and changes in the libraries used.
Dependency on JavaScript: This approach makes styling wholly dependent on JavaScript, which might not be ideal for scenarios where JavaScript is disabled on the user’s browser. It also couples the design too tightly to the application logic, which might complicate separation of concerns.
Tooling Dependency: Developers need to stay updated with the libraries' ecosystems and handle potential breaking changes or deprecations.

Best Use Cases

Applications Requiring Integrated Styling and Logic: When applications need to integrate styling closely with JavaScript logic — such as for data-driven style changes — CSS-in-JS provides a robust solution.
Need for JavaScript-Powered Styling Capabilities: When the styling logic requires the capabilities of JavaScript, such as handling arrays or objects for styles, conditionally applying styles based on complex computations, or integrating with other JavaScript-based libraries and frameworks, CSS-in-JS is exceptionally well-suited. This integration allows for more sophisticated styling dynamics that are difficult to achieve with traditional CSS.

CSS Modules

Description

CSS Modules offer a styling solution that combines the benefits of traditional CSS with the modular scoping of CSS-in-JS. In this method, CSS classes are locally scoped by default, meaning the styles defined in one module are not accessible in another unless explicitly imported. This scoping is achieved at the build time through Webpack, Vite, or other bundlers that process the CSS files and generate unique class names. This approach helps to avoid class name collisions and promotes better organization and reusability of styles without global side effects.

Example

Button.module.css

.button {
  background-color: blue;
  color: white;
  padding: 10px 20px;
  border: none;
  border-radius: 5px;
  font-size: 16px;
  cursor: pointer;
}

.button:hover {
  background-color: darkblue;
}

Button.jsx

import styles from './Button.module.css';

function Button() {
  return <button className={styles.button}>Click Me</button>;
}

In this setup, the CSS class button is automatically scoped to the Button component, and the class name in the final stylesheet is typically transformed into something unique like Button_button__3jN4s.

Advantages

Local Scoping: CSS Modules automatically scope class names to the component, preventing style leakage and ensuring that styles defined in one component do not affect others unintentionally.
Composability and Reusability: Classes from CSS Modules can be composed together and reused across different components. This modular approach enhances maintainability and scalability.
Familiar Workflow: Developers can use standard CSS syntax and leverage existing CSS knowledge without needing to learn a new syntax or library, unlike CSS-in-JS solutions.
No Runtime Overhead: Since styles are processed during the build time, CSS Modules do not introduce any runtime overhead, which is beneficial for performance compared to CSS-in-JS.
Integration with Preprocessors: CSS Modules can be used in conjunction with CSS preprocessors like SASS or LESS, allowing developers to use variables, mixins, and nested rules for more powerful and efficient styling.

Advantages

Limited Dynamic Styling: While CSS Modules support dynamic class names via conditional class bindings in JavaScript, they do not inherently support styling based on component state or props as directly as CSS-in-JS.
Global Styles Management: Managing global styles can be awkward with CSS Modules, as global styles need to be explicitly defined or included through different mechanisms, which might not be as straightforward as using traditional CSS.

Best Use Cases

Medium to Large-Scale Projects: CSS Modules are ideal for projects that require clean, maintainable styles without the overhead of runtime style computations. They provide a good balance between global CSS and inline styles, suitable for medium to large-scale applications.
Applications with Complex Component Libraries: When building applications that utilize a complex set of reusable components, CSS Modules help maintain styles encapsulated and prevent conflicts across components.
Microfrontend Architectures: For organizations employing a microfrontend architecture, where different teams develop discrete parts of a web application independently, CSS Modules are an excellent tool. They ensure style encapsulation within each microfrontend, preventing CSS clashes between disparate teams or sections of the application. This isolation helps maintain a clean and organized codebase, allows independent updates, and supports a more modular and scalable application structure. CSS Modules facilitate this by generating unique class names that are confined to their respective components, thereby enhancing development efficiency in a distributed team environment.

Implementing JavaScript Concepts from Scratch

Anton Zamay — Sun, 07 Apr 2024 12:26:35 +0000

In this article, we explore the foundational building blocks of JavaScript by crafting several key components from the ground up. As we delve into these concepts, we will apply a range of techniques, from basic to sophisticated, making this exploration valuable for both newcomers to the JavaScript world and professionals.

`memoize()`

Task Description

Re-create the memoize function (from "lodash") which optimizes performance by caching the results of function calls. This ensures repeated function calls with the same arguments are quicker by returning cached results instead of recalculating.

Implementation

function customSerializer(entity, cache = new WeakSet()) {
  if (typeof entity !== 'object' || entity === null) {
    return `${typeof entity}:${entity}`;
  }
  if (cache.has(entity)) {
    return 'CircularReference';
  }
  cache.add(entity);

  let objKeys = Object.keys(entity).sort();
  let keyRepresentations = objKeys.map(key =>
    `${customSerializer(key, cache)}:${
      customSerializer(entity[key], cache)
    }`
  );

  if (Array.isArray(entity)) {
    return `Array:[${keyRepresentations.join(',')}]`;
  }

  return `Object:{${keyRepresentations.join(',')}}`;
}


function myMemoize(fn) {
  const cache = new Map();

  return function memoized(...args) {
    const keyRep = args.map(arg => 
      customSerializer(arg)
    ).join('-');
    const key = `${typeof this}:${this}-${keyRep}`;

    if (cache.has(key)) {
      return cache.get(key);
    } else {
      const result = fn.apply(this, args);
      cache.set(key, result);
      return result;
    }
  };
}

Key Aspects of the Implementation

Caching Mechanism: It uses a Map object, cache, to store the results of function invocations. The Map object is chosen for its efficient key-value pairing and retrieval capabilities.
Custom Serializer: The customSerializer function converts the function arguments into a string representation that serves as a cache key. This serialization accounts for basic types, objects (including nested objects), arrays, and circular references. For objects and arrays, their keys are sorted to ensure consistent string representations regardless of property declaration order.
Serializing this: The value of this refers to the object that a function is a method of. In JavaScript, methods can behave differently based on the object they are called with, i.e., the context in which they are invoked. This is because this provides access to the context object's properties and methods, and its value can vary depending on how the function is called.
Circular References: The circular reference occurs when an object references itself directly or indirectly through its properties. This can happen in more complex data structures where, for example, object A contains a reference to object B, and object B in turn directly or indirectly references object A. It is crucial to handle circular references to avoid infinite loops.
Automatic Garbage Collection with WeakSet: A WeakSet holds "weak" references to its objects, meaning that the presence of an object in a WeakSet does not prevent the object from being garbage-collected if there are no other references to it. This behavior is particularly useful in contexts where temporary tracking of object presence is needed without prolonging their lifetime unnecessarily. Since the customSerializer function might only require to mark the visitation of objects during the serialization process without storing additional data, employing a WeakSet would prevent potential memory leaks by ensuring that objects are not kept alive solely by their presence in the set.

`Array.map()`

Task Description

Re-create the Array.map() which takes a transformation function as an argument. This transformation function will be executed on each element of the array, taking three arguments: the current element, the index of the current element, and the array itself.

Key Aspects of the Implementation

Memory Pre-allocation: The new Array(this.length) is used to create a pre-sized array to optimize memory allocation and improve performance by avoiding dynamic resizing as elements are added.

Implementation

Array.prototype.myMap = function(fn) {
  const result = new Array(this.length);
  for (let i = 0; i < this.length; i++) {
    result[i] = fn(this[i], i, this);
  }
  return result;
}

`Array.filter()`

Task Description

Re-create the Array.filter() which takes a predicate function as input, iterates over the elements of the array on which it is called, applying the predicate to each element. It returns a new array consisting only of those elements for which the predicate function returns true.

Key Aspects of the Implementation

Dynamic Memory Allocation: It dynamically adds qualifying elements to the filteredArray, making the method more memory efficient in cases where few elements pass the predicate function.

Implementation

Array.prototype.myFilter = function(pred) {
  const filteredArray = [];
  for (let i = 0; i < this.length; i++) {
    if (pred(this[i], i, this)) {
      filteredArray.push(this[i]);
    }
  }
  return filteredArray;
}

`Array.reduce()`

Task Description

Re-create the Array.reduce() which executes a reducer function on each element of the array, resulting in a single output value. The reducer function takes four arguments: accumulator, currentValue, currentIndex, and the whole array.

Key Aspects of the Implementation

initialValue value: The accumulator and startIndex are initialized based on whether an initialValue is passed as an argument. If initialValue is provided (meaning the arguments.length is at least 2), the accumulator is set to this initialValue, and the iteration starts 0th elements. Otherwise, if no initialValue is provided, the 0th element of the array itself is used as the initialValue.

Implementation

Array.prototype.myReduce = function(callback, initialValue) {
  let accumulator = arguments.length >= 2 
    ? initialValue 
    : this[0];
  let startIndex = arguments.length >= 2 ? 0 : 1;

  for (let i = startIndex; i < this.length; i++) {
    accumulator = callback(accumulator, this[i], i, this);
  }

  return accumulator;
}

`bind()`

Task Description

Re-create the bind() function which allows an object to be passed as the context in which the original function is called, along with pre-specified initial arguments (if any). It should also support the use of the new operator, enabling the creation of new instances while maintaining the correct prototype chain.

Implementation


Function.prototype.mybind = function(context, ...bindArgs) {
  const self = this;
  const boundFunction = function(...callArgs) {
    const isNewOperatorUsed = new.target !== undefined;
    const thisContext = isNewOperatorUsed ? this : context;
    return self.apply(thisContext, bindArgs.concat(callArgs));
  };

  if (self.prototype) {
    boundFunction.prototype = Object.create(self.prototype);
  }

  return boundFunction;
};

Key Aspects of the Implementation

Handling new Operator: The statement const isNewOperatorUsed = new.target !== undefined; checks whether the boundFunction is being called as a constructor via the new operator. If the new operator is used, the thisContext is set to the newly created object (this) instead of the provided context, acknowledging that instantiation should use a fresh context rather than the one provided during binding.
Prototype Preservation: To maintain the prototype chain of the original function, mybind conditionally sets the prototype of boundFunction to a new object that inherits from self.prototype. This step ensures that instances created from the boundFunction (when used as a constructor) correctly inherit properties from the original function's prototype. This mechanism preserves the intended inheritance hierarchy and maintains instanceof checks.

Example of Using `bind()` with `new`

Let's consider a simple constructor function that creates objects representing cars:

function Car(make, model, year) {
  this.make = make;
  this.model = model;
  this.year = year;
}

Imagine we frequently create Car objects that are of make 'Toyota'. To make this process more efficient, we can use bind to create a specialized constructor for Toyotas, pre-filling the make argument:

// Creating a specialized Toyota constructor with 'Toyota'
// as the pre-set 'make'
const ToyotaConstructor = Car.bind(null, 'Toyota');

// Now, we can create Toyota car instances
// without specifying 'make'
const myCar = new ToyotaConstructor('Camry', 2020);

// Output: Car { make: 'Toyota', model: 'Camry', year: 2020 }
console.log(myCar);

`call()`, `apply()`

Task Description

Re-create call() and apply() functions which allow to call a function with a given this value and arguments provided individually.

Implementation

Function.prototype.myCall = function(context, ...args) {
  const fnSymbol = Symbol('fnSymbol');
  context[fnSymbol] = this;

  const result = context[fnSymbol](...args);

  delete context[fnSymbol];

  return result;
};

Function.prototype.myApply = function(context, args) {
  const fnSymbol = Symbol('fnSymbol');
  context[fnSymbol] = this;

  const result = context[fnSymbol](...args);

  delete context[fnSymbol];

  return result;
};

Key Aspects of the Implementation

Symbol Usage for Property Naming: To prevent overriding potential existing properties on the context object or causing unexpected behavior due to name collisions, a unique Symbol is used as the property name. This ensures that our temporary property doesn't interfere with the context object's original properties.
Cleanup After Execution: After the function call is executed, the temporary property added to the context object is deleted. This cleanup step is crucial to avoid leaving a modified state on the context object.

`setInterval()`

Task Description

Re-create the setInterval using setTimeout. The function should repeatedly call a provided callback function at specified intervals. It returns a function that, when called, stops the interval.

Implementation

function mySetInterval(callback, interval) {
  let timerId;

  const repeater = () => {
    callback();
    timerId = setTimeout(repeater, interval);
  };

  repeater();

  return () => {
    clearTimeout(timerId);
  };
}

Key Aspects of the Implementation

Cancellation Functionality: The returned function from mySetInterval provides a simple and direct way to cancel the ongoing interval without needing to expose or manage timer IDs outside of the function's scope.

`cloneDeep()`

Task Description

Re-create the cloneDeep function (from "lodash") that performs a deep copy of a given input. This function should be able to clone complex data structures including objects, arrays, maps, sets, dates, and regular expressions, maintaining the structure and type integrity of each element.

Implementation

function myCloneDeep(entity, map = new WeakMap()) {
  if (entity === null || typeof entity !== 'object') {
    return entity;
  }

  if (map.has(entity)) {
    return map.get(entity);
  }

  let cloned;
  switch (true) {
    case Array.isArray(entity):
      cloned = [];
      map.set(entity, cloned);
      cloned = entity.map(item => myCloneDeep(item, map));
      break;
    case entity instanceof Date:
      cloned = new Date(entity.getTime());
      break;
    case entity instanceof Map:
      cloned = new Map(Array.from(entity.entries(),
        ([key, val]) => 
        [myCloneDeep(key, map), myCloneDeep(val, map)]));
      break;
    case entity instanceof Set:
      cloned = new Set(Array.from(entity.values(),
        val => myCloneDeep(val, map)));
      break;
    case entity instanceof RegExp:
      cloned = new RegExp(entity.source,
                          entity.flags);
      break;
    default:
      cloned = Object.create(
        Object.getPrototypeOf(entity));
      map.set(entity, cloned);
      for (let key in entity) {
        if (entity.hasOwnProperty(key)) {
          cloned[key] = myCloneDeep(entity[key], map);
        }
      }
  }

  return cloned;
}

Key Aspects of the Implementation

Circular Reference Handling: Utilizes a WeakMap to keep track of already visited objects. If an object is encountered that has already been cloned, the previously cloned object is returned, effectively handling circular references and preventing stack overflow errors.
Handling of Special Objects: Differentiates between several object types (Array, Date, Map, Sets, RegExp) to ensure that each type is cloned appropriately preserving their specific characteristics.

- **`Array`**: Recursively clones each element, ensuring deep cloning.
- **`Date`**: Copies the date using its numeric value (timestamp).
- **Maps and Sets**: Constructs a new instance, recursively cloning each entry (for `Map`) or value (for `Set`).
- **`RegExp`**: Clones by creating a new instance with the source and flags of the original.

Cloning of Object Properties: When the input is a plain object, it creates an object with the same prototype as the original and then recursively clones each own property, ensuring deep cloning while maintaining the prototype chain.
Efficiency and Performance: Utilizes WeakMap for memoization to efficiently handle complex and large structures with repeated references and circularities, ensuring optimal performance by avoiding redundant cloning.

`debounce()`

Task Description

Re-create the debounce function (from "lodash") which allows to limit the frequency at which a given callback function can fire. When invoked repeatedly within a short time frame, only the last call is executed after the specified delay.

function myDebounce(func, delay) {
  let timerId;
  const debounced = function(...args) {
    clearTimeout(timerId);
    timerId = setTimeout(() => {
      func.apply(this, args);
    }, delay);
  };

  debounced.cancel = function() {
    clearTimeout(timerId);
    timerId = null;
  };

  debounced.flush = function() {
    clearTimeout(timerId);
    func.apply(this, arguments);
    timerId = null;
  };

  return debounced;
}

Key Aspects of the Implementation

Cancellation Capability: Introducing a .cancel method enables external control to cancel any pending execution of the debounced function. This adds flexibility, allowing the debounced function to be canceled in response to specific events or conditions.
Immediate Execution through Flush: The .flush method allows for the immediate execution of the debounced function, disregarding the delay. This is useful in scenarios where it's necessary to ensure that the effects of the debounced function are applied immediately, for example, before unmounting a component or completing an interaction.

`throttle()`

Task Description

Re-create the throttle function (from "lodash") which ensures that a given callback function is only called at most once per specified interval (in the beginning in our case). Unlike debouncing, throttling guarantees a function execution at regular intervals, ensuring that updates are made, albeit at a controlled rate.

Implementation

function myThrottle(func, timeout) {
  let timerId = null;

  const throttled = function(...args) {
    if (timerId === null) {
      func.apply(this, args)
      timerId = setTimeout(() => {
        timerId = null;
      }, timeout)
    }
  }

  throttled.cancel = function() {
    clearTimeout(timerId);
    timerId = null;
  };

  return throttled;
}

Key Aspects of the Implementation

Cancellation Capability: Introducing a .cancel method enables the ability to clear any scheduled reset of the throttle timer. This is useful in cleanup phases, such as component unmounting in UI libraries/frameworks, to prevent stale executions and to manage resources effectively.

`Promise`

Task Description

Re-create the Promise class. It is a construct designed for asynchronous programming, allowing the execution of code to be paused until an async process is completed. At its core, a promise represents a proxy for a value not necessarily known at the time of its creation. It allows you to associate handlers with an asynchronous action's eventual success value or failure reason. This lets asynchronous methods return values like synchronous methods: instead of immediately returning the final value, the asynchronous method returns a promise to supply the value at some point in the future. Promise includes methods to handle fulfilled and rejected states (then, catch), and to execute code regardless of the outcome (finally).

class MyPromise {
  constructor(executor) {
    ...
  }

  then(onFulfilled, onRejected) {
    ...
  }

  catch(onRejected) {
    ...
  }

  finally(callback) {
    ...
  }
}

`constructor` Implementation

constructor(executor) {
  this.state = 'pending';
  this.value = undefined;
  this.reason = undefined;
  this.onFulfilledCallbacks = [];
  this.onRejectedCallbacks = [];

  const resolve = (value) => {
    if (this.state === 'pending') {
      this.state = 'fulfilled';
      this.value = value;
      this.onFulfilledCallbacks.forEach(fn => fn());
    }
  };

  const reject = (reason) => {
    if (this.state === 'pending') {
      this.state = 'rejected';
      this.reason = reason;
      this.onRejectedCallbacks.forEach(fn => fn());
    }
  };

  try {
    executor(resolve, reject);
  } catch (error) {
    reject(error);
  }
}

Key Aspects of the `constructor` Implementation

State Management: Initializes with a state of 'pending'. Switches to 'fulfilled' when resolved, and 'rejected' when rejected.
Value and Reason: Holds the eventual result of the promise (value) or the reason for rejection (reason).
Handling Asynchrony: Accepts an executor function that contains the asynchronous operation. The executor takes two functions, resolve and reject, which when called, transition the promise to the corresponding state.
Callback Arrays: Queues of callbacks (onFulfilledCallbacks, onRejectedCallbacks) are maintained for deferred actions pending the resolution or rejection of the promise.

`.then` Implementation

resolvePromise(promise2, x, resolve, reject) {
  if (promise2 === x) {
    return reject(new TypeError(
      'Chaining cycle detected for promise'));
  }
  if (x instanceof MyPromise) {
    x.then(resolve, reject);
  } else {
    resolve(x);
  }
}

then(onFulfilled, onRejected) {
  onFulfilled = typeof onFulfilled === 'function' ? 
    onFulfilled : value => value;

  onRejected = typeof onRejected === 'function' ? 
    onRejected : reason => { throw reason; };

  let promise2 = new MyPromise((resolve, reject) => {
    if (this.state === 'fulfilled') {
      setTimeout(() => {
        try {
          let x = onFulfilled(this.value);
          this.resolvePromise(promise2, x, resolve, reject);
        } catch (error) {
          reject(error);
        }
      });
    } else if (this.state === 'rejected') {
      setTimeout(() => {
        try {
          let x = onRejected(this.reason);
          this.resolvePromise(promise2, x, resolve, reject);
        } catch (error) {
          reject(error);
        }
      });
    } else if (this.state === 'pending') {
      this.onFulfilledCallbacks.push(() => {
        setTimeout(() => {
          try {
            let x = onFulfilled(this.value);
            this.resolvePromise(promise2, x, resolve,
              reject);
          } catch (error) {
            reject(error);
          }
        });
      });
      this.onRejectedCallbacks.push(() => {
        setTimeout(() => {
          try {
            let x = onRejected(this.reason);
            this.resolvePromise(promise2, x, resolve,
              reject);
          } catch (error) {
            reject(error);
          }
        });
      });
    }
  });

  return promise2;
}

Key Aspects of the `.then` Implementation

Default Handlers: Converts non-function handlers to identity functions (for fulfillment) or throwers (for rejection) to ensure proper forwarding and error handling in promise chains.
Promises Chaining: The then method allows for the chaining of promises, enabling sequential asynchronous operations. It creates a new promise (promise2) that depends on the outcome of the callback functions (onFulfilled, onRejected) passed to it.
Handling Resolution and Rejection: The provided callbacks are only called once the current promise is settled (either fulfilled or rejected). The result (x) of each callback potentially being a value or another promise, dictates the resolution of promise2.
Preventing Chaining Cycles: The resolvePromise function checks if promise2 is the same as the result (x), avoiding cycles where a promise waits on itself, resulting in a TypeError.
Support for MyPromise and Non-Promise Values: If the result (x) is an instance of MyPromise, then uses its resolution or rejection to settle promise2. This capability supports seamless integration of promise-based operations, both from instances of MyPromise and native JavaScript promises, assuming they share similar behavior. For non-promise values, or when onFulfilled or onRejected simply return a value, promise2 is resolved with that value, enabling simple transformations or branching logic within promise chains.
Asynchronous Execution Guarantees: By deferring execution of onFulfilled and onRejected with setTimeout, then ensures asynchronous behavior. This delay maintains a consistent execution order, guaranteeing onFulfilled and onRejected are called after the execution stack is clear.
Error Handling: Should an exception occur within either onFulfilled or onRejected, promise2 is rejected with the error, allowing error handling to propagate through the promise chain.

`catch` and `finally` Implementation

static resolve(value) {
  if (value instanceof MyPromise) {
    return value;
  }
  return new MyPromise((resolve, reject) => resolve(value));
}

catch(onRejected) {
  return this.then(null, onRejected);
}

finally(callback) {
  return this.then(
    value => MyPromise.resolve(callback())
              .then(() => value),
    reason => MyPromise.resolve(callback())
              .then(() => { throw reason; })
  );
}

Key Aspects of the `.catch` Implementation:

Simplified Error Handling: The .catch method is a shorthand for .then(null, onRejected), focusing exclusively on handling rejection scenarios. It allows for a cleaner syntax when only a rejection handler is needed, improving readability and maintainability of the code.
Promise Chaining Support: As it internally delegates to .then, .catch returns a new promise, maintaining the promise chaining capabilities. This allows for continued chain operations after error recovery or propagation of the error by rethrowing or returning a new rejected promise.
Error Propagation: If onRejected is provided and executes without errors, the returned promise is resolved with the return value of onRejected, effectively allowing for error recovery within a promise chain. If onRejected throws an error or returns a rejected promise, the error is propagated down the chain.

Key Aspects of the `.finally` Implementation:

Always Executes: The .finally method ensures the provided callback is executed regardless of whether the promise is fulfilled or rejected. This is particularly useful for cleanup actions that need to occur after asynchronous operations, independent of their outcome.
Return Value Preservation: While the callback in .finally does not receive any argument (unlike in .then or .catch), the original fulfillment value or rejection reason of the promise is preserved and passed through the chain. The returned promise from .finally is resolved or rejected with the same value or reason, unless the callback itself results in a rejected promise.
Error Handling and Propagation: If the callback executes successfully, the promise returned by .finally is settled in the same manner as the original promise. However, if the callback throws an error or returns a rejected promise, the returned promise from .finally is rejected with this new error, allowing for error interception and alteration of the rejection reason in the promise chain.

`EventEmitter`

Task Description

Re-create the EventEmitter class which allows for the implementation of the Observer pattern, enabling objects (called "emitters") to emit named events that cause previously registered listeners (or "handlers") to be called. This is a key component in Node.js for handling asynchronous events and is widely used for signaling and managing application states and behaviors. Implementing a custom EventEmitter involves creating methods for registering event listeners, triggering events, and removing listeners.

class MyEventEmitter {
  constructor() {
    this.events = {};
  }

  on(eventName, listener) {
    if (!this.events[eventName]) {
      this.events[eventName] = [];
    }
    this.events[eventName].push(listener);
  }

  once(eventName, listener) {
    const onceWrapper = (...args) => {
      listener.apply(this, args);
      this.off(eventName, onceWrapper);
    };
    this.on(eventName, onceWrapper);
  }

  emit(eventName, ...args) {
    const listeners = this.events[eventName];
    if (listeners && listeners.length) {
      listeners.forEach((listener) => {
        listener.apply(this, args);
      });
    }
  }

  off(eventName, listenerToRemove) {
    if (!this.events[eventName]) {
      return;
    }
    const filterListeners = 
      (listener) => listener !== listenerToRemove;
    this.events[eventName] = 
      this.events[eventName].filter(filterListeners);
  }
}

Key Aspects of the `EventEmitter` Implementation

EventListener Registration .on: Adds a listener function to the array of listeners for a specified event, creating a new array if one does not already exist for that event name.
One-time Event Listener .once: Registers a listener that removes itself after being invoked once. It wraps the original listener in a function (onceWrapper) that will also remove the wrapper after execution, ensuring the listener only fires once.
Emitting Events .emit: Triggers an event, calling all registered listeners with the provided arguments. It applies the arguments to each listener function, allowing data to be passed to listeners.
Removing Event Listeners .off: Removes a specific listener from an event's listener array. If the event has no listeners after the removal, it could be left as an empty array or optionally cleaned up further (not shown in this implementation).

1-10 Сustom Utility Types for TypeScript Projects

Anton Zamay — Sun, 31 Mar 2024 11:23:48 +0000

In the dynamic landscape of TypeScript development, utility types stand as base tools for crafting adaptable, clear, and robust type arrangements. This article introduces 10 widely-used utility types that tackle common coding challenges, from manipulating primitive types to fine-tuning object properties for comprehensive control over immutability and optionality.

Second part: 11-20 Сustom Utility Types for TypeScript Projects

Primitive

The type Primitive represents the set of all basic data types in JavaScript (TypeScript). Primitive can be useful for functions or variables that may need to handle a range of simple data types.

type Primitive = string | number | bigint | boolean | symbol | 
    null | undefined;

Example

The following example demonstrates how filters can accommodate various primitive data types effectively.

interface Product {
  id: symbol; // Unique identifier
  name: string;
  price: number;
  available: boolean;
  totalSales: bigint; // Large number representing total sales
}

// The filter definition
interface FilterDefinition {
  key: keyof Product;
  value: Primitive;
}

// Function to filter products
function filterProducts(
  products: Product[],
  filters: FilterDefinition[]
): Product[] {
  return products.filter((product) => {
    return filters.every((filter) => {
      return product[filter.key] === filter.value;
    });
  });
}

Falsy

The type Falsy encompasses all possible values that JavaScript (TypeScript) considers "falsy". In JavaScript, a value is considered falsy if it translates to false when evaluated in a boolean context (e.g., in an if statement). This type is optimally designed for scenarios involving type coercion to Boolean across different primitive types.

type Falsy = false | "" | 0 | 0n | null | undefined;

Example
For instance, consider a form field that may accept several falsy values, including null, false, 0, and empty string.

// A utility function that returns a default value if the
// input is Falsy
function getDefaultIfFalsy<T>(
  value: T | Falsy, 
  defaultValue: T
): T {
  return value || defaultValue;
}

// Define form data interface
interface FormData {
  name: string;
  email: string;
  age: number;
  billingAddress: string;
  shippingAddress?: string;
  sameAsBillingAddress: boolean;
}

// Use `getDefaultIfFalsy` for `shippingAddress`
formData.shippingAddress = 
  getDefaultIfFalsy(formData.shippingAddress, "");

Truthy

This construction allows Truthy<T> to be used to filter out falsy values from type unions, preserving only those types that are considered truthy in JavaScript.

type Truthy<T> = T extends Falsy ? never : T;

Here's how it can work in practice:

// Result: 1 | {}
type Example = Truthy<"" | 1 | false | {} | undefined>;

Example

Utilizing the Truthy type, you can create a function that takes an object with optional properties as input and returns an object with only the properties that were filled out (truthy values), fully typed.

function processInput<T extends object>(
  obj: T
): {[K in keyof T]: Truthy<T[K]>} {
  const result: Partial<{[K in keyof T]: Truthy<T[K]>}> = {};
  Object.entries(obj).forEach(([key, value]) => {
    if (value) {
      result[key as keyof T] = value as any;
    }
  });
  return result as {[K in keyof T]: Truthy<T[K]>};
}

const userInput = {
  name: "John",
  age: 0,
  email: ""
};

const processedInput = processInput(userInput);
console.log(processedInput); // Output: { name: "John" }

Nullish

The Nullish type indicates the absence of a value or signifies that a variable has not been initialized. Its primary purpose is to handle optional properties, variables or function parameters that may not always have a value. It allows to distinguish between missing values and values that are present, but with falsy values like 0, false, or an empty string. Therefore, using Nullish helps enhance the reliability of the code by explicitly handling these null or undefined cases.

type Nullish = null | undefined;

Example

In the example, Nullish is used to manage optional UserInfo properties, allowing the function getFoodRecommendations to default to specific values when those properties are not provided. This approach ensures the function can handle cases where the properties are either null or undefined, preventing potential errors that could arise from directly accessing unset or optional properties.

interface UserInfo {
  name: string;
  favoriteFood?: string | Nullish;
  dietRestrictions?: string | Nullish;
}

function getFoodRecommendations(user: UserInfo) {
  const favoriteFood = user.favoriteFood ?? 'Generic';
  const dietRestriction = user.dietRestrictions ?? 'No Special Diet';

  // In a real app, there could be a complex logic to get proper food recommendations.
  // Here, just return a simple string for demonstration.
  return `Recommendations: ${favoriteFood}, ${dietRestriction}`;
}

NonNullableKeys

The NonNullableKeys type construction is used to filter out the keys of an object type that are associated with nullable (i.e., null or undefined) values. This utility type is particularly useful in scenarios where it's necessary to ensure the access of only those properties of an object that are guaranteed to be non-null and non-undefined. It can be applied, for example, in functions that require strict type safety and cannot operate on nullable properties without explicit checks.

type NonNullableKeys<T> = { 
    [K in keyof T]: T[K] extends Nullish ? never : K 
}[keyof T];

Example

In the example below, we introduce a UserProfile interface with various properties. Using NonNullableKeys, we implement a prepareProfileUpdate function. This function filters out nullable properties from a user profile update object, ensuring that only properties with meaningful (non-null/undefined) values are included in the update payload. This approach can be especially valuable in API interactions where avoiding null/undefined data submission is desired for maintaining data integrity in backend systems.

interface UserProfile {
  id: string;
  name: string | null;
  email?: string | null;
  bio?: string;
  lastLogin: Date | null;
}

function prepareProfileUpdate<T extends object>(
  profile: T
): Pick<T, NonNullableKeys<T>> {
  const updatePayload: Partial<T> = {};
  (Object.keys(profile) as Array<keyof T>).forEach(key => {
    const isValuePresent = profile[key] !== null &&
                           profile[key] !== undefined;
    if (isValuePresent) {
      updatePayload[key] = profile[key];
    }
  });
  return updatePayload as Pick<T, NonNullableKeys<T>>;
}

const userProfileUpdate: UserProfile = {
  id: "123",
  name: "John Doe",
  email: null,
  bio: "Software Developer",
  lastLogin: null,
};

const validProfileUpdate = prepareProfileUpdate(
  userProfileUpdate
);
// Output:
// { id: "123", name: "John Doe", bio: "Software Developer" }
console.log(validProfileUpdate);

JSONObject

The JSONObject type is useful for defining the shape of objects that can be converted to or from JSON without loss or when interfacing with APIs that communicate using JSON. It employs a construction which is known as a recursive type or mutual recursion, wherein two or more types depend on each other. Recursive types are useful for describing data structures that can nest within themselves to an arbitrary dept.

type JSONObject = { [key: string]: JSONValue };
type JSONValue = string | number | boolean | null | JSONObject | 
  JSONValue[];

Example
In this example, we define a configuration object for an application. This configuration object must be serializable to JSON, so we enforce its shape to conform to the JSONObject type.

function saveConfiguration(config: JSONObject) {
  const serializedConfig = JSON.stringify(config);
  // In a real application, this string could be saved to a file,
  // sent to a server, etc.
  console.log(`Configuration saved: ${serializedConfig}`);
}

const appConfig: JSONObject = {
  user: {
    name: "John Doe",
    preferences: {
      theme: "dark",
      notifications: true,
    },
  },
  version: 1,
  debug: false,
};

saveConfiguration(appConfig);

OptionalExceptFor

The OptionalExceptFor type is a utility type that takes an object type T and a set of keys TRequiredKeys from T, making all properties optional except for the specified keys. It's useful in scenarios where most properties of an object are optional, but a few are mandatory. This type facilitates a more flexible approach to typing objects without having to create multiple interfaces or types for variations of optional properties, especially in configurations, where only a subset of properties is required to be present.

type OptionalExceptFor<T, TRequiredKeys extends keyof T> = 
    Partial<T> & Pick<T, TRequiredKeys>;

Example

In the following example, the OptionalExceptFor type is used to define an interface for user settings where only the userId is required, and all other properties are optional. This allows for more flexible object creation while ensuring that the userId property must always be provided.

interface UserSettings {
  userId: number;
  notifications: boolean;
  theme: string;
  language: string;
}

type SettingsWithMandatoryID =
  OptionalExceptFor<UserSettings, 'userId'>;

const userSettings: SettingsWithMandatoryID = {
  userId: 123,
  // Optional: 'notifications', 'theme', 'language'
  theme: 'dark',
};

function configureSettings(
  settings: SettingsWithMandatoryID
) {
  // Configure user settings logic
}

configureSettings(userSettings);

ReadonlyDeep

The ReadonlyDeep type is a utility that makes all properties of a given type T read-only, deeply. This means that not only are the top-level properties of the object made immutable, but all nested properties are also recursively marked as read-only. This type is particularly useful in scenarios where immutability is paramount, such as in Redux state management, where preventing unintended state mutations is crucial.

type ReadonlyDeep<T> = {
  readonly [P in keyof T]: T[P] extends object ? 
  ReadonlyDeep<T[P]> : T[P];
};

Example
The following example ensures that neither the Person object itself nor any of its nested properties can be modified, thus demonstrating how the ReadonlyDeep type can be applied to ensure deep immutability.

interface Address {
  street: string;
  city: string;
}

interface Person {
  name: string;
  age: number;
  address: Address;
}

const person: ReadonlyDeep<Person> = {
  name: "Anton Zamay",
  age: 25,
  address: {
    street: "Secret Street 123",
    city: "Berlin",
  },
};

// Error: Cannot assign to 'name' because it is a read-only
// property.
person.name = "Antonio Zamay";
// Error: Cannot assign to 'city' because it is a read-only
// property.
person.address.city = "San Francisco";

PartialDeep

The PartialDeep type recursively makes all properties of an object type T optional, deeply. This type is particularly useful in scenarios where you're working with complex nested objects and need a way to partially update or specify them. For example, when handling state updates in large data structures without the need to specify every nested field, or when defining configurations that can override defaults at multiple levels.

type PartialDeep<T> = {
   [P in keyof T]?: T[P] extends object ? PartialDeep<T[P]> : 
   T[P];
};

Example

In the example below, we use the PartialDeep type to define a function updateUserProfile that can accept partial updates to a user profile, including updates to nested objects such as address and preferences.

interface UserProfile {
  username: string;
  age: number;
  address: {
    street: string;
    city: string;
  };
  preferences: {
    newsletter: boolean;
  };
}

function updateUserProfile(
  user: UserProfile,
  updates: PartialDeep<UserProfile>
): UserProfile {
  // Implementation for merging updates into user's profile
  return { ...user, ...updates };
}

const currentUser: UserProfile = {
  username: 'johndoe',
  age: 30,
  address: {
    street: '123 Elm St',
    city: 'Anytown',
  },
  preferences: {
    newsletter: true,
  },
};

const userProfileUpdates: PartialDeep<UserProfile> = {
  address: {
    city: 'New City',
  },
};

const updatedProfile = updateUserProfile(
  currentUser,
  userProfileUpdates
);

Brand

The Brand type is a TypeScript utility that employs nominal typing for otherwise structurally identical types. TypeScript’s type system is structural, meaning that two objects are considered the same type if they have the same shape, regardless of the names or locations of their declarations. However, there are scenarios where treating two identically shaped objects as distinct types is beneficial, such as differentiating between types that are essentially the same but serve different purposes (e.g., user IDs and order IDs both being strings but representing different concepts). The Brand type works by intersecting a type T with a unique branding object, effectively differentiating otherwise identical types without changing the runtime behavior.

type Brand<T, B> = T & { __brand: B };

Example

Imagine an application where both user IDs and order IDs are represented as strings. Without branding, these could be confused, leading to potential bugs. Using the Brand type, we can create two distinct types, UserId and OrderId, making it impossible to mistakenly assign one to the other.

type UserId = Brand<string, 'UserId'>;
type OrderId = Brand<string, 'OrderId'>;

function fetchUserById(id: UserId) {
  // Fetch user logic here
}

function fetchOrderByOrderId(id: OrderId) {
  // Fetch order logic here
}

// Creation of branded types
const userId: UserId = '12345' as UserId;
const orderId: OrderId = '67890' as OrderId;

// These calls are safe and clear
fetchUserById(userId); 
fetchOrderByOrderId(orderId);

// Error: Argument of type 'OrderId' is not assignable
// to parameter of type 'UserId'
fetchUserById(orderId);

Lexical Scope, Lexical Environment, Execution Context, Closure in JavaScript

Anton Zamay — Sun, 24 Mar 2024 22:16:56 +0000

In the world of JavaScript programming, mastering the fundamental concepts of Lexical Scope, Lexical Environment, Execution Context, Closures, and the this keyword is vital for crafting sophisticated and efficient code. These core principles govern how variables are accessed and functions are executed, enabling developers to write cleaner, more secure, and highly modular code. Understanding these concepts allows for better control over the scoping mechanism, execution flow, and the dynamic context of this within different scopes, laying the groundwork for advanced JavaScript programming practices and patterns.

Lexical Scope
- Global Scope
- Local Scope
Lexical Environment
- Definition
- Lexical Scope vs Lexical Environment
Execution Context
- Types of Execution Contexts
- Components of an Execution Context
Closure
this Keyword
- this in the Global Scope
- this in the Function Calls
- this with Arrow Functions
- Manipulating this with bind(), call(), and apply()

Lexical Scope

Lexical Scope in programming, particularly in JavaScript, refers to the context in which variables and functions are accessible or visible. Lexical Scopes can be broadly classified into two categories: Global Scope and Local Scope.

Global Scope

When a variable is declared outside any function, it belongs to the Global Scope. This means it can be accessed and modified from any other part of the code, regardless of the context. Global variables are accessible throughout the lifespan of the application, making them readily available but also posing a risk of unintended modifications, which can lead to bugs.

Example:

var globalVar = "I am a global variable";

function accessGlobalVar() {
    // Accessing the global variable within a function
    console.log(globalVar);
}

accessGlobalVar(); // Output: I am a global variable
console.log(globalVar); // Output: I am a global variable

Local Scope

Local Scope, on the other hand, refers to variables declared within a function or a block (in case of let and const in ES6). These variables are only accessible within that function or block, making them hidden from the rest of the program. This encapsulation ensures that local variables are shielded from the unintended side-effects of the outer scope. There are two main types of Local Scopes: Function Scope and Block Scope.

Function Scope: Variables declared within a function using var, let, or const are scoped to the function.

Example:

function localFunctionScope() {
     var functionScopedVar = "I am a local variable";
     // Output: I am a local variable
     console.log(functionScopedVar);
}

localFunctionScope(); // Output: I am a local variable
// Uncaught ReferenceError: functionScopedVar is not defined
console.log(localVar);

Block Scope: Introduced in ES6 with let and const, variables declared inside a block {} are only accessible within that block.

Example:

if (true) {
     let blockScopedVar = "I am block-scoped";
     const anotherBlockScopedVar = "So am I";
     var globalVar = "I am global!!!";
     console.log(blockScopedVar); // Accessible here
     console.log(anotherBlockScopedVar); // Accessible here
}

// Uncaught ReferenceError: blockScopedVar is not defined
console.log(blockScopedVar);
// Uncaught ReferenceError: anotherBlockScopedVar
// is not defined
console.log(anotherBlockScopedVar);
// Output: I am global!!!
console.log(globalVar);

Lexical Environment

Lexical Environment is a core part of the JavaScript engine's execution context and plays a crucial role in how variables and functions are scoped, accessed, and managed.

Definition

Lexical Environment, on the other hand, is a more concrete mechanism employed by JavaScript engines during the runtime to manage and access the variables based on the Lexical Scope. It is a part of the JavaScript execution context that consists of two significant parts:

The Environment Record: This is where the specific variables, constants, and functions defined within the Lexical Scope are actually stored.
A reference to the outer environment: This refers to the Lexical Environment of the parent scope. It allows for the "chain" through which JavaScript searches for variable values when a variable isn't found in the immediate Lexical Environment.

Lexical Environments are created every time a block of code or a function is executed, containing all the local variables and being linked to an outer Lexical Environment. This effectively forms a Scope Chain that determines how variable lookups occur during the execution of the code.

Lexical Scope vs Lexical Environment

Lexical Scope is a part of JavaScript's scoping mechanism — it's about the rules that govern how variable names are resolved in nested layers of code. Lexical Environment, in contrast, refers to the specific implementation where these rules are applied — the concrete structure used by the JavaScript engine during the execution of the code to store variables and function declarations and to keep track of their relationships according to the Lexical Scope.

Execution Context

In JavaScript, an Execution Context can be thought of as an abstract concept that holds information about the environment where the current code is being executed. It includes everything that is needed to track the execution of a block of code or a function, such as the value of this, variables, objects, and functions that are accessible at a given time.

Types of Execution Contexts

There are three main types of Execution Contexts in JavaScript:

Global Execution Context (GEC): This is the default or base execution context. It's where code that is not inside any function gets executed and where globally scoped variables reside. There is only one Global Execution Context in a JavaScript program.
Functional Execution Context (FEC): This context is created by the execution of the code inside a function. Each function call creates a new FEC, and it includes the function's arguments, local variables, etc. It also has a reference to its outer environment, which helps in implementing lexical scope.
Eval Execution Context: Created by the execution of JavaScript code in an eval function, though its use is not recommended due to security and performance issues.

Components of an Execution Context

An Execution Context is composed of a few key components:

Variable Environment: This includes variables and functions declared within the current context. It essentially represents the Lexical Environment for functions and global variables.
Lexical Environment: This is where the magic of closures and scope chain becomes evident. The Lexical Environment is a structure that holds identifier-variable mapping. (Here, an "identifier" refers to the name of variables/functions, and the "variable" is the actual reference to objects/functions/data.) This environment also has a reference to the outer environment, which could either point to the Global environment or an outer function environment, enabling the scope chain.
This Binding: The value of this is determined and stored in the Execution Context. The value of this depends on how the function is called, and can refer to the global context, the current instance of an object (in the case of methods), or be set explicitly using functions like call, apply, or bind.

Example

To solidify the understanding, let's look at a concrete example:

let globalVar = "Welcome to the Global Context";

function outerFunction() {
    let outerVar = "I'm in the Outer Function";

    function innerFunction() {
        let innerVar = "I'm in the Inner Function";
        console.log(innerVar);
        console.log(outerVar);
        console.log(globalVar);
    }

    return innerFunction;
}

const inner = outerFunction(); // Execution Context for outerFunction is created and executed.
inner(); // Execution Context for innerFunction is created and executed.

When outerFunction is called, a new Functional Execution Context is created for it. Inside outerFunction, another function innerFunction is declared, which, when called, has its own execution context. The innerFunction has access to variables declared in its own scope (innerVar), the outerFunction's scope (outerVar), and the global scope (globalVar). This is made possible through the combination of Execution Contexts, Lexical Environments, and the Closure property that JavaScript functions exhibit.

The richness of JavaScript's execution model allows for complex, yet structured execution and scope management, with Closures and scopes being correctly managed through Execution Contexts and their associated Lexical Environments. Understanding how Execution Contexts work under the hood is fundamental to mastering JavaScript and unlocking its full potential.

Closure

A Closure occurs when a function is able to remember and access its lexical scope even when that function is executing outside its lexical scope. In simpler terms, a Closure gives you access to an outer function’s scope from an inner function. This is possible in JavaScript due to how Lexical Scoping works, allowing functions to maintain references to their surrounding Lexical Environment.

To understand Closures, it's important to process two key points:

Every function in JavaScript has access to the scope in which it was created (Lexical Scoping).
JavaScript functions are first-class objects, meaning they can be returned from other functions and passed around like any other value.

When a function returns another function, the returned function will maintain a reference to its original Lexical Environment (where it was created). This is what forms a closure. Despite being executed outside their original scope, functions that are returned from other functions can access the variables of their parent function's scope.

Example

Suppose you want to create a counter object that allows you to increment, decrement, and retrieve the current count value, but you want to keep the count value private and not directly accessible from outside the object. This is where Closures come into play, allowing us to encapsulate the count variable within the scope of a function while exposing specific functionalities.

function createCounter() {
    let count = 0; // `count` is a private variable

    return {
        increment: function() {
            count++;
            console.log(count);
        },
        decrement: function() {
            count--;
            console.log(count);
        },
        getCount: function() {
            console.log(count);
            return count;
        }
    };
}

// Using the createCounter function to create a counter instance
const counter = createCounter();

counter.increment(); // Output: 1
counter.increment(); // Output: 2
counter.decrement(); // Output: 1
counter.getCount(); // Output: 1

// Trying to access the private `count` variable directly
console.log(counter.count); // Output: undefined

When the createCounter function is invoked, a new Execution Context is created. Within this Execution Context, a Lexical Environment is established where the count variable resides. This Lexical Environment includes not just count, but also the inner functions increment, decrement, and getCount. The count variable is in the Lexical Scope of createCounter. This means it's not accessible from outside createCounter's Lexical Environment directly, thus maintaining its privacy.
The inner functions (increment, decrement, getCount) each form a closure. A closure is formed when a function (defined within another function) keeps a reference to its parent's Lexical Environment, even after the parent function has completed execution. This is possible because, in JavaScript, functions carry a "backpack" (the closure) that contains references to variables present in their Lexical Environment at the time they were created. So, even though the Execution Context of createCounter is removed from the execution stack after it finishes executing, the count variable remains accessible to increment, decrement, and getCount because of their Closures over the Lexical Environment of createCounter.
The returned object from createCounter exposes only the increment, decrement, and getCount methods, without directly exposing the count variable itself. This method of encapsulation ensures that count can only be modified or accessed through the interfaces provided, adhering to principles of data privacy and encapsulation. This structure is determined by the Lexical Scope at the time of the function's definition, which dictates what variables are accessible within the function's body.

`this` Keyword

The this keyword in JavaScript is a powerful concept that refers to the object it belongs to, providing a way to give methods access to their owning object. Its value is determined by how a function is called.

`this` in the Global Scope

In the Global Scope, this refers to the global object. In a browser environment, the global object is window, whereas in Node.js, it is global.

console.log(this === window); // Output: true (in a browser environment)

`this` in Function Calls

The value of this inside a function depends on how the function is called:

Regular function call: In the Global Scope, this will point to the global object (e.g., window in browsers). However, in strict mode, this will be undefined since strict mode prevents automatic binding to the global object.

function show() {
  console.log(this); 
}
show(); // Output: Window (in a browser environment)

Method call: When a function is called as a method of an object, this points to the object the method is called on.

const person = {
  name: 'Anton',
  greet() {
    console.log(`Hi, ${this.name}`);
  }
};

// `this` refers to the `person` object
person.greet(); // Output: "Hi, Anton"

`this` with Arrow Functions

Arrow functions do not have their own this binding. Instead, they capture the this value of the enclosing Lexical Scope. This behavior makes them particularly useful for callbacks.

const person = {
  name: 'Antonio',
  timer() {
    setTimeout(() => {
      console.log(this.name);
    }, 1000);
  }
};

person.timer(); // Output: "Antonio" (after 1 second)

In the above example, the arrow function inside setTimeout captures the this value from its surrounding Lexical Environment (in this case, the person object), illustrating how Lexical Scope influences the value of this.

Manipulating `this` with `bind()`, `call()`, and `apply()`

JavaScript provides methods to explicitly set the value of this for a function:

call(): Calls the function with a given this value and arguments provided individually.

function introduce(language) {
  console.log(`I am ${this.name} and I love ${language}.`);
}

const user = { name: 'Anthony' };
// I am Anthony and I love JavaScript.
introduce.call(user, 'JavaScript');

apply(): Similar to call(), but arguments are passed as an array.

// I am Anthony and I love JavaScript.
introduce.apply(user, ['JavaScript']);

bind(): Creates a new function that, when called, has its this keyword set to the provided value, with a given sequence of arguments preceding any provided when the new function is called.

const boundIntroduce = introduce.bind(user);
// I am Anthony and I love JavaScript.
boundIntroduce('JavaScript').

These methods are particularly useful for controlling the Execution Context.

Hoisting of Variables, Functions, Classes, Types, Interfaces in JavaScript/TypeScript

Anton Zamay — Sun, 17 Mar 2024 17:32:18 +0000

In the world of JavaScript, understanding the concept of hoisting can significantly improve the way you write and debug your code. Hoisting is one of those interesting behaviors of JavaScript that can sometimes lead to unexpected results, especially for those new to the language. In this article, we'll explore what hoisting is, how it works, and look at some examples to get a clearer picture.

Variable Hoisting

Variable hoisting is a JavaScript mechanism where variable declarations are moved to the top of their containing scope before the code has been executed. This means that no matter where variables are declared, they are moved to the top of their scope by the JavaScript interpreter.

Importantly, only the declarations are hoisted, not the initializations. This distinction is crucial for understanding some of the puzzling behavior that can arise.

To illustrate how variable hoisting works, let's look at a few examples.

Example 1: Basic Variable Hoisting

console.log(myVar); // Output: undefined
var myVar = 5;

In this example, you might expect a ReferenceError since myVar is printed before it's declared. However, due to hoisting, the JavaScript interpreter sees the code as follows:

var myVar;
console.log(myVar); // Output: undefined
myVar = 5;

Example 2: let and const Hoisting

The introduction of let and const in ES6 has somewhat altered the landscape of hoisting. Unlike var, which is hoisted to the top of its scope, let and const are hoisted to the top of their block scope but are not initialized, leading to what is called a "Temporal Dead Zone" (TDZ).

console.log(myLetVar); // ReferenceError: Cannot access 'myLetVar' before initialization
let myLetVar = 3;

In this scenario, myLetVar is hoisted, but trying to access it before declaration results in a ReferenceError.

Example 3: Re-declaring Variables with var

var myVar = 1;
console.log(myVar); // Output: 1

var myVar = 2;
console.log(myVar); // Output: 2

In this example, despite myVar being declared twice, JavaScript's hoisting mechanism processes and consolidates the declarations at the top of their scope. The reassignment of myVar to 2 happens after the initial assignment, leading to the final value of 2 being logged. Below is how the JavaScript engine interprets the code as if it's written like this:

var myVar;
myVar = 1;
console.log(myVar);

myVar = 2;
console.log(myVar);

Function Hoisting

In JavaScript, functions are subject to hoisting much like variables are. However, how function hoisting works depends on how the function is declared.

Example 4: Function Declaration Hoisting

Function declarations are fully hoisted. This means that the entire body of the function, along with its declaration, is hoisted to the top of its scope. Here's how it works:

console.log(myFunc()); // Output: "Some text!"

function myFunc() {
  return "Some text!";
}

Example 5: Function Expression Hoisting

Function expressions behave differently. If a function is assigned to a variable, the variable declaration is hoisted but not the assignment. This distinction is crucial for understanding how different function declaration methods behave regarding hoisting.

Consider this example using a function expression with var:

console.log(myFunc); // Output: undefined
console.log(myFunc()); // TypeError: myFunc is not a function

var myFunc = function() {
  return "Some text!";
};

Here, the variable myFunc is hoisted to the top of its scope, meaning it exists and is undefined when we try to log it or call it. This results in a TypeError when attempting to invoke myFunc as a function before the function expression is assigned to it.

For function expressions using let or const, an attempt to use them before declaration will lead to a ReferenceError because let and const declarations are in a TDZ as described earlier.

Class Hoisting

Classes in JavaScript exhibit the same hoisting behavior to variables declared with let and const. When you declare a class, its declaration is hoisted to the top of its enclosing scope, much like let and const. However, just as let and const declarations are not initialized until the JavaScript engine executes their declaration line, classes too are not initialized until the engine evaluates their declaration. This also results in a TDZ, meaning any attempts to access the class before its declaration will result in a ReferenceError. So, dealing with inheritance, static methods, and other object-oriented programming constructs, ensure that base classes are defined before derived classes try to extend them, respecting the TDZ.

Type Alias & Interface "Hoisting" in TypeScript

TypeScript's type aliases and interfaces are purely a design-time construct, meaning they are used by the TypeScript compiler for type checking and are erased when the TypeScript code is compiled to JavaScript. So, the concept of hoisting doesn’t really apply to type aliases or interfaces because they do not exist in the compiled output and, therefore, have no impact on the runtime behavior of the code.

For example:

let myVar: MyType = { key: "value" };

type Animal = {
    key: string;
};

In the code above, even though the MyType type is used before its declaration, TypeScript does not throw an error. This is because, from the perspective of the TypeScript type checking system, all type declarations are considered to be known ahead of any value-space code execution or evaluation. This isn't hoisting in the traditional JavaScript sense, but rather a feature of TypeScript's static analysis that all type declarations are globally known to the compiler before any code execution.

Tricky Tasks

Task 1.

var myVar = 1;

var myFunc = function() {
    console.log(myVar); // Output: ?

    var myVar = 2; 

    console.log(myVar); // Output: ?
}

myFunc();

Task 2.

function myFunc() {
    return 1;
}
console.log(myFunc()); // Output: ?

function myFunc() {
    return 2;
}
console.log(myFunc()); // Output: ?

Task 3.

(function() {
    try {
        throw new Error();
    } catch (x) {
        var x = 1, y = 2;
        console.log(x); // Output: ?
    }
    console.log(x); // Output: ?
    console.log(y); // Output: ?
})();

Solutions

Task 1.

When myFunc is invoked, JavaScript hoists the declaration of myVar to the top of the function scope. This means the code inside myFunc behaves as if it was written like this:

var myVar = undefined;

console.log(myVar); // Output: undefined

myVar = 2;

console.log(myVar); // Output: 2

Therefore, the first console.log(myVar) outputs undefined because the declaration (but not the initialization) of myVar is hoisted to the top of the function scope, overshadowing the myVar declared outside the function scope.
After myVar is assigned the value of 2 within the function, the second console.log(myVar) outputs 2.

Task 2.

Both function declarations are hoisted to the top of their scope. However, the second declaration of myFunc overwrites the first. This is because in JavaScript, function declarations are hoisted above variable declarations and are processed before the code begins to run.
Therefore, regardless of where the functions are declared, the version of myFunc that finally resides in memory after hoisting and interpretation is the one that returns 2.
Both console.log(myFunc()); calls will output 2, because that's the version of myFunc being used after hoisting and overwriting.

Task 3.

In the catch block, variables myVar1 and myVar2 are declared. Since var declarations are function-scoped (not block-scoped like let or const), both myVar1 and myVar2 are hoisted to the top of their enclosing function.
Therefore, console.log(myVar1); within the catch block outputs 1.
Outside the catch block but inside the self-invoking function, both myVar1 and myVar2 are accessible due to hoisting, and since they were assigned values in the catch block, their values are preserved outside of the catch block.
console.log(myVar1); outside the catch block also outputs 1.
Similarly, console.log(myVar2); outputs 2.

Using the Singleton Pattern in React

Anton Zamay — Mon, 04 Mar 2024 20:11:56 +0000

The singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance. This is useful when exactly one object is needed to coordinate actions across the system. The singleton pattern is often used in situations where system-wide actions need to be coordinated from a single central place. Examples include a database connection pool or a logger that needs to be accessible by different parts of an application without necessarily creating new instances.

Implementation in TypeScript

Here’s how you could implement a simple singleton pattern in TypeScript:

class Singleton {
    // Hold a reference to the single created instance
    // of the Singleton, initially set to null.
    private static instance: Singleton | null = null;

    // Make the constructor private to block instantiation
    // outside of the class.
    private constructor() {
        // initialization code
    }

    // Provide a static method that allows access
    // to the single instance.
    public static getInstance(): Singleton {
        // Check if an instance already exists.
        // If not, create one.
        if (this.instance === null) {
            this.instance = new Singleton();
        }
        // Return the instance.
        return this.instance;
    }

    // Example method to show functionality.
    public someMethod() {
        return "Doing something...";
    }
}

Eager Instantiation

In the example above, the singleton instance is created the first time it is needed (lazily instantiated). However, sometimes you need to immediately initialize instance. For example, when initialization is asynchronous and takes a certain time. This can be done by instantiating the Singleton instance directly in the declaration.

class Singleton {
    private static instance: Singleton = new Singleton();

    private constructor() {}

    public static getInstance(): Singleton {
        return this.instance;
    }
}

Avoid Using the Singleton Pattern in React

Almost always you need to avoid using the singleton pattern in React and other frameworks from several key considerations:

Global State Management Concerns: Singletons represent a way to create a global state since they ensure there's only one instance of an object throughout the application. However, managing global state through Singletons can lead to difficulties in tracking changes and debugging, as any part of the application can modify the state at any point. This unpredictability contrasts with the unidirectional data flow and component-based state management that React encourages.
Mutation and Side Effects: The mutable nature of singleton instances introduces the risk of accidental state modifications, leading to unreliable state management. React favors immutability and pure functions, as seen with Redux's reducer functions, which ensure predictability and facilitate debugging by avoiding side effects.
Design and Scalability: Utilizing singletons for state management can encourage a monolithic design that hampers modularity and scalability. React favors a more decentralized approach to state management, allowing individual components to manage their own state or utilizing context and state management libraries to handle shared state in a controlled manner. This approach supports more scalable and reusable code.
Global Scope Pollution: The singleton pattern contributes to the broader issue of global scope pollution, where global variables or instances can conflict with each other or be inadvertently modified.

But There Is a Good Use Case...

One practical application of the singleton pattern within React might be through the implementation of a singleton context. This strategy ensures that once the context is initiated, redundant instantiation within nested components is avoided. Such an approach is especially beneficial for overarching functionalities like setting a universal theme (but not only for theme, write your suggestions and thoughts it in the comments if anyone reads this post). Simplified example:

import React, {
  createContext,
  useContext,
  ReactNode,
  Dispatch,
  SetStateAction
} from 'react';

interface ThemeColors {
  primary: string;
  secondary: string;
  background: string;
  text: string;
}

interface Theme {
  colors: ThemeColors;
  provided: boolean;
}

const DEFAULT_THEME: Theme = {
  colors: {
    primary: '#007bff',
    secondary: '#6c757d',
    background: '#ffffff',
    text: '#212529',
  },
  provided: false,
};

type ThemeContextType = [Theme, Dispatch<SetStateAction<Theme>>];


// When using React's Context, you'll also need to provide
// the type for the updater function if you plan to include it.
const ThemeContext = createContext<ThemeContextType>([
  DEFAULT_THEME, 
  () => null
]);

interface ThemeSingletonProviderProps {
  children: ReactNode;
}

export function ThemeSingletonProvider (
  { children }: ThemeSingletonProviderProps
) {
  const [theme, setTheme] = useContext(ThemeContext);

  if (!theme.provided) {
    return (
      <ThemeContext.Provider
        value={[{ ...theme, provided: true }, setTheme]}
      >
        {children}
      </ThemeContext.Provider>
    );
  }

  return <>{children}</>;
};

What Are the Actual Advantages?

Modular or Micro-Frontend Architecture: In large-scale, modular applications, or those adopting a micro-frontend architecture, different parts of the application may be developed, built, and deployed independently. In such a setup ThemeSingletonProvider ensures that all parts of the application, regardless of how they are loaded or what lifecycle stage they are in, use the same theme configuration.
Handling External Theme Resources: When the theme involves more than just CSS variables, such as loading external resources (fonts, icons specific to the theme), ThemeSingletonProvider can include logic to ensure that theme-related resources are loaded only once and efficiently manage changes.

Forem: Anton Zamay

11-20 Сustom Utility Types for TypeScript Projects

TOC

NonNullableDeep

Merge

TupleToObject

ExclusiveTuple

PromiseType

OmitMethods

FunctionArguments

Promisify

ConstrainedFunction

UnionResolver

Approaches to Styling React Components, Best Use Cases

TOC

Inline Styling

Description

Example

Advantages

Disadvantages

Best Use Cases

Normal CSS

Description

Example

Extending to SCSS

Advantages

Disadvantages

Best Use Cases

CSS-in-JS

Description

Example

Extending to Adopt TypeScript

Advantages

Disadvantages

Best Use Cases

CSS Modules

Description

Example

Advantages

Advantages

Best Use Cases

Implementing JavaScript Concepts from Scratch

TOC

memoize()

Task Description

Implementation

Key Aspects of the Implementation

Array.map()

Task Description

Key Aspects of the Implementation

Implementation

Array.filter()

Task Description

Key Aspects of the Implementation

Implementation

Array.reduce()

Task Description

Key Aspects of the Implementation

Implementation

bind()

Task Description

Implementation

Key Aspects of the Implementation

Example of Using bind() with new

call(), apply()

Task Description

Implementation

Key Aspects of the Implementation

setInterval()

Task Description

Implementation

Key Aspects of the Implementation

cloneDeep()

Task Description

Implementation

Key Aspects of the Implementation

debounce()

Task Description

Key Aspects of the Implementation

throttle()

`NonNullableDeep`

`Merge`

`TupleToObject`

`ExclusiveTuple`

`PromiseType`

`OmitMethods`

`FunctionArguments`

`Promisify`

`ConstrainedFunction`

`UnionResolver`

`memoize()`

`Array.map()`

`Array.filter()`

`Array.reduce()`

`bind()`

Example of Using `bind()` with `new`

`call()`, `apply()`

`setInterval()`

`cloneDeep()`

`debounce()`

`throttle()`

`Promise`

`constructor` Implementation

Key Aspects of the `constructor` Implementation

`.then` Implementation

Key Aspects of the `.then` Implementation

`catch` and `finally` Implementation

Key Aspects of the `.catch` Implementation:

Key Aspects of the `.finally` Implementation:

`EventEmitter`

Key Aspects of the `EventEmitter` Implementation

`this` Keyword

`this` in the Global Scope

`this` in Function Calls

`this` with Arrow Functions

Manipulating `this` with `bind()`, `call()`, and `apply()`