Forem: payapula

Context, Redux or Composition?

payapula — Sat, 14 Dec 2024 15:47:49 +0000

This post was originally published on February 23, 2023 @ my blog page

I was one of the developer who got impacted by the recent layoffs from tech companies. So, I started giving interviews for frontend positions with react.

In one of the companies I was given a classic prop drilling problem in react,
and was asked to solve it. To keep things simple, the problem given was like
this:

export default function App() {
  const [user, setUser] = React.useState(null);

  const handleLogin = () => setUser(userDetails);

  return (
    <div className="App">
      Company Logo
      <div>
        {user ? (
          <Dashboard user={user} />
        ) : (
          <button onClick={handleLogin}>Login</button>
        )}
      </div>
    </div>
  );
}

function Dashboard({ user }) {
  return (
    <div>
      <DashboardNav user={user} />
    </div>
  );
}

function DashboardNav({ user }) {
  return (
    <div>
      <WelcomeUser user={user} />
      <UserRole user={user} />
    </div>
  );
}

function WelcomeUser({ user }) {
  return <div>Welcome {user.name}</div>;
}

function UserRole({ user }) {
  return <div>Role {user.role}</div>;
}

As you can observe, we are passing the user prop from App component to the
child components WelcomeUser and UserRole. The intermediate components Dashboard and DashboardNav are just forwarding the props and not really using it.

This is a classic prop drilling issue in react.

Interestingly, the interviewer asked to solve the problem by either React Context API
or by using Redux.

Solving by React Context

Using context API to solve this problem would look like the code below.

const UserContext = React.createContext(undefined);

export default function App() {
  const [user, setUser] = React.useState(null);

  const handleLogin = () => setUser(userDetails);

  return (
    <div className="App">
      Company Logo: Context
      <div>
        {user ? (
          <UserContext.Provider value={user}>
            <Dashboard />
          </UserContext.Provider>
        ) : (
          <button onClick={handleLogin}>Login</button>
        )}
      </div>
    </div>
  );
}

function Dashboard() {
  return (
    <div>
      <DashboardNav />
    </div>
  );
}

function DashboardNav() {
  return (
    <div>
      <WelcomeUser />
      <UserRole />
    </div>
  );
}

function WelcomeUser() {
  const user = React.useContext(UserContext);
  return <div>Welcome {user.name}</div>;
}

function UserRole() {
  const user = React.useContext(UserContext);
  return <div>Role {user.role}</div>;
}

We are creating UserContext and wrapping the Dashboard with Provider, so that
we can pass the props we want to a deeply nested child component. This solution
works.

Solving by Redux

So, if we are going on the classical redux route, we need to create a similar
structure and wrap everything with a single global store, which contains the user
object.

The solution code would contain a ton of boilerplate, as we are using redux for
solving a simple problem.

I just gave the gist of the code below, but if you really want to explore the full
code, here you go: solving with redux.

export default function App() {
  return (
    <Provider store={store}>
      <ReduxConnectedApp />
    </Provider>
  );
}

function ReduxApp({ user, setUser }) {
  const handleLogin = () => setUser(userDetails);

  return (
    <div className="App">
      Company Logo: Redux
      <div>
        {user ? <Dashboard /> : <button onClick={handleLogin}>Login</button>}
      </div>
    </div>
  );
}


function Dashboard() {
  return (
    <div>
      <DashboardNav />
    </div>
  );
}

function DashboardNav() {
  return (
    <div>
      <ConnectedWelcomeUser />
      <ConnectedUserRole />
    </div>
  );
}

function WelcomeUser({ user }) {
  return <div>Welcome {user.name}</div>;
}

const mapStateToPropsWelcomeUser = (state) => ({ user: state });
const ConnectedWelcomeUser = connect(mapStateToPropsWelcomeUser)(WelcomeUser);

function UserRole({ user }) {
  return <div>Role {user.role}</div>;
}

const mapStateToPropsUserRole = (state) => ({ user: state });
const ConnectedUserRole = connect(mapStateToPropsUserRole)(UserRole);

We have connected the components that needs access to global state
stored in redux.

How I solved it

Having read about react composition, I solved the problem by making
use of children prop, which looked like this

export default function AppSolution() {
  const [user, setUser] = React.useState(null);

  const handleLogin = () => setUser(userDetails);

  return (
    <div className="App">
      Company Logo
      <div>
        {user ? (
          <Dashboard>
            <DashboardNav>
              <WelcomeUser user={user} />
              <UserRole user={user} />
            </DashboardNav>
          </Dashboard>
        ) : (
          <button onClick={handleLogin}>Login</button>
        )}
      </div>
    </div>
  );
}

function Dashboard({ children }) {
  return <div>{children}</div>;
}

function DashboardNav({ children }) {
  return <div>{children}</div>;
}

function WelcomeUser({ user }) {
  return <div>Welcome {user.name}</div>;
}

function UserRole({ user }) {
  return <div>Role {user.role}</div>;
}

If you think about it, this is the easy way to solve this problem without introducing
any complexity like createContext or react-redux. We also get other benefits such
as

In the future, if we introduce any state inside Dashboard and manipulate it, our DashboardNav never gets re-rendered.
By supplying the props only to the required components, we have a good visibility of all the consumers of user, without having to navigate between components (files) to look for them.

This pattern is not new, and it's already been talked about in react community. One such good walkthrough is Using Composition in React to Avoid "Prop Drilling"

Conclusion

However, I got the feedback from the interviewer, and it goes like this

The interviewee did not understand the problem correctly, and was unable to provide the expected solution.

I guess the reason being either the interviewer was not aware of this pattern or I chose to solve the problem in a way that was not asked for.

Having said that, I am now motivated to write more about interesting patterns in react, hoping it reaches the wider audience.

Let me know what you think by sharing this article.

References

Positioned Layout in CSS

payapula — Thu, 16 Feb 2023 16:50:59 +0000

This post acts as notes for Module 2 of Josh Comeau's Course CSS for JavaScript Developers. Learning in Public helps me stay focused. The Goal is to have a single post to cover an entire module. So, You can use this page as a quick reference or as a summary. Added a codesandbox link all the way at the bottom with some examples.

Positioned layout differs from the OG Flow layout in CSS in the way that items can overlap with each other. It is set using the position property of CSS. The possible values for position are relative, absolute, fixed, and sticky.

Relative

With this property on an element, along with the directional properties like top, right, bottom or left the element would be positioned relative to its original position.

For example, left: 50px would shift an element 50px from the left.

The crucial difference between shifting an element from its natural position by having position set as relative rather than using margin properties is that the neighboring elements won't be impacted by the shift in the case of relative.

The neighboring elements behave as if the relative positioned element is still in its original position. The shift is just cosmetic.

This property can be applied to inline elements to shift them from natural position.

Absolute

Absolute positioned elements takes the same properties of relatively positioned elements, which is top, right, bottom and left. The difference is absolutely positioned elements would be placed based on its container rather than its in-flow position.

If there is no anchor properties specified on absolute element, it would be laid out in its in-flow position.
position: absolute would take the element out of the flow.
display: inline or display: block has no effect on absolutely positioned elements.
The default behavior of absolute elements is to try to fit the content's width.

Centering Trick

To center an absolutely positioned elements relative to its parent we would make use of hungry margin's trick which sets the element's margin to auto.

