DEV Community: Som Shekhar Mukherjee

Overflow Wrap in a Flex container

Som Shekhar Mukherjee — Fri, 07 Jan 2022 15:58:36 +0000

In this blog, we'll look at a very specific thing i.e. the use of overflow-wrap property inside a flex container. overflow-wrap is a very handy CSS property and I've used it in almost all of the projects that I've worked in.

In a nutshell overflow-wrap allows us wrap some overflowing content in places where it would not wrap by default. But let's explore this with the help of an example.

Getting Started

From the above example our focus would only be in the following snippet, everything else is just for styling.



<div class="card-body">
  <p class="card-body-content">
    The longest word in any of the major English language
    dictionaries is
    <span class="highlight">
      pneumonoultramicroscopicsilicovolcanoconiosis
    </span>
    , a word that refers to a lung disease contracted from
    the inhalation of very fine silica particles,
    specifically from a volcano; medically, it is the same
    as silicosis.
  </p>
</div>

So, by default if the text inside a container cannot fit the container (i.e. it overflows), then the text starts wrapping by introducing line breaks at normal word break points (like spaces).

And that is exactly what's happening currently, the text (card-body-content) inside the container (.card-body) overflows it and hence line breaks are introduced. But the word "pneumonoultramicroscopicsilicovolcanoconiosis" still overflows the container because there are no valid break points to wrap it.

Before we start using overflow-wrap let's try to make the container (.card-body) display: flex

Crap! Things get even worse now, but why? What's so different about flex?



<div class="card-body flex">
  <p class="card-body-content">
    Same content
  </p>
</div>

Flex relies on min-content and max-content intrinsic sizes to structure the layout. So, by default flex tries to fit in all the flex items in a single row wherein each item gets their max-content intrinsic size, but if doing so overflows the container then it starts shrinking the items (this behavior can be altered using the flex-shrink property on the flex items) and the items are shrank until they reach their min-content intrinsic size, after which the items start overflowing the container.

Now coming back to the example, the flex container is initially trying to fit its only item in a single row wherein the item gets a width equal to its max-content intrinsic size (and the max-content size is when the entire item is spread in a single line without any wrapping), but clearly that would overflow the container - so flex starts wrapping the item - but remember it would only wrap the item until it reaches its min-content intrinsic size (which is equal to the longest word in the item).

So, the width of the flex container here is equal to the width of the word "pneumonoultramicroscopicsilicovolcanoconiosis" and the line breaks that happen is based on this width (look at the image below).

Now that we have an understanding of how flex works, let's use the overflow-wrap property in our code and look at the following three scenarios:

overflow-wrap: break-word in non flex container
overflow-wrap: break-word in a flex container
overflow-wrap: anywhere in a flex container

`overflow-wrap: break-word` in non flex container



<div class="card-body">
  <p class="card-body-content wrap-break-word">
    Same content
  </p>
</div>

break-word
The same as the anywhere value, with normally unbreakable words allowed to be broken at arbitrary points if there are no otherwise acceptable break points in the line, but soft wrap opportunities introduced by the word break are NOT considered when calculating min-content intrinsic sizes.

So, from the definition above (except maybe the last sentence which we'll discuss next), it's quite clear that because our content is allowed to wrap at any arbitrary point there's no overflow.

`overflow-wrap: break-word` in a flex container



<div class="card-body flex">
  <p class="card-body-content wrap-break-word">
    Same content
  </p>
</div>

When we make the container a flexbox, overflow-wrap: break-word doesn't seem to have any effect. Let's look at the definition of overflow-wrap: break-word again, specifically the last sentence.

break-word
The same as the anywhere value, with normally unbreakable words allowed to be broken at arbitrary points if there are no otherwise acceptable break points in the line, but soft wrap opportunities introduced by the word break are NOT considered when calculating min-content intrinsic sizes.**

This means break-word is not shrinking the min-content intrinsic size of the flex item because of which the flex-item is still overflowing.

`overflow-wrap: anywhere` in a flex container



<div class="card-body flex">
  <p class="card-body-content wrap-anywhere">
    Same content
  </p>
</div>

anywhere
To prevent overflow, an otherwise unbreakable string of characters — like a long word or URL — may be broken at any point if there are no otherwise-acceptable break points in the line. No hyphenation character is inserted at the break point. Soft wrap opportunities introduced by the word break are considered when calculating min-content intrinsic sizes.

When we use anywhere, it actually shrinks the min-content intrinsic of the flex item because of which the flex item is allowed to wrap and there's no overflow.

That's it for this blog! I understand that the example might be a little contrived and it might not click instantly, but I would suggest you go through it once again and play with the code, it will eventually start making sense. Also, put your thoughts in the comments!

Peace ✌

Have you used `flushSync` in React?

Som Shekhar Mukherjee — Thu, 23 Dec 2021 08:21:28 +0000

In this post we'll discuss about the flushSync utility provided by react-dom.

Let's try and understand what flushSync is and how it can useful through an example.

As always, it's a simple todo example but the point to note here is that the todo container has fixed height and is scrollable.

So, there's our App component that has a todos state and returns a list of todos along with a form.

export default function App() {
  const [todos, setTodos] = useState(mockTodos);

  const onAdd = (newTask) => {
    setTodos([...todos, { id: uuid(), task: newTask }]);
  };

  return (
    <section className="app">
      <h1>Todos</h1>
      <ul style={{ height: 200, overflowY: "auto" }}>
        {todos.map((todo) => (
          <li key={todo.id}>{todo.task}</li>
        ))}
      </ul>
      <AddTodo onAdd={onAdd} />
    </section>
  );
}

The AddTodo component is also fairly simple, it just manages the input state and once the form is submitted it calls the onAdd prop with the new todo.

const AddTodo = ({ onAdd }) => {
  const [taskInput, setTaskInput] = useState("");

  const handleSubmit = (e) => {
    e.preventDefault();

    if (!taskInput.trim()) return;
    setTaskInput("");
    onAdd(taskInput.trim());
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        placeholder="Your Task"
        value={taskInput}
        onChange={(e) => setTaskInput(e.target.value)}
      />
      <button>Add Task</button>
    </form>
  );
};

Now that we've an understanding of how our code works, suppose we want to add a functionality where every time a new todo is added, the container is scrolled to its bottom so that the newly added todo is visible to the user.

Think for while and figure out how you would go about implementing this functionality.

Using `useEffect` hook

You might be thinking of using the effect hook. So, every time the todos change just scroll the container to the bottom.

useEffect(() => {
  listRef.current.scrollTop = listRef.current.scrollHeight;
  // listRef is simply a ref attached to the ul
}, [todos]);

useEffect(() => {
  const lastTodo = listRef.current.lastElementChild;
  lastTodo.scrollIntoView();
}, [todos]);

Both of the above scrolling logics work fine (you might even want to use the useLayoutEffect hook in this situation in case you observe any jitters in scrolling).

But, I would not want to put this in either of these hooks, let me explain why.

The DOM manipulation (scrolling in this case) that we're trying to do here is a side effect (something that doesn't happen during rendering) and in React side effects usually happen inside event handlers, so in my opinion the best place to put this would be inside the onAdd handler.

Also, if you go by the docs useEffect should be your last resort, when you've exhausted all other options but haven't found the right event handler.

If you’ve exhausted all other options and can’t find the right event handler for your side effect, you can still attach it to your returned JSX with a useEffect call in your component. This tells React to execute it later, after rendering, when side effects are allowed. However, this approach should be your last resort. DOCS

Scrolling logic inside the handler

If you simply put the scrolling logic inside the handler (as shown below), you would notice that you're not exactly getting the desired results.

const onAdd = (newTask) => {
  setTodos([...todos, { id: uuid(), task: newTask }]);

  listRef.current.scrollTop = listRef.current.scrollHeight;
};

Because setTodos is not synchronous, what happens is you scroll first and then the todos actually get updated. So, what's in view is not the last todo but second to last.

So, to get it working as expected we would have to make sure that the logic for scrolling runs only after the todos state has been updated. And that's where flushSync comes handy.

Using `flushSync`

To use flushSync, we need to import it from react-dom: import { flushSync } from "react-dom";

And now we can wrap the setTodos call inside flushSync handler (as shown below).

const onAdd = (newTask) => {
  flushSync(() => {
    setTodos([...todos, { id: uuid(), task: newTask }]);
  });

  listRef.current.scrollTop = listRef.current.scrollHeight;
};

Now we have made sure that the state update happens synchronously and the logic for scrolling is executed only after the state has been updated.

That's it for this post, let me know situations where you would want to use flushSync.

Peace ✌

Some interesting points about React's useState hook

Som Shekhar Mukherjee — Thu, 19 Aug 2021 15:23:44 +0000

React's useState hook is used to manage the state of your application and is seen quite often.

Today in this article I would like share some facts about this hook which you might not know and which might increase your understanding of this hook works.

🚀 Setting state with a value similar to the current state will not cause a re-render.

Suppose you have a state foo that's currently set to "Foo" and you call setFoo again with "Foo", it will not cause a re-render. Check the example below:

const App = () => {
 const [foo, setFoo] = React.useState("Foo");

 React.useEffect(() => {
  console.log("Rendered");
 });

 return <button onClick={() => setFoo("Foo")}>Click</button>;
};

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

🚀 Updating state by passing in a callback

To set state we can either pass the new state value directly or we can pass in a function that takes as an argument the current state and returns the new state.

I prefer the second approach when my new state depends on the current state, for ex: setCount(currCount => currCount + 1) instead of setCount(count + 1).

const Counter = () => {
 const [count, setCount] = React.useState(0);

 const handleClick = () => {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
 };

 return (
  <>
   <p>Current Count: {count}</p>
   <button onClick={handleClick}>Add 3</button>
  </>
 );
};

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

In example above although we call setCount thrice but the count only gets updated by one and this because React batches al these three calls.

So, suppose count is currently 0 and you clicked the button. Now, what React sees is the following:

setCount(0 + 1)
setCount(0 + 1)
setCount(0 + 1)

React executes the first setCount call after which count becomes 1 and now the other two setCount calls are essentially updating the state to what it already is and we saw in the previous section that React is smart enough to simply ignore this.

To fix this we need to update the count state using the callback approach. So, we change the handleChange function to the following:

const handleClick = () => {
 setCount((currCount) => currCount + 1);
 setCount((currCount) => currCount + 1);
 setCount((currCount) => currCount + 1);
};

React will again batch all these calls, which you can confirm by adding the following in your code ("Rendered" should be logged only once).

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

So, when React encounters the first setCount call the currCount is 0, so it is updated to 0 + 1.

For the second setCount call the currCount becomes 1, so it is updated to 1 + 1 and similar for the third call.

🚀 Lazy Initializers

Suppose you've an input and whatever your users type in the input gets stored in the localStorage so that if the page reloads your users can continue from where they left.

The example below does exactly the same thing. So, to initialize the firstName state we call the getDataFromLS function which retrieves the data from localStorage and whatever this function returns becomes the initial value of the firstName state.

❗ NOTE: Don't be confused that we have passed a function to useState, we haven't. We've called it there itself, which means we've just passed the value that the function returns.

const getDataFromLS = (key) => {
 console.log(`Retrieving ${key} from Local Storage`);
 const value = window.localStorage.getItem(key) || "";
 return value;
};

const App = () => {
 const [firstName, setFirstName] = React.useState(
  getDataFromLS("firstName")
 );

 return (
  <>
   {firstName && <h1>Hello {firstName}</h1>}
   <form>
    <div>
     <label htmlFor="name">Your First Name: </label>
     <input
      id="name"
      value={firstName}
      onChange={({ target }) => {
       localStorage.setItem("firstName", target.value);
       setFirstName(target.value);
      }}
     />
    </div>
   </form>
  </>
 );
};

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

The initial value passed to useState is only used for the first time. On subsequent calls to useState React figures out that this is not the first time that this hook is being called and so it doesn't set the state variable to its initial value but instead sets it to its current value.

But, if you open the devtools and see the logs you would see that
for every re-render the getDataFromLS function is called (confirmed by the logs).

So, even if React doesn't care what getDataFromLS function returns on subsequent calls it still calls that function.

This is quite okay for this example but this could impact performance if you're doing some complex operations to get that initial value.

Let's add another input field but this time we will set the initial value differently.

const getDataFromLS = (key) => {
 console.log(`Retrieving ${key} from Local Storage`);
 const value = window.localStorage.getItem(key) || "";
 return value;
};

const App = () => {
 const [firstName, setFirstName] = React.useState(
  getDataFromLS("firstName")
 );

 const [lastName, setLastName] = React.useState(() =>
  getDataFromLS("lastName")
 );

 const handleChange = () => {};

 return (
  <>
   {(firstName || lastName) && (
    <h1>
     Hello {firstName} {lastName}
    </h1>
   )}
   <form>
    <div>
     <label htmlFor="name">Your First Name: </label>
     <input
      id="name"
      value={firstName}
      onChange={({ target }) => {
       localStorage.setItem("firstName", target.value);
       setFirstName(target.value);
      }}
     />
    </div>

    <div>
     <label htmlFor="name">Your Last Name: </label>
     <input
      id="name"
      value={lastName}
      onChange={({ target }) => {
       localStorage.setItem("lastName", target.value);
       setLastName(target.value);
      }}
     />
    </div>
   </form>
  </>
 );
};

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

So, this time instead of calling the function there itself, we passed a function to useState which React will call (not us) and whatever this function returns is set as the initial state. This is referred to as "Lazy Initialization".

❗ NOTE: React calls this function synchronously so this function cannot be asynchronous.

Now, you would only see the "Retrieving lastName from Local Storage" log once (unless the component gets unmounted and mounted again) but you would see the "Retrieving firstName from Local Storage" every time the component re-renders.

That's It! 🤘

Hope, you found this useful and learned something new. Let me know your thoughts in the comments.

Understanding the flow of React's useEffect hook

Som Shekhar Mukherjee — Thu, 19 Aug 2021 10:35:17 +0000

React's useEffect hook is used quite often in applications. It is used to perform side effects in your components like subscribing/unsubscribing to events, making API requests etc.

In this article we're going to discuss the flow in which things happen when working with this hook.

Order in which "Setup" and "Cleanup" functions are called

The useEffect hook accepts a function as the only argument which is often referred as the "Setup" function and you can optionally return a function from this "Setup" which is often referred as the "Cleanup" function.

In this example we'll see the flow in which these Setup and Cleanup functions are called.

const { useState, useEffect } = React;

const Counter = () => {
    const [count1, setCount1] = useState(0);
    const [count2, setCount2] = useState(0);

    useEffect(() => {
        console.log("useEffect no dependency ran");

        return () => console.log("useEffect no dependency cleanup ran");
    });

    useEffect(() => {
        console.log("useEffect empty dependency ran");

        return () => console.log("useEffect empty dependency cleanup ran");
    }, []);

    useEffect(() => {
        console.log("useEffect count1 as dependency ran");

        return () => console.log("useEffect count1 as dependency cleanup ran");
    }, [count1]);

    useEffect(() => {
        console.log("useEffect count2 as dependency ran");

        return () => console.log("useEffect count2 as dependency cleanup ran");
    }, [count2]);

    return (
        <>
            <button onClick={() => setCount1((c) => c + 1)}>{count1}</button>
            <button onClick={() => setCount2((c) => c + 1)}>{count2}</button>
        </>
    );
};

const App = () => {
    const [showCounter, setShowCounter] = useState(false);

    return (
        <main className="App">
            <label htmlFor="toggleCounter">Toggle Counter: </label>
            <input
                id="toggleCounter"
                type="checkbox"
                checked={showCounter}
                onChange={({ target }) => setShowCounter(target.checked)}
            />
            <div>{showCounter && <Counter />}</div>
        </main>
    );
};

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

Take a moment to understand the example above, it looks lengthy because it has a bunch of useEffect calls but its fairly simple otherwise.

Our focus is on the Counter component and all our logs are from this component.

So, initially there are no logs because the Counter component is not yet mounted (as showCounter state is set to false).

Let's click on the "Toggle Counter" checkbox

This updates the showCounter state and a re-render happens and we have our Counter mounted for the first time.

Logs
useEffect no dependency ran
useEffect empty dependency ran
useEffect count1 as dependency ran
useEffect count2 as dependency ran

💡 Observation: Notice all setups ran and they ran in the order they were called.

🚀 This is because all Setups run on mount irrespective of the dependency array and they run in the exact same order in which we called them. Also, no Cleanups run on mount.

(Clear the logs before moving to the next section)

Let's click on the first counter button

Logs
useEffect no dependency cleanup ran
useEffect count1 as dependency cleanup ran
useEffect no dependency ran
useEffect count1 as dependency ran

💡 Observation: Notice only two effects ran this time and both cleanup and setup ran for these two (and they still run in order they were called).

🚀 Its because on re-renders the Effect hook (both Cleanup and Setup) runs only if the dependencies change (count1 changed) or if the second argument is skipped completely.

💡 Observation: Notice Cleanups run before Setups for both "no dependency" Effect hook and "count1" Effect hook.

🚀 So, when both Cleanup and Setup has to run for a particular effect hook, the Cleanup will run before the Setup.

If you want to explore why useEffect runs after every render and not just on unmount, React docs does a really great job of explaining this.

(Clear the console before moving to the next section)

Let's now click on the "Toggle Counter" checkbox again

This updates the showCounter state and unmounts the Counter component.

Logs

useEffect no dependency cleanup ran
useEffect empty dependency cleanup ran
useEffect count1 as dependency cleanup ran
useEffect count2 as dependency cleanup ran

💡 Observation: Notice all cleanups ran and they ran in the order they were called.

🚀 This is because all Cleanups run on unmount irrespective of the dependency array and they run in order. Also, no Setups run on unmount.

🔥 CheatSheet

Phase	Setups	Cleaups	Condition
Mount	All	None	None
Re-render	Some	Some	Dependency Array
Unmount	None	All	None

Children's useEffect hooks run before Parent's

Consider the example below, it's to explain a small point that Children's useEffect hooks will always run before Parent's useEffect hook.

const { useEffect } = React;

const Child = () => {
    useEffect(() => {
        console.log("Child useEffect ran");
    });
    return <p>Child</p>;
};

const App = () => {
    useEffect(() => {
        console.log("App useEffect ran");
    });
    return <Child />;
};

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

Logs
Child useEffect ran
App useEffect ran

`useEffect` hooks are called Asynchronously

The example below demonstrates a really important point which is that useEffect hooks are called Asynchronously.

const { useEffect } = React;

const App = () => {
    console.log("Before useEffect");
    useEffect(() => {
        console.log("Inside useEffect");
    });
    console.log("After useEffect");
    return <h1>Hello World</h1>;
};

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

Logs
Before useEffect
After useEffect
Inside useEffect

💡 Observation: Notice the "Inside useEffect" log is printed after the "After useEffect" log.

🚀 And this is because React calls useEffect asynchronously after React has finished rendering.

In other words useEffect doesn't run the moment you call it, it runs after React has completed rendering.

I will mention this point again twice in the coming section because I feel this is really important to understand.

Making API calls inside the `useEffect` hook

Quite often we make async requests to external APIs inside the useEffect hook. So, in this section we would observe the flow of our code in such a scenario.

const UserInfo = ({ userId }) => {
  const [user, setUser] = React.useState(null);
  const [error, setError] = React.useState(null);

  console.log("%cBefore useEffect", "color: yellow");

  React.useEffect(() => {
    console.log("%cInside useEffect", "color: cyan");

    setError(null);

    (async function fetchUser() {
      if (!userId) return;

      try {
        const res = await fetch(
          `https://jsonplaceholder.typicode.com/users/${userId}`
        );
        const data = await res.json();

        if (!Object.entries(data).length) throw new Error("No data found");

        setUser(data);
      } catch (e) {
        setError("Something went wrong");
      }
    })();
  }, [userId]);

  console.log("%cAfter useEffect", "color: coral");

  if (error) return <p>{error}</p>;

  if (!user) return <p>Loading...</p>;

  if (user) return <pre>{JSON.stringify(user, null, 2)}</pre>;
};

const UserSearchForm = ({ setUserId }) => {
  const handleSubmit = (e) => {
    e.preventDefault();
    setUserId(e.target.elements.userId.value);
  };

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="userId">User Id:</label>
      <input type="text" id="userId" placeholder="Enter User Id" />
      <button type="submit">Search</button>
    </form>
  );
};

const App = () => {
  const [userId, setUserId] = React.useState("");
  return (
    <main>
      <h1>Find User Info</h1>
      <UserSearchForm setUserId={setUserId} />
      {userId && <UserInfo userId={userId} />}
    </main>
  );
};

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

Consider the above example, our focus is on the UserInfo component that makes async request to an external API.

Initially there are NO logs from the UserInfo component because it's not yet mounted (as the userId state is initially set to an empty string).

Let's search for a user with `userId` of `1`.

Logs:

Before useEffect
After useEffect
Inside useEffect
Before useEffect
After useEffect

So, when you hit the search button, setUserId is called which causes a re-render and now for the first time the UserInfo component is rendered.

The UserInfo function is called and from there we have our first log "Before useEffect".

💡 Observation: Notice that the second log that we have is not "Inside useEffect" but its "After useEffect"

🚀 This is because useEffect runs asynchronously after React has finished rendering.

So, after the "After useEffect" log, React renders <p>Loading...</p> and then React calls the useEffect function.

Inside useEffect we get the "Inside useEffect" log printed.

Then we have setError(null), before you proceed further just think for a moment will this cause a re-render?

The answer is NO and its because error is currently null and its being set to null, which means the error state has not changed, so a re-render is not required (React is Smart folks!).

So, we move past setError(null) and then fetchUser is called, and once the data is fetched from the API, we call setUser with that data (assuming there's no error) which causes a re-render and because of which we get our last two logs printed.

Before we proceed to the next section I want you add one more log to the UserInfo component as shown below:

console.log("%cAfter useEffect", "color: coral");

if (error) return <p>{error}</p>;
console.log("%cAfter error check", "color: crimson");

if (!user) return <p>Loading...</p>;

if (user) return <pre>{JSON.stringify(user, null, 2)}</pre>;

Let's now search for a user with `userId` of `a`.

I don't want you to observe any logs here because its same as before (except from the one we just added).

We did this because we wanted to set our error state to something other than null.

(Clear the console before moving to the next section)

Let's again search for a user with `userId` of `1`.

There are a lot more logs this time, let's knock them one by one.

Logs

Before useEffect
After useEffect
Inside useEffect
Before useEffect
After useEffect
After error check
Before useEffect
After useEffect
After error check

We already know why we have the first two logs, but notice that we didn't print the "After error check" log and this is because we still have the error state set to null, which again emphasises the same fact that useEffect is not called before React finishes rendering.

So, React first renders <p>{error}</p> and after that it calls the useEffect hook and we get the third log "Inside useEffect".

Now, this time when setError(null) is called, it will cause a re-render because error is not null currently.

So, because of the change in error state we get logs 4, 5 and 6. And this time since error is no more truthy, therefore we log "After error check".

And finally once the data is fetched from the API, we call setUser(data) which causes a re-render and we get the last three logs.

That's It! 🤘

Hope, you found this useful and learned something new. Let me know your thoughts in the comments.

Using ES6 Modules with Jest

Som Shekhar Mukherjee — Thu, 12 Aug 2021 15:03:42 +0000

In this post we're going to see two possible ways of enabling ES6 Modules with Jest that works with all operating systems.

So, following is the screenshot of the file structure, nothing complex just a simple node app with jest installed (npm i jest)

And following is the contents of index.js and index.test.js.

index.js

export default (a, b) => a + b;

index.test.js

import sum from "./index.js";

it("should sum", () => {
  expect(sum(1, 2)).toBe(3);
});

Now, let's update the test script and enable ES6 modules in package.json.

package.json

{
  "name": "jest-es6-modules",
  "type": "module",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "jest"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "jest": "^27.0.6"
  }
}

But if you run npm test you would notice Jest is complaining that it cannot recognize import, so let's fix this.

Method 1

All you need to do is set the experimental-vm-modules flag. Just modify the test script in package.json to the following:

package.json

"scripts": {
  "test": "node --experimental-vm-modules node_modules/jest/bin/jest.js"
}

Method 2

You can also install cross-env as a dev dependency and use that for setting NODE_OPTIONS.

npm i --save-dev cross-env

package.json

"scripts": {
  "test": "cross-env NODE_OPTIONS=--experimental-vm-modules jest"
}

Now, you can use ES6 modules with Jest. Hurray!

For React Beginners

Som Shekhar Mukherjee — Mon, 08 Mar 2021 04:43:13 +0000

If you're a React beginner and just getting started with the React. You must have tried looking through the documentation and specifically the "Intro to React - Tutorial".

If you haven't already I would suggest you to go through it because it is a really nice and quick way to get started with the library. https://reactjs.org/tutorial/tutorial.html

But there are a couple of questions that this tutorial leaves for you to solve as practice and again I would highly recommend you to solve these.
Once you have given it a try you can go through this github repo that I have created with detailed explanations (checkout out the README) to all these practice questions. Hope you find it useful. Have a good day!

Is [ ] truthy in JS ?

Som Shekhar Mukherjee — Sat, 30 Jan 2021 13:17:07 +0000

The code snippet below can be really confusing.

if ([]) {
  console.log([]==false)
}

If [](empty array) is truthy then why is []==false evaluating to true?
If [] is falsy then why is the code entering the if block? Let's answer both these one by one.

The following are the only falsy values in JavaScript:

false
"" (empty string)
0
NaN
null
undefined

So, [] is definitely not falsy

Why is the code entering the if block?

The code is entering the if block because JavaScript is trying to coerce [] to a Boolean which results in being true.

console.log(Boolean([])) // true

Why `[]==false` is true?

Equal (==)
If the two operands are not of the same type, JavaScript converts the operands then applies strict comparison. If either operand is a number or a boolean, the operands are converted to numbers if possible; else if either operand is a string, the other operand is converted to a string if possible. If both operands are objects, then JavaScript compares internal references which are equal when operands refer to the same object in memory.

So, one of the operands here is a Boolean, so JavaScript will try to convert both the operands into Numbers and do a strict comparison. Since both Number([]) and Number(false) give 0, the comparison will become true.

console.log([]==false)
// This is similar to:
console.log(Number([])===Number(false))

Thanks!!

"Switch" statements in GO

Som Shekhar Mukherjee — Thu, 07 Jan 2021 19:08:17 +0000

Switch statements are an important concept in programming and they are used for conditional execution. Switch statements in GO behave a little different as compared to other programming languages. So, in this blog we are going to understand switch statements in GO with the help of meaningful examples.

Getting Started

Let's look at the following example

package main
import "fmt"
func main() {
    fruit := "Orange"
    switch fruit {
    case "Apple":
        fmt.Printf("%v is a nice fruit\n", fruit)
    case "Mango":
        // We can have multiple lines of code inside case
        out := fmt.Sprintf("%v is a nice fruit", fruit)
        fmt.Println(out)
    case "Guava":
        // By default there's NO fall through
        fmt.Printf("%v is a nice fruit\n", fruit)
    case "Orange":
        fmt.Printf("%v is a nice fruit\n", fruit)
    default:
        fmt.Println("Unrecognized fruit")
    }
}

Can you guess the output of the above code snippet? If you've used switch statements in other programming languages you probably guessed the following

Mango is a nice fruit
Mango is a nice fruit
Mango is a nice fruit
Unrecognized fruit

But that's not the case with GO, here in switch statements we don't have fall through by default (fall through basically means executing all cases that come after the matching case). In GO only the statements within the matching case gets executed, so the output is simply Mango is a nice fruit.

NOTE: switch expression == case expression must be a valid comparison, so the code below would give an error.

package main
import "fmt"
func main() {
    num := "Two"
    switch num {
    case 2:
        fmt.Printf("Num is 2")
    default:
        fmt.Println("Num is not 2")
    }
}

Using `fallthrough`

What if we want to fall through, well for that we need to explicitly specify this by using the fallthrough keyword. So, the code below gives that output that we guessed earlier.

package main
import "fmt"
func main() {
    fruit := "Mango"
    switch fruit {
    case "Apple":
        fmt.Printf("%v is a nice fruit\n", fruit)
    case "Mango":
        out := fmt.Sprintf("%v is a nice fruit", fruit)
        fmt.Println(out)
        fallthrough
    case "Guava":
        fmt.Printf("%v is a nice fruit\n", fruit)
        fallthrough
    case "Orange":
        fmt.Printf("%v is a nice fruit\n", fruit)
        fallthrough
    default:
        fmt.Println("Unrecognized fruit")
    }
}

Note that we had to specify fallthrough multiple times to get the desired output, so fallthrough just executes the next case block (irrespective of whether that block is true or false) and not all the subsequent case blocks.
Also, as in other programming languages the default case is optional and is triggered when no other cases match (the default case can be placed anywhere not necessarily at the very bottom)

Multiple Case Expressions

We can also have multiple case expressions separated by commas. If any of the case expressions match the switch expression, then the statements associated with that particular case are executed.

package main
import "fmt"
func main() {
        fruit := "Onion";
    switch fruit {
    case "Apple", "Mango", "Guava":
        fmt.Println("Fruit")
    case "Potato", "Cabbage", "Onion":
        fmt.Println("Vegetable")
    default:
        fmt.Println("What is it?")
    }
}
// OUTPUT
// Vegetable

Till now I have only used literal values in switch and case expressions, but that's not the only possibility. Take a look at the following example

package main
import "fmt"
func main() {
    fruit := "Onion"
    switch fruit + "s" {
    case "Apple" + "s", "Mango" + "es":
        fmt.Println("Fruits")
    case "Cabbage" + "s", "Onion" + "s":
        fmt.Println("Vegetables")
    default:
        fmt.Println("What is it?")
    }
}
// OUTPUT
// Vegetables

Switch Initializer

We can also have a switch initializer as shown below:

package main
import "fmt"
func main() {
    switch fruit := "Onion"; fruit{
    case "Apple", "Mango":
        fmt.Println("Fruit")
    case "Cabbage", "Onion":
        fmt.Println("Vegetable")
    default:
        fmt.Println("What is it?")
    }
}

Now the variable fruit is only available within the switch block, not within the entire main function.

Expressionless Switch

If we don't specify an expression to switch then it defaults to the boolean value true and now the program looks for case expressions that evaluate to true and this is similar to an if-else-if-else chain.

package main
import "fmt"
func main() {
    for i := 1; i <= 30; i++ {
        switch {
        case i%15 == 0:
            fmt.Println(i, "Baz")
        case i%3 == 0:
            fmt.Println(i, "Foo")
        case i%5 == 0:
            fmt.Println(i, "Bar")
        default:
            // default is optional
            fmt.Println(i)
        }
    }
}

Type Switches

A type switch compares types rather than values. It is otherwise similar to an expression switch. Take a look at the following example.

package main
import "fmt"
func main() {
    var num interface{} = "Hello, World"
    switch num.(type) {
    case int:
        fmt.Printf("num is of type int")
    case bool:
        fmt.Printf("num is of type bool")
    case string:
        fmt.Printf("num is of type string")
    }
}
// OUTPUT
// num is of type string

So, I hope we now have a clear understanding of how switch statements work in GO.

Christmas Tree - Holiday Decorations

Som Shekhar Mukherjee — Sun, 20 Dec 2020 12:30:48 +0000

Cool CSS Hover Animation 🤩

Som Shekhar Mukherjee — Mon, 14 Dec 2020 17:04:40 +0000

Today we're going to create this cool quick animation using CSS.

So, without wasting any more time let's get started. Firstly, lets knock off some starter code. The following code just removes some default settings and centers the contents of the body.

* {
    box-sizing: border-box;
    margin: 0;
    padding: 0;
}

body {
    background: darkslateblue;
    height: 100vh;
    display: flex;
    justify-content: center;
    align-items: center;
}

Next, lets complete the markup. So, all we have is an image and a title both wrapped in a container. (Big thanks to Michal Mrozek for this wonderful image)

<div class="container">
    <img src="https://images.unsplash.com/photo-1557912407-eb2900cf49e8?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=1050&q=80" />
    <div class="title">Butterfly</div>
</div>

Next, we just style the container class. This is just to center the image and the title and place them columnwise. Also, we add cursor: pointer on hover.

.container {
    display: flex;
    flex-direction: column;
    align-items: center;
}

Next, we style the image to give it that small round shape. And specifically note these two styles that make it look good filter: grayscale(); transition: filter 0.4s ease-in-out

.container img {
    filter: grayscale();
    width: 200px;
    height: 200px;
    border-radius: 50%;
    border: 6px solid whitesmoke;
    box-shadow: 2px 2px 10px 2px rgba(0, 0, 0, 0.5);
    margin-bottom: 1rem;
    transition: filter 0.4s ease-in-out;
}

Now, when the container class is hovered we simply remove that filter from the image.

.container:hover img {
    filter: none;
}

Next we give some basic styles to the title class. (The font used is from Google Fonts)

.title {
    font-family: "Dancing Script", cursive;
    font-size: 3rem;
    color: whitesmoke;
    position: relative;
}

Next, we use a pseudo element to create the underline. We initially set the width to 0% and left to 50%.

.title::after {
    position: absolute;
    content: "";
    width: 0%;
    height: 4px;
    background-color: whitesmoke;
    left: 50%;
    bottom: -10px;
    transition: all 0.4s ease-in-out;
}

Now, when the container class is hovered we modify the width and left properties of the pseudo element.

.container:hover .title::after {
    width: 100%;
    left: 0;
}

Drum Rolls 🎉🎉 Its Done! Let me know your feedback.
You can view the full code here.

Few neat JS snippets

Som Shekhar Mukherjee — Mon, 09 Nov 2020 17:47:57 +0000

Creating a 2D Array initialized with zeroes

const nrows = 5;
const ncols = 5;
const arr = Array.from({ length: nrows }, () =>
  Array.from({ length: ncols }, () => 0)
);

Flattening a 2D array into a 1D array

const oneD = [].concat(...twoDArr);

Array.from() can be really handy at times

const primes = [2, 3, 5, 7, 11];
const sqPrimes = Array.from(primes, (x) => x * x);

DEV Community: Som Shekhar Mukherjee

Overflow Wrap in a Flex container

Getting Started

overflow-wrap: break-word in non flex container

overflow-wrap: break-word in a flex container

overflow-wrap: anywhere in a flex container

Have you used `flushSync` in React?

Using useEffect hook

Scrolling logic inside the handler

Using flushSync

Some interesting points about React's useState hook

🚀 Setting state with a value similar to the current state will not cause a re-render.

🚀 Updating state by passing in a callback

🚀 Lazy Initializers

Understanding the flow of React's useEffect hook

Order in which "Setup" and "Cleanup" functions are called

Let's click on the "Toggle Counter" checkbox

Let's click on the first counter button

Let's now click on the "Toggle Counter" checkbox again

Children's useEffect hooks run before Parent's

useEffect hooks are called Asynchronously

Making API calls inside the useEffect hook

Let's search for a user with userId of 1.

Let's now search for a user with userId of a.

Let's again search for a user with userId of 1.

Using ES6 Modules with Jest

index.js

index.test.js

package.json

Method 1

package.json

Method 2

package.json

For React Beginners

Is [ ] truthy in JS ?

Why is the code entering the if block?

Why []==false is true?

"Switch" statements in GO

Getting Started

Using fallthrough

Multiple Case Expressions

Switch Initializer

Expressionless Switch

Type Switches

Christmas Tree - Holiday Decorations

Cool CSS Hover Animation 🤩

Few neat JS snippets

`overflow-wrap: break-word` in non flex container

`overflow-wrap: break-word` in a flex container

`overflow-wrap: anywhere` in a flex container

Using `useEffect` hook

Using `flushSync`

`useEffect` hooks are called Asynchronously

Making API calls inside the `useEffect` hook

Let's search for a user with `userId` of `1`.

Let's now search for a user with `userId` of `a`.

Let's again search for a user with `userId` of `1`.

Why `[]==false` is true?

Using `fallthrough`