Forem: Viktor Shcheglov

How To Use Chrome UX Report To Improve Your Site Performance

Viktor Shcheglov — Mon, 12 Aug 2024 16:38:02 +0000

Avoid turning off potential site visitors. Take advantage of the Chrome UX Reports to ensure your site's peak performance with this guide.

Measuring success in website performance is a tricky task for small business owners.

It can be easy to apply the same approach that works when evaluating viability throughout a company.

Black and white, hard and fast numbers. Results.

The truth of website performance is more of a multilayered exploration of RUM (Real User Measurements) within the context of the web at large.

Looking at RUM such as performance, page load, and page views gives a detailed picture of hard data.

However, RUM data is only part of a bigger equation to measure a website’s impact and success.

The CrUX Of The Matter: The State Of The Web As Experienced By Real Users
To be truly informative and deliver actionable data, you must balance users’ experiences on your site within the scope of user experience across the internet.

Stepping back lets businesses understand their site’s performance and know where those metrics land within a vast array of parameters.

This is where the Chrome UX Report enters the fray.

Making Web Performance Data On A Broad Scale Accessible To The Masses
First established by Google in 2017, the Chrome UX Report is a publicly available dataset of real user measurements.

Also known as the CrUX report, it gathers website performance data for Chrome users from millions of websites.

If that data were only compiled, it would be an incredible – but difficult to utilize – resource. When paired with the right program, however, the data is transformed.

When put to use correctly, the CrUX Report transforms an immense collection of web performance data into a clear and accessible resource.

To better understand the data compiled in the CrUX Report and how best to utilize it, we need to step back.

It’s time to review Chrome’s Core Web Vitals.

Page Experience And User Experience Are A Direct Result Of The Health Of A Website
Google is always seeking innovative and cutting-edge ways to provide users with a smooth, crisp online experience.

A significant cornerstone of that effort is Google’s work empowering website owners to maximize their sites.

When website owners deliver user-friendly, beneficial sites effectively, everyone wins.

The only way to achieve success in an endeavor, though, is to know what the rules and standards are.

In May 2020, Google released a new set of metrics to help evaluate website performance as it impacted user experience.

These were its Core Web Vitals.

The goal was to clear away minor and arbitrary details muddying up the water.

To do so, Google narrowed down a website’s user experience score to three core measurements:

LCP (Largest Contentful Paint).
FID (First Input Delay).
CLS (Cumulative Layout Shift).
Core Web Vitals are anchored on the crucial role of page experience in the more extensive user experience.

How does Google define page experience?

For its purposes, page experience measures how users perceive their experience interacting with an individual web page.

Building off of that, they define CWV as:

“A set of real-world, user-centered metrics that quantify key aspects of the user experience. They measure dimensions of web usability such as load time, interactivity, and the stability of content as it loads.”

When merged, the three elements of Core Web Vitals – LCP, FID, and CLS – deliver powerful insight.

As a whole, CWV results provide a precise picture of a user’s page experience on an individual website.

This page experience ultimately defines their user experience as a whole when utilizing the Google search engine.

A year after the initial announcement, it was made permanent.

Google finalized the integration of the new metrics with the permanent inclusion of Core Web Vitals into its algorithm.

Core Web Vitals zero in on website speed, responsiveness, and visual stability. However, it should be noted that they are part of a vast picture.

The Google search algorithm is always evolving, a challenge that demands vigilance on the part of professional SEO operators.

There were once reportedly more than 200 ranking factors.

Nowadays, some are weighted far more heavily and studied throughout the industry.

These factors continue to evolve as Google adapts to new data and user behavior.

The best practice is to review its ranking factors on a year-to-year basis.

Breaking Down The Google Search Algorithm
Despite the blanket of lore that has covered it over the years, the Google search algorithm has a definitive foundation.

It is anchored by the company’s commitment to ensuring a smooth and efficient search experience for all users.

Google continuously molds its search algorithm year-round to best meet the present and future demands of the global population.

The Google search algorithm focuses on a litany of factors that perpetually fluctuates.

In response, the SEO industry has consistently honed in on the key elements to focus on every year.

Knowing where to prioritize your focus when designing your website empowers you to achieve an optimal presence in the rankings.

These can include, but are not limited to:

Send messages to the client in real time using NodeJS and Server-Sent Events

Viktor Shcheglov — Thu, 01 Aug 2024 10:13:10 +0000