This effectively adjusts the margin's vertically and horizontally which forces the element to be in the center of the container.

In case of flow layout, the margin tricks would be applied only on the inline direction (horizontally), however with absolute positioning, margin applies on block direction as well (vertical).

There are four important ingredients for this trick to work:

absolute positioning (position: absolute)
Equal distances from each edge (ideally 0px)
A fixed size (defined width and height properties)
Hungry margins (margin: auto)

Containing Blocks

Absolutely positioned elements would be placed based on its containing block.

Absolute element can only be contained by other elements which uses positioned layout.
When deciding where to place an absolutely-positioned element, it crawls up through the tree, looking for a Positioned ancestor. The first one it finds will provide the containing block.
The other element doesn't necessarily be relative, absolute, fixed, and sticky will also work.
Absolute element's doesn't care about properties like padding, as it is taken out of flow.

Stacking Contexts

When two or more elements overlap, the browser decides to show one element on top of another element. We will see in this section how the overlapping behavior is calculated by the browser.

Positioned elements will always render on top of non-positioned ones.
On the first iteration to layout elements, the browser would paint all the non-positioned elements (Flex, Grid, Flow etc.), then it would render positioned ones on top of them.
If both the elements use positioned layouts then DOM order wins.

These are some declarations that create a new stacking context:

Setting opacity to a value less than 1
Setting position to fixed or sticky (No z-index needed for these values!)
Applying a mix-blend-mode other than normal
Adding a z-index to a child inside a display: flex or display: grid container
Using transform, filter, clip-path, or perspective
Explicitly creating a context with isolation: isolate

Z-Index

Z-Index is used to override default browser behavior as explained in the above section.
Z-Index works only on the positioned elements, it will have no effect on Flow elements.
Z-Index values are not global, they are not compared against the entire application.
When we create a stacking context, any children on that element would only be compared with children within that element.
The isolation property trick can be used to separate different sections from not taking part in stacking context wars.
The isolation: isolate on an element creates a stacking context without setting a z-index!
The isolation property is not supported in Internet Explorer.

Fixed Positioning

Exactly similar to absolute but it doesn't care about containing blocks and always be constrained by viewport.
We can think of Fixed position as spicy absolute 🔥
The centering trick from absolute position can be applied to Fixed elements as well and works great for Modals that needs to be displayed at the center of screen irrespective of scroll position.
If anchor properties were removed, it would be placed in its in-flow position.
If any of the parent or grandparents use transform or will-transform property, the fixed element would become absolutely positioned element in the sense, it would be constrained by the containing block instead of the viewport.

Overflow

Overflow situation occurs with block elements with fixed height, in which the content overflows. To solve overflows, we have overflow property.

Default value for overflow is visible, which displays overflown content beyond the parent.
scroll value displays a scroll area for the container which would be displayed all the time, even if the container does not have overflowing content.
auto is a smart value that adds a scrollbar when one is required.
hidden which hides the overflown content. Its good practice to add a comment when we specify this value to help other developers.

Overflow comprises two values, one for x-axis and other for y-axis

It is not possible in CSS to clip the overflow just in one axis and not affect the other.
When we make overflow:hidden we are actually making a scrollable container without the ability to scroll.

Handling horizontal overflows are a bit tricky. If we have images next to each other and want to create a horizontal scroll bar, just specifying overflow: auto wouldn't help. We need to specify white-space: nowrap instructing browsers that don't line wrap the images.

img elements are inline elements hence line-wrapping them is common in browsers.

Overflow with Positioned Layout

Consider the below example

<style>
.wrapper {
  overflow: auto;
  width: 150px;
  height: 150px;
  border: 3px solid;
}
.box {
  position: absolute;
  top: 24px;
  left: 24px;
  background: deeppink;
  width: 150px;
  height: 200px;
}
</style>

<div class="wrapper">
  <div class="box">
  </div>
</div>

The box is an absolute element wrapped inside wrapper. In general box element should be scrollable inside wrapper as it has overflow: auto. But, it's not!

Absolute positioned box is actually not constrained by wrapper because it does not use positioned layout (anything other than static).
If the wrapper has position: relative, it would turn into a scrollable container for box.
Similarly, for a fixed element, the overflow is not possible as it can only be contained by the viewport (its initial containing block).

Sticky

The idea is that these would be relatively positioned until it sticks to the container, after it touches the container it would be turned to fixed.
Sticky elements only stick while their container is in view.
Sticky elements are not incorporeal, meaning they won't act as holograms, the space it occupies would remain taken, and its siblings knows that the element is still preset.
Sticky elements are considered "in-flow", while fixed elements aren’t.
Sticky elements can stick to either on vertical or horizontal flows.

The anchor values are read differently based on the element's positioning layout mode.

In relative positioning, the element is shifted from its natural, in-flow position.
In absolute positioning, the element is distanced from its containing block's edge.
In fixed positioning, the element is adjusted based on the viewport.
In sticky positioning, the value controls the minimum gap between the element and the edge of the viewport while the container is in-frame.

Sticky in Context

Sticky elements can stick in one context.
Either it sticks to the main viewport scroll, or it sticks to an ancestor that manages overflow.

Hidden Content

Element with style display: none would be hidden, it cannot be clicked or focused.
This display trick is often used to show or hide certain elements with media queries in desktop and mobile.
Element that is hidden with display: none still hogs memory.
visibility: hidden differs from display: none in the way that the hidden element still present and takes space, but just not shown to the user.
visibility: hidden can be selectively undone by children. Usually, when a parent is hidden, all of its children will also be hidden, and there's no way around it except with this visibility: visible.

Accessibility with hidden content

If we have a button with an icon in our application with no text or label, a user who sees that icon would be able to guess what that icon would do. For example, gear for settings and question mark for help, etc.
For people who depend on Screen readers to read web, a helpful text to read out in screen readers would be nice.
Visually hidden CSS trick would hide the text from the page but make it readable for screen readers.
Sometimes we would want to hide some text from screen reader, like when we use it for just cosmetic purposes, in those cases, aria-hidden="true" property can be used to hide that element from screen readers.

Example Playground

Below is the playground with some positioned layouts examples.

Codesandbox playground

References

CSS for JavaScript Developers

How to use Nextjs Link with Chakra UI

payapula — Sat, 20 Nov 2021 12:15:14 +0000

One of the frequently asked questions on chakra ui library discussions is, How do I use nextjs link with chakra ui button or chakra link? In this post let us explore some common patterns to use nextjs link with chakra.

NextJS provides a Link component out of the box, that can be used for Client-side transitions between different routes. This Link component is exported from next/link package.

What is so special about this component is, it prefetches the linked route by default to provide rapid fast 🚀 page transitions. Until the Link becomes visible to the user, it won't prefetch the route, and once the Link is visible the prefetch is done in the background.

So, to use this component with our design system, we can create a custom component wrapper and make it reusable across the application. Let's see how to do that next.

Create Chakra Button with Next Link

Surround chakra Button with next's Link and provide a passHref prop so that it forwards href to the rendered anchor tag for proper semantics and SEO.

import Link from "next/link";
import { Button } from "@chakra-ui/react";

function ChakraNextLinkButton({ href, children, ...props }) {
  return (
    <Link href={href} passHref>
      <Button as="a" {...props}>
        {children}
      </Button>
    </Link>
  );
}

