DEV Community: Lautaro Suarez

What's Hydration in SSR?

Lautaro Suarez — Tue, 10 Oct 2023 20:45:39 +0000

Introduction

On this post I will try to explain in a few words what's hydration and why is it important.

Server Side Rendering

Server Side Rendering difference it self from Static site generation since "SSR" means per-request rendering as opposed to build-time rendering.
Static rendering happens on the server-side too, but at build-time.
Dynamic rendering on the other hand happens at server-side but at request time.

Hydration

Hydration is what let's the server side rendered component to be able to access client-side interactive tools, such as forms, buttons, etc.
Without the hydration we will just have a plain static page.

Conclusion

Hydration helps the ssr components to interact with the user.

"Satisfies" operator, Typescript

Lautaro Suarez — Mon, 11 Sep 2023 13:28:05 +0000

Introduction

On this post i will show a simple example on how to use satisfies and when should you use it. Do not hesitate to ask me anything.

What is the "satisfies" operator?

The satisfies operator checks if a given type satisfies a specific condition or interface, it will ensure that all variables fit the definition and have all the required properties of a specific type or interface.

Why is it useful?

It is useful cause we can use it when for instance we defined a type with two possibles values and then it does not know which one is the one being use. It will help us achieve a more accurate way of knowing what is the actual type of an specific value.
Let's see an example:

type allMyInfo = personalInfo | workInfo

We can see that allMyInfo will be either personalInfo or workInfo.

type personalInfo = "Mike" | "Allan" | "Suarez";
type workInfo = {
  id: number;
  bossAge: number;
};

After defining the two type that allMyInfo is using we are going to define a Person type that will have two values and both of them will have allMyInfo since it could have any of them.

type Person = {
  myInfo: allMyInfo;
  myOtherInfo: allMyInfo;
};

const applicant: Person = {
  myInfo: "John",
  myOtherInfo: { id: 123, bossAge: 28 },
};

Now let's try to access any method such as "toUpperCase" it will show an error saying something like "Property 'toUpperCase' does not exist on type" ,etc.

applicant.myInfo.toUpperCase();

This error occurs because TypeScript is unsure whether the value of "myInfo" or "myOtherInfo".

We can fix this error doing an if statement and checking if in this case "myInfo" is of type string and inside it put the method toUpperCase.

However thats when our satisfies friend comes.

const applicant = {
  myInfo: "John",
  myOtherInfo: { id: 123, age: 22 },
} satisfies Person;

Adding the satisfies at the end with the type will let us in this case use the method since now it knows which value should choice bwtween the options given before.

Conclusion

I hope someone found it useful and in case of having any questions ask them, im coming from vacation so my writing is probably a little rusty, u can judge me ;).

Server side rendering with NextJs

Lautaro Suarez — Sat, 05 Aug 2023 14:32:04 +0000

Introduction

This is just mean to be a short introduction on how to use ssr, if you should use it in your project and understanding how it actually works.

What's the difference between SSR and CSR?

Well there is a couple differences but the main one is that SSR runs on the server giving a a lighter javascript bundle to the web which makes it run faster whereas CSR or cliente side rendering does everything on the browser which could be helpful but it could make the experience slower if we are not using it the right way.

How to use it in NextJS?

NextJs by default will understand that you are using a server component unless you actually tell him to that you want a client component. For instance if you are trying to add a onClick in a component you will receive an error since you can not manage client side requests on the server and you will to tell it at the top of the component that this should be a cliente component.

Button.js

'use client'

import { useState } from 'react'

export default function Counter() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  )
}

