Introduction

ToolJet is an open-source, low-code platform that enables tools and dashboard development. With its drag-and-drop interface, you can easily connect to various data sources, and build interactive applications without extensive coding.

Through this blog, I will guide you through the process of integrating ToolJet with data sources (Rest APIs & MongoDB) to retrieve and display data in a user-friendly application.

We’ll cover the steps:-
1) connect data sources to ToolJet
2) create queries to fetch data
3) display that data using ToolJet’s visual components like tables.

Let’s roll up our sleeves and dive in!

Get Started

Open the ToolJet app and sign in or sign up as needed. Once logged in, you’ll be taken to the dashboard where you can start creating or managing your applications.

Integrating ToolJet with REST APIs

Step 1: Navigate to the Data Sources tab located on the left-hand side of the interface.

Step 2: From the list of available data sources, add REST API

Step 3: Enter the API Details

1) In the configuration screen, enter the Base URL of the REST API you want to connect to. For example, if you are using a public API like JSONPlaceholder, you would enter https://jsonplaceholder.typicode.com/.

2) If the API requires authentication or specific headers add them.

3) If your API uses a specific authentication type like Basic Auth or Bearer Token, select the appropriate option from the dropdown.

4) Click on Save to store the configuration.

Step 4: Go to the App section and create an app.

Step 5: In the Tooljet App-Builder, navigate to the Queries tab and click on Add and select the REST API data source you just configured.

Step 6: Specify the API endpoint relative to the base URL, choose the HTTP method (usually GET for retrieving data), and add any necessary parameters, body, or headers.
For example:- we are using users .

Hit Run to check if the data is coming or not.

Step 7: From the component section, drag and drop a Table component onto the canvas.

Step 8: Remove the pregiven data from Data and put {{queries.restapi1.data}} (it bind the data returned by the restapi1 query to the component, allowing the component to display that specific data.)

With the API data displayed, you can customize it by editing or deleting columns, or adjusting the Table’s appearance using the Properties or Style sections on the right side.

Step 9: Click on the Phone icon and drag the table on the canvas again to make the app responsive.

Step 10: Again in the Data remove the pregiven data and put {{queries.restapi1.data}} and make the necessary changes in table appearance accordingly.

Step 11: Click the Preview button to see how the data appears in the Table.

Integrating ToolJet with MongoDB

Step 1: Navigate to the Data Sources and choose MongoDB from the list of available data sources.

Step 2: Configure the MongoDB settings

1. You have two choices either you can use Manual connection or connect through connection string.
2. If you are using Manual connection, Enter all the details like Host, Port etc.
3. If you are connection string, enter it.

After this, click on test connection, when connection is verified, save the configuration.

Step 3: Go to the App section and create an app and after that navigate to the Queries tab and click on Add and select the REST API data source you just configured.

Step 4: Specify the operation, collection name, filter and Operations.
for example:- we are going to fetch all the users from the users collection.

Step 5: Hit Run to see the results

Step 6: From the component section, drag and drop a Table component onto the canvas, Remove the pregiven data from Data and put {{queries.mongodb1.data}} (It binds the data retrieved from the mongodb1 MongoDB query to the component).

With the data displayed, you can customize it by editing or deleting columns, or adjusting the Table’s appearance using the Properties or Style sections on the right side.
Now you can make the application responsive and phone-adaptive, just like we did with the REST API integration.

Step 7: Click the Preview button to see how the data appears in the Table.

Conclusion

we explored how to integrate ToolJet with REST APIs and MongoDB, enabling you to create responsive, data-driven applications quickly and easily.
Thanks for following along!

In case you want to connect with me:-

Twitter(X)
LinkedIn
Github

The Concept of React Compiler was introduced during React Conf 2021.
React Compiler is an ‘Auto-Memoizing Compiler’ that automates all the memoizations in your React Application.

Why do we need it in the first place?

To understand this, Let’s take an example.

function VideoTab({videos,title}){
  const uniqueVideos = new Set(videos);
  const size = uniqueVideos.size;
  
  return (
    <>
      <Heading title={title} size={size}/>
      <VideoList videos={uniqueVideos}/>
    </>
  )
}

The code is quite straightforward. It receives videos and titles as props and then passes the uniqueVideos to <VideoList/> and the title to <Heading/>.
UniqueVidoes removes duplicates from the videos and then passes it to the <VideoList/>

Now Let’s say we pass a different title as a prop.

Ideally, We should just render the <Heading/>component, not the <VideoList/>component cause it doesn’t depend upon the title.
But React generally re-renders everything which is not a good thing in case of complex and big codebase.

To tackle this we have memorization.

What is memorization?

memoization is the process of storing data in the cache and then retrieving this information the next time it is needed.
In Simple words, it prevents unnecessary re-rendering of components by storing the results of previous function calls.

How is memoization currently handled in React?
Two main hooks are currently used in React for memoization: useMemo and useCallback.

useMemo

This hook helps you store the result of a function so you can use it later without recalculating.

It accepts two arguments:

1. A function that calculates the value you want to cache.
2. Dependency Array.

import { useMemo } from 'react';

function MyComponent({ number }) {
  const squaredNumber = useMemo(() => {
    return (number*number);
  }, [number]);

  return (
    <div>
      <p>Original number: {number}</p>
      <p>Square: {squaredNumber}</p>
    </div>
  );
}

In this example, the useMemo hook caches the result of (number*number)
So, if the number prop doesn't change, it won't recalculate the square, but if number changes, it will recalculate it.

useCallback

The useCallback hook is very similar to useMemo. The main difference is that useCallback returns a memoized function.

When to use useCallbackinstead of useMemo?

Every time a component re-renders, its functions get recreated. This means that a component may end up re-rendering even though the function itself didn’t change — it was just recreated when the page re-rendered.

Sounds Complicated?
Let me break it down.