function IndexPage() {
  return (
      <ChakraNextLinkButton href="/about" colorScheme="facebook">
        About
      </ChakraNextLinkButton>
  );
}

Notice the as prop in chakra button on line number 7. We are rendering anchor tag instead of button on DOM and applying chakra button styles to it! You can pass all the chakra button props to the component ChakraNextLinkButton like onClick, padding, margin etc.

With this approach, we are following proper web semantics.

We can change the variant prop to 'link' to the same component to render the link styles.

<ChakraNextLinkButton href="/about" variant="link">
   About
</ChakraNextLinkButton>

At the same time, if you want to have control over next's Link via props, you would need to separate the props in the custom component and pass it appropriately like below

import Link from "next/link";
import { Button } from "@chakra-ui/react";

function ChakraNextLinkButton({ href, children, prefetch = true, ...props }) {
  return (
    <Link href={href} passHref prefetch={prefetch}>
      <Button as="a" {...props}>
        {children}
      </Button>
    </Link>
  );
}

function IndexPage() {
  return (
      <ChakraNextLinkButton
            href="/about"
            colorScheme="facebook"
            prefetch={false}>
            About without prefetch
       </ChakraNextLinkButton>
  );
}

See more about Next's Link props in next's documentation about Link component

Create Chakra Link with Next Link

If we want to use Chakra's Link with Next's Link, we can do that easily by this method.

import Link from "next/link";
import { Link as ChakraLink } from "@chakra-ui/react";

function ChakraNextLink({ href, children, ...props }) {
  return (
    <Link href={href} passHref>
      <ChakraLink {...props}>{children}</ChakraLink>
    </Link>
  );
}

function IndexPage() {
  return (
      <ChakraNextLink href="https://bharathikannan.com" isExternal color="red">
        Visit my homepage
      </ChakraNextLink>
  )
}

Notice that we can pass isExternal prop to the custom component, and that would forward the prop to Chakra's Link component to add the target="_blank" and rel="noopener noreferrer" attributes to rendered HTML automatically.

Usage with Typescript

If you are using next js with typescript and if you want to make use of typescript intellisense, code completion and static type checking for our custom chakra components, you can create a new prop type by merging Chakra's Props and Next's Props and provide it to our component like below

import Link, { LinkProps } from "next/link";
import {
  Button,
  ButtonProps,
} from "@chakra-ui/react";

type ChakraAndNextProps = ButtonProps & LinkProps;

function ChakraNextLinkButton({
  href,
  children,
  prefetch = true,
  ...props
}: ChakraAndNextProps) {
  return (
    <Link href={href} passHref prefetch={prefetch}>
      <Button as="a" {...props}>
        {children}
      </Button>
    </Link>
  );
}

function IndexPage() {
  return (
      <ChakraNextLinkButton href="/about" colorScheme="facebook">
        About
      </ChakraNextLinkButton>
  );
}

Wow! Now we got code completion with static props checking!

And for the Chakra Link,

import Link, { LinkProps } from "next/link";
import {
  Link as ChakraLink,
  LinkProps as ChakraLinkProps,
} from "@chakra-ui/react";

type ChakraLinkAndNextProps = ChakraLinkProps & LinkProps;

function ChakraNextLink({ href, children, ...props }: ChakraLinkAndNextProps) {
  return (
    <Link href={href} passHref>
      <ChakraLink {...props}>{children}</ChakraLink>
    </Link>
  );
}


function IndexPage() {
  return (
    <ChakraNextLink href="https://bharathikannan.com" isExternal color="red">
      Visit my homepage
    </ChakraNextLink>
  );
}

Great! Now we won't be missing Chakra's prop intellisense!

Note: In the above examples, you are responsible for separating chakra props and next props and passing it to the corresponding components!

Bonus Tip

You can shorten the prop spreading on components without mentioning children

// BEFORE
function ChakraNextLinkButton({ href, children, prefetch = true, ...props }) {
  return (
    <Link href={href} passHref prefetch={prefetch}>
      <Button as="a" {...props}>
        {children}
      </Button>
    </Link>
  );
}

// AFTER
function ChakraNextLinkButton({ href, prefetch = true, ...props }) {
  return (
    <Link href={href} passHref prefetch={prefetch}>
      <Button as="a" {...props} />
    </Link>
  );
}

Sandbox Links

Here is the sandbox link for all the above examples to see it live ✅

Do you think anything else to be added? Did you notice any issues in the post? Let me know at my Twitter handle, or please feel free to submit a PR to my post on the blog, How to use Nextjs Link with Chakra UI

References

Minimizing Lodash Bundle Size in CRA and Next.js

payapula — Sat, 28 Aug 2021 12:28:26 +0000

When developing an application, we would usually write some utility functions that could be reused throughout the application.

An example

//--------------
// utils.js

function sum(a, b){
    return a + b;
}

function subtract(a, b){
    return a - b;
}

export {
    sum,
    subtract
}

//---------------
// component.js

import {sum, subtract} from 'utils.js';

function calculate(a, b){
    return sum(a, b) + subtract(a, b);
}

What is Lodash?

Lodash is a package that provides a ton of utilities to help us with manipulating the data we have. It has implementations like clone, deepClone, isNil, every, sum etc.

In a large application, you would import the utilities from lodash like this and use it

import { sum } from "lodash";

<Button onClick={() => {
    console.log(sum([1, 2, 3, 3]));
}}> Sum of Array </Button>

When we are doing this named import from lodash, we are actually importing the whole lodash.js file and using just the sum function from it.

import { sum } from "lodash";

// would be converted to
var lodash = import('lodash');

// and then accessing sum property from lodash
lodash.sum([1, 2, 3, 3])

So, with the named exports it is not possible for the bundlers like webpack to treeshake the unwanted code, and we
end up shipping entire lodash utilities to the user.

You can avoid this by directly importing the utility you need from lodash like this

import sum from "lodash/sum";
import cloneDeep from "lodash/cloneDeep";
import throttle from "lodash/throttle";
...

But this can be tough to maintain if you are using a lot of utilities from lodash in a file and you would have a bunch
of import statements at the top.

Thankfully with babel we have a plugin called babel-plugin-transform-imports, which, if configured, can transform our named imports to default file imports.

All you have to do is install babel-plugin-transform-imports

npm install --save-dev babel-plugin-transform-imports

and configure babel like this

// pacakge.json or .babelrc file

"babel": {
    "plugins": [
        [
            "babel-plugin-transform-imports",
            {
                "lodash": {
                    "transform": "lodash/${member}",
                    "preventFullImport": false
                }
            }
        ]
    ]
}

What this essentially does is

import { sum } from "lodash";

// would be converted by babel on build step to
import sum from "lodash/sum";

// then on the webpack chunk
var lodash_sum = import('lodash/sum.js');

// and then
lodash_sum([1, 2, 3, 3])

Which results in a smaller bundle size!

Let's Measure It

The significant step that we need to do while carrying out performance optimizations is to measure it.

We need to measure the cost before and after introducing an optimization.

If we aren't measuring it, one little mistake with the optimization would cost us additional performance hit than what was before! So, the rule of the thumb is

Don't do performance optimizations without measuring it.

Let's create a react app

npx create-react-app fresh-cra