The example above us is an example on how we have to put at the top of the file "use client" for nextJS to understand that this is going to be a client server component. Is also a good example cause we are using state too which can`t be use in ssr either.
If you want a depth explanation i'll leave this nextjs documentation.

Should you use it?

Well it really depends, there is a lot of adavantages regarding using SSR but these adavantages are not for every project. Altough i'm going to give to you some good example of when it would be a good approach to use it.

Blog: In a blog there is a lot of static things such as img, links, text, etc. All this static things could be render on the server to avoid having an enormous js bundle when is not needed.
Ecommerce.

In other cases i would consider if the best option is SSR since you have a lot javascript functionalities in the client side, the best option for you could be use a CSR such as react to have a better experience.

Conclusion

This is a very short explanation but i would be glad to help you if you have any concerns about SSR or CSR, let me know on the comments.

Cheers.

Island architecture, should you use it?

Lautaro Suarez — Sat, 29 Jul 2023 11:14:39 +0000

Introduction

Lately i've been researching about island architecture and how some people say it's the future for javascript "0kb", but is it the future? is javascript "0kb" even possible? Well i would try to answer this questions here and explain a little about it and what i have discovered after my research on it.

What is island architecture?

I will try to introduce you with island architecture even though i'm not a expert on the field.
What island architecture is trying to achieve is basically avoid having enormous chunks of javascript in every render but instead having isolated by the components that actually need javascript such as buttons, etc.
For instance, let's say we have a navBar with a title and then a little button that if you click it will send you a notification.
The navbar since it's stateless it will be static server renderer and the button will have it's own script since its interactive and after an action it will be rehydrated to be updated.
And this is basically island architecture but it's probably not the best explanation so i will leave a link where i found the best explanation explanation.

Is it the future?

Well yes and no, let me elaborate.
I think that is the future for specific cases, since in apps where you have literally all stateful components is not useful neither recommended to use it, an example would a social media where there is basically no static components. However i think this type of architecture could be really helpful on ecommerce's and blog's for example where it will give a better performance for it and will a provide a better experience for the user.

Is javascript "0kb" possible?

Short answer: no.
Why i think that is not possible? Well several of reasons, first of all, why did we start even using javascript? Ask yourself that.
We started using it for big websites where state is a really important thing, to provide things that can probably can be achieve without it but at what cost?
So, no i don't think is possible at least not yet, but i would love to know your opinion about it.

Conclusion

I would encourage you to do your research about it and the other possibilities out there. I hope this was useFul and if you have any questions you can drop a comment and i would try to help you out.

Cheers, Lautaro.

An introduction to documenting code

Lautaro Suarez — Sat, 22 Jul 2023 13:45:36 +0000

Introduction

In this post, I will try to explain the basics of how to start documenting your code to everyone to understand it or will try ;).

Why is it important?

When embarking on a collaboration or working with a team, especially involving multiple developers, the code might become increasingly confusing, leading everyone to get lost in the complexity of certain functions or algorithms. Explaining everything in a meeting becomes impractical. To address this challenge, various approaches can be employed, which we will explore in this post.

Name convention

The naming convention may appear deceptively simple, yet it can occasionally spark discussions among colleagues regarding the appropriate name for a function. Below, I'll provide you with some essential factors that can guide you in naming your files or functions.

Do's and Don'ts

Do's

Keep the name short but meaningful
Include unique identifiers such as project title, etc.
Be consistent
Ensure the purpose of the document is easily identifiable

Don'ts

Common words such as 'letter', 'current', etc.
Vague titles such as 'array'.
Symbol characters such as: ?, <>,+, etc.
Abbreviations that are not commonly understood, or which may frequently change throughout time

I'm particularly highlighting my dislike for abbreviations as they are one of the things I strongly dislike. There's a common belief that keeping names short automatically implies using abbreviations, but I disagree. For instance, I prefer having a file called "arrayToFirstIndex" rather than "arrayToFI" – after all, what does "FI" even stand for? This example serves as a compelling illustration of how brevity is not always the best approach.

Code documentation

This is probably one of the most important things when coding with a group or in a company, documenting your code is just as important as the code.
If we want to maintain the project we are working on and use it longterm we will need to improve our abilities to documenting what we have done.

Block Tags

I have discovered that employing block tags is a highly effective and lucid way to describe what the code accomplishes. It assists in maintaining clean and comprehensible code. While numerous block tags are available, I will outline the ones I frequently use and explain why they are beneficial.

@param: I utilize it specifically to describe the parameter's data type, its name, and the possible values it can accept.

@type: I utilize it to describe the type of it.

@defaultValue: I utilize it to know the default value of a specific variable

@return: I utilize it to know what it would return

@property: This one could be used with objects to describe what each property could do.

Examples:

I'm gonna finish this post with an examples of how to document your code.

As observed, I began by providing a brief description of the function's purpose. Next, I employed the "@param" block tag to specify the parameter's type and expected input. Finally, I detailed the return value, including its type and description.

/**
 * Convert string to an array.
 * @param {string} str - String to convert.
 * @return {Array} An array of the string received.
 */
const StringToArray = (str: string): string[] => {
 let result = str.split(' ')
 return result
}

Conclusion

All in all, I think that this is a really good option to start understanding what it means to document but I would encourage you to do research and I am also I'm gonna leave the documentation of probably one the most used conventions to document your code. https://jsdoc.app/
Cheers.

TypeScript: "type predicates"

Lautaro Suarez — Sat, 08 Jul 2023 10:19:43 +0000

What are type predicates?

This question came up while I was going through the TypeScript documentation. Initially, I found it difficult to understand their purpose and when to use them. However, after conducting thorough research and studying practical examples, I finally grasped their significance and the situations in which they are beneficial. With that in mind, I will now make an effort to explain type predicates in a way that is easier to comprehend.

Type Predicates functions

Type predicate functions, also known as type guards, are functions that return a boolean value. They play a crucial role in refining the types within a function, allowing us to have a clear understanding of what we can expect from it. By utilizing type predicate functions, we can effectively narrow down the type of a variable or parameter, enabling more precise type inference and ensuring safer and more reliable code execution.

function isString(x: unknown): x is string {
  return typeof x === 'string';
}

This concept is quite straightforward, and that's precisely why it is so valuable. We have a function called isString that accepts arguments of any type. Inside this function, we perform a type check using the typeof operator to determine if the argument is of type string.

But why do we use the x is string syntax? It serves two purposes. Firstly, it provides context and clarity to the code, clearly indicating that the function is expected to return a boolean value indicating whether the argument is a string or not. Secondly, it follows clean code practices by employing a well-defined naming convention that enhances code readability and maintainability.

Cons and pros

Let's start with the cons:

A bad type on the function can result in a non ending debugging error that can take hours even days to understand where the error was.
It adds more code to every function.

Example of a really common mistake or error:

function isString(x: unknown): x is number {
  return typeof x === 'string';
}

function isString(x: unknown): x is string {
  return typeof x === 'number';
}

In both cases, there seems to be an error. In the first example, we incorrectly state that we expect x to be a number in order for the function to return true. However, this contradicts the actual code, where we are checking if x is a string.

It's important to ensure consistency between the expected type mentioned in the comment and the actual type check performed within the function. To rectify this, we should update the comment or the type check to accurately reflect the intended behaviour, ensuring that x is checked for being a string. This alignment between the comment and code promotes clarity and helps other developers understand the function's purpose more accurately.

Conclusion

I highly recommend using type predicates when adhering to good coding practices to enhance the readability of your code for other developers. However, it is essential to exercise caution and avoid overusing type predicates, as excessive reliance on them can introduce errors and make it challenging to identify their root causes. Striking the right balance and using type predicates judiciously will contribute to code clarity without compromising code maintainability and debugging efficiency.

Cheers, Lautaro

2nd Episode: Best practices.

Lautaro Suarez — Thu, 15 Jun 2023 19:54:58 +0000

Best practices

During the testing process, our focus is on verifying the desired behaviour rather than specific implementation details.

The Arrange-Act-Assert (AAA) pattern

This widely used pattern helps to ensure that your tests are well-organized and structured correctly. It involves three essential steps: arranging the test environment and setting up any necessary variables, acting by performing the desired action, and asserting that the expected outcome has indeed taken place.
Example:

// Counter.js
import React, { useState } from 'react';

const Counter = () => {
  const [count, setCount] = useState(0);

  const increment = () => setCount(count + 1);

  return (
    <div>
      <h1>Counter: {count}</h1>
      <button onClick={increment}>Increment</button>
    </div>
  );
}

export default Counter;

Test

// Counter.test.jsx
import { fireEvent, render, screen } from '@testing-library/react';
import Counter from './Counter';

test('increments counter when button is clicked', () => {
  // Arrange
  render(<Counter />);
  const button = screen.getByRole('button');

  // Act
  fireEvent.click(button);

  // Assert
  const counterValue = screen.getByText(/1/i);
  expect(counterValue).toBeInTheDocument();
});

While it is valuable to follow industry standards, we should also use our judgment to determine when and how to apply them. It's important to aim for tests that closely resemble the behaviour of the code in a production environment.

1st Episode: Testing React components, a series.

Lautaro Suarez — Sun, 11 Jun 2023 17:23:08 +0000

Introduction

This series of posts will guide you through the process of testing React components, covering a range of examples starting from easy ones and gradually diving into more in-depth scenarios. While it may take some time to complete the series, I'll make an effort to include challenging examples as well. Additionally, I encourage you to share any specific cases you would like me to cover. If I find them valuable for the broader audience, I will gladly incorporate them into the series.

By exploring different testing techniques for React components, this series aims to equip developers with the knowledge and skills necessary to effectively test their applications. Whether you're a beginner looking to grasp the basics or an experienced developer seeking advanced testing strategies, this series will provide insights and practical guidance.

Feel free to follow along, and don't hesitate to reach out if you have any questions or need further clarification. Let's embark on this journey of mastering React component testing together!

Tools

In this posts i will be using jest and react testing library **which usually both of them are included in starting projects but if you don't have them include it you can do a simple **npm install --save-dev jest if you are using npm.
And then you will have to add the following to the package.json.

"scripts": {
 "test": "jest"
}

This case is specific for react components but i would encourage you to check your specific case in google.

Testing your first component

We will begin by exploring a straightforward yet practical component. It features a conditional statement, and we will examine the testing approach for this particular component.

FirstComponent.tsx

const FirstComponent = ({name?: string}) => {
 if(data){
   return <div>{name}</div>
 }
return <div>Component without name</div>
}

export default FirstComponent;

Now the test for it:

FirstComponent.test.tsx

import { render, screen } from '@testing-library/react';
import FirstComponent from './FirstComponent';

test('renders the FirstComponent correctly without a name', () => {
 **get** render(<FirstComponent />);
  const divElement = screen.getByText(/without/i);
  expect(divElement).toBeInTheDocument();
});

test('renders the FirstComponent correctly with a name', () => {
  render(<FirstComponent name="Lautaro" />);
  const divElement = screen.getByText(/Lautaro/i);
  expect(divElement).toBeInTheDocument();
});

Now let's take apart the code:

First I'm import render and screen from react testing library. The render function will basically render the component into a fake DOM which we'll be able to query later. The screen will be that querying interface where we will be able to get the rendered method in this case using getBytext.
I've chosen to call the test function twice instead of using an alternative approach because it provides clearer separation and identification of the tests. Additionally, I'm not explicitly importing the test and expect functions since they are Jest helpers that are automatically available within the testing environment.
In the end, I am conducting tests for two distinct scenarios due to the presence of an if statement in the component. Depending on whether the component receives a name prop, it will render one outcome, and if not, it will render a different outcome. I accomplish this by selectively passing or omitting the prop, which is optional in this case. By examining the rendered HTML, I am able to capture specific text within it to determine the expected outcome.

keyof typeof Object

Lautaro Suarez — Sat, 10 Jun 2023 15:19:54 +0000

Introduction

I'm going to talk about keyof typeof in typescript and how it could be helpful. I will start explaining typeof and key separate and in which case you might want to use it.

Literal types

Literal types in TypeScript are more specific types of string, number or boolean. Let's elaborate with an example, "Hey" is a string, but a string is not "Hey". "Hey" is a more specific type of type string, so it is a literal type.

A literal type can be declared as following:

type Saludo = "Hey"

This means that the object of type Saludo can have only a string value "Hey" and no other string value or any other value of any other type as shown in the following code:

let saludo: Saludo
saludo = "Hey" //Ok
saludo = "hi" // Error: Type "hi" is not assignable to type "Hey"

Literal types are not useful on their own, however when combined with union types, type aliases and type guards they become powerful.

Following is an example of union of literal types:

type Saludo = "Hey" | "Hi" | "Welcome"

Now the object of type Saludo can have the value either "Hey", "Hi" or "Welcome".

let saludo: Saludo
saludo = "Hey" //Ok
saludo = "Hi" //Ok
saludo = "Welcome" //Ok
saludo = "Good" //Error: type "Good" is not assignable to type Saludo

keyof

keyof of some type T gives you a new type that is a union of literal types and these literal types are the names of the properties of T. The resulting type is a subtype of string.

For example, consider the following interface:

interface Person {
 name: string
 age: number
 location: string
}

Using the keyof operator on the type Person will give you a new type as shown in the following code:

type SomeNewType = keyof Person

This SomeNewType is a union of literal types ("name" | "age" | "location") that is made from the properties of type Person.

Now you can create objects of type SomeNewType:

let newTypeObject: SomeNewType
newTypeObject = "name" //ok
newTypeObject = "age" //ok
newTypeObject = "location" //ok
newTypeObject = "other" //Error..

keyof typeof together on an object

The typeof operator gives you the type of an object. In the above example of Person interface, we already knew the type, so we just had to use the keyof operator on type Person.

But what to do when we do not know the type of an object or we just have a value and not a type of that value like the following?

const bmw = {name: "bmw", power: "100ph"}

This is where we use keyof typeof together.

The typeof bmw gives you the type: {name: string, power: string}

Ant then keyof operator gives you the literal type union as shown in the following code:

type CarLiteralType = keyof typeof bmw;

let carPropertyLiteral: CarLiteralType
carPropertyLiteral = "name" //Ok
carPropertyLiteral = "power" //Ok
carPropertyLiteral = "other" //Error

Basically what it means is that if the value is inside of the object we will be able to call the property since the keyof typeof give us that advantage.

Conclusion

I found really interesting this use of keyof type object and I recommend to use it. I will be posting more things about typescript and how to type react components.

Cheers, Lautaro.

Atomic Design

Lautaro Suarez — Sun, 04 Jun 2023 13:26:21 +0000

Introduction

I'm going to talk about atomic design, what i've learned after reading documentation about it and Brad Frost Book, where he explained how to actually structured your application. I could have some bad practices and errors so i open to have feedback and see different point of views.

What's Atomic Design?

When we talk about Atomic design, we are talking about a way to structure our components in order to be reusable and well written in order for other developers to understand it.

How is it structured?

Atomic design is structured just like in chemistry, atoms, molecules, organisms, templates and pages.
Atoms basically being the smaller portion of it, where we place things like buttons,text,etc. Basically anything small enough to be reusable everywhere and it would just have a div tag maybe.
Molecules are groups of two or more atoms held together by chemical bonds. These combinations of atoms take on their own unique properties, and become more tangible and operational than atoms.
Organisms are assemblies of molecules functioning together as a unit. These relatively complex structures can range from single-celled organisms all the way up to incredibly sophisticated organisms like human beings.
Templates are page-level objects that place components into a layout and articulate the design's underlying content structure. To build on our previous example, we can take the header organism and apply it to a homepage template.
Pages are specific instances of templates that show what a UI looks like with real representative content in place. Building on our previous example, we can take the homepage template and pour representative text, images, and media into the template to show real content in action.

Why would you want to use atomic design?

There is a couple reasons but i would say that the main one is to keep your code clean and reusable, this would always be applied if the code you are writing is clean.

What you should take in consideration when creating new components?

You should always think, is it an atom? a molecule? an organism?, there are a few clues to figure out what are you doing. Let me elaborate: If you are not using any atoms and just using a small piece of tags let's say, you are maybe creating a new atom. If you are using multiple atoms you are creating a molecules and go on.
In order to be reusable you should always take in consideration what you are adding to the component, try to no put business logic on it unless it's 100% necessary but always give it another point of view to know if you can reduce the code or take out the business logic.

Recommendations

You should always discuss with your team new big changes and if you are creating a new molecule or organism you will always be tempted to add unnecessary logic so i would recommend to discuss it with your colleagues and try to figure out the best solution.

Here i will leave you the atomic design manual.Here
Cheers, Lautaro.

React Lifecycle

Lautaro Suarez — Mon, 22 May 2023 21:40:03 +0000

Introduction

This would be a simple post about React lifecycle with hooks and react lifecycle with classes.

React lifecycle with hooks.

React Lifecycle with classes

Difference

I was wondering just like you about unmounting which in the hooks lifecycle but in this case the unmount will be when we do the clean up with for example useEffect, where inside the useEffect doing the return we are doing the unmounting which is called clean up.

Conclusion

We can do basically the same and in a simpler way with functional components. We just have to know how to do it.

Hope someone found it useFul.

Lautaro

Handling errors in React

Lautaro Suarez — Sun, 21 May 2023 18:45:48 +0000

Errors when developing are something that you will always have and it's better to know that i know how to handle them. In this post I'm going to write about how to handle them in React.

Try/Catch

I will start talking about try/catch method which is really simple but useful at the same time.
We just can use it for imperative code and event handlers which are often used in a declarative way in react.

Event handler using Try/Catch

The provided code demonstrates a basic event handler that employs a try/catch block. Within the try block, there is a comment indicating the potential presence of code performing operations like making API calls using fetch or internal API functions. The try block attempts to execute these operations, while the catch block is responsible for capturing any encountered errors in case the operations within the try block fail.

const MyComponent = () => {
  const [error, setError] = useState(null)
  handleClick() {
    try {
      // Do something that could throw
    } catch (error) {
     setError(error);
    }
  }

    if (error) {
      return <h1>Caught an error.</h1>
    }
    return <button onClick={this.handleClick}>Click Me</button>
}

Common mistakes

When utilizing the try/catch method, it is essential to be mindful of certain considerations. As this method operates in an imperative manner, it can lead to complications when employed alongside React lifecycle methods like useEffect, children components, and state updates during rendering.

Example with useEffect (Wrong)
This will never work, since we can't wrap useEffect with try/catch.

try{
 useEffect(() => {
  throw new Error("Main Error!")
},[])
}catch(e){
 // useEffect throws, but this will never be called
}

Example with useEffect (Right)
This is an example of how to use try/catch with useEffect the right way.

useEffect(() => {
 try{
  throw new Error("Main Error!") 
}catch(e){
 // this one will be caught
}
}, [])

Example with children components
We also can not do this cause it will be useless cause it will never catch an error since the child component belongs to the lyfecycle method of the react virutal DOM.

const Component = () => {
  try {
    return <Child />
  } catch(e) {
    // still useless for catching errors inside Child component, won't be triggered
  }
}

Example setting state during render
The following example will just cause an infinite loop in case of an error.

const Component = () => {
 const [error, setError] = useState(false);

 try{
  something();
}catch(e){
 setError(e)
 }
}

We could use something like this though, where we will set the state inside a useEffect but we will also have a try/catch at the render but in case of error it will return an error screen instead of setting some state.

const Component = () => {
 const [error, setError] = useState(false);

 useEffect(() => {
 try{
 //something
}catch(e){
 setError(true);
}
},[])

 try{
  something();
}catch(e){
 return <ErrorScreen/>
 }

if(error) return <ErrorScreen/>

return <NiceComponent/>
}

React ErrorBoundary component

To be able to avoid the limitations of try/catch we could use a "Error boundaries" Api that react give us that converts a regular component into a try/catch, only for React declarative code.

How to implement it?
Here is the way react documentation show us how to implement it.

const Component = () => {
 return(
   <ErrorBoundary>
    <ChildComponent/>
   </ErrorBoundary>
)
}

If something goes wrong in the child component or their children during render, the error will be caught and dealt with.

The catch is that react docs does not give us the component already built, but it gives us a tool to implement it.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    // initialize the error state
    this.state = { hasError: false };
  }

  // if an error happened, set the state to true
  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  render() {
    // if error happened, return a fallback component
    if (this.state.hasError) {
      return <>Oh no! Epic fail!</>
    }

    return this.props.children;
  }
}

And no, react does not support error boundaries built as a functional component yet.
So let me break down the code for you and explain it a little but is not that hard to understand if you have some experience with react.
Basically we extend react component, then we initialise a constructor that will have a hasError as the state, getDerivatedStateFromError was literally mainly build to be able to catch errors on the lyfecycle of react, so if it finds an error it will change the value of hasError to true and if hasError is true our errorBoundary will return "Oh no! Epic fail!" but in case it does not have an error it will just return the children the component has wrap it.

Add a fallback to the errorBoundary

Let's say we want to add a specific fallback depending what components had an error we could add a fallback to the errorBoundary so we will be able to return that specific component.

ErrorBoundary

render() {
  // if error happened, return a fallback component
  if (this.state.hasError) {
    return this.props.fallback;
  }

  return this.props.children;
}

And this is how we would use it

const Component = () => {
  return (
    <ErrorBoundary fallback={<>Oh no! Do something!</>}>
      <SomeChildComponent />
    </ErrorBoundary>
  )
}

Conclusion

We always would need to use try/catch to catch async functions and imperative code but the best would be to use a combination of both, Error Boundaries and try/catch to have a well documented code that handles errors right.

Hope someone found it useFul, and if you have any questions i would try to solve them, catch(e){Or not}.