DEV Community: Mazen Emam

Migrating from Create-React-App to Vite: Boosting Performance in Legacy Applications

Mazen Emam — Sat, 17 Aug 2024 17:39:04 +0000

I'm excited to share that we are successfully transitioning from create-react-app (CRA) to Vite in my workplace! 🎉

Switching wasn’t straightforward, but it was necessary. Our app was becoming increasingly sluggish, and the developer experience (DX) was deteriorating. I found myself leaving my laptop on all day because restarting the app was painfully slow. If you ever removed node_modules, reinstalled them, and attempted to start the app, you could lose an hour just waiting for everything to download and start up again. The app would usually take 12-15 minutes to start—a significant delay, especially when dealing with urgent bug reports. Additionally, CRA is deprecated and is no longer recommended for bootstrapping React applications.

Why Vite?

Initially, I considered using Rspack, which is touted as

A drop-in replacement for webpack, with more powerful features and exceptional productivity.

However, the transition wasn’t as seamless as I had hoped. Although Rspack is nearing production readiness (at version 1.0.0-beta.4 as of this writing), I decided to opt for the more mature and battle-tested solution: Vite.

Moving away from Webpack and CRA gave me a newfound appreciation for these tools and the effort behind them. They simplify so much of the development process and provide a ready-to-use setup.

I hope that one day we’ll have a true drop-in replacement for CRA and Webpack, so we won’t need to make extensive file changes when switching to tools like Vite.

If you have no idea what Webpack, Vite, or Rspack are, I went down this rabbit hole in my last post, I explored Webpack and what it does. Vite and Rspack are more modern tools doing a similar job but more efficient.

My Experience with Vite: Pros and Cons

Before diving into how I transitioned our old app to Vite, I'd like to share the pros and cons I've encountered during my brief experience using Vite in development and production environment.

Pros:

Faster Startup: After a fresh install, our server startup time was drastically reduced. With Webpack, it used to take up to 30 minutes; with Vite, it now takes about 8.5 minutes. Subsequent startups went from 12-15 minutes to just 1.5 minutes. While this might still seem slow, it's a win considering the complexity of our project.

Note: The laptop I’m testing on is quite old. On a newer machine with better specs, startup times were as low as 20–30 seconds for the second start.

Faster Build Time: Our GitHub workflow build time decreased from 12–13 minutes to just 7 minutes — almost half the time! This transition saves our development team at least 20 minutes per developer each day.

With Webpack

With Vite

Cons:

Different Bundlers for Development and Production: Vite uses esbuild for development and Rollup for production, which has been a significant pain point. Some pages worked perfectly in development but crashed in production. This discrepancy required manual testing and troubleshooting, though there weren't many issues overall.

Planning the Transition: How to Migrate from CRA to Vite

Do Your Research:

This is the most crucial step. Extensive research is essential. I browsed Reddit to read about other developers’ experiences transitioning from CRA to Vite. Most agreed that the process is tricky but worth the effort. Additionally, I read several blog posts on the steps needed to move a CRA app to Vite, as there is no official tutorial or documentation on this topic now.

Build Your Action Plan:

Convert .js files to .jsx: This was a surprising challenge, as Vite doesn't support .js files as Webpack does. Manually converting all .js files to .jsx was out of the question, but luckily, I found a CLI tool that automated the process.
Remove react-script, install vite, create vite.config.js: Ensure you're using a Vite version compatible with your Node.js version. After that, remove react-scripts, install vite, and create the vite.config.js file.

yarn remove react-scripts
yarn add vite @vitejs/plugin-react --dev

and in the project root

import react from '@vitejs/plugin-react';
import { defineConfig } from 'vite';

export default defineConfig({
    plugins: [react()],
    build: { // to output your build into build dir the same as Webpack
        outDir: 'build',
    },
    server: {
        open: true,
        port: 3000,
    },
});

Move index.html to the project root and fonts to the public directory then update reference paths to the fonts accordingly.
Remove %PUBLIC_URL% from links in index.html.

<link rel="icon" href="%PUBLIC_URL%/favicon.ico" /> ❌ 
<link rel="icon" href="/favicon.ico" /> ✅

Add Script pointing at your project entry point in index.html

<body>
  <noscript>You need to enable JavaScript to run this app.</noscript>
  <div id="root"></div>

  <script type="module" src="/src/index.jsx"></script>
</body>

Replace environment variables: Replace REACT_APP with VITE in .env , update process.env.NODE_ENV with import.meta.env.MODE and process.env.REACT_APP with import.meta.env.VITE in your code.
Configure eslint: Install vite-plugin-eslint and update vite.config.js to include the plugin.

yarn add vite-plugin-eslint --dev

import react from '@vitejs/plugin-react';
import { defineConfig } from 'vite';
import eslintPlugin from 'vite-plugin-eslint';

export default defineConfig({
    plugins: [react(), eslintPlugin()],
    build: {
        outDir: 'build',
    },
    server: {
        open: true,
        port: 3000,
    },
});

Revalidate your GitHub workflows: Update any workflow steps that reference react-scripts to use vite.

Fix Environment-Specific Issues:

Change all require images to module imports.

Issue: In CRA, images were commonly loaded using require statements, which won’t work with Vite.
Solution: Replace require with ES module imports. For instance:

<img src={require('assets/images/logo.svg')}/> ❌

import Logo from 'assets/images/logo.svg'; 

<img src={Logo}/> ✅

2. Resolve globalThis is not defined.

Issue: Vite doesn’t automatically provide globalThis, which can cause issues if your code relies on it, Webpack was polyfilling it for us.

global variable “globalThis” in a Webpack application

Solution: Add a manual definition for globalThis in your index.jsx file

window.global ||= window;
// just double checked my code and I'm a bit skeptical of why I'm not using
// `window.globalThis`and why my code is working with `window.global` 🤔

3. Generate source maps for error monitoring.

Issue: By default, Vite may not generate source maps, which are essential for debugging when you use an error monitoring tool.
Solution: Enable source maps in your vite.config.js:

import react from '@vitejs/plugin-react';
import { defineConfig } from 'vite';
import eslintPlugin from 'vite-plugin-eslint';

export default defineConfig({
    plugins: [react(), eslintPlugin()],
    build: {
        outDir: 'build',
        sourcemap: true,
    },
    server: {
        open: true,
        port: 3000,
    },
});

4. Fix global SASS variables.

Issue: Vite may not handle global SASS variables defined with :export as CRA does.
Solution: Move global SASS variables to a JavaScript file. For example:

//theme.scss ❌

:export { 
    primaryColor: $app-primary;
    secondaryColor: $secondary;
     ....
}

import theme from '../styles/theme.scss';

<div style={{ color: theme.primaryColor }}>Hello World</div>

Will be replaced by

// theme.js ✅

const theme = { 
    primaryColor: '#10142a',
    secondaryColor: '#2695a2',
    .....
}

export default theme;

import theme from '../styles/theme.js';

<div style={{ color: theme.primaryColor }}>Hello World</div>

5. Handle absolute imports for .jsx files.

Issue: Absolute imports might not work properly in Vite.
Solution: Configure aliases in vite.config.js:

import react from '@vitejs/plugin-react';
import { defineConfig } from 'vite';
import eslintPlugin from 'vite-plugin-eslint';

export default defineConfig({
    plugins: [react(), eslintPlugin()],
    build: {
        outDir: 'build',
        sourcemap: true,
    },
    resolve: {
        alias: [
            { find: 'actions', replacement: '/src/actions' },
            { find: 'assets', replacement: '/src/assets' },
            { find: 'components', replacement: '/src/components' },
            .....
            { find: 'styles', replacement: '/src/styles' }, 
        ],
    },
    server: {
        open: true,
        port: 3000,
    },
});

6. Handle absolute imports for **.scss files.**

Issue: Vite might not resolve absolute imports for SCSS files correctly in the production environment, for example, The code below was importing a file called app.[hash].js (not a part of my build) instead of app.[hash].css in production

import MyComponent from 'components/MyComponent';
import styles from 'styles/app.scss';

<MyComponent className={styles.someClassName} />

Solution: I tried falling back to the relative path of the file but it didn’t work 🤷‍♂️, I opted into import SCSS files globally since these classes were shared through the application

// index.jsx
import React from 'react';
import { render } from 'react-dom';
import Main from './pages/Main';

// Import SCSS globally
import './global.scss';

render(<Main/>, document.querySelector('#root'));

// global.scss

.class1{...}
.class2{...}

...

// cut & paste classes from styles/app.scss here 
// then drop that cursed file

then I’d use them like vanilla CSS

<MyComponent className='someClassName' />

7. Address third-party library issues.

Issue: Some libraries may not be fully compatible with Vite.
Solution: Update or replace incompatible libraries. In my case, I needed to: — Replace jsonwebtoken with jsonwebtoken-esm — Replace react-notifications with react-toastify — Use lodash-es instead of lodash — Update libraries like react-bootstrap-sweetalert and recharts to their latest versions

