<img src=""><img src="https://ankitsinha.in/api/uploads/1664663427032.jpeg"> We'll be building a trivial frontend-only filtering feature on top of a list of items. The goal of this blog is to provide enough information to the readers to be able to use this as a baseline, plug and unplug different parts involved and build their very own filtering feature. This blog talks about the same technique I'm currently using on the <a href="https://ankitsinha.in/blogs" rel="noopener noreferrer" target="_blank">blogs</a> page of this website. We'll be building the functionality using React+Typescript and we'll be adding the magic of animation using <a href="https://www.framer.com/motion/" rel="noopener noreferrer" target="_blank">framer-motion</a>. Let's get going! If things go well, we should end up seeing something like this. <img src="https://ankitsinha.in/api/uploads/1664659999041.gif"><h2>Components</h2>To build the functionality we mainly need 3 components.<ol><li>Wrapper - Will render the other 2 components and handle state sharing between them.</li><li>Filters - Will render a list of `string` filters provided as props and whenever a filter is selected, it'll convey it to its parent.</li><li>List - Will render a list of items. The Wrapper will maintain the logic of filtering and sending `List` the filtered set of items.</li></ol> Let's start from bottom to top. `List` seems to be pretty simple to implement cuz all it has to do is take a set of items, map over them and render. For simplicity, I've considered a `ListItem` to be containing only 2 attributes - text and id. `id` has a very important role to play in our animations, we'll deal with it later. But in a real-world scenario, we'll almost always have a unique id associated with every element in an array. <pre class="ql-syntax" spellcheck="false">type=typescript
/** List.tsx */

export interface ListItem {
 text: string;
 id: string;
}


interface ListProps {
 items: ListItem[];
}


export const List = (props: ListProps) =&gt; {
 const { items } = props;


 if (!items?.length) {
 return &lt;&gt;&lt;/&gt;;
 }


 return (
 &lt;div className="list"&gt;
 {items.map((item: ListItem, index: number) =&gt; (
 &lt;div
 key={`item-${item.id}`}
 className="listItem"
 &gt;
 {item.text}
 &lt;/div&gt;
 ))}
 &lt;/div&gt;
 );
};
</pre> Next up, is our independent `Filters` component. This component will take the following props.<ol><li>filters - An array of strings to be displayed.</li><li>currentSelectedFilter - A string which determines showing extra styles on the selected filter. For this blog, we're keeping it as a string as we'll rely on direct string match to apply styles to the currently selected filter. However, you can choose it to be an `id`, if your filters are more than a string. In that case, you can use the `id` to match the currently selected filter.</li><li>onFilterClick: A callback function for the parent to determine which filter the user has currently selected.</li></ol> <pre class="ql-syntax" spellcheck="false">type=typescript
/** Filters.tsx */

interface FiltersProps {
 filters: string[];
 currentSelectedFilter: string;
 onFilterClick: (clickedFilter: string) =&gt; void;
}


export const Filters = (props: FiltersProps) =&gt; {
 const { filters, currentSelectedFilter, onFilterClick } = props;


 const getClickFilterCallback = useCallback(
 (filter: string) =&gt; () =&gt; onFilterClick(filter),
 [onFilterClick]
 );


 if (!filters?.length) {
 return &lt;&gt;&lt;/&gt;;
 }


 return (
 &lt;div className="filterList"&gt;
 {filters.map((filter: string, index: number) =&gt; (
 &lt;div
 key={`filter-${index}`}
 className={`filterItem ${
 filter === currentSelectedFilter ? "selectedFilter" : ""
 }`}
 onClick={getClickFilterCallback(filter)}
 &gt;
 {filter}
 &lt;/div&gt;
 ))}
 &lt;/div&gt;
 );
};

</pre> Okay, these 2 partially reusable components have now been built, and it's now time for us to wire them up together. Since we need some dummy data for items and filters. I've used a set of auto-generated sentences and put them under `ALL_ITEMS` and have hard-coded filtering strings and this list is called `ALL_FILTERS`. I've not put the dummy data in the blog as that's not necessary for the purpose. Here goes our `Wrapper` component. <pre class="ql-syntax" spellcheck="false">type=typescript
/** Wrapper.tsx */