1. When you declare a function inside a functional component, each time the component re-renders, a new instance of that function is created. Even though the function might have the same logic, it’s considered a different instance because it’s recreated each time the component renders.
2. If you pass functions as props to child components, and these functions are recreated on every render of the parent component, it can lead to unnecessary re-renders of the child components. This can impact performance, especially if these child components are expensive to render.

To solve this we use useCallback.

// App.js
import { useState, useCallback } from "react";
import ReactDOM from "react-dom/client";
import Todos from "./Todos";

const App = () => {
  const [count, setCount] = useState(0);
  const [todos, setTodos] = useState([]);

  const increment = () => {
    setCount((c) => c + 1);
  };
  const addTodo = useCallback(() => {
    setTodos((t) => [...t, "New Todo"]);
  }, [todos]);

  return (
    <>
      <Todos todos={todos} addTodo={addTodo} />
      <hr />
      <div>
        Count: {count}
        <button onClick={increment}>+</button>
      </div>
    </>
  );
};

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<App />);

// Todos.js

import { memo } from "react";

const Todos = ({ todos, addTodo }) => {
  console.log("child render");
  return (
    <>
      <h2>My Todos</h2>
      {todos.map((todo, index) => {
        return <p key={index}>{todo}</p>;
      })}
      <button onClick={addTodo}>Add Todo</button>
    </>
  );
};

export default memo(Todos);

Let’s use memoization in our starting example.

function VideoTab({videos,title}){
  const uniqueVideos = useMemo(()=>{
    return new Set(videos);
  },[videos])
  const size = uniqueVideos.size;
  
  return (
    <>
      <Heading title={title} size={size}/>
      <VideoList videos={uniqueVideos}/>
    </>
  )
}

So now if we send a different title, only the <Heading/>will be re-render.
Looks like the problem is solved right?

Not really. It does solve the problem of re-rendering but manual memoization comes with its own set of drawbacks, including code clutter, potential errors, and ongoing maintenance overhead.

Ex->

React Compiler

Now, everything we just learned about useMemo and useCallback may become irrelevant when the React Compiler is released.

The React Compiler aims to automate the process of optimizing re-renders in React applications. The goal is to automatically re-render only the necessary parts of the UI when the state changes, without compromising on React’s core mental model.

React Compiler is introduced as an optimizing compiler for React. It leverages knowledge of both JavaScript and React’s rules to safely compile code. React components are expected to follow certain rules.
For that Developers are encouraged to enable Strict Mode and use React’s ESLint plugin to catch subtle bugs and ensure their code follows React’s rules. If the compiler detects code that doesn’t strictly adhere to React’s rules and either compiles it safely or skips compilation if it’s not safe.

Overall, the announcement highlights Meta’s commitment to improving React’s performance and developer experience, with React Compiler representing a significant step forward in achieving these goals.

Useful Links:-

1. https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024
2. https://www.youtube.com/watch?v=kjOacmVsLSE
3. https://www.youtube.com/watch?v=qOQClO3g8-Y

In case you want to connect with me:-

Twitter(X)
LinkedIn
Github

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Venture | Cubed
• More content at Stackademic.com

Optimizing React: A Deep Dive into the Evolution of React Compiler was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

JavaScript is a versatile programming language that provides various features to help developers write efficient and expressive code. One such feature is Generator, which brings a new approach to handling async tasks and working with data streams.

What are JavaScript Generators?

Generators are a special type of function in JavaScript that allows you to control the execution of a function. Unlike regular functions, which run to completion, generators can be paused at any point during their execution and later resumed from where they left off.

Generator Functions are defined using the syntaxfunction*. It uses something called yieldto pause the execution of the generator function and return a value to the caller. When the generator is resumed, it continues executing from where it was paused.

When a generator function is called, it returns an iterator object, which can be used to control the function’s execution.

Let’s take a basic example

function* simpleGenerator() {
  yield 'First yield';
  yield 'Second yield';
  return 'Generator done';
}

const gen = simpleGenerator();  // iterator object
console.log(gen.next()); // { value: 'First yield', done: false }
console.log(gen.next()); // { value: 'Second yield', done: false }
console.log(gen.next()); // { value: 'Generator done', done: true }

When a generator function is called, it returns something called an iterator object.
The iterator object has two methods:- next() and return().

Next( ) Method

The next() method is used to resume the execution of a generator function from where it was paused. It returns an object with two properties: value and done.

• The value property contains the value produced by the yield statement.
• The done property is a boolean indicating whether the generator has completed (true) or is still running (false).

Return( ) Method

The return() method allows us to force complete a generator function before it reaches the end.

It also takes an optional argument that will be returned as the final value of the generator.

function* simpleGenerator() {
  yield 1;
  yield 2;
  yield 3;
}

const iterator = simpleGenerator();
console.log(iterator.next()); // Output: { value: 1, done: false }
console.log(iterator.return("Finished!")); // Output: { value: "Finished!", done: true }
console.log(iterator.next()); // Output: { value: undefined, done: true }

Let’s take some real-world use cases and examples of generators.

1) For..of Loop with Generator

Let’s say a generator yields a lot of data, the best thing will be to use for..of loop instead of next().

function* countTo100(){
  for(let i=0;i<100;i++){
    yield i;
  }
}
const iterator = countTo100();

for(const item of iterator){
  console.log(item);
}
// 0 1 2 3 ...

2) Lazy evaluation

Let’s say you want a sequence of numbers, but you’re not sure how many. Here’s how a generator helps:

function* numberGen(){
  let number = 1;
  while(true){
    yield number++;
  }
}

const number = numberGen();
console.log(number.next()); // { value: 1, done: false }
console.log(number.next()); // { value: 2, done: false }

With generators, you get the next number only when you ask for it.

3) yield*

If we have another generator and need to iterate on that before proceeding with the execution of the current generator function, we can use yield*

Let’s take an example:-

function* anotherGeneratorFunction() {
  yield 'A';
  yield 'B';
}