Conclusion

Transitioning from create-react-app to Vite has been a challenging but rewarding experience. The performance improvements alone have made the effort worthwhile, and I believe this will significantly boost both developer productivity and overall project maintainability. By carefully addressing these issues, you can make the most of Vite’s modern tooling and improve the efficiency of your development workflow.

Exploring Webpack

Mazen Emam — Wed, 08 May 2024 00:49:47 +0000

In each Frontend Developer's life, there comes a time when they need to edit something in the bundler, luckily this day hasn’t come yet for me, but I had some free time so I decided it was the time to demystify these keywords: Webpack — Craco — Bundles — Chunks — Bundle Size — Code Splitting — Dynamic imports.

Through this post, I aim to explore the basics of Webpack with you and help you understand why it is important for modern web development.

So the first question is:

What is Webpack?

Webpack is a module bundler, that bundles the files in your project into one or multiple files (bundles). Then it does some extra cleanup (converting ES6 to older Javascript — minifying/uglifying — tree shaking — code splitting— compressing and assets optimization and extra production mode-specific optimizations) to prepare your code for production. so in short, Webpack is the middleman between the development and the production code.

Another important job that Webpack does is to resolve dependencies and include them in the final bundle.

Let me tell you a story about life before the front-end frameworks.

Back in the old, when we were using only HTML, CSS, and Javascript, do you remember how we used to structure our HTML files?

<!DOCTYPE html>
<html lang='en'>
<head>
    <meta charset='UTF-8'>
    <meta name='viewport' content='width=device-width, initial-scale=1.0'>
    <title>Document</title>
    <link rel='stylesheet' href='style.css'>
</head>
<body>

    <script src='script.js'></script>
</body>
</html>

What if we wanted to add Bootstrap to our project?

<!DOCTYPE html>
<html lang='en'>
<head>
    <meta charset='UTF-8'>
    <meta name='viewport' content='width=device-width, initial-scale=1.0'>
    <title>Document</title>
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-QWTKZyjpPEjISv5WaRU9OFeRpok6YctnYmDr5pNlyT2bRjXh0JMhjY6hW+ALEwIH" crossorigin="anonymous">
    <link rel='stylesheet' href='style.css'>
</head>
<body>

    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js" integrity="sha384-YvpcrYf0tY3lHB60NNkmXc5s9fDVZLESaAA55NDzOxhy9GkcIdslK1eN7N6jIeHz" crossorigin="anonymous"></script>
    <script src='script.js'></script>
</body>
</html>

Did you notice that your stylesheet and script are after Bootstrap’s stylesheet and script? why did we used to do that?

We would want the styles to override the default bootstrap styles or in the case of the script we wanted to make sure that the custom script runs the last thing on the webpage to make use of and override anything in the previous scripts, and to make sure that the rest of your page is fully rendered, so that when you do something like:

document.querySelector('#firstName')

#firstName would exist on the DOM, the same goes for the bootstrap script, that’s why the script is at the bottom of the page not at the top, it wants to ensure that the HTML is there before adding javascript to it.

So some dependencies are happening here, order matters and the element must exist in the DOM before we try to manipulate it.

In modern web development, you don’t write HTML or scripts, you don’t add Bootstrap link to the HTML head, you download a package, you will use a library like react-bootstrap and you would import the components into your files, right?

Here, you can see the first glimpse of Webpack magic happening behind the scenes, consider the following code:

import Container from 'react-bootstrap/Container';
import Row from 'react-bootstrap/Row';
import Col from 'react-bootstrap/Col';

function AutoLayoutExample() {
  return (
    <Container>
      <Row>
        <Col>1 of 2</Col>
        <Col>2 of 2</Col>
      </Row>
      <Row>
        <Col>1 of 3</Col>
        <Col>2 of 3</Col>
        <Col>3 of 3</Col>
      </Row>
    </Container>
  );
}

export default AutoLayoutExample;

For the AutoLayoutExample component to render correctly, it depends on 3 other components (Container , Row , and Col) that don't exist in this file but must exist to have the AutoLayoutExample component rendering correctly. Webpack is our traffic man, it ensures that whatever code your components depend on exists before you use it, the same as putting the HTML before the scripts.

Webpack also helps us develop projects by running a development server. Back in the old days, to test your code changes, you would need to save the changed files and hit the refresh button, but this isn’t the case now, you are no longer clicking the refresh button. When you run the start script in package.json, the script listed under start runs that creates a new instance of the WebpackDevServer, passing in the compiler and configuration. A listener method on the instance is called, passing in the port and host values. Then it clears the console and reads “ Starting the development server…”. The browser is opened with the correct dev URL. Lastly, two listeners are added for when the process is killed, which turns off the web server, and exits the start.js process.

Under the hood, your start script looks something like this:

"start": "webpack-dev-server --mode development --open"

This tells Webpack to spin up a development server, serve the files live, and open the browser to the port you specify in the webpack.config file (or it will use the default 8080). If you are ready to build your project for final deployment, you will run the build script which might look like this under the hood:

"build": "webpack --mode production"

This script will use the default Webpack config which looks up in your project root for a src directory and looks up for an index.js as the entry point, from index.js Webpack starts building a dependency graph, similar to the previous example where you would need Container , Row , and Col for the AutoLayoutExample to render correctly, so it goes and makes sure that Bootstrap exists ahead of rendering AutoLayoutExample since it depends on it.

Have you noticed that a typical React app doesn’t have Webpack in package.jsonor a webpack.config.js file in the project tree?

A Default Create-React-App

The reason for this is that the react team is already handling all of the Webpack configurations for you under the hood when you are using create-react-app , they don’t want developers to randomly tweak the Webpack configuration as they might introduce unexpected behavior that reduces the overall experience.

But what if you know what you are doing? Well, there’s a tool to help override React’s team Webpack config called CRACO (Create React App Configuration Override)

Here’s how Craco defines itself in its documentation:

To customize most things when using Create React App, you can eject. However, you’ll then need to maintain every configuration and script yourself, which can be a bit annoying. CRACO, which stands for Create React App Configuration Override, allows you to get all of the benefits of Create React App without ejecting. Customize your configurations ESLint, Babel, PostCSS, and many more with just a single configuration file at the root of your project.

There’s also a big warning underneath this definition:

By doing this you’re breaking the “guarantees” that CRA provides. That is to say, you now “own” the configs. No support will be provided. Proceed with caution.

So using CRACO is the equivalent of telling React “I’m a big boy, I know what I’m doing”.

Well, in my case, I’m planning on using CRACO to analyze my build, I won’t modify the default build script, I’ll add a new script just for learning purposes to have a behind-the-scenes look at my bundles.

From here on out, I’ll be analyzing a bloated private repo we use in my company, It is so big that I think It is the perfect candidate to learn about bundles and chunks.

But before installing any tool, why not use the ones in hand?

We have the browser which can be a great starting point for learning how to analyze our bundles .. but what is a bundle? what is a chunk?

Bundle:

Produced from a number of distinct modules, bundles contain the final versions of source files that have already undergone the loading and compilation process.

Chunk:

This webpack-specific term is used internally to manage the bundling process. Bundles are composed out of chunks, of which there are several types (e.g. entry and child). Typically, chunks directly correspond with the output bundles however, there are some configurations that don’t yield a one-to-one relationship.

When you’re application is quite big it’s meaningful to split up big bundles into chunks and load them lazily, generally speaking, it can decrease time loading dramatically.

Analyzing bundles is a good first step to optimize the amount of Javascript shipped to the browser which can improve page load time and directly result in better Large Contentful Paint (LCP) and First Input Delay (FID)

by decreasing the time the browser needs to parse, analyze, and compile the code.

Consider the following case where I went into the users' page in my app:

In the screenshots above you can see the chunks sent by the server to load this page in the network tab, additionally, you can also see the size of the chunk and the time needed to send these chunks from the server to the browser, in the coverage tab you can see the size of the unused bytes from the chunks, additionally, in development mode only, you can see a source map indicating to the actual files in your chunk, you can find it by clicking on the dropdown indicator next to your chunk.

Notice that 14.chunk.js has one file which is useLocalStorage custom hook that has 97.7% of unused bytes that’s an indicator that maybe we should recheck our usage for useLocalStorage, maybe we don’t need it on this page.

Using the Network and Coverage tab can be a good start if we already have a small and focused scope to analyze but if we are interested in a bird eye analysis of our project we would need help from some 3rd party tools.

The first thing we will do is install craco and a Webpack plugin called webpack-bundle-analyzer these packages will help us view the bundled code outputted by Webpack when we run our new script:

yarn add @craco/craco webpack-bundle-analyzer progress-bar-webpack-plugin chalk --dev