I am using latest version of create-react-app, with the below packages

"react": "^17.0.2",
"react-dom": "^17.0.2",
"react-scripts": "4.0.3"

I am going to install lodash

npm install lodash

Then, I am going to modify the App.js to include the sum function

import "./App.css";
import { sum } from "lodash";

function App() {
  return (
    <div className="App">
      <button
        onClick={() => {
          console.log(sum([1, 2, 3, 3]));
        }}
      >
        Sum of Array
      </button>
    </div>
  );
}

Now, let's analyse the bundle size.

For this, we would use the package source-map-explorer
which gives a nice visualisation of the bundles that we ship to the users.

npm install --save source-map-explorer

Add a new script in package.json

"scripts": {
+   "analyze": "source-map-explorer 'build/static/js/*.js'",
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",

I am going to build the app to create a /build folder

$ npm run build 

Compiled successfully.
File sizes after gzip:

  65.17 KB  build/static/js/2.ab4556c4.chunk.js
  1.63 KB   build/static/js/3.49b2ab04.chunk.js
  1.17 KB   build/static/js/runtime-main.97cb050d.js
  574 B     build/static/css/main.9d5b29c0.chunk.css
  469 B     build/static/js/main.c3c1410a.chunk.js

Now, I am going to run analyze

npm run analyze

Running this command would open a tab in the default browser with the bundle details.

If the image is too small, the box which has text underlined in red is the size of lodash we are serving to users. We are shipping ~70 KB of lodash package just for using a simple sum utility. Accounts for about 35% of total bundle size 🤯

Let's optimize it

I am going to install babel-plugin-transform-imports

npm install --save-dev babel-plugin-transform-imports

In order to tweak babel configuration without ejecting from create-react-app, we need to add additional
packages.

npm install -D react-app-rewired customize-cra

Then create a config-overrides.js file in your root directory with this code

/* config-overrides.js */
const { useBabelRc, override } = require("customize-cra");

module.exports = override(
  // eslint-disable-next-line react-hooks/rules-of-hooks
  useBabelRc()
);

Replace react-scripts with react-app-rewired in package.json

- "start": "react-scripts start",
- "build": "react-scripts build",
+ "start": "react-app-rewired start",
+ "build": "react-app-rewired build",

The override setup is completed. Now, we can configure babel in create-react-app!

To do that, create a .babelrc file in root directory and use the following code

{
  "plugins": [
    [
      "babel-plugin-transform-imports",
      {
        "lodash": {
          "transform": "lodash/${member}",
          "preventFullImport": true
        }
      }
    ]
  ]
}

Now that we are all set, let's run the build

$ npm run build

Compiled successfully.
File sizes after gzip:

  41.41 KB (-23.75 KB)  build/static/js/2.39f2f9c9.chunk.js
  1.63 KB               build/static/js/3.49b2ab04.chunk.js
  1.17 KB               build/static/js/runtime-main.97cb050d.js
  574 B                 build/static/css/main.9d5b29c0.chunk.css
  472 B (+3 B)          build/static/js/main.9d111c34.chunk.js

then

npm run analyze

💥 Boom! 💥

In the above image, we could not see the lodash box that we saw earlier because of optimization

It looks like lodash is gone! Actually, it's not. Since the cost of sum utility is so small, our source-map-explorer isn't showing that up. Right after the build command, you can see the reduction of chunk size by 23 KB.

Let's explore further

If you are satisfied with the optimization by looking at the output from source-map-explorer then we are good. If you are not, and you are really curious to see the babel magic, let's explore further.

First, let's go back to the state of our application before optimization.

This is simple for us, just replace react-app-rewired with react-scripts

- "build": "react-app-rewired build",
+ "build": "react-scripts build",

Now, to see the babel transpilation, go to webpack.config.js file in node_modules directory and look for the object optimization with the key minimize then make that as false

// node_modules/react-scripts/config/webpack.config.js

...
return {
    ...
    optimization: {
        minimize: false, //isEnvProduction,
        ...
    }
}

This would stop the minification of our source code by webpack, so that we can understand what is shipped to the end-user.

Now, run the build command.

$ npm run build

Compiled successfully.

File sizes after gzip:

  142.77 KB (+77.6 KB)  build/static/js/2.b2a9563e.chunk.js
  2.48 KB (+1.31 KB)    build/static/js/runtime-main.51b24467.js
  2.06 KB (+441 B)      build/static/js/3.8a130f73.chunk.js
  960 B (+491 B)        build/static/js/main.1ad88ea0.chunk.js
  625 B (+51 B)         build/static/css/main.9d5b29c0.chunk.css

The first thing you can observe here is the increase in bundle size! This is because we are no longer minifying our code.

Go into the /build/static/js folder and open the main chunk (main.[HASH].chunk.js).

Search for lodash, and you will see the below code

...
// EXTERNAL MODULE: ./node_modules/lodash/lodash.js
var lodash = __webpack_require__(4);

...

// sum is accessed as a property from lodash object
("button",{onClick:function onClick(){console.log(Object(lodash["sum"])([1,2,3,3]));},children:"Sum of Array"})
...

The one on line number 8 is the transpiled JSX that we wrote.

I have already explained about the JSX transpilation in the post React is Just Javascript

Now, let's do the optimization

- "build": "react-scripts build",
+ "build": "react-app-rewired build",

and run the build

$ npm run build

Compiled successfully.

File sizes after gzip:

  49.64 KB (-93.13 KB)  build/static/js/2.08144287.chunk.js
  2.48 KB               build/static/js/runtime-main.51b24467.js
  2.06 KB               build/static/js/3.8a130f73.chunk.js
  965 B (+5 B)          build/static/js/main.22f99645.chunk.js
  625 B                 build/static/css/main.9d5b29c0.chunk.css

Let's check the transpiled chunk (/build/static/js/main.22f99645.chunk.js)

// EXTERNAL MODULE: ./node_modules/lodash/sum.js
var sum = __webpack_require__(4);
var sum_default = /*#__PURE__*/__webpack_require__.n(sum);

// default sum is called
("button",{onClick:function onClick(){console.log(sum_default()([1,2,3,3]));},children:"Sum of Array"})

Did you notice the difference in the code that we shipped?

Instead of importing everything from lodash.js we are now importing from lodash/sum.js.

Now we can be confident that the babel transform is working as expected.

How to configure for Next.js

In the demo above, we saw how to configure babel-plugin-transform-imports in create next app CLI.

If you are using lodash package with NextJS and if you want to reduce the footprint, it is very simple to do without doing the extra work of rewiring and customizing stuff.

Next.js provides a way for us to tweak into babel and webpack configuration without any hassle. This is the thing I like about Nextjs, it sets up all the right defaults for you, and at the same time, it gives you the root user permissions to tweak the stuff. Enough said, let us see how to do this (in) next.

First install babel-plugin-transform-imports

npm install --save-dev babel-plugin-transform-imports

Then create .babelrc file in the root directory and place this code.

{
    "presets": ["next/babel"],
    "plugins": [
        [
            "babel-plugin-transform-imports",
            {
                "lodash": {
                    "transform": "lodash/${member}",
                    "preventFullImport": true
                }
            }
        ]
    ]
}

This custom configuration file would be picked by next while building your application.

That's it! Congrats 🎉

Now you have shipped just the code you need to run your application !

The beauty of the package babel-plugin-transform-imports is that it can be used to optimize the imports of other packages as well like Material UI, react-bootstrap etc.

References

How I smashed a bug on the biggest developer community

payapula — Sat, 14 Aug 2021 08:04:11 +0000

In this post I will share my experience on smashing a bug on the dev.to codebase.

Open Source Background

I have about 5 years of web development experience but kinda new to open source community.

I started with .NET web applications, then learnt Javascript & react. I fell in love with react and started exploring open source community and all the good tools people are contributing.

I have to thank Epic React course by Kent which ignited the spark to everything!

I started following NextJs, Chakra UI and developed my personal website to share what I have been working on. Then I was introduced to dev.to by people's blog posts and cross posted some of my posts from the website.

I received a good amount of attraction and followers in this community which keeps motivating to write more.

Also, I am very happy to share that one of my blog post was shared by the DEV Community twitter account! 🤯

DEV Community 👩‍💻👨‍💻

@thepracticaldev

Understanding the core concepts behind React Hooks will increase your confidence when it's time to use them in your own components.

{ author: @bharathispeaks } #DEVCommunity
dev.to/payapula/react…

10:02 AM - 05 Jul 2021

About This Bug

Storybook for `crayons-tabs` redirects off page #13601

Link2Twenty posted on Apr 30, 2021

Describe the bug

Currently the story for tabs doesn't really show what the tabs do. You can see the default state but can't click on a tab.

To Reproduce

Go to storybook
Click on a tab
You are redirected off the page

Expected behavior

Clicking a tab should update which tab is marked as current but should not navigate away.

Screenshots

N/A

Desktop (please complete the following information):

N/A

Smartphone (please complete the following information):

N/A

Additional context

The code is located here /app/javascript/crayons/navigation/NavigationTabs/stories/navigationTab.html.stories.jsx

I'd probably update the href to # and add some JS to handle the active state.

View on GitHub

It was a bug related to Tab components, happening in the storybook. When you click on a different tab header, the webpage was redirecting the user to the home page ('/') rather than to the selected tab.

How I Smashed It

Fixes #13601 - Storybook redirects off page #14491

payapula posted on Aug 12, 2021

What type of PR is this? (check all applicable)

[ ] Refactor
[ ] Feature
[x] Bug Fix
[ ] Optimization
[ ] Documentation Update

Description

#13601 Fixed the anchor tags with hash routes to prevent navigating to different page.
Since the stories are inside iFrame, I couldn't keep it in the same story navigatable view, instead it will open the story on fullscreen and the corresponding selected tab is highlighed.
Took reference from implemented Tab component for className toggles - Tabs.tsx
Used state to highlight the current tab.
Used location.hash to set the initial state.

Related Tickets & Documents

Closes #13601

QA Instructions, Screenshots, Recordings

The fix is shown in the GIF below

UI accessibility concerns?

There are no UI changes.

Added/updated tests?

[ ] Yes
[x] No, and this is why: This is a bugfix in storybook story
[ ] I need help with writing tests

[Forem core team only] How will this change be communicated?

Will this PR introduce a change that impacts Forem members or creators, the development process, or any of our internal teams? If so, please note how you will share this change with the people who need to know about it.

[ ] I've updated the Developer Docs and/or Admin Guide, or Storybook (for Crayons components)
[ ] I've updated the README or added inline documentation
[ ] I've added an entry to CHANGELOG.md
[ ] I will share this change in a Changelog or in a forem.dev post
[ ] I will share this change internally with the appropriate teams
[ ] I'm not sure how best to communicate this change and need help
[ ] This change does not need to be communicated, and this is why not: please replace this line with details on why this change doesn't need to be shared

What gif best describes this PR or how it makes you feel?

View on GitHub

Reflection

I felt happy contributing something that 'I can' to open source.

The bug is really a simple thing to smash, but the learning from it is such a good experience. I now have confidence to clone an open source repo, make it run on my machine, able to reproduce the bug and fix it, raise a PR & follow up with reviewers.

I understood how storybooks are being used in big applications, what are some of good coding practices and standards, and learnt more on accessibility.

The Forem team has such a wonderful get started guide for people like me to start contributing.

Suggestions for DEV Community Bug Smash

I now have few suggestions to improve forem codebase. Soon, I am going to raise issues with contributing PRs to discuss and fix them. Together we can build a rock solid community! 😀

❤️ Thanks to all the DEV Community members ❤️

Simple Introduction to Chakra UI

payapula — Sun, 25 Jul 2021 07:37:46 +0000

A lot of things need to be taken into consideration while designing any software application in general. To build a website with the component-based development approach, we would tend to approach a design as individual components.

For example, consider a super simple website like a blog. It would typically have a header, post cover, post content, a footer, and so on.

When we are presented with a design of a website, we would start building up the small individual parts of it, which we refer to as components and then fuse those components together to complete the design for a page.

Suppose, if we want to build a button then it is super simple like

  <button onclick="alert('hello world');">Hello</button>

This is a simple HTML tag, an element, and also a component. There can be a lot of components we will want to build for a real client application. Some of the examples are modals, drawers, links, tabs, inputs etc.

Things to consider 🤷🏾‍♂️

When building these components we should be careful that we are following same design architecture throughout our application. All the buttons in our application must look and feel the same.

Next thing to be taken for consideration while developing web applications is Web Accessibility. If we are building a dropdown/select component, it must be navigatable via keyboard, should have proper color contrast, accessible by screen readers etc.

There could be many other cases that we may not even aware of while building some complex components like tabs, overlays, modals.

To help us solve these problems and to easily get started with development, there are a lot of UI Component Libraries out there. They have a lot of battle tested components, which would help the developers like us to build our application quickly without sacrificing on accessibility, design architecture, meaningful navigation and so on.

One of such component Library is Chakra UI.

Chakra UI is a simple, modular and accessible component library that gives you the building blocks you need to build your React applications.

Think of these building blocks like set of lego blocks. We can start picking the right ones we need and compose them together to make our dream project!

A Re-Introduction to CSS in React ⚛️

Before we see about Chakra UI, let's revisit on the ways that we can style our React components with css.

External styles 💄

In this approach, we would write our component code in a .jsx or .tsx files and we would create another file with css and reference them in our component file.

components
  - mycomponent.jsx
  - mycomponent.css

The challenge with this approach is that the css we are writing is not scoped to the component, rather it would be applied globally.

When we are selecting the elements with classname or IDs and writing specific styles, we should be careful to not repeat the same names. If we are not careful enough then wrong styles would be applied to the element with same selector name on a different page.

This is because our entire css files are bundled together and server over the wire.

Another big headache is when we are removing some components from our application, it is so very easy to forget about the styles that we wrote for that component. Since the styles are not scoped to the component, we have no way to find out the dead css in our application.

CSS In JS 🌹

As the name suggests, in this approach, we would be writing CSS code in Javascript!

This has a lot of benefits, like

Easy Maintenance
Fast Performance
Dynamic Styling

When we scope the css to a particular component, we no longer have to worry about our styles messing up other components. When we remove a component from the application, the css goes away with that! The major benefit of it is sending just the CSS that we need for the page over the wire.

There are a lot of libraries to help us with the css-in-js approach. The famous ones are Styled Components and Emotion.

A simple example of CSS-In-JS with emotion

You can see the difference in the casing of the css properties, backgroundColor instead of background-color and pseudo selectors as well. We are passing styles as a object to a custom prop css which is inferred by emotion and applies those styles inline to that div.

If you want to have a deep dive on this concept, please read thorough the documentation from emotion

We can build our react application with emotion or styled components, but the Chakra UI library takes this approach a one level higher and simpler.

Getting Started with Chakra UI 🎉

The above example with emotion's css prop can be achieved in Chakra UI with the below piece of code.

import { Box } from "@chakra-ui/react";

return (
    <Box
      backgroundColor="hotpink"
      _hover={{
        color: "lightgreen"
      }}
    >
      This has a hotpink background.
    </Box>
);

Here we are passing in the styles directly to the component <Box/> as props. The Box component renders a div by default.

Chakra UI uses emotion under the hood, so you can also style your components in pure emotion way, but you won't be needing this for the most part.

This is chakra component styled with emotion.

return (
    <Box
      css={{
        backgroundColor: "hotpink",
        "&:hover": {
          color: "lightgreen"
        }
      }}
    >
      This has a hotpink background.
    </Box>
);

Both renders the same result.

Let's see another example, where we want to get username and password in a form with a submit button.

In React with plain elements,

Same element styles in Chakra would be

Note: Please ignore the semantics here, as this is just to demonstrate comparison of styles

If the images aren't clear, take a look at the Sandboxes for Plain React and
with Chakra UI components mentioned above.

There are a lot of components we have in chakra and even specific ones like Grid and Flex to handle layouts exclusively like the one seen above.

The awesome part of using Chakra components is the intellisense for the styles are always available for you so that you need not worry about the casing of styles.

The point here is that, Chakra UI is well documented, and you can easily peek into any of the components from the chakra ui repo to learn more about them, and to customize according to your requirements.

In the above form example with chakra, we have seen a component <chakra.form/> which simply renders HTML <form> but the beauty is, it can accept chakra's style props. We can convert any custom component to receive chakra props with the chakra function.

Similar to styled function from emotion.

import styled from '@emotion/styled'

const Button = styled.button`
  color: turquoise;
`
render(<Button>This my button component.</Button>)

Accessibility ❤️

Chakra components are built with accessibility in mind 🚀. For an example, if you are using modal from chakra, these are the keyboard and focus management you get out of the box which complies with accessible standards:

When the modal opens, focus is trapped within it.
When the modal opens, focus is automatically set to the first enabled element.
When the modal closes, focus returns to the element that was focused before the modal activated.
Clicking on the overlay closes the Modal.
Pressing Esc closes the Modal.
Scrolling is blocked on the elements behind the modal.
The modal is rendered in a portal attached to the end of document.body to break it out of the source order and make it easy to add aria-hidden to its siblings.

There is special component <VisuallyHidden/> which is not visible to the normal user but would be accessible by screen readers. This is useful for providing additional details to a icon button or image which cannot be perceived by visually
challenged users. Though this can be achieved with 10 lines of css, kudos to chakra team for thinking about it and providing it as a component 💯

Dark Mode 🌗

All the chakra UI components are dark mode compatible, the colors & default styles are easily overridable.

With the excellent community support and documentation, you can build out awesome components with just minimal amount of time.

And to finish off the introduction,

My website is built with Chakra UI components and I feel very happy about it 🥳

Further Information

React Hooks Dependencies and Stale Closures

payapula — Sat, 10 Jul 2021 13:10:19 +0000

After we got the confidence on the flow of hooks in React, it's important to understand about it's dependencies as well.

In this post we will dive a bit deeper into the dependency array of hooks.

As always, let's start with a Javascript example. Before looking at the output, try to guess what would be logged.

function App(count) {
  console.log('Counter initialized with ' + count);
  return function print() {
    console.log(++count);
  };
}

let print = App(1);
print();
print();
print();

print = App(5);
print();
print();

The above function is a simple example of closure in JavaScript. The console output is as below.

Counter initialized with 1 
2
3
4
Counter initialized with 5 
6
7

If you can get it, then great! I will go ahead and explain what is happening.

The App function returns another function called print this makes our App, a higher order function.

Any function that returns another function or that takes a function as argument is called as Higher order function.

function App(count) {
  console.log('Counter initialized with ' + count);
  return function print() {
    console.log(++count);
  };
}

The retuned function print closes over the variable count which is from its outer scope. This closing is referred to as closure.

Please don't get confused with the name of the functions. Names need not necessarily be identical, as for an example

function App(count) {
  console.log('Counter initialized with ' + count);
  return function increment() {
    console.log(++count);
  };
}

let someRandomName = App(1);
someRandomName(); //logs 2

Here App is returning a function increment and we are assigning it to the variable someRandomName

To define a "Closure",

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. ~ MDN

Ah? that doesn't look like simple definition right ?

Alright, MDN is not much helpful here let us see what W3Schools says

A closure is a function having access to the parent scope, even after the parent function has closed. ~ W3Schools

When we call the App function, we get the print function in return.

let print = App(1);

The App function gets count as 1 and returns print which simply increases the count and logs it. So each time when print is called, the count is incremented and printed.

If we are writing logic that uses closures and not careful enough, then we may fall into a pitfall called....

Stale Closures

To understand what is stale closures, let us take our same example and modify it further.

Take a look at this code and guess what would be getting logged into the console.

function App() {

  let count = 0;

  function increment() {
    count = count + 1;
  }

  let message = `Count is ${count}`;

  function log() {
    console.log(message);
  }

  return [increment, log];
}

let [increment, log] = App();
increment();
increment();
increment();
log();

To break it down,

There are two variables count and message in our App.
We are returning two functions increment and log.
As per the name, increment increases our count and log simply logs the message.

Try to guess the output. Let me give you some space to think.
.
.
.
.
.
.
.
.
Warning! 🚨 Spoilers 🚨 ahead
.
.
.
.
.
.
.
.

The output is

Count is 0

Oh, did we fail to increment the count?

Let's find out by placing console log inside our increment function

function App() {

  let count = 0;

  function increment() {
    count = count + 1;
    console.log(count);
  }

  let message = `Count is ${count}`;

  function log() {
    console.log(message);
  }

  return [increment, log];
}

let [increment, log] = App();
increment();
increment();
increment();
log();

And this time, the output will be

1
2
3
Count is 0

Yes, we are incrementing the count that is present in the lexical scope of increment. However, the problem is with the message and log.

Our log function captured the message variable and kept it. So, when we increment the count, the message is not updated and our log returns the message "Count is 0".

To fix this stale closure, we can move the message inside of log

function App() {

  let count = 0;

  function increment() {
    count = count + 1;
    console.log(count);
  }

  function log() {
    let message = `Count is ${count}`;
    console.log(message);
  }

  return [increment, log];
}

let [increment, log] = App();
increment();
increment();
increment();
log();

And executing would produce the result,

1
2
3
Count is 3

As per the name, stale closure is when we fail to capture updated value from the outer scope, and getting the staled value.

Hmm.. So, what does this stale closure has to do in React?

Hooks are nothing but Closures!

Let us bring the same JS example we saw above, into the react world,

function App() {
  const [count, setCount] = React.useState(0);

  let message = `Count is ${count}`;

  React.useEffect(() => {
    if (count === 3) {
      console.log(message);
    }
  }, []);

  return (
    <div className="App">
      <h1>{count}</h1>
      <button
        onClick={() => {
          setCount((c) => c + 1);
        }}
      >
        Increment
      </button>
    </div>
  );
}

After hitting Increment button three times, we should have a log that says "Count is 3".

Sadly we don't event get anything logged !!!

This is however not exact replica of our example from our JS world, the key difference is in our React world, message does get updated, but our useEffect just failed to capture the updated message.

To fix this stale closure problem, we need to specify both count and message as our dependency array.

function App() {
  const [count, setCount] = React.useState(0);

  let message = `Count is ${count}`;

  React.useEffect(() => {
    if (count === 3) {
      console.log(message);
    }
  }, [count, message]);

  return (
    <div className="App">
      <h1>{count}</h1>
      <button
        onClick={() => {
          setCount((c) => c + 1);
        }}
      >
        Increment
      </button>
    </div>
  );
}

Note - This is just a contrived example, You may choose to ignore either of those dependencies as both are related. If count is updated, message does get updated, so specifying just either of those is fine to get the expected output.

Things are simple with our example, The logic that we wrote inside the hook is not really a side effect, but it will get more and more complicated if we start to write hooks for data fetching logic and other real side effects

The one thing that, always we need to make sure is,

All of our dependencies for hooks must be specified in the dependency array and, we should not lie to React about dependencies

As I said, things get really complicated with closures in real-world applications and it is so very easy to miss a dependency in our hooks.

From my experience, if we failed to specify a dependency and if not caught during the testing, later it would eventually cause a bug and in order to fix it we may need to re-write the entire logic from scratch !!

This is a big 🚫 NO 🚫 and MUST BE AVOIDED at all cost. But how?

ESLint Plugin React Hooks

In order to make our life simpler, the react team wrote an ESLint Plugin called eslint-plugin-react-hooks to capture all possible errors with the usage of hooks.

So when you are all set up with this eslint plugin react hooks When you miss a dependency, it would warn you about the possible consequence.

If you are using latest create-react-app then this comes out of the box (react-scripts >= 3.0)

As seen below, when we violate the rules of hooks we will get a nice warning suggesting that we are probably doing something wrong.

The above image shows the error from ESLint that reads, React Hook React.useEffect has missing dependencies: 'count' and 'message'. Either include them or remove the dependency array.

It even fixes the dependency problem with just a single click!

Keep in mind that a stale closure problem does not only affect useEffect, we would run into the same problem with other hooks as well like useMemo and useCallback.

The Eslint plugin works with all the React hooks, can also be configured to run on custom hooks. Apart from just alerting with dependency issues, it would also check for all the rules of hooks, So, make good use of it!

Again to enforce,

🚫 Don't Lie to React about Dependencies and 🚫 Don't disable this ESLint rule 🤷🏾‍♂️

Big Thanks to:

React useEffect Hook Flow

payapula — Sun, 04 Jul 2021 07:19:27 +0000

It is important to understand the core concept of Hooks in React Components. This will increase our confidence with usage of hooks and help us understand what is actually happening inside our React components.

This post is to increase your understanding of flow of hooks in a react component with exclusive focus on the most confusing useEffect hook.

As always, let's start with Just Javascript

Take a look at the function below, which returns a string

function App(){
  return 'Hello World';
}

const text = App();
console.log(text); // logs 'Hello World'

We are storing the value returned from App function in variable text and displaying it in the console. We know that Javascript is single threaded and can execute only one line at a time. The flow of execution is top-to-bottom.

When we execute the code, this is what would happen

The Javascript engine first sees a function declaration from line 1 to 3
Then goes to line number 5 where it sees a function being called.
Then JS engine calls that function and assigns the value returned from that function into the text variable.
In the next line the text is displayed in the console.

Now that we understand the flow of Javascript in general, let's explore the useEffect() hook in a react component and explore when it is called and in what order.

React useEffect

Let's explore useEffect in React on three Lifecycle phases of react component.

Mount
Update
Unmount

useEffect on Mount

Take a look at the react component below

function App(){
  React.useEffect(() => {
    console.log('useEffect Ran!')
  }, []);

  return(
    <div>Hello, World!</div>
  )
}

When you scan through this code and find the useEffect with empty [] dependencies, you would have guessed that this hook runs only on mount (exactly like componentDidMount). Yes, you are right, it runs just on the mount. so you would get this in console

useEffect Ran!

Lets see an example with a dependency in useEffect,

function App() {
  const [count, setCount] = React.useState(0);

  React.useEffect(() => {
    console.log("Count Changed");
  }, [count]);

  return (
    <button
      onClick={() => {
        setCount((c) => c + 1);
      }}
    >
      {count}
    </button>
  );
}

This is the classic counter example, when we scan the react component and find the useEffect with [count] dependency we would think this would run when the count changes.

So, on the first render the count is 0 and not changed, when you click the button, the count would change, thus calling the useEffect hook right? lets check it out!

This is what would be logged on the first mount of the component.

Count Changed

Whaaaat? We didn't even click the button but the useEffect ran! Why?

Hooks are side-effects, and would be used mostly for performing any side-effects in the component, and the common side effect would be data fetching.

When compared to class Lifecycle methods, mentioning any dependency in a hook would make that hook similar to componentDidUpdate. If you have componentDidUpdate it would still be called on the mount phase!

This is how the hooks are designed to work. No matter how many dependencies you specify and how many hooks you create, every hook would be called on the mount phase of the component.

If you are curious to know why the hooks are designed in this way, take a look at Fun with React Hooks in which Ryan Florence live codes useEffect hook and explains why hooks should only be called in the top level of react component

After the mount phase is completed, our useEffect in the above counter example would be called whenever the count changes.

React.useEffect(() => {
  console.log("Count Changed");
}, [count]);

So, the takeaway from this section is

Every hook in a component would be called on the mount phase (with or without the dependencies specified).

useEffect on Unmount

Now let's look at another example below with the Unmount behaviour.

function Child() {
  React.useEffect(() => {
    console.log("Child useEffect Ran!");

    return () => {
      console.log("cleanUp of Child useEffect Ran!");
    };
  }, []);

  return <div>Hello, From Child!</div>;
}

export default function App() {
  const [showChild, setShowChild] = React.useState(false);

  React.useEffect(() => {
    console.log("useEffect Ran!");

    return () => {
      console.log("cleanUp of useEffect Ran!");
    };
  }, []);

  return (
    <div>
      <div>Hello, World!</div>
      {showChild ? <Child /> : null}
      <button
        onClick={() => {
          setShowChild((b) => !b);
        }}
      >
        {showChild ? "Hide" : "Show"} Child
      </button>
    </div>
  );
}

Our Parent App component renders a Child component which has useEffect with a cleanup function. This cleanup would be executed when the child component unmounts. So, When you render the component and toggle on the Hide/Show child button, You would get the corresponding logs as expected.

If you have 3 useEffects in same component and all does return a cleanup function, then, when the component is unmounted, all the cleanup functions would be called.

Lets see that in action below

function Child() {
  React.useEffect(() => {
    console.log("No Dependency!");

    return () => {
      console.log("cleanUp of No Dependency Ran!");
    };
  });

  React.useEffect(() => {
    console.log("Empty Dependency!");

    return () => {
      console.log("cleanUp of Empty Dependency Ran!");
    };
  }, []);

  return <div>Hello, From Child!</div>;
}

and the output is

The takeaway is

When the component is unmounted, cleanup function from all the useEffects would be executed.

In comparison to class components, where we only have one componentWillUnmount this is the only part that would be executed on the unmount phase of that component.

useEffect on Update

Here comes the interesting part, when you have specified a dependency and if the effect re-runs because of any change in the specified dependencies, it would execute the cleanup functions before executing the hook.

Let's see this behaviour with an example. Open up the console section, and play around with the buttons.

You can play around with the useEffect flow sandbox to see when each effect is getting called and its order.

On the first mount, we see both the useEffects of App running, and when you click on the Increment count button, before running the no deps hook, the cleanup function is executed.

▶️ App Render Start 
🛑 App Render End 
 App: useEffect no deps Cleanup 🧹
🌀 App: useEffect no deps

Similarly, when you click on Show Child button, before running the no deps hook of App, the cleanup is executed.

▶️ App Render Start 
🛑 App Render End 
       ▶️ Child Render Start 
       🛑 Child Render End 
 App: useEffect no deps Cleanup 🧹
       🌀 CHILD: useEffect empty [] 
       🌀 CHILD: useEffect no deps 
🌀 App: useEffect no deps

As seen above, from React v17, the cleanup of parent's effects are executed even before executing child component's useEffect(s).

Below GIF is the full rundown from the sandbox. We can see the cleanup functions are executed before the execution of hook on the update/re-render phase. I have highlighted the cleanups with bigger fonts to notice it easily.

The key takeaway is,

React, when re-running an useEffect, it executes the clean up function before executing the hook.

The full picture of the flow of hooks can be understood from this flow-chart by donavon

I hope this post helps you with understanding of flow of useEffect hook.

To Summarise

Every hook in a component would be called on the Mount phase (with or without the dependencies specified).

When the component is unmounted, cleanup function from all the useEffects are executed.

React, when rerunning an useEffect, it executes the clean up function before executing the hook.

Big thanks to:

React is Just Javascript

payapula — Sun, 27 Jun 2021 08:31:44 +0000

React components are not returning HTML & React is not magic! React is just plain Javascript Library for building powerful and interactive User Interfaces.

Let's start with a simple function in Javascript.

function App(){
  console.log('Hello World'); // logs 'Hello World'
}

App();

In the above code snippet, the function call on line no 5 calls the App function which outputs 'Hello World' in the console.

Let's React!

React is simply Javascript. A component defined in React is just a Javascript function.

Consider the React component below.

function App() {
  return (
    <h1>
      Hello World
    </h1>
  );
}

This component renders <h1> with a text 'Hello World' in the Webpage.

To reiterate,

A component defined in React is just a Javascript function

Just compare our plain JS code with this react code:

// JS
function App(){
  return 'Hello World';
}

// React
function App() {
  return (
    <h1>
      Hello World
    </h1>
  );
}

Now you would have these questions:

This is just a function declaration. Where it is being called?
If this is a Javascript function then, how HTML is being returned from the function? Is this even valid?
Also, Why is it called rendering?

Let's answer all these questions.

1. Where it is being called?

The function App() would actually be rendered by ReactDOM from react-dom package.

import ReactDOM from "react-dom";
import App from "./App";

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);