Overview
Server-Sent Events(SSE) technology, which allows sending information from server to client in real time, is based on HTTP protocol.

On the client side server-sent events API provides EventSource interface (part of HTML5 standard), through which a persistent connection to HTTP server is opened.

The HTTP server sends events in text/event-stream format. The connection remains open until the EventSource.close() method is called.

Limitations:

Only receiving data from the server is possible (unidirectional data stream, unlike WebSockets);
Data can only be transmitted in UTF-8 format (non-binary data).
Possible advantages:

Works over HTTP, which means that clients will not have connection problems when connected via proxies that do not support other connections (such as WebSockets);
If the connection is established via HTTPS, SSE traffic is protected by encryption.
Browser support: https://caniuse.com/eventsource.

In this paper, we will develop a Todo List application that allows users to add, delete, mark as completed tasks in a list.

Note, the state of the list using Server-sent Events will be shared by all users:

Manifest Web Performance: Balancing JavaScript, Rendering Techniques, and Hardware Considerations

Viktor Shcheglov — Sun, 12 May 2024 16:15:19 +0000

Creating an interactive web interface often involves sending a large amount of JavaScript code to users, which affects performance.
It's important to balance the use of JavaScript to ensure fast loading while maintaining high quality user interactions.
There is a trend towards "zero JavaScript use", emphasizing reliance on default browser capabilities.
Various rendering models have emerged, such as server-side rendering (SSR), island architecture, and partial hydration.
SSR generates the full HTML code on the server, eliminating the need to send JavaScript to the client, but this can delay the interactivity of single-page applications.
Progressive hydration selectively loads and displays components to enhance performance.
Optimizing JavaScript bundles can increase loading speed, reduce memory usage, and lower CPU costs.
The runtime performance of JavaScript is critical, but the costs of syntactic parsing and compilation are less important.
It's important to consider hardware optimization, CPU performance, thermal regulation, cache size, and energy consumption constraints on various devices.
Network latency and bandwidth also affect website performance.
Understanding the real cost of JavaScript and optimizing for hardware and network conditions can significantly enhance website performance.
The cumulative effect of frameworks, libraries, UI components, third-party code, trackers, and analytics, known as the "JavaScript utility tax", can significantly impact performance.
The goal is to provide users with a fast, interactive interface as quickly as possible.
Strategies for enhancing web application performance include dynamic component imports, bundle splitting, route-based and component-based code splitting, and import-on-view.
Various approaches to rendering and hydration include island architecture, progressive hydration, renewable hydration, server components in React, server-side streaming rendering, and selective hydration.
I emphasized the importance of performance budgets and testing on real devices.
I recommend a free book on performance patterns available at patterns.dev.

Frontend Fundamentals: Top 10 Interview Questions and In-Depth Answers for Every Developer

Viktor Shcheglov — Fri, 12 Apr 2024 17:02:53 +0000

Coding Interview Questions

These are some questions that can be asked in coding interviews to assess a developer's skill level and ability to solve practical problems.

1. Preventing Concurrent Editing of Articles

Question:

Suppose you are implementing a journal editing system where editors can edit articles in the admin panel. How would you prevent two editors from simultaneously editing the same article and overwriting each other's changes?

Answer

Use optimistic locking or pessimistic locking mechanisms to ensure that only one editor can modify an article at a time.

2. Principles of Zero Downtime Deployment

Question:

What are the principles of zero downtime deployment, an approach that deploys an application without service downtime? How is this achieved?

Answer

Key principles of zero downtime deployment include:

Blue-green deployment: Use two identical production environments, swapping between them during deployment.
Feature flagging: Gradually roll out new features by controlling their visibility with feature flags.
Canary releasing: Deploy new code to a small subset of users first, monitoring for issues before wider rollout.

3. Criticisms of Your Preferred Framework

Question:

Name aspects of your preferred framework that you dislike or that don't work the way you'd like. Explain how and where these issues arise and how they could be improved.

Answer
Be honest about the limitations of your chosen framework, providing specific examples and suggestions for improvement.

4. Handling Long-Running Cron Jobs

Question:

What could happen if your cron job, which runs every minute, starts taking more than one minute to execute? How can this be prevented?

Answer
Potential issues include missed executions and cascading failures. Consider breaking down the task into smaller chunks, optimizing code, or using a queueing system.

5. Denormalizing Data in Databases

Question:

Have you ever encountered the need to denormalize data in a database? If so, what problem were you trying to solve, what challenges did you face, and how could it have been done better?

Answer

Explain the specific situation where denormalization was necessary, the trade-offs involved, and potential alternatives.

6. Mocking External Calls in Tests

Question:

If you write tests, how do you circumvent the issue of external calls made by the code you're testing? Consider the scenario where external calls are prohibited on CI (continuous integration). Why is this a good practice?

Answer
Discuss techniques like mocking, stubbing, and dependency injection to isolate tests from external dependencies. Explain the benefits of avoiding external calls in CI environments.

7. Synchronizing Email Changes with External Systems

Question:

Suppose your system implements email change functionality. However, the email is also stored in an external system, such as a payment processor, which sends emails to users (but users don't directly interact with it). How would you implement email synchronization with the external system?

Answer

Outline a strategy for synchronizing email changes, considering options like polling, webhooks, or message queues.

8. Discovering Production Errors

Question:

How do you learn about errors that occur in production? Do you rely on user reports or have automated mechanisms in place?

Answer

Describe your approach to error monitoring and reporting, emphasizing the use of tools and techniques for proactive error detection and alerting.

9. Designing a Simple Chat Application

Question:

How would you design a simple chat application? You can ask the backend engineer about the backend part and the frontend engineer about the frontend part. There could be many branches in this conversation.

Answer
Break down the chat application into its components (backend, frontend, database) and explain the interaction and data flow between them.

10. Isolating Tests in a Multi-User Environment

Question:

How is test isolation ensured when multiple tests run concurrently and access the database, potentially modifying it? If your framework doesn't provide isolation, how would you implement or improve it?

Answer
Discuss mechanisms like transactions, rollbacks, or test databases to ensure data integrity and prevent conflicts during concurrent test execution.

Additional Tips:
Encourage the candidate to elaborate on their thought process and reasoning behind their answers.
Assess their problem-solving skills, ability to think critically, and knowledge of relevant technologies.
Gauge their communication and collaboration skills throughout the interview.

Resume Best Practices 2024 for Standing Out in the Job Market

Viktor Shcheglov — Thu, 14 Mar 2024 09:58:48 +0000

Delete these from your CV.

Marital status
Your high school and primary details if you have attended college (If you are an experienced candidate).
Your Religion.
Your hobbies. Nobody is going to shortlist your CV because you love traveling (unless it is a travel agent job).
Non-professional email addresses. Ensure that your email address is professional and appropriate for job applications.
Long paragraphs. Instead use bullet points to present information in a clear and concise manner.
Irrelevant work experience. Copy

Implementing a "Defer" Class in TypeScript

Viktor Shcheglov — Tue, 05 Mar 2024 07:35:35 +0000

When working with asynchronous operations in JavaScript and TypeScript, Promises are the heart and soul of managing those operations. However, there are cases where the traditional promise patterns such as .then() and async/await might not give you the level of control you require. In such cases, having a Defer class can provide a more flexible way to handle promises.

In this article, we'll explore how to implement a Defer class in TypeScript, which allows for manually controlling the resolution and rejection of a promise.

What is a Defer?

In some programming contexts, a "defer" refers to a construct used to put off an operation until later. In the realm of promises, a Defer class can be used to create a promise whose resolution or rejection can be controlled externally, giving the programmer greater control over asynchronous flows.

Implementing Defer in TypeScript

Let's dive into how we can implement such a class in TypeScript:

class Defer<T> {
    promise: Promise<T>;
    resolve: (value: T | PromiseLike<T>) => void;
    reject: (reason?: any) => void;

    constructor() {
        this.promise = new Promise<T>((resolve, reject) => {
            this.resolve = resolve;
            this.reject = reject;
        });
    }
}

In this implementation, Defer<T> is a generic class where T represents the type of value the promise will resolve with. The constructor of this class creates a new promise, storing the resolve and reject functions as class properties. This allows you to invoke these functions outside the initial promise constructor context, thereby controlling the promise's outcome manually.

Usage

Here is how you could use the Defer class:

const myDefer = new Defer<number>();
myDefer.promise.then(value => console.log(`Resolved value: ${value}`));

// Somewhere else in the code
myDefer.resolve(42);  // Outputs: Resolved value: 42

In this example, we create an instance of Defer<number>, meaning our promise will resolve with a number. We then add a .then() method to handle the resolution case. Since resolve and reject are controlled externally, we can call myDefer.resolve(42) anywhere in our code to resolve the promise.

Why Use a Defer?

While it's not common to need a Defer in everyday coding with promises, there are specific scenarios where it can be invaluable:

Complex asynchronous control flow: When dealing with multiple asynchronous sources that need to be synchronized in unconventional ways.
Testing and Mocking: **When testing, you might want to resolve or reject promises at specific times to simulate different scenarios.
**Advanced Resource Management: In cases where resources need to be initialized asynchronously and controlled explicitly.

Conclusion

While the need for a Defer class is not everyday, its availability can simplify complex asynchronous handling scenarios, making code cleaner and more understandable. Remember, with great power comes great responsibility: use it wisely and sparingly.

I hope this guide helps you understand how and when to implement a Defer class in your TypeScript projects. Happy coding!

Discover Defer in Practice

Interested in seeing Defer in real-world scenarios?

Video Walkthrough: Dive into a live demonstration where I showcase the Defer class's applications. https://www.youtube.com/watch?v=Gco9RBubWU8

In-depth Article: Prefer reading? Explore a detailed guide that expands on Defer's usage and benefits. https://dev.to/shcheglov/make-dialog-component-like-a-hero-24e3

Enhance your async handling skills with these resources!

links: https://github.com/shogogg/ts-deferred

Memory leak detection in modern frontend app

Viktor Shcheglov — Sun, 28 Jan 2024 11:32:58 +0000

One of the challenges when building a single-page application (SPA) like dev.to or an app where users have standart session more than 10 minutes, is testing for memory leaks at a large scale. Manual testing, finding and analyzing memory leaks can be time-consuming and inefficient, especially when there are a large number of changes being made continuously by a large team of developers.

This article demonstrate how to detect and automatically detect memory leaks in large applications, and how to avoid memory issues for a long period of time.

Catching users experiencing problems

Hi, dear developers. I've encountered a problem with freezing. Could you help me?

How does it happen that some users complain about everything freezing and slowing down, while everything works fine on our expensive and beautiful Macs?

The issue is that it can be challenging to replicate the problem without having access to the specific devices that your users log in from, and due to privacy settings, we may not be able to recreate the exact environment that the user experiencing the issue is in.

Fortunately, browsers provide us with technical data about devices and how much memory your site consumes or allocates for certain actions. There is an API for this information, which is called the "Performance: memory" property.

Solution: To write a small script that checks the performance of the system from time to time. If it detects that memory usage has exceeded a certain threshold, it can indicate that the user may be experiencing issues with RAM or a memory leak. In such a case, it is best to send all relevant technical metrics to assist in diagnosing and fixing the problem. Here is a small example:

// Memory usage threshold (e.g. 80% of jsHeapSizeLimit)
const threshold = performance.memory?.jsHeapSizeLimit * 0.8 

// Function for checking and sending memory data
function checkMemoryUsage(): void {
  if (!performance.memory) {
    console.warn('Performance.memory API is not available.');
    return;
  }

  const { usedJSHeapSize, jsHeapSizeLimit } = performance.memory;
  console.log(`Current memory usage: ${usedJSHeapSize} of ${jsHeapSizeLimit}`);

  if (usedJSHeapSize > threshold) {
    sendEvent(`Memory usage exceeded: ${usedJSHeapSize} exceeds threshold of ${threshold}`);
    sendSnapshot({
        device,
        userAgent,
        os,
        ...
    })
  }
}

setInterval(checkMemoryUsage, 10000)

NOTE: Please note that this API is not supported in all browsers and
has recently been marked as deprecated. Sounds like that replaced by measureUserAgentSpecificMemory

Here we send the userAgent, device as data (there may be a problem with the device itself), and of course i would recomend also send specific for you date as example: size of the store, number of DOM nodes and etc...

Catching on a dev stage with MemLab

We have figured out how to perfectly catch problems from real users, but this approach seems rather rash and dangerous for a large-scale enterprise project. It would be nice if our development team could highlight possible problems at the assembly or testing stages.

Fortunately, Facebook has a separate team that deals with performance and quality issues. So, they developed a special tool for detecting problems at the development stage and made it available as open-source - MemLab. Now, I'll talk more about it.

How it works

In short, Memlab finds memory leaks by running an offline browser according to predefined test scenarios, as well as by comparing and analyzing snapshots of the JavaScript heap.
This process takes place in six stages:

Browser interaction
Diffing the heap
Refining the list of memory leaks
Clustering retainer traces
Reporting the leaks

You can read about all these steps in detail in the official documentation.

Simply put, MemLab takes a snapshot of all the metrics every time and compares them to the standard, as shown in the image below:

After that, it generates a detailed report on all possible new problems, with detailed information about what was changed and how:

I would consider the disadvantages that this tool requires very careful configuration and description of all possible scenarios and screens, while if you believe the Facebook presentation, they were able to halve memory consumption and almost get rid of performance problems (crashes)

And this tool also allowed us to find a leak even in react.js

Conclusion

So, nowadays, we should still not forget about the cost of JavaScript and identifying performance issues. These can mean a lot and significantly affect a company's profits or costs.

So, for example, I once worked to speed up the customer support chat for a popular European bank. The average session time for agents was 5-6 hours without restarts, but due to lag in the interface, the average user response time was around 140 seconds. After implementing two tools and fixing problems identified, both support agents and users were incredibly happy, as response time had dropped by almost half to 80 seconds. Agents themselves told me that it was nice when everything worked smoothly and quickly (I think this was because their salary depended on it too, haha).

Good luck and speed to your projects, and no MEMORY LEAKS anymore!

Mastering Modal Dialogs in React Like a Pro

Viktor Shcheglov — Thu, 25 Jan 2024 10:29:34 +0000

Modals, dialogs, popups, snackbars, notification, alert, confirm and etc…

It's hard to imagine modern React Application without pop-up dialogs for confirming addresses, deleting items from a cart, and other such interactions — challenges every developer faces daily.

The design and management architecture of these dialogs often raise numerous questions. I've encountered everything from complex integration schemes with stores to extensive prop drilling for opening windows, and intricate setups using event emitters. It's time to tackle these issues head-on.

In this article, I'll share the solution our team has developed, which significantly aids us in maintaining clean code daily, even as our project scales.

Problem

Let's take a look at this typical example of how developers usually display modals:

№1: Boilerplate
Managing dialog in app often involves creating several state variables to control their opening and closing. A typical setup for a component might start with several lines of code like this:

const [openConfirm, setOpenConfirm] = useState(false);
  const [deleteDialogOpened, setDeleteDialog] = useState(false);
  const [editDialogOpened, setEditDialog] = useState(false);
  const [moveOnDialogOpened, setMoveOnDialog] = useState(false);

Does this code look familiar?

Can you imagine the complexity involved in rendering this component, where hundreds of lines of code in JSX track how and when these dialogs open? Managing several dialog windows in this way not only clutters the components but also increases the risk of bugs, as the state of each dialog is intertwined with the overall logic of the component.

№2: Performance

Imagine you have a table where every cell has its own set of dialog boxes for management tasks. If you put the dialog control logic right inside each cell's component, React ends up doing a lot of work. For every update, it has to check through hundreds of these virtual parts to figure out which dialog boxes to show or hide. This can slow things down because React has to keep comparing all these parts every time something changes. It makes your code more complex and harder to deal with, too.

Moving dialogs to a parent level seems straightforward, but the main issue was this:prop drilling. Ultimately, you end up having to pass data through many layers to reach the dialog windows, which complicates matters. It's like unraveling a knot that only gets tighter the more you pull on it.

№3: Package size

In large projects with numerous dialogs, a problem arises: many dialogs are loaded but never used by some users. Without code splitting, other forms of preloading/caching, or similar strategies, the application can become sluggish, loading unnecessary items.

Solution

We often see two main types of dialogs in apps. First, there are the common ones, used about 90% of the time, like confirmation messages, map location pickers, ads, or subscription offers.

These dialogs pop up frequently, look similar, and aren't tied to any specific part of the app. Then, there's the other 10%: specialized dialogs made for one-time events or specific actions. By figuring out which dialogs are used most and which are for special occasions, we can make managing and loading them much easier.

The Solution — Modal Manager

💡 My idea is to create a single entry point for all dialogs, allowing us to manage them as conveniently as we do routes in React applications. This means we will describe their behavior strategy, share data, and invoke them using hooks and React context. By leveraging Suspense, we can ensure that these dialogs are not loaded unnecessarily. This approach streamlines dialog management, making it more efficient and less prone to performance issues. By centralizing dialog control, we can easily adjust their behavior and appearance across the entire application, improving consistency and user experience. Additionally, using Suspense for lazy loading helps keep our app lightweight, loading resources only when they are truly needed.

Let’s do it:

import { lazy } from 'react'

export enum Modals {
  ConfirmModal,
  SubscriptionModal,
}

export const DialogManager = {
  [Modals.ConfirmModal]: lazy(() => import('./modals/ConfirmModal')),
  [Modals.SubscriptionModal]: lazy(
    () => import('@components/common/Subscriptions')
  ),
}

The DialogManager - just a simple hashmap, where each dialog is associated with a unique key and contain a lazy component of the dialog.

Provider

type DialogStructure = {
  id: string
  component: () => JSX.Element
}

export type DialogCloseHandler<T = boolean> = {
  onCloseHandler?: (value?: T) => T
} 

const useDialogProvider = () => {
  const [activeDialogs, setActiveDialogs] = useState<Array<DialogStructure>>([])

  const close = useCallback(
    (id: string, value?: unknown) => {
      setActiveDialogs(activeDialogs.filter(dialog => dialog.id !== id))

      return value
    },
    [activeDialogs]
  )

  const open = useCallback(
    <T extends Modals>(
      type: T,
      props: Omit<ComponentProps<(typeof dialogManager)[T]>, 'onCloseHandler'>
    ) => {
      const id = nanoid()
      const Component = dialogManager[type as Modals]

      setActiveDialogs([
        {
          id,
          component: () => (
            <Component {...props} onCloseHandler={value => close(id, value)} />
          ),
        },
        ...activeDialogs,
      ])

      return null
    },
    [activeDialogs, close]
  )

  return useMemo(
    () => ({ open, close, activeDialogs }),
    [open, close, activeDialogs]
  )
}

export const DialogContext = createContext<
  ReturnType<typeof useDialogProvider> | undefined
>(undefined)

Let's break down our magic in more detail:

Let's delve deeper into our methodology:

In the activeDialogs state, we accumulate our dialogs. This is an array because we anticipate that multiple dialogs might be called one after another.
useDialogProvider is what's passed as a value to our DialogContext. It's crucial that it returns both an opening function and a closing function, as well as a list of all dialogs.
The open function is generic, thanks to , it knows the props our dialog accepts. This will be incredibly useful for invoking our dialogs in the future.
close - simply deletes our component from activeDialogs
onCloseHandler is one of the key tricks of our architecture. The only thing our manager-created dialog needs to know is how to close itself. There are numerous ways to teach it this, but the simplest method seems to be incorporating a callback into each of the dialogs invoked by our system that can perform this action.

Context and part

Now, let's focus on our context setup:

export const DialogProvider: FC<PropsWithChildren> = ({ children }) => {
  const value = useDialogProvider()

  return (
    <DialogContext.Provider value={value}>
      {children}
      {typeof window !== 'undefined' && value.activeDialogs.length ? (
        <Suspense fallback={null}>
          {value.activeDialogs.map(({ id, component: LazyDialog }) => (
            <LazyDialog key={id} />
          ))}
        </Suspense>
      ) : null}
    </DialogContext.Provider>
  )
}

Remember how we opted for lazy wrapping for our dialogs within the manager to facilitate on-demand loading? By incorporating Suspense in our provider, we streamline this process even further. Now, iterating through any open dialogs in our provider becomes straightforward, ensuring that dialogs are loaded efficiently and only when necessary, enhancing the overall performance and user experience of our application.

Hook useDialog

This is the final piece of our entire splendid structure. Now, we need to learn how to conveniently invoke our dialogs from anywhere within our application. I suggest doing this with the useDialog hook, as all the necessary functionality for it is already in place:

export const useDialog = () => {
  const context = useContext(DialogContext)

  if (context === undefined) {
    throw new Error('useDialog() called outside of DialogProvider')
  }

  return context
}

That's it. Now, in any component, we can simply call:

const {open} = useDialog()

return (
  <button onClick={() => open(Modals.subscription, { onConfirm: () => location.reload() })}>Buy subscription</button>

After we use Modals.Subscription, our TS and IDE will help us correctly identify the missing props. Therefore, we've added an onConfirm callback because that's what our subscription dialog component requires.

Final

In essence, this is what we've achieved:

A Clearly Defined Dialog Structure: All popular or frequently used popups are extracted and described in a special manager. If you prefer not to use this approach for some dialogs, you can still do it the old way, and everything will work just fine.
Asynchronous Code: We load our code as needed using lazy loading and Suspense, making our application lighter and faster.
No More Boilerplate: Managing the state of our dialogs is now encapsulated within the useDialog hook and can be expanded according to the needs of your application.

With these improvements, our application benefits from a more organized, efficient, and scalable dialog management system. This structure not only enhances performance but also simplifies development and maintenance, providing a clear path forward for incorporating dialog windows in a React application.

useRequest: Create a Basic Declarative React hook for Managing API Requests as an Alternative to useQuery

Viktor Shcheglov — Sat, 20 Jan 2024 09:15:24 +0000

In the world of React, managing API requests and their state can be a complex task. Libraries like react-query have provided robust solutions, but sometimes, you might need something simpler and more controllable. This is where a custom hook, useRequest, comes into play. This article will guide you through creating useRequest - a straightforward, declarative hook for handling API requests without the advanced features of react-query, making it a lighter and more straightforward alternative.

What is useRequest?

useRequest is a custom React hook designed to fetch data from an API and manage its state within a component. It's built using React's basic hooks - useState, useEffect, and useCallback. The goal is to provide a simple way to make API requests, track loading states, handle errors, and cache responses with minimal setup.

Why useRequest?

While react-query is powerful, it can be overkill for simple projects or when you need more direct control over request handling. useRequest:

Simplifies state management for API requests.
Provides built-in loading and error states.
Offers basic caching capabilities.
Is easy to integrate and use in small to medium-sized projects.
Building the useRequest Hook:

1. Setup and State Management:

Start by setting up the hook structure using useState to manage the data, error, and loading states.

const useRequest = (queryFn, { queryKey } = {}) => {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);
  const [isLoading, setIsLoading] = useState(false);

  // Rest of the logic will go here
};

2. Fetching Data:

Use useEffect and useCallback to fetch data from the API. useCallback ensures that the function doesn't get recreated unless necessary.

const fetchData = useCallback(async () => {
  setIsLoading(true);
  try {
    const result = await queryFn();
    setData(result);
  } catch (err) {
    setError(err);
  } finally {
    setIsLoading(false);
  }
}, [queryFn, queryKey]);

useEffect(() => {
  fetchData();
}, [fetchData]);

3. Caching Mechanism:

Implement a basic caching mechanism to store and retrieve responses using a global object.

const cache = {};

// Inside fetchData
if (cache[queryKey]) {
  setData(cache[queryKey]);
  return;
}
// Save to cache after fetching
cache[queryKey] = result;

4. Adding Cache Control:

Provide functions to clear specific cache entries or the entire cache.

const clearCache = useCallback(() => { /*...*/ }, [queryKey]);
const clearAllCache = useCallback(() => { /*...*/ }, []);

5. Return from the Hook:

Finally, return the data, loading state, error, and cache control functions from the hook.

*Usage Example: *

Demonstrate how to use useRequest in a component, including fetching data, displaying it, and handling loading and error states.

const MyComponent = () => {
  const { data, error, isLoading, refetch } = useRequest(fetchMyData, { queryKey: 'myData' });

  // Render your component based on the data, loading, and error states
};

Bonus: Adding Type Safety to useRequest with TypeScript

For developers using TypeScript, adding type safety to your useRequest hook enhances its reliability and the overall developer experience. TypeScript's generics allow you to define the type of data your API request will return, ensuring type correctness throughout your component.

To add type safety to useRequest, modify the hook to accept a generic type parameter. This parameter will represent the type of data expected from the API:

const useRequest = <T,>(queryFn: () => Promise<T>, { queryKey } = {}): UseRequestReturn<T> => {
  const [data, setData] = useState<T | null>(null);
  const [error, setError] = useState<Error | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  // ... rest of the hook implementation
};

Define a return type for the hook that includes the generic type T:

type UseRequestReturn<T> = {
  data: T | null;
  error: Error | null;
  isLoading: boolean;
  refetch: () => void;
};

Now, when you use the useRequest hook in your components, you can specify the type of data you expect.

Conclusion:

useRequest provides a simpler, more direct way to handle API requests in React applications. While it doesn't offer the advanced features of react-query, it's an excellent tool for developers who need a lightweight and straightforward approach to managing API states. This custom hook can be a valuable addition to your React toolkit, especially in projects where simplicity and direct control are paramount.

Next Steps:

Encourage readers to try implementing useRequest in their projects, and suggest experimenting with additional features like request deduplication or more advanced caching mechanisms to further enhance the hook's capabilities.