export const Wrapper = () =&gt; {
 const [selectedFilter, setSelectedFilter] = useState&lt;string&gt;("");
 
 const filteredItems = useMemo(() =&gt; 
 selectedFilter === "" 
 ? ALL_ITEMS
 : ALL_ITEMS.filter((item: ListItem) =&gt;
 item.text.includes(selectedFilter)
 )
 ,[selectedFilter]);

 const onFilterItemClick = useCallback(
 (clickedFilter: string) =&gt; {
 if (clickedFilter === selectedFilter) {
 setSelectedFilter("");
 } else {
 setSelectedFilter(clickedFilter);
 }
 },
 [selectedFilter]
 );


 return (
 &lt;div className="Wrapper"&gt;
 &lt;div className="filterContainer"&gt;
 &lt;Filters
 filters={ALL_FILTERS}
 currentSelectedFilter={selectedFilter}
 onFilterClick={onFilterItemClick}
 /&gt;
 &lt;/div&gt;
 &lt;div className="listContainer"&gt;
 &lt;List items={items} /&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 );
}
</pre> In all of these implementations, I've made use of the `useCallback` hook which prevents React from performing a few unnecessary operations (a good practice), and we can talk about the hook in a separate blog. Rendering the Wrapper component now should give you something like this. <img src="https://ankitsinha.in/api/uploads/1664661822472.gif">We have the functionality of filtering running. Let's move on to adding some cool animation to the list. As I said earlier in the blog, the `id` plays a helpful role in animating the list. When dealing with layout animations, framer-motion relies on the `key` attribute of elements in a list to keep track of their position on the screen. So whenever the elements have to shift position due to other elements moving out of the DOM, framer-motion uses the `key` attribute to animate them from where they were, to where they are now supposed to be. It's pretty cool, according to me! :D Let's go ahead and add a few changes to our `List` component. <pre class="ql-syntax" spellcheck="false">type=typescript
/** List.tsx */ 

...
import { motion } from 'framer-motion';
.
.
.

export const List = (props: ListProps) =&gt; {
 ...

 return (
 &lt;motion.div layout className="list"&gt;
 {items.map((item: ListItem, index: number) =&gt; (
 &lt;motion.div
 layout
 key={`item-${item.id}`}
 className="listItem"
 initial={{ opacity: 0 }}
 animate={{ opacity: 1 }}
 &gt;
 {item.text}
 &lt;/motion.div&gt;
 ))}
 &lt;/motion.div&gt;
 );
};
</pre> To our container div, we've converted it to `motion.div` and added the `layout` prop, telling framer-motion that this element will be undergoing a `layout` animation. Any motion component with the `layout` prop undergoes animations using the `transform` CSS property. We've also converted the children `listItem` divs to `motion.div` and added the `layout` prop. Without this, we'd get a distorted animation. You can read more about this <a href="https://www.framer.com/docs/layout-animations/##scale-correction" rel="noopener noreferrer" target="_blank">here</a>. The `initial` and `animate` props tell the motion component that whenever it renders, begin with `opacity:0` and throughout transition duration (default 0.3s), change the value of opacity from 0 to 1. I'll be writing another blog which will get into a bit of detail about animating stuff using javascript. If you have constraints on the size of your served assets, you can look into writing your library to perform javascript animations, instead of using framer. However, there can also be a middle ground that you can learn more about on their <a href="https://www.framer.com/docs/guide-reduce-bundle-size/" rel="noopener noreferrer" target="_blank">reduce bundle size</a> page. <h1 class="ql-align-center">Fin.</h1>

We'll be building a trivial frontend-only filtering feature on top of a list of items. The goal of this blog is to provide enough information to the r...

Build an animated filtering list

<img src="https://ankitsinha.in/api/uploads/1664629195105.jpg"> In the last 3-4 years, I've appeared for multiple interviews across 5 companies. One of them rejected me in their first round, but the other 4 companies felt I was a good fit for them. These 4 include Microsoft, Coinbase, Amazon and Google. Here's my story of how I approach an interview. It may or may not work for you, because taking an interview is just one part of the entire process of you being a good fit for the company.<h2> </h2>Before getting into the details of my process, I'd like to take a bit of your time to convey my point of view on interviews in general. A set of interviews is a part of a larger hiring process for a candidate. The hiring process is in place to evaluate the need of the company and to find one or more people who can satisfy this need in the best possible way, according to a bunch of folks involved in the decision-making process. Think of it like a problem which the company is trying to solve. Business requires completion of a client request, we need a bunch of folks who, we think, can get the job done and generate business for the company. The general approach of a company to hire more people can be in two ways. They're either looking out for a specific role and requirement, or they're looking to increase their headcount by conducting generic interviews and they want to hire individuals who show that they're capable of learning the required skills to solve a problem and produce valuable outcomes for the company. If they are looking for a specific role, the candidate is required to demonstrate skills and prove that they're capable of handling the role already. So if the company is in desperate need of developers who can build a product for them using specific technologies, they'll evaluate you based on these required technologies. In the case of generic interviews, you're mostly evaluated on general technical skills, which involve Data Structures, Algorithms and System Design. However, there can be a mix of both too. Ready to switch jobs? No? - Read ahead to just know my approach towards taking an interview.Yes? - Read ahead to understand what has been working out right for me, and maybe the same could help you too in getting your next job. <h2>Begin</h2>First things first, you need an opportunity to land an interview at a company. Again, there are 3 ways in which you can get an opportunity. All of these, however, require you to prepare a good resume/profile/write-up which can catch anyone's attention within a minute or two. For example, when someone reaches out to me for referrals, the first thing I do is visit their LinkedIn profile and see what they've been doing in their career. Next is, their resume, which pretty much says the same as Linkedin but can sometimes have a detailed version too. Next, any public forum links where they've demonstrated their skills and achievements. This could even be a portfolio website like <a href="https://ankitsinha.in/" rel="noopener noreferrer" target="_blank">mine</a> (haha backlink to increase page visit count, lol). I know only about these till now, but there can be many more. Anything which can help me know about your skills is a valid candidate. Okay, getting back to the ways of landing an opportunity. <h3>Recruiter -&gt; Candidate</h3>The recruiter reaches out to you - Why would they, you ask? Your profiles on LinkedIn, Leetcode, Naukri, or other public forums where people talk about jobs, caught their attention. <h3>Candidate -&gt; Recruiter</h3>You reach out to the recruiter - So you are looking at a company to interview with, and that company would most likely have folks working in their recruitment department. You can reach out to them on LinkedIn (or email, if you get to know it) and show them your profile and see if your profile interests them. The prerequisite here is that you have a decent set of experience (or projects) which you can display and highlight in your initial message to the recruiter. If your profile catches their attention, you'd get an email soon to begin the interview process! <h3>Candidate -&gt; Employees</h3>Referral through folks already in the company - Almost all companies have an internal portal to refer external candidates. If they don't, existing employees can still reach out to the recruiters internally and forward your profile. So in any scenario, reaching out to existing employees of a company and asking them for a referral is not a bad idea. I don't think there's anything wrong with cold messaging, properly, of course. Again, even with existing employees, your best bet for them to refer you is for you to show them what you're capable of. Done with these? If you took the recruiter route and they liked your profile, you are already short-listed as a candidate which the company will interview. Congrats! However, if you took the employee referral route, and they submitted it on a portal, then your resume and other profile information need to catch the interest of recruiters skimming through the portal to find a candidate. If you feel your resume didn't get short-listed, repeat the steps. <h2>Step 1: Understand the process</h2>Congrats, you now have your interviews at the company lined up in the coming few weeks! Your recruiter might reach out to you to inform you about the process. Also, it's now a good time to understand that your opportunity at landing a job in the company, is now an opportunity for your recruiter as well to complete their target, lol. So, stay connected to them, and learn from them any tips and tricks. Good companies often employ good people, and good people are always ready to help you out. You now know what's lined up for you. Often, I've noticed, the interviews are organized in this fashion. (x? indicates 0 or 1 occurrences of x)<ol><li>DSA + System Design + Hiring Manager + (Behavioral)?</li><li>(DSA)? + Frontend/Backend skills + Hiring Manager + (Behavioral)?</li></ol> In most companies, you'd have to go through a DSA round. I'll share my thoughts on DSA in a separate blog. I'd add a few blogs on preparing for each of these rounds separately, as I don't want to clutter this blog with a lot of information. Now that you're well aware of what you'll be facing in the coming few weeks, it's not a bad idea to revise or prepare for them, is it? :P You can't go 0 to 1 in a few days, but you can always try! Something is always better than nothing. What do you even have to lose? Any skill which you acquire even by not getting through an interview successfully is still a valuable skill. More on this at the end of the blog.So go ahead, prepare for the skills you'll be evaluated on, and learn stuff! <h2>Step 2: Before an interview</h2>You're about to appear for a technical interview in the next few hours, what do you do? I'll tell you what I do. Nothing at all. Focus on your routine and what work you have at hand. 1hr of the interviews shouldn't take the entire day from you. It's still just a part of your day. Your skills won't improve or deteriorate in a matter of a few hours. Chill out. <h2>Step 3: During an interview</h2>You're in a 45mins to 1hr interview with an existing employee in your target company. Here's the part where you're being judged. It's good to understand a few things here. Your interviewer is human. Every individual's mentality is what they've perceived of life in the time they've been here on Earth. It's a good line, but I guess you can ignore it cuz it doesn't make any sense here. Lol. However what you can't ignore, is the fact that your interviewer can make mistakes, can have bad days, and is just another Software Developer (most likely), just like you. So talk to them. Introduce yourself and get to know them. You can spend about 5-10mins on just talking to the interviewer, knowing more about their work and the work which you are being hired to do. Your interviewer will now put a question in front of you. The first thing I do here is to read the question well. Ask any doubts I have regarding the question and confirm my understanding of the problem statement with my interviewer. It adds a lot of points when you communicate well in an interview. After all, you're being hired to solve a real-world problem and not just a few DSA questions, right? During the interview, your interviewer is evaluating you on your ability to solve problems, your approach to tackling a problem and your ability to reach a possible solution to a problem. To understand the problem well, before proceeding to give a solution. I mean if I have to put it in the ways which you've already heard before - "Think about edge cases etc. etc.". Your goal is to solve the problem. When you solve a problem, by building a product or by fixing bugs in an existing product, you solve it by considering yourself as the end user. That's where the need to "think about edge cases" comes into the picture. So, it's all part of the process of evaluating whether you can "solve" a problem, or not. Now that you understand the question well, it's time to think about it. The way I usually do is, whenever I read a question, there's most likely 1 direct solution which comes to my mind. If nothing comes to my mind, then I usually go back to asking more about the question to understand it even better. But most likely, a step-by-step solution to the question comes to my mind. I convey it to the interviewer at that moment and we have a brief discussion about the pros and cons of this solution. Again, talking in a more "DSA interview" way, we talk about the brute-force solution. I think it's good to have this discussion. And note that I use the word discussion rather than "answering the question". So once we discuss pros and cons, since it's mostly me thinking, lol, every time we discuss a con, my mind goes into thinking about the way to get rid of this con. Here comes the role of your experience. The human brain works in a bit of a pattern-matching manner. So when your mind is thinking about the solution to a small problem, it'll quickly try to match it to similar problems you've faced in the past. That means, if you see that your algorithm keeps on going back again and again to find the answer to the same sub-problem, the mind (having known memoization concepts) would suggest you apply memoization. Hence, the need to prepare, and hence you see that cracking interviews is not only about the DSA practice you've done, but every bit of problem-solving mindset you've applied throughout your life, comes into action. And this is how, we come up with a more optimal solution to a problem, in an interview. This process takes most of the time in the interview, so once both, the interviewer and I, have agreed to a solution (or if we're running short on time, the interviewer will let you know when to stop), we move on to the end of the interview. Here, you'd be asked the famous "Do you have any questions, for me?" question. And this is your opportunity to interview the interviewer. Just kidding. This is your opportunity to ask them about their work, the technologies they work with, the growth of an employee within the company, learning opportunities and so many more questions which can help determine if the company is fit for you. It's extremely important to research a company and your growth opportunities before you join them. <h2>Step 4: After an interview</h2>After the interview, I like to follow up with my recruiter on the submitted feedback. You can choose to do or not do this. Doesn't matter much as the feedback for this round is already in the system. Besides this, I go back to my normal schedule of whatever I'm supposed to be doing on a normal day. <h2>End</h2>After the interview process is completed. The hiring process can go on for a few more days (or weeks) before you get your result. But by now, you'd know from your recruiter about the possible outcome. I don't have anything more to add here as the entire process of interviewing is just a part of your life. Your days should go on as usual and if you're an individual who's been in the industry, the way to look at interviews is as just one of those meetings in your day.<h2> </h2>I've shared with you my thoughts on a typical interview process. These may or may not align with your thoughts and I'm open to listening to anything which will increase my knowledge in general about life. However, to summarise, I'd like to emphasise just this.<ul><li>An interview is a discussion with an active employee to find whether you are a fit for the company, based on certain parameters.</li><li>It's more about solving a problem together with another employee than answering viva questions in college exams.</li><li>The goal is to know whether both the candidate and the company are a good fit for each other.</li><li>Luck plays a big role in an interview. Your brain might not already be wired to solve a typical kind of problem on a particular day.</li><li>If you don't get selected at any phase, you're not banned for life. Get back again after the cooling period and restart the process. It's just a matter of time.</li><li>Just by being in the process of being interviewed, you're now better at it than you were before it. You know what and what not, to do.</li></ul> I'll share more thoughts on what I feel about jobs in general, in a separate blog. :) <h1 class="ql-align-center">Fin.</h1>

In the last 3-4 years, I've appeared for multiple interviews across 5 companies. One of them rejected me in their first round, but the other 4 compani...

Looking Back on My Job Interviews - What I Learned

<img src="https://ankitsinha.in/api/uploads/1664395284785.png"> This blog describes the design and architecture of my portfolio website. For no real reason, I wanted to build everything from scratch and have complete control of how I create and manage the data which goes on the site, on my own. On a high level, this site has 3 segments, pre-rendered public pages which you are currently seeing, admin pages to create, update and delete blogs, projects and updates, (where I am writing this blog), and a backend to manage auth and data. So there are two products managing the frontend, one for everyone and another just for the admins, both built on React but use different rendering techniques to optimise the experiences. And then we have the API service backend written on Node+Express to manage all data coming in from the admins, and going out to everyone. Let's look into each of these in the following segments. <h2>Backend</h2>The heart of the product is its backend which is built on Node+Express and coded with the magic of TypeScript. It follows the typical backend practices and connects to a MongoDB server hosted on MongoDB Atlas to fetch, update and delete the blogs, projects and updates for the website. It exposes a bunch of APIs, the get methods provide support for both public pages and admin pages, and the post methods provide support for only the admin pages to manage the website's data.The initial goal of writing the API services was not only meant to handle the data of the website, but to have a central server for any product I'll be building in future as well. The reason was to optimise the cost of hosting the server on a public network, accessible from anywhere. With a central service managing APIs for all my products, I'd not need to deploy multiple servers on multiple instances, for a very limited set of audiences to start with. <h2>Frontend</h2>Let's address the very basic question of why 2 frontends for 1 site. Why couldn't there have just one frontend with capabilities of both, serving public pages and admin pages? <h3>Approach #0;</h3>I'd initially started with a single-page application (SPA) built on React and was extremely happy when the end-to-end flow of CRUD operations was successful and deployed. But soon, I realised that this SPA React application doesn't work well with SEO. To generate a production build to deploy it, webpack would bundle all of React's logic into javascript files and these files will be embedded into a template HTML, which when served to the requested, would request for the javascript files to load separately. This isn't good for SEO as everything on the site is essentially an output of Javascript running. For example, the very first operation of the web app was to render the index component into an element on the HTML template. So, if you block all javascript on the page, then even the top-level React component will not be rendered and all you'll get is the template, which most likely will be a blank page. Now, let's talk about how it'd affect SEO. Google crawler for indexing pages, is not famous for waiting for the page's javascript to load before it moves on to another page to index. So when the crawler requests <a href="https://ankitsinha.in/" rel="noopener noreferrer" target="_blank">ankitsinha.in</a>, it'll just see a blank page and move on to another website to index. Essentially, the crawler understood nothing on the page and there's nothing for it to index it on. And this is the reason I felt the need to migrate to a different technique of rendering the pages. <h3>Rendering techniques;</h3>There are 3 famous techniques for serving web content to users -<ol><li>Server Side Rendered (SSR) pages</li><li>Static Site Generated (SSG) pages</li><li>Client Side Rendered (CSR) pages</li></ol> Client-side rendering;When you build an application with React and use Webpack or any other bundler to bundle it, it produces one big chunk of initial javascript, which when downloaded after the initial HTML page load, flushes the components and data into the HTML. So the render and data fetch, happen on the client side. This is an example of Client-side rendering. Server-side rendering;Now with server-side rendering, the user requests a page, the server understands what is being requested, tries to fetch all the data the page relies upon, creates an HTML page out of it (template + data), and then sends it back to the client. So the client receives the first HTML page for the URL it requested, it already has all the information which the page needs! This prevents the issue of SEO, however, it poses another problem.Let's say there's a page which depends upon some API call, which internally requests the DB and serves it back to the page. So on every request of the page, the server will attempt to call the API to fetch data. More page requests, and more API calls. It's an unnecessary overhead if your APIs return the same data again and again and the data changes only occasionally. This process reduces the performance of the page and increases the load on the APIs. Although there's a solution to this as well, in which you apply the techniques of caching to improve the performance, that's a story for another blog. :D Static site generation;So the choice comes down to having, static-site-generated pages. This technique fetches data and creates HTML files during build time itself and the generated pages are served statically when the URL is requested. This helps you quickly serve the pre-rendered pages. Additionally, you get the power to cache these static content on CDNs to improve the performance even further. However, let's talk about a few issues with this approach as well. Since the pages are generated during the build, any changes to the data will require a re-fetch of the APIs on the page, which will only happen if we build the pages again. Although SSG blocks me from auto-updating the content on the website whenever I push a blog from admin, it was the fastest way for me to migrate to a rendering technique which would heavily support SEO. <h3>Migrating from CSR to SSG</h3>So how do we migrate a fully functional CSR application, supported with Authentication, CMS (content management system) for blogs, projects and (twitter copy) updates, to server-generated pages? The admin pages (CUD) for blogs, projects and updates can not be migrated to SSG so easily as they deal with real-time data. So I decided to separate my frontend into 2 separate apps. The first one will contain only public pages, or the pages containing the published data, generated server-side and cached on CDNs. And the second app will just consist of pages to manage CUD. This approach according to me was the quickest to implement without compromising the abilities of the website. I'll cover the details of how this was done in a separate blog. :D <h1 class="ql-align-center">Fin.</h1>

This blog describes the design and architecture of my portfolio website. For no real reason, I wanted to build everything from scratch and have comple...

Tech design of this site

<img src=""><img src="https://ankitsinha.in/api/uploads/1664116443021.png"><img src=""> I hope this is not the first blog on react which you're reading. If it is, checkout the <a href="https://github.com/facebook/create-react-app" rel="noopener noreferrer" target="_blank">create-react-app</a> package. It'll help you set up your project and help you kick start your react story pretty easily. When you're learning something new, it always helps to get your hands dirty as fast as possible and get the feel of living in the new environment. It'll help you understand React faster, with all the concepts of component based web dev, virtual DOM, props and states etc etc. Now that you're familiar with the world of React, let's try and get everything in our own hands! (Just to be clear, I don't mean to rewrite the entire process in vanilla JS. But you may give it a shot after this!) Let's begin our journey then. The following sections will walk you through setting up a React app with TypeScript and Webpack. <h2>Initialise things</h2>Considering that the first few lines in this blog were read and it's known that we need NPM, let's initialise an empty directory as a node project. <pre class="ql-syntax" spellcheck="false">type=powershell
&gt; mkdir react-scratch
&gt; cd react-scratch
&gt; npm init
</pre> Running these command should set up an empty directory with the name <code>react-scratch</code>, containing a <code>package.json</code> file. <h2>Begin with React</h2>Let's start by React itself. Along with react, we need React-DOM to render react code in normal HTML and since we're using Typescript, we should also install the typings for these 2 packages. Let's install all these 4 packages using the following command. <pre class="ql-syntax" spellcheck="false">type=powershell
&gt; npm install --save-dev react react-dom @types/react @types/react-dom
</pre> Now that we have the react packages we can begin building our app. Ideally, we place all our react code inside an src directory under root, so create a folder called <code>src</code> under root. Also, to use whatever react code we write, we need React-DOM to render the react code into an HTML file. Now, we need a place where we make use of React-DOM to render React code in HTML, right? Let's create an index.tsx file inside src folder. This is our react entry point. <pre class="ql-syntax" spellcheck="false">type=typescript
import React from "react";
import ReactDOM from "react-dom";
import { App } from "./components/App";

ReactDOM.render(&lt;App /&gt;, document.getElementById("root"));
</pre> Now, we haven't written our App component yet, but the idea here is that any react component can be rendered by using ReactDOM. Let's look at the second parameter to the render function, document.getElementById("root"). We know that browsers understand HTML as views. So in order to display something on a browser, we need an HTML file. React, after all, is a JS framework and the output of all the rendering and JS execution, has to finally become HTML only. So all that this line does here is that, in some HTML file, it'll render all React code through the imported component, under an element on the page whose id is root! <pre class="ql-syntax" spellcheck="false">type=html
&lt;html&gt;
&nbsp; &lt;head&gt;
&nbsp; &nbsp; &lt;meta charset="UTF-8" /&gt;
&nbsp; &nbsp; &lt;title&gt;React-Scratch&lt;/title&gt;
&nbsp; &nbsp; &lt;script src="./node_modules/react/umd/react.development.js"&gt;&lt;/script&gt;
&nbsp; &nbsp; &lt;script src="./node_modules/react-dom/umd/react-dom.development.js"&gt;&lt;/script&gt;
&nbsp; &lt;/head&gt;


&nbsp; &lt;body style="margin: 0px;"&gt;
&nbsp; &nbsp; &lt;div id="root"&gt;&lt;/div&gt;
&nbsp; &lt;/body&gt;
&nbsp;&nbsp;
&lt;/html&gt;
</pre> We can have our HTML file as simple as this. Specify the title, add few meta tags and include react scripts. But the most important one is the div inside body. Without a div with id root, our ReactDOM won't know where to render our base component. Place this HTML file inside /public/ directory for now in your project. Well, you can place it anywhere you want as long as you are making sure everything comes together to make sense. <h2>Install and configure Webpack</h2>You wrote few components, added a React entry point and even added the base HTML file! But what do you do now? You can't just expect the index.tsx file to start running magically, can you?You need some application to start processing whatever you wrote. Also, remember you asked ReactDOM to render your component inside root? ReactDOM is just an interface between HTML and react world. It's similar to how parent components render children components. ReactDOM renders the top most React component in an HTML page. Your browsers don't understand .tsx files. They need plain old JS to understand what to do. And there comes the need of <a href="https://webpack.js.org/" rel="noopener noreferrer" target="_blank">webpack</a>. Webpack is a JS bundler. It takes all your fancy code which you've written in React (or for many other frameworks), and converts them into plain JS which the browsers can understand. Check out their documentation to know what else can it do. Let's go ahead and install webpack and webpack-cli so that we can run webpack from command line too. <pre class="ql-syntax" spellcheck="false">type=powershell
&gt; npm install --save-dev webpack webpack-cli
</pre> Now that we have webpack, let's configure it to so that it knows how to read our project. Create a new <code>webpack.config.js</code> file in your project's root dir and put the below code. <pre class="ql-syntax" spellcheck="false">type=typescript
const HtmlWebpackPlugin = require("html-webpack-plugin");
const { CleanWebpackPlugin } = require("clean-webpack-plugin");
const path = require("path");

module.exports = {
&nbsp; &nbsp; entry: "./src/index.tsx",
&nbsp; &nbsp; output: {
&nbsp; &nbsp; &nbsp; &nbsp; path: path.resolve(__dirname, "dist"),
&nbsp; &nbsp; &nbsp; &nbsp; filename: "app.js",
&nbsp; &nbsp; },
&nbsp; &nbsp; devtool: "source-map",
&nbsp; &nbsp; resolve: {
&nbsp; &nbsp; &nbsp; &nbsp; extensions: [".ts", ".tsx", ".js"],
&nbsp; &nbsp; },
&nbsp; &nbsp; plugins: [
&nbsp; &nbsp; &nbsp; &nbsp; new CleanWebpackPlugin({ cleanStaleWebpackAssets: false }),
&nbsp; &nbsp; &nbsp; &nbsp; new HtmlWebpackPlugin({
&nbsp; &nbsp; &nbsp; &nbsp; template: path.resolve(__dirname, "public/index.html"),
&nbsp; &nbsp; &nbsp; &nbsp; filename: "index.html",
&nbsp; &nbsp; &nbsp; &nbsp; }),
&nbsp; &nbsp; ],
&nbsp; &nbsp; devServer: {
&nbsp; &nbsp; &nbsp; &nbsp; port: 3000,
&nbsp; &nbsp; },
&nbsp; &nbsp; module: {
&nbsp; &nbsp; &nbsp; &nbsp; rules: [
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; test: /\.ts(x?)$/,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; exclude: /node_modules/,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; use: [
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; loader: "ts-loader",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ],
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; test: /\.css$/,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; use: ["style-loader", "css-loader"],
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; test: /\.(png|jpg|svg|gif)?$/,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; use: "file-loader",
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; enforce: "pre",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; test: /\.js$/,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; loader: "source-map-loader",
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; ],
&nbsp; &nbsp; },
&nbsp; &nbsp; externals: {
&nbsp; &nbsp; &nbsp; &nbsp; react: "React",
&nbsp; &nbsp; &nbsp; &nbsp; "react-dom": "ReactDOM",
&nbsp; &nbsp; },
};
</pre> Here's what most of the lines above do.<ol><li>First 2 lines are plugins for our webpack config where they control the output of the run. clean-webpack-plugin makes sure that there is no stale data in the output directory which our app doesn't use. html-webpack-plugin is simply used to parse the base HTML file and insert the generated JS into it as a script tag.</li><li>entry: Specifies the entry point from where webpack should begin bundling</li><li>output: Controls the output filename for the bundles JS</li><li>resolve: Controls what kind of files to consider</li><li>plugins: Read the first point again.</li><li>module: Controls how different modules in the project will be treated. Such as, in case of files ending with tsx, ts-loader will process them etc Here I've specified 4 rules, you can have a look at the documentation for more options. Each module needs to be separately installed as a package. Follow the commands below.</li></ol> <pre class="ql-syntax" spellcheck="false">type=powershell
&gt; npm install --save-dev webpack-dev-server ts-loader style-loader css-loader file-loader source-map-loader
</pre> Don't forget to install the plugins too! <pre class="ql-syntax" spellcheck="false">type=powershell
&gt; npm install clean-webpack-plugin html-webpack-plugin
</pre> <h2>Install and configure Typescript</h2>Okay, time to install typescript. <pre class="ql-syntax" spellcheck="false">type=powershell
&gt; npm install --save-dev typescript
</pre> Because we're using Typescript in our project, we should specify how do we want to control the ts-loader to behave. A tsconfig.json file generally describes a set of options which the typescript processor will use while transpiling the files. Create a tsconfig.json file in the root directory of your project and use the following configurations. <pre class="ql-syntax" spellcheck="false">type=javascript
{
&nbsp; "compilerOptions": {
&nbsp; &nbsp; "outDir": "./dist/",
&nbsp; &nbsp; "sourceMap": true,
&nbsp; &nbsp; "noImplicitAny": true,
&nbsp; &nbsp; "esModuleInterop": true,
&nbsp; &nbsp; "lib": ["es5", "es2015", "es2016", "dom"],
&nbsp; &nbsp; "module": "esnext",
&nbsp; &nbsp; "moduleResolution": "node",
&nbsp; &nbsp; "target": "es6",
&nbsp; &nbsp; "jsx": "react"
&nbsp; }
}
</pre> This blog is already too long and in the interest of time, as well as to make sure you all read the docs, I'll not cover what all do these options mean. Have a look at the Typescript <a href="https://www.typescriptlang.org/docs/" rel="noopener noreferrer" target="_blank">documentation</a> and you'll find everything you need there. <h2>Running the project</h2>Finally, the last step. Finally! Everything seems set now. Webpack will read the entry point, parse all the dependencies and bundle them into a vanilla JS output, using the tsconfig and the ts-loader. For other types of file it'll use the other module loaders. ReactDOM in entry point will make sure that the base component is mounted in the container div once the script is executed. So how do we run them then? We have webpack and webpack-dev-server to start the webpack process. Let's modify our package.json and add 2 scripts to handle them. <pre class="ql-syntax" spellcheck="false">type=javascript
{
&nbsp; &nbsp; ...&nbsp;
&nbsp; &nbsp; "scripts": {
&nbsp; &nbsp; "build": "webpack",
&nbsp; &nbsp; "dev": "webpack serve"
 }
}
</pre> Run the scripts using npm and enjoy your efforts!

I hope this is not the first blog on react which you're reading. If it is, checkout the create-react-app package. It'll help you set up your project a...

Blogs