The Function App is called here with angle brackets like <App /> the returned HTML is rendered by ReactDOM into the rootElement.

Read More about ReactDOM.render() on the react docs

This rootElement can be any valid HTML DOM. Usually, we prefer to go with an empty <div> with the id root.

<div id="root"></div>

You should be careful, this should be an empty element because when the rendering occurs, this div's children would be replaced with the tag h1 with text 'Hello World' inserted automatically by React (ReactDOM)

<div id="root">
  <h1 class="App">Hello World</h1>
</div>

2. How HTML is being returned from the function? Is this even valid?

To start off, the HTML like thing that is returned from our App function is called JSX.

function App() {
  return (
    <h1>
      Hello World
    </h1>
  );
}

Technically this JSX is just a transpiled Javascript function call (yes it sounds scary). This HTML like thing is converted to Javascript by a transpiler called babel and, Finally the App would be sent to JS engine like below code that is just pure javascript.

function App() {
  return (
    React.createElement("h1", null, "Hello World")
  );
}

And this is the reason to import React in the module even though we don't explicitly use it.

import React from 'react';

function App() {
  return (
    <h1>Hello World</h1>
  );
}

React.createElement is top level API provided by react
package to create the corresponding element in Virtual DOM.

createElement returns React elements, which are plain JS objects that describe the intended structure of the UI.