then we can add a new script to our package.json under scripts called analysis

 "scripts": {
        "analysis": "craco build",
        // other scripts

}

and we create a craco.config.js and add the following code

const chalk = require('chalk');
const ProgressBarPlugin = require('progress-bar-webpack-plugin');
const BundleAnalyzerPlugin =
    require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
    webpack: {
        plugins: [
            new BundleAnalyzerPlugin({
                analyzerMode: 'server',
            }),
            new ProgressBarPlugin({
                format: `${chalk.green('analyzing...')} ${chalk.green(
                    '[:bar]'
                )}${chalk.green('[:percent]')}${chalk.green(
                    '[:elapsed seconds]'
                )} - :msg`,
            }),
        ],
    },
};

NB: CommonJS syntax is used because webpack config files are executed in a Node.js environment.

In this file, we are using BundleAnalyzerPlugin to open up a server after the build to visually display the size and contents of the Webpack output files, and using ProgressBarPluginto show a progress bar in the terminal during the build, indicating how much of the build has been completed and how long it has been running. Lastly, we are using chalk to add some coloring to the terminal

This is the result of running our analysis script:

What is this?

This is our final bundle, including both the application code and any dependencies it relies on, including those from node_modules after code splitting and various webpack optimizations. BundleAnalyzerPlugin provides us with 3 views:

Stat : This view shows the raw size of each module in your bundle before any optimizations are applied. It gives you an idea of the size of each file/module in your project.
Parsed : In this view, you see each module’s size after Webpack has parsed and processed them. This typically includes tree shaking, code splitting, and other optimizations. So, the numbers you see in this view reflect the size of the modules after webpack has applied various optimizations.
Gzipped : This view shows the size of each module after gzip compression is applied. Gzip compression is a standard technique to reduce the size of files sent over the network further. The numbers in this view represent the estimated size of each module after compression.

Generally when talking about the bundle size we mean the Gzipped size , but both Parsed and Gzipped are important metrics, Parsed size helps us understand how much work the browser has to do when it loads the app, while gzipped size tells us how fast the app will download and start running for users.

We can enhance the output by adding magic comments to our Lazy imports in React.

Lazy imports or Lazy loading :

is an optimization technique that delays the loading of certain parts of your application code until they are needed. This improves the initial load time and overall performance of your React app.

import React from 'react';

const Users = React.lazy(() =>
    import(
        /* webpackChunkName:"Users" */ 'path/to/users/page'
    )
);

return (
<React.Suspense fallback={<div>loading....</div>}>
  <Users/>
<React.Suspense>
)

The Output After Using Webpack Magic Comment

This enhanced result can make a good starting point for enhancing our enormous bundle, After I narrowed down the selection to our top eight chunks (They make about 2/3 of our bundle size😲) and after adding Webpack magic comment to the lazy imported routes components, I can identify two of the biggest problematic chunks, EmployeeScoreCard (452 KB) chunk and Style chunk (296 KB)

The Bad Wolves

2 ways commonly used to optimize the bundle size are Lazy Loading and Dynamic Imports, I can go further and Lazy Load some of the components inside EmployeeScoreCard resulting in breaking this chunk into multiple chunks, this is the result:

EmployeeScoreCard became much smaller after Lazy Loading the component inside, it is not showing up at all unless we implicitly went on and looked it up, you can also see in the last picture a chunk called EmployeeInfoGrid , the result of this simple enhancement is so surprising even for me, our total chunk size decreased from 7.25MB to 6.83MB, a 6% decrease 🤯

The second way we can go about optimizing our bundle is by using Dynamic Imports inside our chunks, Dynamic Imports are usually used with conditional loading based on user action, consider the following code:

import React, { useState } from 'react';

const Dashboard = () => {
  const [showUserDetails, setShowUserDetails] = useState(false);
  const [UserDetails, setUserDetails] = useState(null);

  const handleClick = async () => {
    if (!UserDetails) {
      const { default: UserDetailsComponent } = await import('./UserDetails');
      setUserDetails(UserDetailsComponent);
    }
    setShowUserDetails(true);
  };

  return (
    <div>
      <button onClick={handleClick}>View Details</button>
      {showUserDetails && UserDetails && <UserDetails user={/* your user data */} />}
    </div>
  );
};

export default Dashboard;

Here, we are only importing the UserDetailsComponent after the user clicks the button, this way we create a separate chunk for UserDetailsComponent

Following these techniques could vastly decrease your bundle size which will result in:

Reducing initial load
Reduce bandwidth usage
Improve browser caching
Lower bounce rate
Improve user experience
Better SEO

But I think my №1 tip to have a smaller bundle size is:

“Avoid installing 3rd party libraries whenever possible.”

I know what you will say:

“You want me to reinvent the wheel?”
“That library is making my life easier.”

I’m not prohibiting you from installing them 😅 Just be resourceful, if you would look closely into the terminal output or webpack analyzer output, all those unnamed chunks are node_modules , zero logic code, and an extra debt we gotta carry.

I love libraries like the very next person, but if you are installing libraries in your project you must

Maintain/Upgrade them regularly
Don’t install multiple libraries doing the same job,
Stay up to date, libraries get deprecated, browsers have features being added to them to replace libraries each day.

One last thing you can do after analyzing your bundle, if having these libraries is a must, try replacing them with smaller ones. A tool like https://bundlephobia.com/ can be a great aid in your journey before installing your next package.

Wishing you a smaller bundle and a bug-free day.

Fat Components vs. Fat Pages in React: Choosing the Right Approach

Mazen Emam — Tue, 26 Sep 2023 23:49:48 +0000

Photo by Kadarius Seegars on Unsplash

Introduction:

When it comes to organizing logic in React, developers have two prominent approaches: fat components and fat pages. Imagine fat components as all-in-one powerhouses, handling significant logic within themselves, while fat pages delegate substantial logic to components, focusing on rendering the UI. In this article, we’ll explore the pros and cons of each approach, provide practical examples, and discuss the factors to consider when deciding which approach suits your project best.

Comparison: Fat Components vs. Fat Pages Through the Lens of Moving Houses

To understand the distinction, let’s draw an analogy. Imagine you’re moving houses. Fat components can be likened to putting your things into boxes and neatly organizing everything in one place. It simplifies the moving process, making it easier to manage. On the other hand, fat pages are comparable to buying new stuff each time you move. While it may appear convenient initially, it can lead to redundancy and unnecessary complexity in the long run.

Advantages of Fat Components:

Easier to reason about as all the logic resides in one place. A fat component encapsulates everything it needs to make its magic happen.
Increased reusability by extracting common logic into separate components. You can create reusable building blocks that sprinkle their logic across your application.

Disadvantages of Fat Components:

Maintenance challenges as components grow in size and complexity. Over time, a fat component might become harder to understand, debug, and maintain, especially when it juggles multiple responsibilities.
Potential performance impact as components trigger re-renders upon state changes. Frequent state updates in a fat component can lead to unnecessary re-renders, potentially affecting your application’s overall performance.

Advantages of Fat Pages:

Enhanced efficiency as the logic executes once for the entire page. Fat pages can leverage caching mechanisms, optimizing data fetching and computations for superior performance.
Improved clarity as logic is shared across multiple components. By distributing logic across different components, each component can focus on its specific responsibility, resulting in a modular and comprehensible codebase.

Disadvantages of Fat Pages:

Increased maintenance complexity due to logic spread across multiple components. Spreading logic across different components can make it trickier to trace and comprehend the flow of data and actions.
Reduced reusability as the logic becomes more page-specific. Since fat pages often encompass page-specific logic, it may limit the reusability of the components within those pages.

Single Responsibility Principle and Its Impact on Logic Organization

One crucial principle to consider when organizing logic in React is the Single Responsibility Principle (SRP). The SRP states that a component or module should have only one reason to change. Applying this principle helps to create more maintainable and scalable codebases. Let’s explore how the SRP aligns with the concepts of fat components and fat pages.

SRP and Fat Components:

Fat components inherently run the risk of violating the SRP. As a component grows in size and complexity, it becomes challenging to adhere to a single responsibility. The logic within a fat component may become entangled, making it harder to identify and modify specific functionalities. Therefore, when using fat components, it’s crucial to be mindful of keeping each component focused on a single responsibility.

SRP and Fat Pages:

Fat pages, by distributing logic across multiple components, can align more easily with the SRP. Each component within a fat page can focus on a specific responsibility, ensuring a modular and maintainable codebase. With this approach, it becomes easier to identify and modify the logic associated with a particular functionality without affecting the entire page.

Factors to Consider When Deciding between Fat Components and Fat Pages:

Scalability: Fat pages can be more scalable since they only require re-rendering when the data they are rendering changes. In contrast, fat components need to be re-rendered whenever their state changes.
Maintainability: Fat pages can be more challenging to maintain as the logic is spread across multiple components, making understanding and debugging more difficult. Fat components, on the other hand, contain all the logic for a component, making them easier to understand and maintain.
Performance: Fat pages can be more performant as they only need to be re-rendered when the data they render changes, while fat components require re-rendering whenever their state changes.

Tips for Choosing Between Fat Components and Fat Pages:

Start with fat components, especially for new projects or teams, as they are easier to understand and maintain.
Encapsulate repeated logic into fat components to improve code reusability and maintenance.
Transition fat components to fat pages as needed for improved efficiency and scalability, considering bottlenecks or performance issues as triggers.
Consider your team’s experience and project timeline. If your team is new to React or you have tight deadlines, fat pages may be a better option.
Evaluate project requirements. If scalability or performance is crucial, consider choosing fat pages or a combination of fat components and fat pages.

Choosing the Right Approach:

To strike a balance between fat components and fat pages, it is crucial to consider the size and complexity of your project. For smaller projects or when starting out, fat components offer simplicity and reusability. As your project grows, transitioning to fat pages can improve efficiency and maintainability, aligning with the Single Responsibility Principle.

Conclusion:

Ultimately, the choice between fat components and fat pages in React depends on your project’s requirements, team dynamics, and long-term goals. By considering scalability, maintainability, and performance, you can make an informed decision that best suits your specific situation. Remember to evaluate the advantages and disadvantages of each approach and adjust as needed to create a robust and efficient React application.

✨Bonus: Creating a Complex Select Component with the Single Responsibility Principle

Let’s apply the Single Responsibility Principle to a practical example: a complex select component. By breaking down the select component into smaller, focused components, we adhere to the SRP. Each component handles a specific responsibility, making the codebase more modular and maintainable.

// SelectInput.js
// Responsible for rendering the select input UI

import React from 'react';

const SelectInput = ({ options, onChange }) => {
  return (
    <select onChange={onChange}>
      {options.map((option) => (
        <option key={option.value} value={option.value}>
          {option.label}
        </option>
      ))}
    </select>
  );
};

export default SelectInput;

// SelectValidator.js
// Responsible for validating the selected option

const SelectValidator = (selectedValue) => {
  // Validation logic here
  return isValid;
};

export default SelectValidator;

// SelectFetcher.js
// Responsible for fetching data for select options

const SelectFetcher = () => {
  // Data fetching logic here
  return options;
};

export default SelectFetcher;

// SelectComponent.js
// The main select component that brings everything together

import React, { useState, useEffect } from 'react';
import SelectInput from './SelectInput';
import SelectValidator from './SelectValidator';
import SelectFetcher from './SelectFetcher';

const SelectComponent = () => {
  const [selectedValue, setSelectedValue] = useState('');
  const [options, setOptions] = useState([]);

  useEffect(() => {
    const fetchData = async () => {
      const fetchedOptions = await SelectFetcher();
      setOptions(fetchedOptions);
    };

    fetchData();
  }, []);

  const handleChange = (event) => {
    setSelectedValue(event.target.value);
  };

  const isValid = SelectValidator(selectedValue);

  return (
    <div>
      <SelectInput options={options} onChange={handleChange} />
      {isValid ? null : <p>Please select a valid option.</p>}
    </div>
  );
};

export default SelectComponent;

By following this approach, we can easily modify and extend the functionality of the select component without affecting other parts of the application. This example demonstrates how applying the SRP can lead to more manageable and scalable codebases.

Finally, whether you choose fat components or fat pages, or a combination of both, keep the Single Responsibility Principle in mind. Strive for modular, maintainable, and scalable code that aligns with your project’s needs. Experiment, learn, and adapt your approach as your project evolves, ensuring an efficient and enjoyable development experience in React.

Boost Your React Performance: How to Use the useCallback Hook

Mazen Emam — Fri, 07 Jul 2023 23:41:00 +0000

Photo by Oskar Yildiz on Unsplash

As React developers, we’re always looking for ways to optimize the performance of our applications. One way to achieve this is by using the useCallback hook.

The useCallback hook is a built-in React hook that allows us to memoize a function, meaning that it will only be re-created if one of its dependencies changes. This can be especially useful when passing functions down to child components, as it can prevent unnecessary re-renders.

Identifying Functions to Memoize

So which functions are good candidates for optimization with useCallback? Generally speaking, any function that is passed down to a child component as a prop can benefit from being memoized with useCallback. This includes event handlers, callback functions, and other functions that are used as props.

To identify which functions can be memoized, look for functions that are created inside the component’s render method or inside other functions that are called on each render. These functions will be re-created on each render, which can be costly if they’re passed down to child components and cause unnecessary re-renders.

For example, consider the following functional component:

function MyComponent({ onClick }) {
 const handleClick = () => {
  onClick();
 };

return (
 <button onClick={handleClick}>Click me</button>
 );
}

In this component, the handleClick function is created inside the component’s function body and is called on every render when the button is clicked. If MyComponent is re-rendered for any reason, such as when its props change or its state is updated, handleClick will be recreated and the button will be re-rendered, even though its behavior hasn’t changed. This can cause unnecessary re-renders and affect the performance of the application.

By using the useCallback hook to memoize handleClick, we can avoid this problem:

function MyComponent({ onClick }) {
 const handleClick = useCallback(() => {
  onClick();
 }, [onClick]);

return (
 <button onClick={handleClick}>Click me</button>
 );
}

In this updated version of MyComponent, handleClick is memoized using useCallbackand the onClick prop is included in its dependency array. This means that handleClick will only be re-created if onClick changes, which helps to avoid unnecessary re-renders.

Understanding Shallow Copying

When using useCallback, it’s important to understand how React determines whether a dependency has changed. React uses shallow copying to check for changes in the values of the dependency array.

Shallow copying means that only the top-level reference of an object or an array is checked, not the contents of the object or array. This means that if the contents of an object or array change, but the reference remains the same, React won’t detect the change and the memoized function won’t be re-created.

Here’s an example to illustrate shallow copying:

https://cseducators.stackexchange.com/a/811

and here is a better illustration with some code 😅

import React, { useState, useCallback } from 'react';

function App() {
  const [count, setCount] = useState(0);
  const [person, setPerson] = useState({ name: 'John', age: 20 });

  const incrementCount = useCallback(() => {
    setCount(count + 1);
  }, [count]);

  const updatePerson = useCallback(() => {
    person.age += 1;
    setPerson(person);
  }, [person]);

  console.log('Render App');

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={incrementCount}>Increment Count</button>
      <p>Person: {person.name}, {person.age}</p>
      <button onClick={updatePerson}>Update Person</button>
    </div>
  );
}

export default App;

In the above example, we have two useCallback functions, incrementCount and updatePerson. Both of these functions have dependencies defined in their second argument, which is an array of values that the function depends on.

incrementCount depends on the count state and is created with the dependency array [count]. This means that the function will be memoized and only re-created when the value of count changes.

updatePerson depends on the person state and is created with the dependency array [person]. However, in the function body, we are modifying the age property of the person object, but not creating a new object reference. This means that although the contents of the person object have changed, the reference remains the same, and React won't detect the change. This causes the updatePerson function to not be re-created, and subsequent calls to it will have the old person object reference with the updated age property.

To fix this issue, we need to create a new object reference with the updated age property whenever we update the person state. We can do this by using the spread operator to create a shallow copy of the person object:

const updatePerson = useCallback(() => {
  setPerson({ ...person, age: person.age + 1 });
}, [person]);

This creates a new object with all the properties of the old person object, but with the age property updated. Now, when we call the updatePerson function, React will detect the change in the person object reference and re-create the function.

checkout this code demo on codesandbox

Conclusion

The useCallback hook is a powerful tool for optimizing React performance by memoizing functions and preventing unnecessary re-renders. However, in the hands of inexperienced developers, the useCallback hook could be misused, leading to performance issues and unexpected behavior. Therefore, it’s important to use it responsibly and to ensure that the dependencies are updated correctly.

Additionally, it’s crucial to prioritize code readability and maintainability to ensure that the application remains easily understandable and maintainable in the long run. By striking a balance between performance and readability, we can create React applications that are efficient, maintainable, and easy to understand.

So the next time you’re passing functions down to child components, consider using the useCallback hook to optimize your React application. Your users (and your CPU) will thank you!

Automating Code Formatting with Bash and Prettier

Mazen Emam — Thu, 22 Jun 2023 21:36:27 +0000

Code formatting can be a tedious and time-consuming task, but it’s also an essential part of writing clean and maintainable code. Inconsistent formatting can make it difficult to read and understand code, and can even introduce bugs or errors.

Fortunately, there are tools available that can automate code formatting and ensure consistency across your codebase. Prettier is one such tool, and it’s become a popular choice among developers for its ease of use and flexibility.

In this tutorial, I’ll show you how to configure Prettier to automatically format your code using a pre-commit hook and a configuration file, including how to use a local configuration file to override a global configuration file.

Step 1: Install Prettier

The first step is to install Prettier in your project. You can do this using npm or yarn:

npm install --save-dev --save-exact prettier

yarn add --dev --exact prettier

This installs Prettier as a development dependency in your project and ensures that you have a specific version of Prettier installed that will not change unexpectedly.

Step 2: Create a Global Prettier Configuration File

Next, you’ll need to create a global configuration file for Prettier. This file tells Prettier how to format your code, and allows you to customize the formatting options to suit your preferences.

Create a file called .prettierrc in the root of your project, and add the following contents:

{
  "trailingComma": "es5",
  "tabWidth": 2,
  "semi": true,
  "singleQuote": true
}

This configuration specifies that Prettier should use a comma after the last element in an array or object (using the “es5” option), use 2 spaces for indentation, add semicolons at the end of statements, and use single quotes for strings.

You can customize these options to suit your project’s coding style and conventions. For a full list of options and their values, see the Prettier documentation.

Step 3: Create a Local Prettier Configuration File

When working on a project with an existing .prettierrc configuration, you may find that the formatting is difficult to read and work with or doesn’t match your personal preferences. For example, the line width may be set to 80, which can be too small for some screen sizes and cause discomfort when reading the code. To address this issue, you can create a local configuration file that allows you to override the global Prettier configuration and customize the formatting options to your preferences.

To create a local configuration file, create a file called .prettierrc.local.json in the root of your project and specify the desired formatting options. For example, you can set the tab width to 4 spaces instead of the 2 spaces specified in the global configuration. This ensures that your code is formatted according to your preferences without affecting the formatting of other files in the project.

{
  "tabWidth": 4,
  "printWidth": 120
}

This configuration specifies that Prettier should use 4 spaces for indentation, instead of the 2 spaces specified in the global configuration and change the line width to 120 instead of the default 80 characters.

Additionally, to ensure that your changes to the code do not cause unnecessary formatting changes when committing the code, We will use a pre-commit hook. This hook runs Prettier on the files that are about to be committed and ensures that they are formatted according to .prettierrc configuration file. This way, your code is formatted according to your preferences while still maintaining consistency with the project’s overall formatting standards.

Step 4: Configure VS Code to Use the Local Configuration File

To use the local configuration file in VS Code, you need to add the prettier.configPath option to your VS Code settings. This tells the Prettier extension to use the local configuration file instead of the global configuration file.

To do this, open your VS Code settings (File > Preferences > Settings or using the shortcut Ctrl+,), and add the following line to your settings:

{
  "prettier.configPath": "./.prettierrc.local.json"
}

This configuration specifies the path to the local configuration file.

Step 5: Install the Prettier Extension in VS Code

To use Prettier in VS Code, you must also install the Prettier extension. The extension provides integration with Prettier and makes it easy to run Prettier on your code directly from the editor.

To install the Prettier extension, open the Extensions view in VS Code (View > Extensions or using the shortcut Ctrl+Shift+X), search for “Prettier — Code formatter”, and click the Install button.

Step 6: Create a Pre-Commit Hook

Now that Prettier is installed and configured, you can create a pre-commit hook that will automatically run Prettier on your code before each commit, and ensure that all code is properly formatted.

Create a file called .git/hooks/pre-commit (without a file extension) in your project, and add the following contents:

#!/bin/bash

# Get the list of files added or modified in this commit
files=$(git diff --cached --name-only --diff-filter=ACM | grep "\.js$")

# If there are no JavaScript files, exit without doing anything
if [-z "$files"]; then
  exit 0
fi

# Run Prettier on the changed files using the shared configuration file
echo "Running Prettier on the following files:"
echo "$files"
for file in $files; do
  npx --no-install prettier --config .prettierrc --write "$file"
  git add "$file"
done

This script does the following:

It uses Git to determine which files have been modified and staged for commit and filters the list to include only JavaScript and JSX files.
It runs Prettier on the staged files using both the global configuration file and the local configuration file and writes the corrected formatting back to the files.
It uses Git to add the modified files back to the index so that the corrected formatting is included in the commit.
It prints a message to the console indicating that Prettier has formatted the code.
This script ensures that all staged JavaScript and JSX files are automatically formatted with Prettier before each commit, using both the global and local configuration files.

Make sure to make the pre-commit hook executable by running the following command in your bash terminal:

chmod +x .git/hooks/pre-commit

Step 7: Test the Pre-Commit Hook

To test the pre-commit hook, you can create a test commit that introduces some formatting errors in your code, and see if the hook detects and fixes them before the commit is made.

Here’s an example workflow for testing the pre-commit hook:

Create a new file called test.js in your project directory and add some intentionally bad formatting to it. For example:

const test=()=>{console.log('test');}

Stage the file for commit using git add test.js .
Attempt to commit the changes using git commit -m “Test commit”.
If the pre-commit hook is working properly, it should detect the formatting errors in test.js and fix them automatically. The output in your terminal should look something like this:

Running Prettier on the following files:
test.js
[warn] test.js
Code formatted with 1 warning

The [warn] message indicates that Prettier has detected a formatting error in the file, and the Code formatted with 1 warning message indicates that Prettier has corrected the formatting error.

Conclusion

By following the steps in this tutorial, you can ensure that all of your code is consistently formatted, without having to spend time manually formatting each file. This can save you time and reduce the risk of formatting-related errors in your code.

If you enjoy automating tasks in your development workflow, you might also be interested in my other post on automating the creation of React components.

I hope this tutorial has been helpful. If you have any questions or feedback, please let us know in the comments!

Three Useful TypeScript Features For React Developers

Mazen Emam — Wed, 10 May 2023 23:59:12 +0000

As a React developer, you’re likely familiar with the benefits of using a statically-typed language like TypeScript. TypeScript offers a type system that helps catch errors early, making it easier to write more reliable code faster. In a React context, TypeScript can also provide additional benefits such as improved code maintainability and extensibility. If you’re new to TypeScript, it’s a superset of JavaScript that adds optional static types to your code. This means that you can catch errors before your code runs, which can save you time and improve the quality of your codebase.

Matt Pocock’s React With Typescript course is an excellent resource to learn about how TypeScript works with React. Here are three useful features that I learned from the course:

1. ComponentProps utility type:

A common pattern in React is to create a component that takes props as an argument. TypeScript provides a utility type called ComponentProps, which automatically extracts the props type from a given component. This saves you time and helps avoid errors when defining a component’s props.

import React from 'react';

const MyComponent = ({ name, age }: { name: string; age: number}) => {
  return (
    <div>
      <p>{name}</p>
      <p>{age}</p>
    </div>
  );
};

type MyComponentProps = React.ComponentProps<typeof MyComponent>;

const App = () => {
  const props: MyComponentProps = {
    name: 'John',
    age: 26,
  };

  return <MyComponent {...props} />;
};

ComponentProps proves more useful when used with rest parameters and Native HTML Elements

import React from 'react';

function CustomButton(props: React.ComponentProps<'button'>) {
  return <button {...props}>Click me!</button>;
}

function App() {
  return (
    <div>
      <CustomButton onClick={() => console.log('Button clicked!')} />
    </div>
  );
}

In this example, we’re using the ComponentProps utility type to define the props for a custom CustomButton component that extends the functionality of the native button element. By passing the onClick prop to CustomButton, we're able to handle the button click event and log a message to the console. The ...props syntax allows us to pass any additional props to the underlying button element, such as className or disabledand if we tried to pass an invalid prop to the CustomButton element, Typescript will throw an error.

2. Union Types:

Another useful TypeScript feature is the ability to use union types with useReducer. This allows you to define a state type that can have multiple variations. For example, you can specify the type of action and the exact payload key expected

import { useReducer } from "react";

type State = { count: number };

type Action =
  | { type: "add"; add: number }
  | { type: "subtract"; subtract: number };

const reducer = (state: State, action: Action) => {
  switch (action.type) {
    case "add":
      return { count: state.count + action?.add };
    case "subtract":
      return { count: state.count - action?.subtract };
    default:
      throw new Error();
  }
};

export const Reducer = () => {
  const [state, dispatch] = useReducer(reducer, { count: 0 });

  function onAdd1() {
    dispatch({ type: "add", add: 1 });
  }

  function onAdd2() { 
    dispatch({ type: "add" }); // will give error because we didn't provide a payload (add) with a number value
  }
  function onSubtract1() { 
    dispatch({ type: "SUBTRACT", subtract: 1 }); // will give error because type doesn't match
  }

  function onSubtract2() { 
    dispatch({ type: "subtract", subtract: "123" }); // will give error because payload subtract must be a number
  }

  return (
    <>
      <h1>{state.count}</h1>
      <button onClick={onAdd1}>add</button>
      <button onClick={onAdd2}>add</button>
      <button onClick={onSubtract1}>subtract</button>
      <button onClick={onSubtract2}>subtract</button>
    </>
  );
};

3. Excess Properties & Explicit Typing:

Finally, TypeScript provides a way to strongly type the functions returned by useState. This helps ensure that you’re using the correct type when updating the state and provide better error handling.

When you use the useState hook in a React component with TypeScript, the type of the state is inferred based on the initial value you provide. However, when you update the state using setState, TypeScript does not perform excess property checking by default. This means that you can add additional properties to the object you pass to setState, even if they are not part of the type of the state.

Consider the code below:

import { useState } from "react";

interface TagState {
  tagSelected: number | null;
  tags: { id: number; value: string }[];
}

export const Tags = () => {
  const [state, setState] = useState<TagState>({
    tags: [],
    tagSelected: null,
  });
  return (
    <div>
      {state.tags.map((tag) => {
        return (
          <button
            key={tag.id}
            onClick={() => {
              setState((currentState) => ({
                ...currentState,
                tagselected: tag.id,
              }));
            }}
          >
            {tag.value}
          </button>
        );
      })}
      <button
        onClick={() => {
          setState((currentState) => ({
            ...currentState,
            tags: [
              ...currentState.tags,
              {
                id: new Date().getTime(),
                value: "New",
                otherValue: "something",
              },
            ],
          }));
        }}
      >
        Add Tag
      </button>
    </div>
  );
};

In the example above, when the Add Tag button is clicked it adds a new tag to the tags array, with properties id, value, otherValue , if the user clicked on one of the tags, the tagselected will be the tag id, there are two issues with our code, can you spot them? we added otherValue to the tags array, this property didn’t exist in our original tags type, yet typescript didn’t spot the issue. the second issue is tagselected , our original TagState interface had a property called tagSelected camel-cased, typescript didn’t spot this issue as well.

To get an error for this bug we can use explicit typing:

<button
      key={tag.id}
      onClick={() => {
        setState(
          (currentState): TagState => ({ //notice the change in this line
            ...currentState,
            tagselected: tag.id, // will get an error due to explicit typing
          })
        );
      }}
    >
      {tag.value}
    </button>

<button
    onClick={() => {
      setState(
        (currentState): TagState => ({ //notice the change in this line
          ...currentState,
          tags: [
            ...currentState.tags,
            {
              id: new Date().getTime(),
              value: "New",
              otherValue: "something", // will get an error due to explicit typing
            },
          ],
        })
      );
    }}
  >
    Add Tag
  </button>

With explicit typing in place, TypeScript will now catch the typo in tagselected and the extra property otherValue, and throw an error. By catching these errors early, we can avoid bugs and improve the reliability of our code.

To summarize, TypeScript offers several useful features for React developers, including:

The ComponentProps utility type, which automatically extracts the props type from a given component and helps avoid errors when defining a component’s props.
Union types, which allow you to define a state type that can have multiple variations and provide better error handling with useReducer.
Explicit typing with useState functions, which helps ensure that you’re using the correct type when updating the state and catches errors early.

By leveraging these features, you can improve your React codebase’s maintainability, extensibility, and robustness. So next time you’re working on a React project, consider using TypeScript to take your development to the next level.

Automate The Boring Stuff In React

Mazen Emam — Mon, 17 Oct 2022 13:33:38 +0000

Have you heard of DRY before?

In the world of programming, DRY stands for Don’t Repeat Yourself. React, being a library, lacks a lot of the boilerplate code, you don’t even get a folder for components folder in the src folder!!!

I’ve been working with React for almost 3 years now, and I can’t begin to tell you how much time I wasted on the structure of my project or creating code snippets to help myself write code faster.

One thing Angular and Vue excel at is their CLI (command line interface), you can get a lot of things out of the box and won’t have to waste time on things that are mandatory to get a real project up and running.

Angular being a framework, you have a specific folder structure for the project, you get the option to connect the router out of the box to it, and a CLI tool that helps you easily create components.

You type one line ng generate component component-name and get a folder with the component name you specified, an HTML file, a CSS file, a typescript file, and a file for testing. With Vue, you can get even move out of the box with their CLI tool, you can get a router, global state management, unit testing, and end-to-end testing.

Today I took it into my own hands to right this wrong

https://medium.com/media/df850b5cd00bdfb2ff3d729a9d886f8b/href

Or at least try to.

I was so sick of manually creating a folder for my component, creating a JSX, and a CSS file, and adding the template code for the 47876984654 times. I had an idea of what I needed, I needed to run a script!

Here’s a look at what our final script will look like

#! /bin/bash
echo "what is the component name?"
read component
echo "jsx or tsx?" # find someway in the future to loop back if the value isn't jsx or tsx
read type # find someway in the future to loop back if the value isn't jsx or tsx
echo "I'll Create An Awesome ${component^} Component For You ✨✨"

mkdir $component
cd $component
touch index.$type
touch ${component^}.module.css

echo ".$component {" > ${component^}.module.css
echo " position: relative;" >> ${component^}.module.css
echo "}" >> ${component^}.module.css

if ["$type" = "jsx"];
then
    echo "// Style" > index.$type
    echo -e "import classes from \x22./${component^}.module.css\x22;" >> index.$type
    echo "" >> index.$type
    echo "const ${component^} = () => {" >> index.$type
    echo "" >> index.$type
    echo " return (" >> index.$type
    echo " <section className={classes.$component}>${component^}</section>" >> index.$type
    echo " );" >> index.$type
    echo "};" >> index.$type
    echo "export default ${component^}" >> index.$type
else
    echo "// Style" > index.$type
    echo -e "import classes from \x22./${component^}.module.css\x22;" >> index.$type
    echo "" >> index.$type
    echo "// Interface" >> index.$type
    echo "export interface ${component^}Props {" >> index.$type
    echo "" >> index.$type
    echo "}" >> index.$type
    echo "" >> index.$type
    echo "const ${component^} = (props:${component^}Props): JSX.Element => {" >> index.$type
    echo " const { } = props;" >> index.$type
    echo "" >> index.$type
    echo " return (" >> index.$type
    echo " <section className={classes.$component}>${component^}</section>" >> index.$type
    echo " );" >> index.$type
    echo "};" >> index.$type
    echo "export default ${component^}" >> index.$type
fi

echo "(￣^￣ )ゞ I'm done!"

But first, what is a script/bash script/shell script?

NB: you can find what shells are installed on your system by opening your terminal and type

cat /etc/shells

This might sound awkward but, although I’ve been using different Linux distributions as my main operating system for the past 4 years, I never need to write a single script during that time 😅 There is no shame in using the GUI, but now I can understand why the community recommends investing time learning about scripting and CLI tools.

To my surprise, learning to write a script to do the task I had in mind wasn’t so hard, all I wanted was to automate the boilerplate creation of my components similar to the one in Angular. It took me a few hours of googling, asking the right questions, and watching a couple of tutorials on YouTube, but in the end, the job was finished successfully 😎

First things first, let’s open the terminal again, go to Desktop and create a playground folder, you can do so by following these commands

cd Desktop # This is a comment, all comments will have # before it, comments are ignored by the interpreter

mkdir bashExamples # mkdir stands for make directory
cd bashExamples # cd stands for change directory

Now we need to locate the bash interpreter

which bash

In my case the output was /bin/bash, we will need this location later so save the output on your clipboard.

Now that we are in the bashExamples folder let’s create our first script.

nano component.sh # nano is a command line text editor, it will create a file called component.sh and open it in the terminal

Now let’s write our first script!

#! /bin/bash
echo "what is the component name?"
read component
echo "jsx or tsx?"
read type
echo "I'll Create An Awesome ${component^} Component for you ✨✨"

Then you click ctrl+x to exit, save? Y filename to write: I don’t want to change that so I click onenter

NB: emojis might look different in nano when you copy-paste them, this is ok, the output will be normal emojis when you run the script.

So what did we write?

Remember the output from the which bash command that I told you we will need later, now is later, we need it on the first line of the file to let the interpreter know how to interpret our file and this is the syntax to do it with #!, think of this line as <!DOCTYPE html> for the HTML file.

Then we use echocommand to output a text and save the value the user writes into a variable called component withread command, then we output another text with and save the value the user writes into a variable called type, then we output some text with the variable the user entered. The ${component^} syntax will capitalize the first letter in a variable.

You can run the script by writing bash component.sh

This is the output I got after running the script at this point

I was prompted with a question asking me to enter the component name, I typed navbar and clicked enter, then I was prompted with the jsx or tsx? I typed tsx and clicked enter, and I got the output you see in the last line.

Ok, this is good, useless but, still good. Next, let’s make use of these variables and create a folder for our component, a CSS file, and another file (jsx or tsx) using those variables.

Open your file once again by typing nano component.sh , and add the code below

mkdir $component # make a directory/folder with the variable name stored in component
cd $component # change directory into that folder
touch index.$type # create a file called index with the file type entered
touch ${component^}.module.css # create a css file called with the component name entered

Then you click ctrl+x to exit, save? Y filename to write: I don’t want to change that, so I click onenter

Let’s run the script once more bash component.sh repeat what we did the first time and see the result of our newly added code, if you didn’t face an error you should have a navbar folder with index.tsx and Navbar.module.css files in it

Next, let’s write into a file, one thing I picked up from my senior at work is having my component wrapped in a section tag that has a className with the component name, and making this class a position relative in my CSS file so that anything absolutely positioned will be bounded by the boundaries of my component.

Open your file once again by typing nano component.sh and add the code below

echo ".$component {" > ${component^}.module.css
echo " position: relative;" >> ${component^}.module.css
echo "}" >> ${component^}.module.css

Then you click ctrl+x to exit, save? Y filename to write: I don’t want to change that, so I click onenter

So far we have been using echo only to show some text in the terminal but, echo can be used to add text to a file as well, to do that you will use > and >> at the end of your line followed by the file name.

will add text to the first line of the file, and >> will add text to the very next line.

So what does this code do?

It will add a dot, the variable name stored in the component variable, and then will open curly braces to the first line of your CSS file, on the second line will add some spacing and position: relative; , and on the third line, it will add closing curly braces.

If we tested the code now and write navbar as our component name, we will get an error because a folder with that name already exists, we have two options, either delete that folder so we could create it again or create a component with another name, I will go with the latter.

Next, we will create the jsx/tsx file.

Open your file once again by typing nano component.sh and add the code below

if ["$type" = "jsx"];
then
    echo "// Style" > index.$type
    echo -e "import classes from \x22./${component^}.module.css\x22;" >> index.$type
    echo "" >> index.$type
    echo "const ${component^} = () => {" >> index.$type
    echo "" >> index.$type
    echo " return (" >> index.$type
    echo " <section className={classes.$component}>${component^}</section>" >> index.$type
    echo " );" >> index.$type
    echo "};" >> index.$type
    echo "export default ${component^}" >> index.$type
else
    echo "// Style" > index.$type
    echo -e "import classes from \x22./${component^}.module.css\x22;" >> index.$type
    echo "" >> index.$type
    echo "// Interface" >> index.$type
    echo "export interface ${component^}Props {" >> index.$type
    echo "" >> index.$type
    echo "}" >> index.$type
    echo "" >> index.$type
    echo "const ${component^} = (props:${component^}Props): JSX.Element => {" >> index.$type
    echo " const { } = props;" >> index.$type
    echo "" >> index.$type
    echo " return (" >> index.$type
    echo " <section className={classes.$component}>${component^}</section>" >> index.$type
    echo " );" >> index.$type
    echo "};" >> index.$type
    echo "export default ${component^}" >> index.$type
fi

echo "(￣^￣ )ゞ I'm done!"

Then you click ctrl+x to exit, save? Y filename to write: I don’t want to change that, so I click onenter

Most of the syntax here isn’t new, we are just adding some text to a file, what you will find new are lines 4 and line 15 (basically the same line) and the syntax for writing an if statement. The thing about the if statement in shell is that spacing and indentation are important.

if ["$secretvariable" = "yes"] # the spacing here is important
then
     echo "yes" # indentation here is important
else
    echo "no" # indentation here is important
fi # this is how you end if statments

The idea in this small snippet is the same as that in my 32 lines code, If my secretvariable equals to “yes” it will output “yes” or else it will output “no”. I used the same idea in my 32-line code up there, but I am inserting text into a file instead.

The weird syntax in lines 4 and line 15 is used to add a double quotation to our text, notice that any echo statement starts and ends with a double quotation, I tried some suggestions from stack overflow but I couldn’t escape it 😔 luckily I found an answer where someone suggested another way around it using the ASCII codes of the double quotation character instead 😊 so that is all about the weird -e and \x22 .

let’s see the result of our hard work 🤞

NB: you might see an error Cannot find module ‘./yourModuleName.module.css’ or its corresponding type declarations. this is normal since we are not using a React project for testing but, a regular folder. I tested the script in a Typescript React project, and it didn’t show the error.

Now into the final scene, having you test the script in a React js/ts project 😅

We need to make component.sh available globally in our system, so we could call it from anywhere we like, this could be done easily on Linux, you will need to move the file to a folder called bin which you will find in the user folder, the path will be /home/[YourUserName]/bin

The steps to have a script available globally will probably be different depending on your operating system, so you will need to do some research on your own.

Edit: Hello this is Mazen from the future, I’m using Windows now 😭

To make your script excutable you need to follow these steps:

Open a Git Bash shell as an administrator
Navigate to a directory that is already on the PATH. cd /c/Windows/System32
Create a symbolic link to the component.sh script in the current directory using the ln command. ln -s "path/to/your/script/component.sh" component

Now you can call your script from anywhere by just typing component in your Bash.

And that’s it, I hope you can see now how useful it is to learn about bash scripting and how you can build on what I taught you to build the structure for your whole React project with a single command line.

The code I wrote is by no means the best code to do the job, my whole experience with scripting is just a few hours, I’m open to suggestions and ideas to refactor this code. Please write them down below in the comment section, and also if you built any script to automate some boring repetitive React-related task, feel free to share it down there.

Don’t forget to clap and share the post if you found it useful, it will help me write more often.

Ciao 👋

My Unorthodox Frontend Interview

Mazen Emam — Sun, 25 Sep 2022 14:36:48 +0000

Picture from the Search Committee episode — The Office tv series

Last week I did my first technical interview at a medium-size tech company, most of the interviews I had so far were at small-size tech companies, It was interesting and different from other interviewing experiences I had before.

Q: What is the difference between small and medium size company interviews?

A: The difference is in the type of questions and what the interviewer seeks to learn about you.

Here is a comparison between applying to a React Developer role in those two different organizations.

In the small ones, you would typically be asked about programming languages and frameworks you will use in your daily life.

For example: in my last interview in a small company I was asked about the difference between var, let, and const, some more Javascript questions, and a Javascript problem, I was also asked If I’ve used Typescript before, then we moved to the React, I was asked about Context API, React Router and Redux Toolkit.

In the medium ones, the interviewer is after something else, they want to know if you know the value of the code you are writing and its effect on the whole project.

Example: I was asked about clean code, object-oriented programming (OOP), testing (unit testing — automated testing), website performance, tracking traffic, data structure, and the space and time complexity of an algorithm.

I was also asked some general frontend questions which I regret not answering perfectly :(

Hopefully, they will help you be more prepared for your next interview🤞

Q1: What is the difference between cookies, local storage, and session storage?

Q2: What is the difference between HTTP and HTTPS?

Q3: What is the difference between Put and Patch request methods?

I didn’t know the answer to this one at all 😐 I’m still embarrassed about it.

Q4: What are 3 ways you can use to optimize a page that loads 100 Images

Pagination
Lazy loading
Intersection Observer API

I found this article to be very insightful on optimization and performance.

Have you heard of AbortController API before 👀 Check out this article!

Q5: Find all the duplicates in an array and explain the time complexity of your algorithm

At the time of the interview, I didn’t do well at this one, I gave an algorithm with O(n²) complexity🤦‍♂ but this incident taught me a lesson about the importance of learning algorithms.

On a regular day, I’d probably solve this problem with a code like this:

function removeDuplicates(arr) {
   return arr.filter((item,index) => arr.indexOf(item) === index);
 }

If you are looking for a more efficient solution, you should check the video below, I tested both solutions on Leetcode and the one from the video was way faster than my solution.

Bonus: Do you know that for loop is the fastest loop?

Hope you enjoyed this read and have refreshed your memory on some interview topics.

Ciao👋

EgyptFWD React Nanodegree Walkthrough

Mazen Emam — Sun, 14 Aug 2022 15:44:06 +0000

Photo by Nubelson Fernandes on Unsplash

EgyptFWD is a digital scholarship provided by the Egyptian Ministry of Communication and Information Technology.

Content:

Prerequisites
Duration
Who is this Nanodegree for:
Applying process
A regular day/week
Program Syllabus

1. Prerequisites:

There are 2 types of prerequisites for this scholarship:

General for any course, and specific to each course.

A. The General prerequisites:

You’re Egyptian.
You’re older than 18.

B. The Specific prerequisites:

You have a good grasp of frontend fundamentals (HTML, CSS, JS)
You have good knowledge of promises and asynchronous Javascript
You have a basic understanding of the command line and GIT version control

I’d recommend that you have built some small-medium size projects from the ground up, like an e-commerce application for example before applying.

“why?”

Because by building this kind of project will ensure that you’re comfortable enough with Javascript arrays, objects, loops, DOM Manipulation, and all the other fundamentals that will set you on the right pass to success in the Nanodegree

NB: one important thing that you should be aware of before applying is that the scholarship program has 3 tracks: Specialized Program, Cross-Skilling Program, and Expert Programs.

The React Nanodegree belongs to the cross-skilling program, after finishing it, you may only apply to the courses from the expert program, but you can’t apply to courses from the specialized program or the cross-skilling program again.

I’d advise you to check out all the courses on EgyptFWD first before applying as applying to courses from some tracks may prevent you from applying to others.

2. Duration:

The cohort duration is one month.

3. Who is this Nanodegree for?

In my opinion, this Nanodegree is a good addition to your knowledge arsenal if you’re just beginning with React. It will build you from the ground up, and the greatest part is that there are no jumping hoops or shortcuts. Everything is logical, you go from A to B to C to D, and there’s no A to D. But, my favorite thing about Udacity is the personalized project reviews 😍 this service is what makes Udacity better than all its competitors in my opinion, a human reviewing your code, not a machine just comparing the result.

If you’re an experienced React developer, I think you’ll enjoy the extracurricular section more than the core curricular (check out the content section)

4. Applying process:

The process is simple. after you go to the React Nanodegree page and click apply, it will redirect you to a Udacity page where you get a couple of MCQ problems, you finish them, and submit your information, your national ID, etc … and that’s it. The absurd part is, that you don’t get to hear anything about your score (actually you won’t) and if you’re accepted or not till the very last day before the program starts, but after you receive that mail, it’s all up from here 🎉

5. A regular day/week

Your best friends during the scholarship are going to be Slack and Google Calendar 😂

Slack is used as the main way of communication between you and the Udacity community moderator, session leads, and your peers.

Each week you will have one connect session (technical session), one career coaching session (career AMA session), one career webinar session (soft skills session), and one agile session (two throughout the whole scholarship).

The session duration is about two hours max, and they all start after 6 pm throughout the week. You’re also advised to study from 2 to 4 hours each day to ensure finishing all your graduation projects in time. Get ready to sharpen those time management skills of yours, no more slacking!

6. Program Syllabus

The curriculum consists of two parts: core and extra

A. Core Curricular

React Fundamentals (1 Project)
Foundations of Agile
Career Services for EgFwd Program (4 Projects)

B. Extracurricular

React & Redux

NB: the content is a little different than what you see in the original React Nanodegree on Udacity

Core Curricular

The most important module in the Core Curricular is the React Fundamentals module , here is where the magic happens, you start transitioning your mindset from the vanilla Javascript world into the DRY, React, and components world.

The React Fundamentals module consists of 5 lessons and 1 Project

Why React
Rendering UI with React
State Management
Hooks
Routing

And the project would be relatively easy after you’re done with those 5 lessons

Next, Foundations of Agile module , I enjoyed learning about agile.

If you don’t know what agile is, it’s a different approach to managing projects.

In agile, you publish a working demo with the core features of your final project within 1 to 3 weeks (depending on the sprint length) then depending on the users’ feedback, the project development may go in another direction, you listen to that feedback, update and add new features and publish a new working demo by the end of every sprint and this cycle continues till the project is done.

Meme time:

The last module is the Career Service module , this one is very straightforward, it focuses on your online presence and what you’d need when applying for a job.

It consists of 7 lessons and 4 projects, the lessons are:

Resume Review
Cover Letter Review
Linkedin Review
Conduct Industry Research
Github Review
Collaborate Using Github
Write Meaningful READMEs

The 4 projects are:

Resume Review
Cover Letter Review
Linkedin Review
Github Review

Extracurricular

In the extracurricular, you will go deep into Redux and the world of state management.

This part consists of only one module called React & Redux which consists of 6 lessons:

Managing State
UI + Redux
Redux Middleware
Redux with React
Asynchronous Redux
React-Redux

After you’re done with this module, you’ll need to have a look at Redux Toolkit (RTK) and see how much faster/easier the work we used to do with plain Redux can be done with RTK.

And that’s it, hope the journey wasn’t long, boring, or intimidating 😅

I promise it’s a fun ride, and you’ll gain a lot of valuable knowledge along the way. Did I miss something you’d like to know? feel free to shoot me your questions

Ciao 👋

Sorting Table Columns

Mazen Emam — Sat, 12 Mar 2022 20:36:03 +0000

I’ve been working with tables a lot these past few weeks, one task I got today was to implement a feature to sort table columns for unsorted data coming from the backend, this is how I tackled the task

NB: I’m using jsonplaceholder to mimic the API I’ll be using for fetching data

So here’s what happened so far, our return statement ran first, we draw the table, Data and TableHeaders are initially empty, so nothing is shown, then the useEffect kicks in, we fetch our data, set the Data state to JSON variable resulted from the API call and then we set TableHeaders to the keys of the first object in JSON

The result of json[0] is

{
    "userId": 1,
    "id": 1,
    "title": "delectus aut autem",
    "completed": false
}

Object.keys(json[0]) returns an array with the keys of an object so now our TableHeaders look like this

["userId", "id", "title", "completed"]

setting the TableHeaders & Data states triggers a rerender, we then redraw our table and this is how it’d look like.

Next, Sorting the Columns.

I created an array called HeadersSchema which I’ll use to enforce the new order on my headers and since our tbody is drawn through the values in TableHeaders there won’t be much work needed on that end.

In the useEffect, instead of just setting the keys from the first object as they are to the TableHeaders, I’ll loop over those keys and loop over the schema when the name in my schema objects matches the Key from Object.keys(json[0]), I’ll add that Key to a new variable I’ve created in line 32 (very poor naming on my end, should have picked a better name than TableHeaders to avoid confusion😅) in that specific order I got in my schema.

At this point, TableHeaders look like this

[empty x 2, "title", empty x 3, "id", empty x 2, "completed",empty x 78, "userId"]

to remove those empty slots we’ll use the filter function, filter returns a new array that matches our callback function, and in the callback, we’ll return the truthy values only hence all the empty slots are undefined (falsy)

TableHeaders now look like this

["title", "id", "completed", "userId"]

and that’s it! we have sorted our columns successfully in the same order provided in the schema 🥳

Lastly, we’ll handle the edge case scenarios if the same order in our schema is duplicated or if an object in our schema has no order at all 🤔

Luckily, both cases aren’t tough to handle.

const HeaderOrder = HandlingHeaders(Header.order ? Header.order : 99);
TableHeaders[HeaderOrder] = Key;

I’ve replaced the Header.order from the second demo with the variable HeaderOrder.

HandlingHeaders is a function that checks if there’s no value in the index passed in the TableHeaders array … no value in that index? cool, return that number … value in that number? add 1 and check again.

In our case, both userId and title have order 2

[empty x 2, "userId", .....]

userId will take that spot since it comes first in our schema, when it’s time for the title to be called, HandlingHeaders will be called with the order of title (2) … oh no someone already filled that spot! recursion happens, calls HandlingHeaders(3) and this time and our array will look like this

[empty x 2, "userId", "title", ......]

and that’s how we’ll handle having two objects in our schema with the same order.

In case we didn’t receive an order at all in our schema, I handled it with a small condition before passing the values to HandlingHeaders

const HeaderOrder = HandlingHeaders(Header.order ? Header.order : 99);

And that’s the two edge case scenarios!

The result will look like this:

Hope you found this post useful,

Feel free to leave a comment if you have any questions.

And you can find all the code from the demos here: https://github.com/mazenadel19/React-SortingTableColumns

The Truth Table in React

Mazen Emam — Wed, 19 Jan 2022 22:17:17 +0000

One of the first topics you learn about when you get introduced to programming is “The Truth Table”, Do you remember that topic?

In case you don’t, here’s a reminder:

I remember memorizing that table, I kept repeating it day and night, but I never had any real application for it (or so I thought…)

Today I realized that I’ve been using it all the time but I never knew 🤯

The most common use case is showing/hiding a component based on conditions with the && operator

true && <Component/> {/* will render the component*/}

false && <Component/> {/* will hide the component*/}

Does this code block look familiar?

It’s !!

Actually, these conditions resolve to

true && true => true 

false && true => false

Which is the result expected if you know the truth table

Another use-case is using the || operator to assign a default value

Ignoring that we could set the initial state to [] instead of null , using the || operator could come in handy.

In this example, we pass a prop called data to the Blog component, posts have a falsy initial value (null ) and the empty array is a truthy value

data={false || []} {/* sends the empty array to Blog component */}

so that expression will resolve to

false || true => true

After the API call resolves successfully and our posts become populated, posts become truthy

true || true => true

But which true value is sent

|| behaviour is to return the first truthy value, opposite to && which returns last truthy value

and since our posts are truthy now

data={true || []} {/* sends posts array to Blog component*/}

Hope you found this post useful,

If you know of any other use cases, feel free to share them in the comment section.

Ciao👋