function* generatorFunction() {

  yield 1;

  yield* anotherGeneratorFunction();

  yield 2;
  yield 3;
}
const generator = generatorFunction();

console.log(generator.next()); // {value: 1, done: false}
console.log(generator.next()); // {value: 'A', done: false}
console.log(generator.next()); // {value: 'B', done: false}
console.log(generator.next()); // {value: 2, done: false}
console.log(generator.next()); // {value: 3, done: false}
console.log(generator.next()); // {value: undefined, done: true}

We have called anotherGeneratorFunction() with the yield*, so it will be executed till the end before proceeding to the execution of generatorFunction().

4) Memory utilization

Generators don’t hold all the results in memory, they generate them on the fly.

Imagine you need a sequence of a million numbers. With a regular function, you’d need to store all these numbers in an array, which will consume a significant memory.

A Generator would be a much more efficient solution in this case.

function* bigNumberGen(){
  let num = 1;
  while(num<=100000000){
   yield number++;
  }
}

const bigNum = bigNumberGen();
const chunk = 10;
for(let i=0;i<chunk;i++){
  const value = bigNum.next().value();
}

5)Handling Async Tasks

One of the main advantages of generator functions is their ability to handle asynchronous operations with ease.

Let’s take a look at an example of how we can use a generator function to handle async operations.

function* asyncGenerator() {
  try {
    const result1 = yield asyncTask1();
    console.log(result1);

    const result2 = yield asyncTask2();
    console.log(result2);

    const result3 = yield asyncTask3();
    console.log(result3);
  } catch (error) {
    console.error('Error occurred:', error);
  }
}

async function asyncTask1() {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve('Async Task 1 Completed');
    }, 1000);
  });
}

async function asyncTask2() {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve('Async Task 2 Completed');
    }, 1500);
  });
}

async function asyncTask3() {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve('Async Task 3 Completed');
    }, 2000);
  });
}

async function executeAsyncGenerator() {
  const gen = asyncGenerator();
  let result;
  while (true) {
    const { value, done } = await gen.next(result);
    if (done) {
      break;
    }
    result = await value;
  }
}

executeAsyncGenerator();

6) Typing Animations

We all have used Typing Animation, a visual effect designed to mimic someone typing text.

Let’s see how we can leverage generators to achieve this.

function* typeAnimation(text){
  for(let char of text){
    yield char;
  }
}

const itr = typeAnimation("Coding Beauty");
function typeAnimation(elementId){
  let element = document.getElementById(elementId);
  setInterval(()=>{
    let result = itr.next();
    !result.done && element.innerHTML += result.value;
  },100);

}

In case you want to connect with me:-

Twitter(X)
LinkedIn
Github

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Venture | Cubed
• More content at Stackademic.com

Mastering JavaScript Generators: Practical Use Cases was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

SOLID is an acronym, where each letter represents one out of five design principles that help make the code understandable, flexible, and maintainable.

• Single responsibility principle (SRP)
• Open-closed principle (OCP)
• Liskov substitution principle (LSP)
• Interface segregation principle (ISP)
• Dependency inversion principle (DIP)

In this article, we’ll talk about the importance of each principle and see how we can apply the learnings from SOLID in React applications.

SOLID principles were initially meant for object-oriented languages like Java and C#, where classes and interfaces play a big role. But in JavaScript, especially in React, we don’t rely on these concepts as much.

The good news is SOLID principles aren’t tied to any specific language or programming style. Even in the more functional world of React, we can still apply these principles to write cleaner and more maintainable code.

1. Single Responsibility Principle (SRP)

every class should have only one responsibility.

In React, adhering to the Single Responsibility Principle (SRP) means ensuring each component has a clear and distinct purpose. By focusing on a single task, we can enhance the clarity and maintainability of our codebase.

Here’s how we can effectively implement SRP in our React applications:

1. Component Modularity: Keep your components small and focused on doing one thing well. This approach improves code readability and makes it easier to understand and maintain.
2. Task Segregation: Avoid mixing unrelated tasks within a single component. For example, a component responsible for rendering a form should not also handle fetching data from an API. Separating concerns in this way improves code organization and reduces complexity.
3. Composition: By breaking down complex UIs into smaller, reusable parts, we can build more modular and flexible applications. This approach also encourages code reusability and reduces duplication.

Let’s Take an example of a code that does not follow SRP and then we’ll refactor it to follow SRP.

import React, { useState, useEffect } from "react";
import axios from "axios";

const UserDetails = () => {
 const [user, setUser] = useState(null);
 const [isLoading, setIsLoading] = useState(true);

 useEffect(() => {
   axios.get("https://.../userDetails/").then((res) => {
       setUser(res.data)
   }).catch(e => {
       console.error('Error fetching user details:', e.message);
   }).finally(() => {
       setIsLoading(false);
   })
 }, [])

 if (isLoading){
   return <p>Loading...</p>
 }

 return (
   <div>
       <h2>User Details</h2>
       <p>Name: {user.name}</p>
       <p>Email: {user.email}</p>
   </div>
 );
};

export default UserDetails;

This code looks well-written right? At least this is what most of us are used to.

As we examine the UserDetails component, we start to notice a few issues. It's taking on multiple responsibilities:

1. Managing the state.
2. Making requests for list items and handling the fetching process.
3. Rendering the component.

While it may seem ordinary at first glance, according to the Single Responsibility Principle (SRP), it’s juggling more responsibilities than it should. So, how can we improve it?

One common approach is to extract logic that involves side effects, like fetching data, into a custom hook. By doing this, we can separate concerns and adhere to SRP more effectively.

Let’s create a custom hook

import React, { useEffect, useState } from "react";
import axios from "axios";