// This JSX syntax:
return  <h1>Hello World</h1>

// is converted to this call:
return  React.createElement("h1", null, "Hello World")

// and that becomes this element object:
{type: 'h1', props: null, children: ["Hello World"]}

"Babel compiles JSX down to React.createElement() calls." - React Docs

You can play around with Babel and its transpiled code on the live babel repl.
To get to know about JSX, head-over to JSX on react docs.

Also, it is now worth pointing out that with React worked with Babel to introduce new JSX transform which enables users to write JSX without even importing React.

Starting with React 17, babel now automatically imports 'react' when needed. After the new JSX transform, our App component would compile from this

// No import 'React' from 'react' needed 

function App() {
  return (
    <h1>Hello World</h1>
  );
}

to this

import { jsx as _jsx } from "react/jsx-runtime";

function App() {
  return (
    _jsx("h1", {
      children: "Hello World"
    });
  );
}

React core team is making these set of changes gradually to remove the need of forwardRef in the future.

And to the most important question,

3. Why is it called Rendering ?

In short, Rendering in Web refers to the appearance of something. On a broader picture, the terminology rendering on the web can mean a lot of things like painting, server-rendering, etc. For our understanding, Let's keep it short, Render refers to appearance of a element, or a set of elements (component) on a webpage.

From the React docs it is clear that React is

