Stories by Bicky Tamang on Medium

The state is fully private to the component declaring it. The parent components can’t change it.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*kN4IIIcp9hhwN-5xlV1K4A.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@lautaroandreani?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Lautaro Andreani</a> on <a href="https://unsplash.com/photos/xkBaqlcqeb4?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Ok! I know that both title and subtitle contradict each other. The title says we can change the state from the parent component, while the subtitle says we cannot since the state is private to the component declaring it. The second statement is true. State is isolated and private. State is local to a component instance on the screen. In other words, if you render the same component twice, each copy will have a completely isolated state! Changing one of them will not affect the other. State is not tied to a particular function call or a place in the code, but it’s “local” to the specific place on the screen. This lets you add a state to any component or remove it without impacting the rest of the components.
However, changing the state of a child from the parent is possible. Let me explain it thoroughly with a real-world example. I have prepared a code sandbox. You can visit the <a href="https://codesandbox.io/s/initial-zcrvot">link</a>. What we have is a Table component with an actions column. The actions column has a Popover component with a link to open a Modal. Once we open the Modal, you can see that the Popover does not automatically closes itself; it is triggered only on a click event.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*PU7UdDXVTZPzzB9IihslLQ.png"><figcaption>After the modal is open, the Popover is still open</figcaption></figure>To control this behavior of Popover, we use open prop, which is a boolean indicating the state of Popover, whether it is open or closed. We define a state and change the state with onOpenChange a callback executed when the visibility of the Popover card is changed. Here, if we define the state in the Table component as shown in the code below, the state is now shared with every instance of the Popover, and we’ll have a different behavior where a state change of a single Popover component triggers all the Popover to open and close at the same time. You can visit the <a href="https://codesandbox.io/s/phase-state-in-parent-17j3qn?file=/src/TableComponent.tsx">codesandbox here</a> for a demo.
<pre>// file: TableComponent.tsx const TableComponent = () =&gt; { const [open, setOpen] = useState(false); const handleOpenChange = (newOpen: boolean) =&gt; { setOpen(newOpen); }; const columns: ColumnsType&lt;DataType&gt; = [ { title: "Name", dataIndex: "name", key: "name", render: (text) =&gt; &lt;a&gt;{text}&lt;/a&gt; }, { title: "Age", dataIndex: "age", key: "age" }, { title: "Address", dataIndex: "address", key: "address" }, { title: "Tags", key: "tags", dataIndex: "tags", render: (_, { tags }) =&gt; ( &lt;&gt; {tags.map((tag) =&gt; { let color = tag.length &gt; 5 ? "geekblue" : "green"; if (tag === "loser") { color = "volcano"; } return ( &lt;Tag color={color} key={tag}&gt; {tag.toUpperCase()} &lt;/Tag&gt; ); })} &lt;/&gt; ) }, { title: "Action", key: "action", render: (_, record) =&gt; ( &lt;Popover content={&lt;Actions /&gt;} trigger="click" open={open} onOpenChange={handleOpenChange} &gt; &lt;EllipsisOutlined style={{ fontSize: 16 }} /&gt; &lt;/Popover&gt; ) } ]; return &lt;Table columns={columns} dataSource={data} pagination={false} /&gt;; };</pre>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*PXGWzT8sg1VAE2i00vqPIg.png"><figcaption>The state defined on the Table component is shared across every popover instance</figcaption></figure>In order to solve this problem, we can put the popover into its own component, which has an internal state that tracks the visibility by itself. The demo is provided <a href="https://codesandbox.io/s/phase-popover-a-separate-component-8u8be6">here</a>. However, we’ve not yet solved the first issue we discussed of autoclosing the popover when the modal is open. Now, we have control over the state of popover. All that’s left to do is set the state of popover to false when we click on the Open Modal. But how can we achieve it? Since the state is created in the child component (PopoverComponent) and to update it from the parent component (TableComponent), we can use the ref attribute. We expose the setOpen function to the parent component using useImperativeHandle and a ref.
In React, it’s generally recommended to keep as much state and logic as possible within the components that need it. However, there are cases where it’s necessary for a parent component to be able to call a method or access a property of a child component. This is where useImperativeHandle comes in.
useImperativeHandle is a React hook that allows you to expose certain functions or methods of a child component to its parent component. It takes two arguments: a ref object and a function that returns an object containing the exposed methods. The updated popover component looks something like this:
<pre>// file: PopoverComponent.tsx import React, { useState, useImperativeHandle } from "react"; import { Popover, PopoverProps } from "antd"; export type OpenState = { setOpen: (visible: boolean) =&gt; void; }; const PopoverComponent = React.forwardRef&lt;OpenState, PopoverProps&gt;( ({ ...rest }, ref) =&gt; { const [open, setOpen] = useState(false); // expose the setOpen function to the parent component using useImperativeHandle useImperativeHandle(ref, () =&gt; ({ setOpen(visible: boolean) { setOpen(visible); } })); return ( &lt;Popover open={open} onOpenChange={(newOpen: boolean) =&gt; setOpen(newOpen)} {...rest} &gt; {rest.children} &lt;/Popover&gt; ); } ); export { PopoverComponent as Popover };</pre>
We have defined a OpenState type, which is used to define the interface of the ref object that is returned from React.forwardRef. The OpenState interface defines a single property, setOpenwhich is a function that takes a boolean value and returns void. The useImperativeHandle hook is used to expose the setOpen function to the parent component using the ref object. This function can be called by the parent component to set the value of the open state within the PopoverComponent.
<pre>// file: TableComponent.tsx import { useRef, useState } from "react"; .... const TableComponent = () =&gt; { const popoverOpenRef = useRef(null); .... const columns: ColumnsType&lt;DataType&gt; = [ ...., { title: "Action", key: "action", render: (_, record) =&gt; ( &lt;Popover ref={popoverOpenRef} content={ &lt;Actions showModal={showModal} popoverOpenRef={popoverOpenRef} /&gt; } trigger="click" &gt; &lt;EllipsisOutlined style={{ fontSize: 16 }} /&gt; &lt;/Popover&gt; ) } ]; ....</pre>
<pre>// file: Actions.tsx import { OpenState } from "./PopoverComponent"; interface ActionsProps { showModal: () =&gt; void; popoverOpenRef: React.RefObject&lt;OpenState&gt;; } const Actions: React.FC&lt;ActionsProps&gt; = ({ showModal, popoverOpenRef }) =&gt; ( &lt;&gt; &lt;p style={{ fontSize: "16px", cursor: "pointer", fontWeight: 700 }} onClick={() =&gt; { showModal(); popoverOpenRef.current?.setOpen(false); }} &gt; Open Modal &lt;/p&gt; &lt;/&gt; ); export default Actions;</pre>
In the Table component, we create a popoverOpenRef using useRef, and pass it to the PopoverComponent using the ref prop. Finally, we pass in the popoverOpenRef prop to the Actions component and in the onClick handler, we call the setOpen function on the popoverOpenRef to update the state of the PopoverComponent to false.
<blockquote>The Actions component is typed using an interface ActionsProps, which defines the expected types for the props. The showModal prop is defined as a function that takes no arguments and returns void. The popoverOpenRef prop is defined as a React Ref object that refers to the OpenState type.</blockquote>
The final demo of the project can be found <a href="https://codesandbox.io/s/final-mub2b0?file=/src/Actions.tsx">here</a>.
<h3>Conclusion</h3>
With this, the first issue we discussed of autoclosing the Popover when the modal is open is solved, and through this example, we got a brief overview of how we can update the children's internal state from the parent component with the help of useImperativeHandle react hook.
Happy coding! See you in the next article.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=3975a73c12ba" width="1" height="1" alt=""><hr>
<a href="https://articles.wesionary.team/how-to-update-the-internal-state-of-the-child-component-from-the-parent-component-3975a73c12ba">How to update the internal state of the child component from the parent component?</a> was originally published in <a href="https://articles.wesionary.team/">wesionaryTEAM</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to update the internal state of the child component from the parent component?

React Query is one of the most robust libraries in the React ecosystem which handles many challenges related to fetching, updating, caching, and retries.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*y0iG9ihK2mKSq29Ar1uutQ.jpeg"><figcaption>Infinite Scroll using React Query</figcaption></figure>Infinite Scroll is a common pattern of loading chunks of data as the user scrolls toward the end of the loaded content. A common example is Facebook's news feed where you keep on scrolling as there is no end to it. It is often used to provide a more seamless and engaging browsing experience for users. Another common pattern is pagination.
In this article, we’ll be loading a bunch of to-dos content from JSONPlaceholder. JSONPlaceholder is a free online REST API that you can use whenever you need some fake data. This is what we’re going to build:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ZXrM1Nbo1VH3s6zehVSRnA.png"></figure><h3>Installation</h3>
You can clone the starter project from GitHub. In this article, we’re solely going to focus on React Query implementation for infinite scroll so I’ve already installed the necessary packages in the starter repo. You can try it out using the following commands:
<pre>git clone -b starter https://github.com/bicky-tmg/react-query-infinite-scrolling.git cd react-query-infinite-scrolling npm install</pre>
If you look into App.js and a bunch of files you might notice React Query has been configured for you and a sample implementation has also been done. Hit npm run start in the terminal. Visit http://locahost:3000 if not redirected to the browser and voilà.
React Query supports a useful version of useQuery hook called useInfiniteQuery for rendering a list of additive data onto an existing set of data which is a common pattern known as as ‘Infinite Scroll’. useInfiniteQuery hook includes a bunch of options and returns an object that contains a bunch of useful properties. We’ll only discuss those options and properties that we’ll be implementing throughout this article.
Options
queryKey : Query keys are unique to the query’s data. It can be as simple as an Array with a single string, or as complex as an array of many strings and nested objects.
queryFn : The function that the query will use to request data. In our case, we’ll be passing in pageParams with a default value of 1 to the queryFn.
getNextPageParam : It helps to determine if there is more data to load and the information to fetch it. This information is either a single variable that is supplied as an additional parameter in the query function or undefined indicates there is no next page available. When new data is received for this query, this function receives both the last page of the infinite list of data and the full array of all pages.
Returns
data : The returned data is an object containing infinite query data. The object consists of;
<ul>
<li>data.pages an array containing the fetched pages</li>
<li>data.pageParams an array containing the page params used to fetch the pages.</li>
</ul>
hasNextPage : It is a boolean true if getNextPageParam returns a value other than undefined
fetchNextPage : This function allows fetching the next “page” of results. You can manually specify a pageParam instead of using getNextPageParam .
isFetchingNextPage : It is a boolean true while fetching the next page with fetchNextPage . It helps to distinguish between a background refresh state and a loading more state.
Now that we have basic information about all the options and return properties of the useInfiniteQuery hook let’s get started with the project.
<h3>Let's get started</h3>
In the App.js file replace the import of useQuery hook with useInfiniteQuery hook. Then we need to make changes to the query function fetchTodos as below:
<pre>// file: App.js function App() { const LIMIT = 10; const fetchTodos = async (page) =&gt; { const response = await fetch( `https://jsonplaceholder.typicode.com/todos?_page=${page}&amp;_limit=${LIMIT}` ); return response.json(); }; ...</pre>
Here the fetchTodos accepts a page as an argument and will fetch the todos per page basis. We’ve also added a LIMIT constant of 10 which limits the page size to 10. The data fetched will be at most 10. Next, completely replace the useQuery hook with the below code:
<pre>// file: App.js const { data, isSuccess, hasNextPage, fetchNextPage, isFetchingNextPage } = useInfiniteQuery("todos", ({ pageParam = 1 }) =&gt; fetchTodos(pageParam), { getNextPageParam: (lastPage, allPages) =&gt; { const nextPage = lastPage.length === LIMIT ? allPages.length + 1 : undefined; return nextPage; }, });</pre>
Woah! What the hell is this? You don’t have to panic let’s break down the code step by step. The useInfiniteQuery hook takes three arguments: The first argument is a string representing the query key, which is used to identify the query in the cache. The second argument is a function that takes an object containing a pageParam property (which defaults to 1 if not provided) and returns a promise that resolves to the todos for that page. The third argument is an object containing options for the query, such as a getNextPageParam function that indicates whether a next page is available or not. The function receives both the last page of the infinite list of data and the full array of all pages. The function checks if the lastPage array has a length of LIMIT indicating that the last page was a full page of todos. Then it sets nextPage to allPages.length + 1, indicating that there is at least one more page to fetch. Otherwise, it sets nextPage to undefined, indicating that there are no more pages to fetch. It might not be the best logic for now but it works for us. The return value nextPage is passed into the queryFn in our case tofetchTodos under the hood by React Query. Now we need to change how we render the data object onto our UI.
<pre>// file: App.js function App() { ... return ( &lt;div className="app"&gt; {isSuccess &amp;&amp; data.pages.map((page) =&gt; page.map((todo, i) =&gt; ( &lt;article className="article"&gt; &lt;h2&gt;{todo.title}&lt;/h2&gt; &lt;p&gt;Status: {todo.completed ? "Completed" : "To Complete"}&lt;/p&gt; &lt;/article&gt; )) )} &lt;/div&gt; ); }</pre>
With these changes, the fetched todos must be displayed on the browser. So far what we’ve done is fetched the todos using useInfiniteQuery hook. We’ve laid down the groundwork for the infinite scrolling to work. To make it work we need to call the fetchNextPage hook whenever we scroll down to the last fetched todo. In order to achieve this we’ll be using a package called react-intersection-observer it is the React implementation of the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API">Intersection Observer API</a> to tell you when an element enters or leaves the viewport. Let’s install the package using the following command:
<pre>npm i react-intersection-observer</pre>
Once the package has been installed we need to import the package. Right below our React Query import, import the react-intersection-observer :
<pre>// file: App.js import { useInfiniteQuery } from "react-query"; import { useInView } from "react-intersection-observer";</pre>
React Intersection Observer provides us with the useInView hook. The useInView hook makes it easy to monitor the inView state of the components. It will return an array containing a ref, the inView status, and the current entry. We need to assign the ref to the DOM element we want to monitor, and the hook will report the status.
<pre>// file: App.js function App() { const { ref, inView } = useInView(); const LIMIT = 10; ...</pre>
In our case, we need to attach the ref to the last fetched todo. But before that let’s create a separate Todo component. Create a Todo.js file and paste the code below:
<pre>// file: Todo.js import React from "react"; const Todo = React.forwardRef(({ todo }, ref) =&gt; { const todoContent = ( &lt;&gt; &lt;h2&gt;{todo.title}&lt;/h2&gt; &lt;p&gt;Status: {todo.completed ? "Completed" : "To Complete"}&lt;/p&gt; &lt;/&gt; ); const content = ref ? ( &lt;article className="article" ref={ref}&gt; {todoContent} &lt;/article&gt; ) : ( &lt;article className="article"&gt;{todoContent}&lt;/article&gt; ); return content; }); export default Todo;</pre>
Here since we will be assigning the ref from the useInView hook, we need to forward the ref down to the Todo component from App component. Ref forwarding is an opt-in feature that lets some components take a ref they receive, and pass it further down (in other words, “forward” it) to a child. React passes the ref to the ({todo}, ref) =&gt; ... function inside forwardRef as a second argument. We forward this ref argument down to &lt;article className=”article” ref={ref}&gt; by specifying it as a JSX attribute. When the ref is attached, ref.current will point to the &lt;article&gt; DOM node. Since we don’t want to attach ref to the list of todos, only the last todo from the fetched lists which will be covered later. The code below describes the implementation of attaching if ref has been passed attach the ref else not.
<pre>const content = ref ? ( &lt;article className="article" ref={ref}&gt; {todoContent} &lt;/article&gt; ) : ( &lt;article className="article"&gt;{todoContent}&lt;/article&gt; );</pre>
Now in App.js, we need to import the Todo component and make changes as:
<pre>// file: App.js import { useInfiniteQuery } from "react-query"; import { useInView } from "react-intersection-observer"; import Todo from "./Todo"; import "./App.css"; function App() { const { ref, inView } = useInView(); const LIMIT = 10; const fetchTodos = async (page) =&gt; { const response = await fetch( `https://jsonplaceholder.typicode.com/todos?_page=${page}&amp;_limit=${LIMIT}` ); return response.json(); }; const { data, isSuccess, hasNextPage, fetchNextPage, isFetchingNextPage } = useInfiniteQuery("todos", ({ pageParam = 1 }) =&gt; fetchTodos(pageParam), { getNextPageParam: (lastPage, allPages) =&gt; { const nextPage = lastPage.length === LIMIT ? allPages.length + 1 : undefined; return nextPage; }, }); const content = isSuccess &amp;&amp; data.pages.map((page) =&gt; page.map((todo, i) =&gt; { if (page.length === i + 1) { return &lt;Todo ref={ref} key={todo.id} todo={todo} /&gt;; } return &lt;Todo key={todo.id} todo={todo} /&gt;; }) ); return ( &lt;div className="app"&gt; {content} &lt;/div&gt; ); } export default App;</pre>
What changes have we done? We imported the Todo component and slightly updated the JSX content.
<pre>// file: App.js const content = isSuccess &amp;&amp; data.pages.map((page) =&gt; page.map((todo, i) =&gt; { if (page.length === i + 1) { return &lt;Todo ref={ref} key={todo.id} todo={todo} /&gt;; } return &lt;Todo key={todo.id} todo={todo} /&gt;; }) ); return ( &lt;div className="app"&gt; {content} &lt;/div&gt; );</pre>
if (page.length === i + 1) indicates we are attaching ref to the last todo from the list of fetched todos. If it is the last todo from the list, attach ref else not. We’re almost at the end of this article. Now all that’s left is to monitor the last article dom node where the ref is attached using the inView state returned from useInView hook and if it hasNextPage we will fetchNextPage . We can achieve it through the code below:
<pre>// file: App.js useEffect(() =&gt; { if (inView &amp;&amp; hasNextPage) { fetchNextPage(); } }, [inView, fetchNextPage, hasNextPage]);</pre>
We also need to know when our data is being fetched so we can add a loader indicating that the Todo is being fetched using the isFetchingNextPage boolean provided by the useInfiniteQuery hook:
<pre>// file: App.js func App() { ... return ( &lt;div className="app"&gt; {content} {isFetchingNextPage &amp;&amp; &lt;h3&gt;Loading...&lt;/h3&gt;} &lt;/div&gt; ); }</pre>
To summarize what we’ve done so far in the App.js file:
<pre>// file: App.js import { useEffect } from "react"; import { useInfiniteQuery } from "react-query"; import { useInView } from "react-intersection-observer"; import Todo from "./Todo"; import "./App.css"; function App() { const { ref, inView } = useInView(); const LIMIT = 10; const fetchTodos = async (page) =&gt; { const response = await fetch( `https://jsonplaceholder.typicode.com/todos?_page=${page}&amp;_limit=${LIMIT}` ); return response.json(); }; const { data, isSuccess, hasNextPage, fetchNextPage, isFetchingNextPage } = useInfiniteQuery("todos", ({ pageParam = 1 }) =&gt; fetchTodos(pageParam), { getNextPageParam: (lastPage, allPages) =&gt; { const nextPage = lastPage.length === LIMIT ? allPages.length + 1 : undefined; return nextPage; }, }); useEffect(() =&gt; { if (inView &amp;&amp; hasNextPage) { fetchNextPage(); } }, [inView, fetchNextPage, hasNextPage]); const content = isSuccess &amp;&amp; data.pages.map((page) =&gt; page.map((todo, i) =&gt; { if (page.length === i + 1) { return &lt;Todo ref={ref} key={todo.id} todo={todo} /&gt;; } return &lt;Todo key={todo.id} todo={todo} /&gt;; }) ); return ( &lt;div className="app"&gt; {content} {isFetchingNextPage &amp;&amp; &lt;h3&gt;Loading...&lt;/h3&gt;} &lt;/div&gt; ); } export default App;</pre>
With this, new todos will be fetched when we scroll to the bottom of the page in our app.
<blockquote>Note: For better user experience what can be done is instead of detecting the visibility of the last element/todo for fetching the next list of todos if available, we can attach ref to the third last element/todo so when the third last element/todo is visible we fetch the next list of todos already and the user will not have to wait for a loading state which provides a smooth and seamless experience. All we need to do is change the logic in App.js .</blockquote>
<blockquote>From if (page.length === i + 1)</blockquote>
<blockquote>to if (page.length &gt;= 3 &amp;&amp; page.length — 3 === i</blockquote>
<h3>Conclusion</h3>
In this article, we covered how to implement Infinite Scroll using the React Query along with a very easy-to-use React Intersection Observer package.
For the next steps, you can dive into <a href="https://react-query-v3.tanstack.com/">React Query's</a> official documentation page to learn more advanced concepts.
If you are interested to see how the code would look altogether, you can take a look at the <a href="https://github.com/bicky-tmg/react-query-infinite-scrolling.git">GitHub repository</a>.
Happy coding! See you in the next article.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5fd7c425908f" width="1" height="1" alt=""><hr>
<a href="https://articles.wesionary.team/how-to-implement-infinite-scroll-using-react-query-5fd7c425908f">How to implement infinite scroll using React Query?</a> was originally published in <a href="https://articles.wesionary.team/">wesionaryTEAM</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to implement infinite scroll using React Query?

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ltTs-gGGHWsumjxpj0xXIw.png"></figure><h3>What is a Monorepo?</h3>
A monorepo (“mono” meaning ‘single’, and “repo” is short for ‘repository’) is a single repository that holds multiple distinct projects. The projects have well-defined relationships, run by different teams with many engineers working on them simultaneously. Monorepo is often confused with a monolithic architecture, while a monolith combines its sub-projects into one large project, a monorepo may contain independent projects. Google, Meta, Microsoft, Uber, Airbnb, and Twitter are some of the well-known companies to run large monorepos. Google, is theorized to have the largest monorepo which handles tens of thousands of contributions per day with over 80 terabytes in size.
<h3>Advantages of Monorepo</h3>
There are a number of potential advantages but at the highest level:
<ul>
<li>
Visibility: It gives the visibility of the entire company’s code base without the need to clone and track down a bunch of repos. This leads to better collaboration and cross-team contribution.</li>
<li>
Consistency: It provides consistency because similar functionality can be abstracted into a shared library like a UI library of web components for your design system, eslint config, documentation, etc can be directly included by projects.</li>
<li>
Dependency management: In a multiple repository environment where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo, the build can be easily optimized, as referenced dependencies all exist in the same codebase. Also, monorepo tools can help visualize the entire dependency graph of the application.</li>
<li>
Atomic commits: When projects that work together are contained in separate repositories, releases need to sync which versions of one project work with the other. In a monorepo, this problem can be negated, since developers may change multiple projects atomically.</li>
<li>A monorepo is also ideal for continuous integration and automation (CI/CD) because your code is all unified by default making it much easier to build and test everything together.</li>
</ul>
<h3>Limitations</h3>
The problem with monorepos is the fact that they are big. With a monorepo, you check out all projects by default. This can take up a significant amount of storage space. A monorepo gives access to the whole codebase possibly presenting new security issues. As the monorepo becomes bigger there are more things to test, and more things to build. The code editor will start lagging trying to process the massive git history. And you’ll need to wait for everything to run on the CI server after every commit. To operate a monorepo in scale, it’s essential to have the right tooling.
<h3>Tools</h3>
Proper tooling is key for effective monorepos. There are different tools for managing monorepos and the toolset is constantly growing. In this article, we’ll be discussing tools that are getting more attention in the JavaScript realm:
<ul>
<li>Turborepo</li>
<li>Lerna</li>
</ul>
<h3>Turborepo</h3>
Turborepo is a high-performance build system for JavaScript and TypeScript codebases. The basic principle of Turborepo is to never recompute work that has been done before so basically, Turborepo can cache the results and logs of any task in the codebase. By default, Turborepo only caches to the local filesystem so the same task gets re-executed on each machine. This can result in a lot of duplicated work when you’re working with a CI. Remote caching, Turborepo can store the results of the tasks in a cloud server (Vercel), this provides a single remote cache that can be shared across the team. This can save enormous amounts of time preventing duplicated work across entire organizations, including CI agents. Turborepo creates a dependency tree between all the apps and packages which allows the tooling to understand what needs to be tested and what needs to be rebuilt whenever there is a change to the codebase. Turborepo supports the parallel execution of tasks making it faster.
<a href="https://medium.com/media/05c203b3ea900c3679c109c2faa59f26/href">https://medium.com/media/05c203b3ea900c3679c109c2faa59f26/href</a><h3>Lerna</h3>
Lerna is a fast modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository. On May 2022, Nrwl (the company behind the open-source build system Nx) took over the responsibility of maintaining Lerna. Nrwl was founded by two ex-Googlers and Angular core team members <a href="https://twitter.com/jeffbcross">Jeff Cross</a> and <a href="https://twitter.com/victorsavkin">Victor Savkin</a>. Soon after Lerna v5 was released with some package upgrades and security fixes. Immediately after that Lerna started addressing the issues of what most Lerna users have been complaining about: scaling and speed. Lerna v5 has the ability to use Nx to run tasks. Nx is an additional package we need to install. The following gives a high-level overview of what Lerna provides and what features we get with the integration of Nx:
Lerna features:
<ul>
<li>Bootstrap: Lerna links different projects within the repo so they can import each other without having to publish anything to NPM.</li>
<li>Version: Automatically increment versions of packages</li>
<li>Publish: Automatically create tags and publish packages.</li>
</ul>
Nx integration features:
<ul>
<li>Run only tasks affected by a code change</li>
<li>Run prerequisite tasks first</li>
<li>Cache task results locally</li>
<li>Visualize the project graph</li>
<li>Nx Console — Visual Studio Code plugin</li>
</ul>
<a href="https://medium.com/media/c16803a4c96ec76b8f93ef45a214d1d2/href">https://medium.com/media/c16803a4c96ec76b8f93ef45a214d1d2/href</a><h3>Conclusion</h3>
In this article, I tried to give an overview of both libraries at a higher level only highlighting some features of both toolings. Choosing either depends. Both of the tools were built with specific goals. Lerna helps to manage and publish independent packages from the same repository. Lerna does not use any cache system of its own. It’ll always rerun everything from scratch. Jared Palmer, the creator of Turborepo first extracted Lerna into a monorepo tool, and with more research, he found out that most of the advanced techniques used by larger companies in their build system had not been made into the JS ecosystem. So, the goal of Turborepo is to leverage many of the advanced techniques in a monorepo tool with zero configs. With the release of Lerna v5, we can leverage the features provided by Nx. <a href="https://blog.nrwl.io/lerna-used-to-walk-now-it-can-fly-eab7a0fe7700#ab28">Lerna+Nx is 5.3 times faster than Turborepo</a>. You can also reproduce the benchmark by yourself by going to the <a href="https://github.com/vsavkin/large-monorepo">benchmark repo</a> provided by Victor Savkin.
If you want to have a deeper insight into both tools you can dive into <a href="https://turborepo.org/">Turborepo</a> and <a href="https://lerna.js.org/">Lerna’s</a> official websites.
Happy coding! See you in the next article. 👋
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=74dc6415ad30" width="1" height="1" alt=""><hr>
<a href="https://articles.wesionary.team/monorepos-turborepo-vs-lerna-74dc6415ad30">Monorepos: Turborepo vs Lerna</a> was originally published in <a href="https://articles.wesionary.team/">wesionaryTEAM</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Monorepos: Turborepo vs Lerna

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qo9V5r07jsNHBt1FY9tlNQ.png"></figure>React hook form is a library for working with forms in React. It is flexible, performant, and straightforward to use. On the other hand, Zod is a TypeScript first schema declaration and validation library. The term ‘schema’ here broadly refers to any data type, from a simple string to a complex nested object.
We’ve been talking about Schema Validation but what exactly is it? Schema validation is related to checking that a data structure correctly confirms a specific schema. It provides static documentation for your application and ensures the validity of the user input.
In this article, we’ll build a simple registration form using React hook form with Zod as a validation library. We’re also going to use TypeScript and TailwindCSS for styling although the stylings are all basic. This is what we’re going to build:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*XGz63WEyoP6Ux24Dg9M2WQ.png"></figure><h3>Installation</h3>
We’ll use Create React App with TypeScript to create our project. You can use any one of the following commands:
<pre>npx create-react-app react-hook-form-with-zod --template typescript</pre>
<pre>or</pre>
<pre>yarn create react-app react-hook-form-with-zod --template typescript</pre>
After that, moving on we install TailwindCSS. The installation steps for the TailwindCSS in this project are the standard setup guide <a href="https://tailwindcss.com/docs/guides/create-react-app">Install Tailwind CSS with Create React App</a>. Click on the link, follow the detailed instructions and get right back here.
Next, we’ll add React hook form, Zod and @hookform/resolvers . The @hookform/resolvers allows the use of any external validation library such as in our case Zod.
<pre>npm install react-hook-form @hookform/resolvers zod</pre>
And that’s it! We’ve installed all the necessary dependencies for the project.
First of all, let's clear out all the files and codes we don’t need. We can remove App.css, App.test.tsx, logo.svg, reportWebVitals.ts and setupTests.ts inside the src folder. We should also remove all the imports of the deleted files as mentioned earlier from the App.tsx and index.tsx. Inside the src folder we will create a file Form.tsx and add the boilerplate code for our form component:
<a href="https://medium.com/media/eb419f8caf9015945868f2b71c692d4d/href">https://medium.com/media/eb419f8caf9015945868f2b71c692d4d/href</a>This just provides the layout and styling for the form, we haven’t added any functionalities to it yet. Now you can probably replace the existing code inside App.tsx with the code below:
<a href="https://medium.com/media/1391e752389d634baf82275db83ff8c2/href">https://medium.com/media/1391e752389d634baf82275db83ff8c2/href</a>Save all the files and run npm run start in the terminal. Visit http://locahost:3000 if not redirected to the browser and voilà.
<h3>Building the form validation schema using Zod</h3>
First of all, let's have a quick overview of Zod. Zod is a TypeScript-first schema declaration and validation library. So, TypeScript-first means that the Zod will automatically infer the static TypeScript type for your data structure and you only declare a validator once. This eliminates the duplicative type declaration once in Zod and again in TypeScript. z.infer&lt;typeof schema&gt; using infer you can extract the type from a schema automatically. This is a really cool feature for TypeScript users.
<pre>import { zod } from "Zod";</pre>
<pre>const personSchema = z.object({ name: z.string(), age: z.number() });</pre>
<pre>// extracting the type type Person = z.infer&lt;typeof personSchema&gt;;</pre>
Zod has zero dependencies meaning it’s a standalone library that helps in keeping the bundle size smaller. It has a concise and chainable API interface. This makes it easier to create a complex data structure. It’s easy to compose simpler types into complex data structures.
Let’s get right back to our project. We’ll build a schema that matches values in our form. Let’s start off by importing the necessary dependencies in src/Form.tsx:
<pre>import { SubmitHandler, useForm } from "react-hook-form"; import { zodResolver } from "@hookform/resolvers/zod"; import { z } from "zod";</pre>
And then let’s define our schema validationSchema with some custom error message in src/Form.tsx in between the import statement and our Form component:
<a href="https://medium.com/media/dd1f36d08194671a45b8aabb14f54b78/href">https://medium.com/media/dd1f36d08194671a45b8aabb14f54b78/href</a>Let’s break down the code step by step.
We will declare the validationSchema using the z.object() method. We will use string validation chained with min validation for our firstname &amp; lastname field. z.string().min(1, { message: 'Firstname is required'}) first checks if the value is a string and then checks the input data must be one or more characters long, a non-empty string .i.e the field is required. When using validation methods, we can pass in an additional argument to provide a custom error message. Later we will learn how to show the error messages.
For the email field, we will use string validation and min validation along with email validation. Zod provides a handful of string-specific validations and email is one of those.
For the password field, we first check with string validation and then check that the entered password must be 6 or more characters long. For the confirmPassword field, we will validate the same as firstname and lastname. Also, we need to validate to match both password and confirmPassword. Zod lets you provide custom validation logic via refinements i.e. refine.
<pre>.refine((data) =&gt; data.password === data.confirmPassword, { path: ["confirmPassword"], // path of error message: "Password don't match", });</pre>
Notice that refine is implemented as a custom validator on the outer object. We are using refine to check if the password and confirmPassword match. As you can see, refine takes two arguments: 1) The first is the validation function. Any truthy value will pass validation. 2) The second argument accepts some options. The use of path parameter is to customize the error path since the error path needs to be the confirmPassword. The message parameter provides the custom error message.
For the terms of service checkbox, we will use a literal validator with the value of true. Literal just means that the field must be exactly this value. In case of literal, we’re using errorMap which is passed in as a parameter to the literal method. Every schema can be associated with an error map. The errorMap is used to simply customize the error message.
We’ll then extract the inferred type from the validationSchema schema:
<pre>type ValidationSchema = z.infer&lt;typeof validationSchema&gt;;</pre>
We can see that TypeScript inferred the following type from it:
<pre>type ValidationSchema = { firstName: string; lastName: string; email: string; password: string; confirmPassword: string; terms: true; }</pre>
This will help us keep all our functions type-safe. To summarize what we have done so far in the Form.tsx component:
<a href="https://medium.com/media/0740b00cafbe562492d2ec95758feef1/href">https://medium.com/media/0740b00cafbe562492d2ec95758feef1/href</a><h3>Using React hook form</h3>
We have already imported the necessary dependencies required for React hook form.
<pre>import { SubmitHandler, useForm } from "react-hook-form"; import { zodResolver } from "@hookform/resolvers/zod";</pre>
We’ll add the following code excerpt in the Form.tsx component:
<a href="https://medium.com/media/7664d57744b5c33d64286110aea2581a/href">https://medium.com/media/7664d57744b5c33d64286110aea2581a/href</a>useForm is a custom hook for managing forms with ease. It takes one object as an optional argument. We’ll use the resolver property, this function allows us to use any external validation library such as in our case Zod. In the resolver method, we use zodResolver hook that we imported from @hookform/resolvers/zod which takes in the validator validationSchema. Notice that we have given useForm and SubmitHandler the type inferred by Zod.
We’ve created onSubmit function that will simply log the validated data into the console. The onSubmit function will get invoked only after the handleSubmit function has validated the inputs. No need to worry we haven’t used handleSubmit yet, so far we’ve only destructured it with others including register and formState from useForm hook.
Notice if you try filling out the form and submitting nothing happens. This is because we haven’t registered the inputs and we haven’t used the onSubmit function to handle the submit event.
<h3>Registering the inputs</h3>
One of the key concepts in React Hook Form is to register your component into the hook. This will make its value available for both the form validation and submission.
<blockquote>
Note: Each field is required to have a name as a key for the registration process.</blockquote>
We’ll use the register function that we get from useForm hook to register the form inputs by giving it the same name that we have provided to the validationSchema schema.
For the firstname field we’ll register as:
<pre>&lt;input className="w-full px-3 py-2 text-sm leading-tight text-gray-700 border rounded appearance-none focus:outline-none focus:shadow- outline" id="firstName" type="text" placeholder="First Name" {...register("fitstName")} /&gt;</pre>
Similarly for email field:
<pre>&lt;input className="w-full px-3 py-2 text-sm leading-tight text-gray-700 border rounded appearance-none focus:outline-none focus:shadow-outline" id="email" type="email" placeholder="Email" {...register("email")} /&gt;</pre>
I think you get the idea you can register other input fields similarly but keep in mind that the name must be the same as we’ve provided in the schema.
<h3>Handling the form submission</h3>
We’ve already added the custom onSubmit handler function. All we need to do is pass in the onSubmit function to the handleSubmit as an argument and the rest is handled by it.
<pre>&lt;form className="px-8 pt-6 pb-8 mb-4" onSubmit= {handleSubmit(onSubmit)}&gt;</pre>
We get handleSubmit method from the useForm hook so what it does is handleSubmit will validate the inputs before invoking the custom onSubmit method. Notice that we don’t need to prevent any default behavior as we normally would, this is done by the handleSubmit method.
Now if you try filling up the form with valid inputs and submit the value gets logged into the console successfully. However, if you try to submit with invalid values or with an empty form nothing happens. We’ll have to conditionally show the error message for each field if they are invalid.
<h3>Handle errors</h3>
React Hook Form provides an errors object to show you the errors in the form. errors type will return given validation constraints. We can further destructure the formState into the error object:
<pre>const { register, handleSubmit, formState: { errors }, } = useForm&lt;ValidationSchema&gt;({ resolver: zodResolver(validationSchema), });</pre>
Now we can conditionally show the error message for each field through the error object. For the firstName field:
<pre>&lt;input className="w-full px-3 py-2 text-sm leading-tight text-gray-700 border rounded appearance-none focus:outline-none focus:shadow-outline" id="firstName" type="text" {...register("firstName")} /&gt; {errors.firstName &amp;&amp; ( &lt;p className="text-xs italic text-red-500 mt-2"&gt; {errors.firstName?.message} &lt;/p&gt; )}</pre>
For the rest of the fields you can compare them below:
<a href="https://medium.com/media/6c5be010f1647d17843bf1d76b174abf/href">https://medium.com/media/6c5be010f1647d17843bf1d76b174abf/href</a>I’ve also added ${ errors.firstName &amp;&amp; “border-red-500” } in the className to conditionally highlight the input with a red border if they are invalid. Now if you try submitting the form with invalid inputs you should see the error messages showing in their respective fields.
To summarize what we’ve done so far in the Form.tsx file:
<a href="https://medium.com/media/71649936a9eb2b7a2cb320cf1e90c4ad/href">https://medium.com/media/71649936a9eb2b7a2cb320cf1e90c4ad/href</a><h3>Conclusion</h3>
In this article, we covered how to use Zod as a validation library with React hook form. We also looked at how we can create schema and use it to infer the types for our form. I’ve tried to cover the basics of both the library and how you can integrate with one another.
For the next steps, you can dive into <a href="https://react-hook-form.com/">React hook form </a>and <a href="https://zod.dev/">Zod</a> official documentation to learn more advanced concepts.
If you are interested to see how the code would look altogether, you can take a look at the <a href="https://github.com/bicky-tmg/form-validation-with-zod.git">GitHub repository</a>.
Happy coding! See you in the next article.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=80d406e22cd8" width="1" height="1" alt=""><hr>
<a href="https://articles.wesionary.team/react-hook-form-schema-validation-using-zod-80d406e22cd8">React Hook Form: Schema validation using Zod</a> was originally published in <a href="https://articles.wesionary.team/">wesionaryTEAM</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

React Hook Form: Schema validation using Zod

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*cC9PQ00bv1_1CePwcttLhg.jpeg"><figcaption>Photo by <a href="https://www.pexels.com/photo/love-people-woman-heart-11035471/">RealToughCandy.com</a> on <a href="https://www.pexels.com/">Pexels</a></figcaption></figure>The Context API was introduced with React 16.3, which provides us with a way to share data between components without having to manually pass a prop through every level of the component tree.
Typically data is passed top-down(parent to child) via props but such usage of props for certain types as an authenticated user, theme, or preferred language can be cumbersome that is required by many components in an application. These props are passed further down to deeply nested components. This is where the term ‘drilling’ comes in. Prop drilling is moving props through a certain level of the component tree i.e. from grandparent to child to parent and so on. Some components in the component tree might not need the props so they simply forward the props. Context provides a way to share values like these between components without having to pass them down manually through every level.
Prop drilling is not ideal as it quickly introduces complicated, hard-to-read code, re-rendering excessively, and slows down performance. Component re-rendering is especially damaging since passing data down multiple levels of components triggers the re-rendering of components unnecessarily.
Theory aside let's see it in action. Let’s take a simple app as an example:
<a href="https://medium.com/media/86e8b35d4457eb9fc19e9864bd570708/href">https://medium.com/media/86e8b35d4457eb9fc19e9864bd570708/href</a>The App component has a state user . The state has a default value and a setter function setUser. The value is passed down to the MainPage component and the setter function setUser down to the NavBar component. The component MainPage receives the user as props and immediately forwards down to the WelcomePage component and similarly the WelcomePage component to the WelcomeMessage component. Finally, the WelcomeMessage component uses the user prop. Passing props down in this manner is Prop drilling, which is the default method.
<blockquote>Notice how we have put all the components in the same file rather the splitting them into different files. We can now use them without any external imports.</blockquote>
With only a few layers this isn’t a problem, but this can quickly get out of hand in larger applications. Along the chain, anything can go wrong there could be a typo or a prop might experience mutation. The way react works there rises an issue of re-rendering because passing data down the intermediary components are forced to re-render which might cause performance issues in the app. Thankfully there's a better way to solve these problems using the Context API.
As mentioned earlier, context provides a way to pass data through the component tree without needing intermediary components which simply relay the props and don’t necessarily consume them. Each component in the context is context-aware. The root component or the parent component whose child components are nested deep-down the tree requires the data to be wrapped with the context provider. The data/state is then passed to the context provider with its value attribute. The children components can then access the value using the context consumer or the useContext hook.
Let’s create a context and pass user to the context provider. We’ll use the context provider in the components above to specify the context value and call useContext in components below to read it.
<a href="https://medium.com/media/ce57a8fae6adb6c0fbcd11c8b29f149c/href">https://medium.com/media/ce57a8fae6adb6c0fbcd11c8b29f149c/href</a>We start by importing a createContext Hook, which is used for creating a context, and a useContext hook, which will extract the state provided by a context provider.
We then call the createContext Hook function, where we specify the default context value as undefined. This value never changes. React only uses this value as a fallback if it can’t find a matching provider above. createContext returns a context object that is then stored in a variable called UserContext.
Now the NavBar and the MainPage is wrapped with the Context.Provider and pass the user and setUser as an object to its value attribute. No matter how deep the components inside the wrapped component, the component itself and the nested components can access the passed context value directly.
Lastly, we extract this user in the WelcomeMessage component nested within the MainPage component, using the useContext Hook and a bit of destructuring. Therefore we have completely refactored the code and nullified the case of prop drilling. Our rendered output remains the same, but the code underneath is a bit leaner and cleaner.
We have used a simple example here to demonstrate the use of the context API and how it helps us solve prop drilling. However, it is recommended to use Context API sparingly as it makes component reuse difficult as mentioned in the official <a href="https://reactjs.org/docs/context.html#before-you-use-context">React docs</a>.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=188e001abc00" width="1" height="1" alt=""><hr>
<a href="https://articles.wesionary.team/prop-drilling-react-context-api-to-the-rescue-188e001abc00">Prop drilling? React Context API to the rescue.</a> was originally published in <a href="https://articles.wesionary.team/">wesionaryTEAM</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, I'm Bicky

How to update the internal state of the child component from the parent component?

How to implement infinite scroll using React Query?

Monorepos: Turborepo vs Lerna

React Hook Form: Schema validation using Zod