const useFetchListItems = () => {
   const [user, setUser] = useState([]);
   const [isLoading, setIsLoading] = useState(true);

useEffect(() => {
   axios.get("https://.../listitems/").then((res) => {
       setUser(res.data)
   }).catch(e => {
       console.error('Error fetching user details:', e.message);
   }).finally(() => {
       setIsLoading(false);
   })
 }, [])

   return { user, isLoading };
}

After refactoring, our component becomes easier to understand. Its only job is to display information, which makes it more maintainable and flexible.

Here’s the refactored version of our component, aligned with the Single Responsibility Principle (SRP):

import React from "react";
import { useFetchUserDetails } from "hooks/useFetchUserDetails";

const UserDetails = () => {
 const { user, isLoading } = useFetchUserDetails();

 if (isLoading){
   return <p>Loading...</p>
 }

 return (
   <div>
       <h2>User Details</h2>
       <p>Name: {user.name}</p>
       <p>Email: {user.email}</p>
   </div>
 );
};

export default UserDetails;

Upon closer examination, our new hook is handling both state management and fetching list items. This violates the Single Responsibility Principle.
To address this, let’s separate the logic for fetching list items into its module.

API File

import axios from "axios";

export const fetchUserDetails = () => {
 return axios
   .get("https://.../userDetails/")
   .catch((error) => {
     console.error('Error fetching user details:', error.message);
   })
   .then((response) => response.data);
};

Custom Hook File

import { useEffect, useState } from "react";
import { fetchUserDetails } from "./api";

const useFetchUserDetails = () => {
 const [user, setUser] = useState(null);
 const [isLoading, setIsLoading] = useState(true);

 useEffect(() => {
   fetchUserDetails()
     .then((userData) => setUser(userData))
     .finally(() => setIsLoading(false));
 }, []);

 return { user, isLoading };
};

Keeping it simple: While the Single Responsibility Principle (SRP) helps us maintain tidy, error-free code, it can also complicate our file structure and planning.
However, it’s important to find a balance. While SRP promotes clarity and maintenance, we shouldn’t overly complicate things. Sometimes, a bit of complexity is fine if it makes the code easier to understand overall.

2. Open-closed principle (OCP)

software entities should be open for extension, but closed for modification

Open for extension: A component should allow for the addition of new behaviors, functionalities, and features without requiring modifications to its existing functionality.

Closed for modification: Once a React component has been created and implemented, it’s best to refrain from directly altering its source code unless absolutely necessary.

Let’s take an example to understand this

import React from 'react';

const Button = ({ variant, children }) => {
  let buttonStyle = {};
  if (variant === 'primary') {
    buttonStyle = {
      backgroundColor: 'blue',
      color: 'white',
    };
  } else if (variant === 'secondary') {
    buttonStyle = {
      backgroundColor: 'white',
      color: 'black',
      border: '1px solid black',
    };
  }

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

export default Button;

Now, let’s say we want to add a new variant called “warning”, which should render a button with a yellow background and red text color.

The Above implementation of the Button component violates the OCP because we have to modify the component's source code to accommodate the new variant. This means the component is not closed for modification.

Let’s refactor this:-

import React from 'react';

const Button = ({ variant, children, customStyles }) => {
  let buttonStyle = {};
  const baseStyles = {
    padding: '8px 16px',
    borderRadius: '4px',
    cursor: 'pointer',
  };

  switch (variant) {
    case 'primary':
      buttonStyle = {
        ...baseStyles,
        backgroundColor: 'blue',
        color: 'white',
      };
      break;
    case 'secondary':
      buttonStyle = {
        ...baseStyles,
        backgroundColor: 'white',
        color: 'black',
        border: '1px solid black',
      };
      break;
    default:
      buttonStyle = baseStyles;
  }

  return (
    <button style={{ ...buttonStyle, ...customStyles }}>
      {children}
    </button>
  );
};

export default Button;

With this refactored approach, we’ve made the Button component open for extension. We can now add new variants without modifying the component's source code.
For example:

<Button variant="warning" customStyles={{ backgroundColor: 'yellow', color: 'red' }}>Danger!</Button>

This way, the Button component is closed for modification but open for extension, adhering to the Open/Closed Principle.

3. Liskov Substitution Principle (LSP)

Objects of a superclass should be replaceable with objects of its subclasses.

In simpler terms, if you have a hierarchy of classes where one class inherits from another, you should be able to substitute instances of the child class wherever instances of the parent class are expected, and the program should still behave as intended.

In the context of React, applying LSP means that a child component should be able to replace its parent component without causing any unexpected behavior.

Let’s take an example:-

const Button = ({ onClick, children }) => {
  return (
    <button onClick={onClick}>{children}</button>
  );
};

const PrimaryButton = ({ children }) => {
  return (
    <button style={{ backgroundColor: 'blue', color: 'white' }}>{children}</button>
  );
};

The PrimaryButton here is styled differently, but it doesn't accept or pass along the onClick prop, meaning it can't fully replace Button in all contexts where a button's click functionality is required.

Let’s Refactor it, so it follows LSP

const PrimaryButton = ({ onClick, children }) => {
  return (
    <button onClick={onClick} style={{ backgroundColor: 'blue', color: 'white' }}>
      {children}
    </button>
  );
};

Now, PrimaryButton can be used anywhere Button is used, adhering to LSP. It can handle clicks and display children just like Button, but with additional styling.

4. Interface Segregation Principle (ISP)

No code should be forced to depend on methods it does not use.

The Interface Segregation Principle (ISP) in React emphasizes that components should only depend on the props that they actually use.

Let’s explore this concept further with an example:

const User = ({ item }) => {
  return (
    <View>
      <h1>{item.name}</h1>
      <Text>{item.description}</Text>
    </View>
  );
};

In this example, the User component receives an item prop, which contains multiple fields, however, the component only needs name, and description from the item prop.

To adhere to the ISP, we should modify the User component to only accept the specific props it needs:

const User = ({ name, description }) => {
  return (
    <View>
      <h1>{item.name}</h1>
      <Text>{item.description}</Text>
    </View>
  );
};

By doing so, we ensure that the component is not dependent on props it doesn’t use, aligning with the principles of ISP.
This makes the component more focused, maintainable, and easier to reason about.

5. Dependency Inversion Principle (DIP)

one should depend upon abstractions, not concretions

In simple words, one component shouldn’t directly depend on another component, but rather they both should depend on some common abstraction.

Let’s take an example to understand this.

const CreateListItemForm = () => {
  const handleCreateListItemForm = async (e) => {
    try {
      const formData = new FormData(e.currentTarget);
      await axios.post("https://myapi.com/listItems", formData);
    } catch (err) {
      console.error(err.message);
    }
  };

  return (
    <form onSubmit={handleCreateListItemForm}>
      <input name="title" />
      <input name="description" />
      <input name="image" />
    </form>
  );
};

In this example, the CreateListItemForm component directly handles the logic for creating a list item, including sending a POST request to an API endpoint. However, if we need another form for editing list items with similar UI but different logic, the CreateListItemForm would be unreusable.

Let’s refactor it:

const ListItemForm = ({ onSubmit }) => {
  return (
    <form onSubmit={onSubmit}>
      <input name="title" />
      <input name="description" />
      <input name="image" />
    </form>
  );
};

Now, we’ve created a generic ListItemForm component that only focuses on rendering the form UI and calls the onSubmit function provided via props when the form is submitted. This component is agnostic to the specific logic for creating or editing list items.

const CreateListItemForm = () => {
  const handleCreateListItem = async (e) => {
    try {
      const formData = new FormData(e.currentTarget);
      await axios.post("https://myapi.com/listItems", formData);
    } catch (err) {
      console.error(err.message);
    }
  };

  return <ListItemForm onSubmit={handleCreateListItem} />;
};

const EditListItemForm = () => {
  const handleEditListItem = async (e) => {
    try {
      // Editing logic
    } catch (err) {
      console.error(err.message);
    }
  };

  return <ListItemForm onSubmit={handleEditListItem} />;
};

By following these SOLID principles, we can create robust and maintainable React applications that are easy to understand and modify. Remember, a little bit of upfront design can save a lot of headaches down the line.
Happy coding!

In case you want to connect with me:-

Twitter(X)
LinkedIn
Github

Introduction:

In the world of web development, efficiency and speed are paramount. Developers constantly seek tools that streamline the deployment process while maintaining performance and reliability.

What is Vercel?

Vercel is a cloud platform designed to simplify the deployment process for web applications, particularly those built with modern frameworks like React, Next, etc.
It lets you deploy their front end stupidly easily.

Beyond the frontend-as-a-service offering, Vercel has consistently released features to make it a one-stop solution to build your entire application:

1. Edge Functions:- let you write backend code serverless to handle things like authentication etc.
2. Analytics:- statistics and dashboards on your site’s performance and accessibility.
3. CLI / API:- interact programmatically with Vercel to run deployments, performance checks, etc.

Vercel operates on serverless architecture combined with a global content delivery network (CDN).

How Does Vercel Work on a High Level:

Deploying a website on Vercel typically follows a three-stage process at a high level:

1. Uploading the Project Files.
2. Creating the Deployment.
3. Request Phase.

Uploading the Project Files:-

A POST request is made containing the project’s files to be uploaded to a scalable, secure, and highly durable data storage service.
In simple words, it takes the files from your GitHub Repository and then uploads them to something like AWS S3.

Creating the deployment:-

Once the files have been uploaded successfully to the storage service, another POST request is made to start the build and deployment process.

Here’s a breakdown of the deployment process on Vercel:

1. Authentication and Validation: Vercel authenticates the user and checks the request’s authenticity and permissions against the vercel.json file to prevent unauthorized access.
2. Scheduling Build: If everything checks out, the deployment is scheduled for building.
3. Tracking Build Progress: While processing files, the build container pings an API endpoint to track deployment status, visible in the CLI and dashboard.
4. Ready for CDN: Once resources are provisioned and metadata is uploaded, the deployment is ready to be served via the Vercel CDN

In Simple words and keeping all the complex things as a black box, the Deployment Service grabs the repository code from the Storage location (like S3) and then builds that project and stores the build in the Storage.

Request Phase:-

After deployment, you receive a URL for your website, such as myapp.vercel.app which you can use to access it.

Let’s delve into how Vercel accomplishes this behind the scenes:

1. DNS Lookup: When you type a website’s address, Vercel uses smart routing to make sure your request reaches the closest data center, which makes the website load faster.
2. Content Serving: Different types of content like static pages, special functions, or optimized images are served accordingly.
3. Caching: Vercel caches some of the stuff it sends you, so the next time you ask for it, it can give it to you faster.

Services Vercel uses:-

1. Amazon S3
2. Amazon Simple Queue Service
3. Auto-scaling fleet of EC2 instances powered by AWS Fargate
4. Amazon Global Accelerator
5. AWS Global Network
6. Amazon EKS
7. AWS Lambda

Wasn’t it fascinating to learn how Vercel operates behind the scenes?
Now, let’s move on to the second part of our blog, where we’ll embark on building something similar to Vercel.

Crafting Your Vercel

Disclaimer:- Our aim is to create a simplified version of Vercel, enabling the deployment of React projects. While prioritizing learning, we’ll initially overlook considerations like security, scalability, practices, and performance. These aspects may be addressed in future iterations or separate blog posts.

Similar to Vercel’s three-stage process, we’ll divide our project into three parts:

1. Upload Service
2. Deploy Service
3. Request Service

System Design

Let’s dive inside the System Design of how our project works:

1. Upload Service

From the client side, the Upload Server receives the URL of the GitHub repository. This URL is utilized to clone the project from GitHub. Once the project is successfully cloned into the system, the server generates a unique ID and uploads the project to AWS S3 using that ID. Subsequently, the server stores this ID in a queue, which will facilitate the Deploy Server. For the queue, options such as Redis or AWS SQS can be employed. Finally, the server sends back the ID to the client.

2. Deploying Service

From the queue, the Deploy Server retrieves an ID and proceeds to clone the project stored in S3 (Object Storage). Once the project is cloned, the server executes npm install and npm run build to build the project. Following this, the server stores dist (build of the project) on S3.

The number of servers deployed — whether one, two, or more — depends on the quantity of IDs received from the queue. This scalability can be achieved using auto-scaling mechanisms like AWS Fargate.

3. Request Phase

After the deployment phase, users can access their website by visiting dist<id>.vercel.app/index.html

When a user sends a request to the server, the server retrieves the build from S3 using the<id>and serves it back to the user. This build typically includes HTML, CSS, JavaScript, and other necessary files.

This concludes the high-level system design overview of our project’s functionality.
Now, let’s delve deeper and begin writing the code to bring this project to life.

Code: Let’s roll up our sleeves and dive in!

To facilitate the entire functionality, we will employ three servers, each handling one of the three services.

Let’s start with the upload server.

Upload Server

At a high level, the Upload Server is responsible for receiving the GitHub repository URL from the client side, cloning the repository onto the system, and then uploading it to cloud storage.
For this project, we’ve decided to use Cloudflare R2 instead of AWS S3, as it offers similar functionality, and Cloudflare provides a free tier for R2, making it an excellent choice for our needs. Additionally, we’ll utilize an AWS SDK for compatibility with Cloudflare R2.

Now, let’s discuss the required tech stack and dependencies to get started with the coding process:-

1. Node.js
2. TypeScript
3. Redis(for queue part)
4. NPM Packages:- express, redis, aws-sdk, simple-git, cors, dotenv
5. Cloudflare

Create a typescript project and do basic configuration like

1. Change rootDir to src
2. Change outDir to dist

This is how the directory structure will look like

Index.ts

import express from "express";
import cors from "cors";
import simpleGit from "simple-git";
import { generate } from "./utils";
import { getAllFiles } from "./file";
import path from "path";
import { uploadFile } from "./aws";
import { createClient } from "redis";

const publisher = createClient(); // to store id in the queue
publisher.connect();

const subscriber = createClient(); // to store about the status being uploaded or deployed
subscriber.connect();

const app = express();
app.use(cors());
app.use(express.json());

app.post("/deploy", async (req, res) => {
  const repoUrl = req.body.repoUrl;
  const id = generate(); // something like asd12
  await simpleGit().clone(repoUrl, path.join(__dirname, `output/${id}`)); // clones the repo in dist/output

  const files = getAllFiles(path.join(__dirname, `output/${id}`));

  files.forEach(async (file) => {
    const filename = path.relative(__dirname, file).replace(/\\/g, "/");
    await uploadFile(filename, file); // upload all the files to the R2 bucket
  });

  await new Promise((resolve) => setTimeout(resolve, 5000)); // waiting for 5 seconds so that id does not get stored in the queue
  // before the code gets deployed to R2

  publisher.lPush("build-queue", id);  // store the id in the queue shared by upload service and deploy service
  publisher.hSet("status", id, "uploaded"); // store the status in redis regarding project being uploaded or deployed

  res.json({
    id: id,
  });
});

app.get("/status", async (req, res) => {  // api to get the status of the project
  const id = req.query.id;
  const response = await subscriber.hGet("status", id as string);
  res.json({
    status: response,
  });
});

app.listen(3000);

What does this code do:-
When the /deploy API is accessed, the first step is to extract the GitHub URL from the request body. Subsequently, we generate a random ID using a generate function. Following this, we clone the project from GitHub using simpleGit and store it in dist/output/<id>.

Next, we create an array containing the paths of all the files in that repository. We then iterate over this array and store each file of the repository in Cloudflare R2, structured under output/<id>/<files>.

After this, we store the ID in the Redis queue, which will be consumed by the next service. Additionally, we store the status of that project as “uploaded” in a Redis set. Finally, we return the user ID as a response.

aws.ts

require("dotenv").config();
import { S3 } from "aws-sdk";
import fs from "fs";

const s3 = new S3({
  endpoint: process.env.ENDPOINT,
  accessKeyId: process.env.ACCESSKEYID,
  secretAccessKey: process.env.SECRETACCESSKEY,
});

export const uploadFile = async (fileName: string, localFilePath: string) => {
  const fileContent = fs.readFileSync(localFilePath);
  const response = await s3
    .upload({
      Body: fileContent,
      Bucket: "vercel",
      Key: fileName,
    })
    .promise();
  console.log(response);
};

file.ts

import fs from "fs";
import path from "path";

export const getAllFiles = (folderPath: string) => {
  let response: string[] = [];

  const allFilesAndFolders = fs.readdirSync(folderPath);
  allFilesAndFolders.forEach((file) => {
    const fullFilePath = path.join(folderPath, file);
    if (fs.statSync(fullFilePath).isDirectory()) {
      response = response.concat(getAllFiles(fullFilePath));
    } else {
      response.push(fullFilePath);
    }
  });
  return response;
};

utils.ts

const MAX_LEN = 5;

export function generate() {
  let ans = "";
  const subset = "123456789qwertyuiopasdfghjklzxcvbnm";
  for (let i = 0; i < MAX_LEN; i++) {
    ans += subset[Math.floor(Math.random() * subset.length)];
  }
  return ans;
}

.env

ENDPOINT = "cloudflare R2 end point"
ACCESSKEYID = ""
SECRETACCESSKEY = ""

Now, let’s delve into how the Deploy Server operates.

Deploy Server

In the Deploy Server, an infinite loop is initiated to continuously monitor the presence of an ID in the Redis queue. When an ID is detected, it is dequeued, and the deployment process begins.

Initially, the project associated with that ID is downloaded from our R2 Bucket. Subsequently, the project is built, which typically involves running npm install followed by npm run build.

Once the build process is completed, the generated dist the directory in that project is stored back in the R2 bucket, utilizing dist/<id> as the path.

After successfully storing the build in the bucket, the status in the Redis set is updated from “uploaded” to “deployed”.

Now, let’s discuss about dependencies to get started with this:-

1. install npm packages:- aws-sdk, dotenv, redis

Create a typescript project and do basic configuration like

1. Change rootDir to src
2. Change outDir to dist

This is how the directory structure will look like

index.ts

import { createClient, commandOptions } from "redis";
import { copyFinalDist, downloadS3Folder } from "./aws";
import { buildProject } from "./utils";
const subscriber = createClient();  // to get the id from the redis-queue
subscriber.connect();

const publisher = createClient(); // to change the status to deployed
publisher.connect();

async function main() {
  while (1) {
    const res = await subscriber.brPop( //checks if there is any id in queue or not
      commandOptions({ isolated: true }),
      "build-queue",
      0
    );
    const id = res.element;

    await downloadS3Folder(`output/${id}`); // download the project
    await buildProject(id); // build the project
    copyFinalDist(id);  // copy it back to the R2 bucket
    publisher.hSet("status", id, "deployed"); // sets the status as deployed
  }
}
main();

utils.ts

import { exec, spawn } from "child_process";
import path from "path";

export function buildProject(id: string) {
  return new Promise((resolve) => {
    const child = exec(
      `cd ${path.join(
        __dirname,
        `output/${id}`
      )} && npm install && npm run build`
    );

    child.stdout?.on("data", function (data) {
      console.log("stdout: " + data);
    });
    child.stderr?.on("data", function (data) {
      console.log("stderr: " + data);
    });

    child.on("close", function (code) {
      resolve("");
    });
  });
}

We utilize the exec method to instantiate a child process within the current server environment. This process navigates to the directory dist/output/<id>, where it sequentially executes npm install to install all project dependencies. Following this, the command npm run build is executed to generate a build directory named dist within the repository. Given the asynchronous nature of these tasks, we employ a promise to await their completion before advancing to the next steps.

aws.ts

import { S3 } from "aws-sdk";
import fs from "fs";
import path from "path";
require("dotenv").config();
const s3 = new S3({
  endpoint: process.env.ENDPOINT,
  accessKeyId: process.env.ACCESSKEYID,
  secretAccessKey: process.env.SECRETACCESSKEY,
});

// output/asdasd
// to download all the files from R2 bucket to server in the dist/output/<id>
export async function downloadS3Folder(prefix: string) {
  const allFiles = await s3
    .listObjectsV2({
      Bucket: "vercel",
      Prefix: prefix,
    })
    .promise();

  //
  const allPromises =
    allFiles.Contents?.map(async ({ Key }) => {
      return new Promise(async (resolve) => {
        if (!Key) {
          resolve("");
          return;
        }
        const finalOutputPath = path.join(__dirname, Key);
        const outputFile = fs.createWriteStream(finalOutputPath);
        const dirName = path.dirname(finalOutputPath);
        if (!fs.existsSync(dirName)) {
          fs.mkdirSync(dirName, { recursive: true });
        }
        s3.getObject({
          Bucket: "vercel",
          Key,
        })
          .createReadStream()
          .pipe(outputFile)
          .on("finish", () => {
            resolve("");
          });
      });
    }) || [];
  console.log("awaiting");

  await Promise.all(allPromises?.filter((x) => x !== undefined));
}
// to store the build in R2 bucket
export function copyFinalDist(id: string) {
  const folderPath = path.join(__dirname, `output/${id}/dist`);
  const allFiles = getAllFiles(folderPath);
  allFiles.forEach((file) => {
    uploadFile(
      (`dist/${id}/` + file.slice(folderPath.length + 1)).replace(/\\/g, "/"),
      file
    );
  });
}
// this function generates an array of path all the files in the folder
const getAllFiles = (folderPath: string) => {
  let response: string[] = [];

  const allFilesAndFolders = fs.readdirSync(folderPath);
  allFilesAndFolders.forEach((file) => {
    const fullFilePath = path.join(folderPath, file);
    if (fs.statSync(fullFilePath).isDirectory()) {
      response = response.concat(getAllFiles(fullFilePath));
    } else {
      response.push(fullFilePath);
    }
  });
  return response;
};
// used to upload the files to R2
const uploadFile = async (fileName: string, localFilePath: string) => {
  const fileContent = fs.readFileSync(localFilePath);
  const response = await s3
    .upload({
      Body: fileContent,
      Bucket: "vercel",
      Key: fileName,
    })
    .promise();
  console.log(response);
};

.env

ENDPOINT = "cloudflare R2 end point"
ACCESSKEYID = ""
SECRETACCESSKEY = ""

Let’s talk about the last phase which is the request phase.

Request Phase:-

In the final phase, when a user sends a request to the server with the ID of the deployed project, the server retrieves the build from the R2 bucket and serves it to the user. The build, represented by the dist folder, primarily comprises HTML, CSS, and JavaScript files. These files are essential for rendering the website in the user's browser, as browsers inherently comprehend HTML, CSS, and JavaScript.
While higher-level frameworks like React are used in development, they are ultimately translated into JavaScript code that browsers can process for rendering.

Now, let’s discuss about dependencies to get started with this:-

1. install npm packages:- aws-sdk, dotenv, express

Create a typescript project and do basic configuration like

1. Change rootDir to src
2. Change outDir to dist

This is how the directory structure will look like

index.ts

require("dotenv").config();
import express from "express";
import { S3 } from "aws-sdk";

const s3 = new S3({
  endpoint: process.env.ENDPOINT,
  accessKeyId: process.env.ACCESSKEYID,
  secretAccessKey: process.env.SECRETACCESSKEY,
});

const app = express();

app.get("/*", async (req, res) => {  //  global route catch

  const host = req.hostname;
  const id = host.split(".")[0];
  const filePath = req.path;
  const contents = await s3
    .getObject({
      Bucket: "vercel",
      Key: `dist/${id}${filePath}`,
    })
    .promise();

  const type = filePath.endsWith("html")
    ? "text/html"
    : filePath.endsWith("css")
    ? "text/css"
    : "application/javascript";
  res.set("Content-Type", type);
    console.log(type);
  res.send(contents.Body);
});

app.listen(3001);

In this phase, the server retrieves the project’s ID, fetches the corresponding content from the R2 bucket, and then serves it to the user.

Now, the question arises: how do I test this on a local host environment?

While uploading and deploying are relatively straightforward tasks, verifying the website poses a challenge. Let’s consider an example URL format:

<id>.vercelclone.com:3001/index.html
For instance:- if the ID is “epwic”, the URL would be epwic.vercelclone.com:3001/index.html

To achieve local testing, we can mimic this URL format by renaming localhost to epwic.vercelclone.com (or whatever is your id.vercelclone.com).

MAC

If you are using Mac it’s going to be a piece of cake for you.

1. Open Terminal and write this command.

sudo vi /etc/hosts

2. Write the following thing

127.0.0.1  epwic/vercelclone.com

In this scenario, “epwic” represents the unique ID of my project. Similarly, in your case, you would have a different ID specific to your project.

Windows

In Windows, renaming localhost is kind of complex, so we are going to test it in another way.

In your index.ts code of Request phase, do these changes

app.get("/*", async (req, res) => {

  const id = "ka8u3";
  const filePath = req.path;
  const contents = await s3
    .getObject({
      Bucket: "vercel",
      Key: `dist/${id}${filePath}`,
    })
    .promise();

Here we are manually writing down the id.
The URL is going to be:- http://localhost:3001/index.html

Thanks a lot for reading the entire blog and congrats you now know how Vercel works and how you can create one for yourself.

I’m aware that the code for this project isn’t production-ready and may not adhere to best practices. The primary aim of this blog was to provide an understanding of how Vercel works and how one can create a basic clone of it. If the response to this blog is positive, I’ll consider developing a Vercel clone with production-level code, implementing best practices, and ensuring scalability and security.

Here is a video of how it works:-

In case you want the code:-

1. Vercel Upload Service:- https://github.com/Mayank2808sharma/vercel-uploadService
2. Vercel Deploy Service:- https://github.com/Mayank2808sharma/vercel-deployservice
3. Vercel Request Handler:- https://github.com/Mayank2808sharma/vercel-requesthandler

In case you want to connect with me:-

Twitter(X)
LinkedIn
Github

When building a react application, we often need to fetch data from APIs.

There are mainly two ways to achieve this:- useEffect and React Query.

Now the question is which one to use?

Let's compare useEffect and React Query for fetching data and decide which one to in which case.

Using useEffect to fetch data

UseEffect has been a quick go-to way to fetch data for a long time.

Here is an example:-

const MyComponent = () => {
  
const [data, setData] = useState(null);
  // State to manage loading state
  const [loading, setLoading] = useState(true);
  // State to handle error
  const [error, setError] = useState(null);

  useEffect(() => {
    // Function to fetch data
    const fetchData = async () => {
      try {
      
        setLoading(true);
        // Fetch data from an API
        const response = await fetch('https://api.example.com/data');
        // Parse the JSON response
        const responseData = await response.json();
        // Set the fetched data in state
        setData(responseData);
        // Set loading state to false after data is fetched
        setLoading(false);
      } catch (error) {
        // Set error state if there's an error during fetching
        setError(error.message);
        // Set loading state to false in case of error
        setLoading(false);
      }
    };
    fetchData()
    }, []);

When to Use:

1. Simple Data Fetching:- If your application requires fetching data from an API once, useEffect is a good solution.
2. Basic State Management: For applications with basic state management, where you handle data loading, error, etc manually.

Drawbacks of useEffect:

1. No built-in caching, pagination, or query invalidation support.
2. Loading, Error state has to be handled manually.

Using React Query to fetch data

React Query is a library that handles fetching, caching, synchronizing, and updating state.

Here is an Example:-

import { useQuery } from 'react-query';

const fetchUsers = async () => {
  const response = await fetch('https://jsonplaceholder.typicode.com/users');
  const data = await response.json();
  return data;
};

const UsersList = () => {
  const { data, isLoading, isError } = useQuery('users', fetchUsers);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  if (isError) {
    return <div>Error: Failed to fetch users</div>;
  }

  return (
    <div>
      <h2>Users</h2>
      <ul>
        {data.map(user => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </div>
  );
};

When to Use:

1. Complex Data Requirements: If your application requires features like caching, pagination, background data synchronization, or automatic query invalidation, React Query is the go-to way for you.
2. Streamlined State Management: simplifies data fetching by automatically managing isLoading and isError states internally.
3. Optimistic Updates: React Query smoothly manages to update the user interface (UI) optimistically, meaning it changes what you see on the screen right away, assuming that a change or action will succeed, even before getting confirmation.

Advantages:-

1. Automatic Caching: provides automatic caching, reducing unnecessary network requests and improving performance.
2. Pagination and Infinite Loading: Easily implement pagination and infinite loading with built-in features, simplifying complex UI requirements.
3. Automatic Data Re-fetching: Automatically updates fetched data when changes occur, ensuring that the UI reflects the latest information without manual intervention.

In summary, the choice between React Query and useEffect depends on the complexity of your data fetching requirements.

For simple applications with basic data fetching needs and limited states, useEffect provides a straightforward solution

for most real-world cases — especially when sharing and refetching data across components — React Query will save you time and headaches.

In case you want to connect with me:-

Twitter(X)
LinkedIn
Github