A JavaScript library for building user interfaces

React helps us build user interfaces, not only on the Web. It helps us render something on screens that can be presented to the user.

A revisit to the example of ReactDOM API:

ReactDOM.render(<App />, rootElement);

The ReactDOM renders our <App /> into the <div> that we specified.

High level overview of the the rendering process:

React would create a Virtual DOM in memory which is very similar to the real DOM and renders our <h1> tag in the Virtual DOM, this virtual DOM would be synced with real DOM and during this process <h1> tag is added to real DOM. This process is called Reconciliation

The costliest operation on Web is DOM painting and manipulation.

If you are wondering this is too much boilerplate, why can't we just simply write HTML files and include Javascript and CSS to make it more presentable?

Yes! You are right, We can easily build a website with plain HTML, JS, and CSS and still make it cool. No one can deny it.

Where our React shines is, it will drastically simplify how we render and re-render our elements by providing set of Declarative APIs

Declarative : You just tell what you need and don't need on DOM and React would take care of that for you!

With the APIs provided by react, we can create Web Applications which are highly ⚡️ interactive, 🔥 performant and 🚀 responsive

If you want some examples, all these following websites are built with 🚀 React

Also, keep in mind that,

For the end-users, it is all just HTML, CSS, and JavaScript!

Thanks go to: