Tiltable cards are everywhere, let's recreate them from scratch in React!

# Introduction
![Meme](https://i.imgur.com/7pNeWYql.png)

These days it looks like tiltable cards are all the rage, and I wanted to see
how easy it would be to implement them from scratch in React.

I'm going to be using the bare minimum of external dependencies to implement this (namely just
`framer-motion` to interpolate animation values smoothly, but using 
alternatives such as `react-spring` should be pretty straightforward).

# Step 1: Designing the card
We're gonna lay down a very rough card design, just to get things started.

[break](#)

Let's start by creating a card component that will contain the content of the card.
Inside of it, there will be a single, centered paragraph of text:

```jsx
<div
  style={{
    width: "240px",
    height: "320px",
    backgroundColor: "#C2B8F0",
    borderRadius: "0.5rem",
    boxShadow:
      "0 0 0 1px rgba(0, 0, 0, 0.105), 0 9px 20px 0 rgba(0, 0, 0, 0.02), 0 1px 2px 0 rgba(0, 0, 0, 0.106)",
    position: "relative",
    display: "flex",
    alignItems: "center",
    justifyContent: "center"
  }}
> 
  <p>LIGMA</p>
</div>
```

We should end up with something like this:
[snip-1-1](#)

This sets the basics for our card. Now, let's add some tilt effects to it. 

[break](#)

# Step 2: Implementing the tilt effect

We'll start by adding some dedicated CSS properties to the card:
```
transformStyle: 'preserve-3d'
transformOrigin: 'center'
perspective: '320px'
```

Let's break down their meanings:
* `transform-style: preserve-3d`: Indicates that the children of the element should be positioned in their own 3D plane, or be flattened to their parent's.
[snip-1-5](#)

[break](#)

* `transform-origin: center`: Sets the fulcrum for the element's transformations.
[snip-1-6](#)

[break](#)


* `perspective: 320px`: Determines the distance between the z=0 plane and the viewer in order to give a 3D-positioned element some perspective. In this case I found the card's height in pixels to be the sweet spot.
[snip-1-7](#)

[break](#)

#### We're now ready to implement the tilt effect!
[break]('#')

In order to do that, we'll need to keep track of the mouse position on the card, plus the card's animation state:
* `rotations`: We'll use this to store the current tilt angle(s) of the card.
* `isAnimating`: We'll use this to keep track of the animation state of the card.

React's `useState` hook will be perfect for this:
```
const [rotations, setRotations] = useState({ x: 0, y: 0, z: 2 });
const [isAnimating, setAnimating] = useState(false);
```

Now we're gonna have to handle two separate interaction events:
* `onMouseMove`: When the mouse is moving on the card, we want to do some calculations to determine the tilt angle.
* `onMouseLeave`: When the mouse leaves the card, we want to reset the tilt angle to 0.

Let's look at their implementations:

> Some logic is getting implemented for now on, watch the comments! 👀  

### onMouseMove event handler
```jsx
// Put these anywhere you wish, I personally put them into a dedicated `utils` file.
export function round(num, fix = 2) {
  return parseFloat(num.toFixed(fix));
}

export function distance(x1, y1, x2, y2) {
  return Math.sqrt(Math.pow(x2 - x1, 2) + Math.pow(y2 - y1, 2));
}

const handleMouseMove = (event) => {
  setAnimating(true); // We're animating the card.

  // We're getting the bounding box of the card.
  const rect = event.currentTarget.getBoundingClientRect();

  // We're getting the mouse position relative to the card.
  const absolute = {
    x: event.clientX - rect.left,
    y: event.clientY - rect.top
  };

  // We're getting the mouse position relative to the center of the card,
  // in percentage, starting from x, y 0% 0% top-left, ending in 100% 100% bottom-right. 
  const percent = {
    x: round((100 / rect.width) * absolute.x),
    y: round((100 / rect.height) * absolute.y)
  };

  // We're getting the tilt angle of the card, calculated on the
  // percentage of distance from the center, going from
  // -50% to 0% to 50% left to right, top to bottom.
  const center = {
    x: percent.x - 50,
    y: percent.y - 50
  };

  // We can now set the tilt angle(s) of the card. Note that the
  // divisions here (/ 12, / 16, / 20) are used to stabilize the
  // rotations using smaller values. Play with them and experiment
  // you perfect fine-tuning!
  setRotations({
    x: round(((center.x > 50 ? 1 : -1) * center.x) / 12),
    y: round(center.y / 16),
    z: round(distance(percent.x, percent.y, 50, 50) / 20)
  });
};
```

Before we go any further, let's break down what's about to happen for the `onMouseLeave` event:
* We're gonna set the `isAnimating` state to `false`.
* We're gonna set a timeout to reset the tilt angle(s) to 0 after 100ms, to stop the card from abruptly stopping its animation.

We're gonna have to check for the `isAnimating` state in the `onMouseMove` event handler,
but having to do that inside of a `setTimeout` callback is not ideal. In order
to access the current `isAnimating` state in this case, we'll need to create a
**closure** around the object. 
The reference to the object will always be the same in the closure function but 
the actual value stored by the object will be changed each time the callback 
function runs.

[break]('#')
A solution to this issue is to use the `useRef` hook:
```
const isAnimatingReference = useRef(isAnimating);
```

We can now proceed to implement the `onMouseLeave` event handler:

### onMouseLeave event handler
```js
const stopAnimating = () => {
  setAnimating(false);

  setTimeout(() => {
    if (!isAnimatingReference.current) return;

    setRotations({ x: 0, y: 0, z: 2 });
  }, 100);
};
```


Now we have all the pieces we need to tilt the card. Let's bind our states and event handlers to the card component:

(if you haven't already, install the `framer-motion`, so we can use the `motion` component to smoothly transition between different values)

[break]('#')

```jsx
<motion.div
  // Mouse interactions events handlers.
  onMouseMove={animate}
  onMouseLeave={stopAnimating}
  animate={{
    // Rotation values used to tilt the card.
    rotateY: rotations.x,
    rotateX: rotations.y,
    transformPerspective: rotations.z * 100
  }}
  style={{
    width: '240px',
    height: '320px',
    backgroundColor: '#C2B8F0',
    borderRadius: '0.5rem',
    boxShadow:
      '0 0 0 1px rgba(0, 0, 0, 0.105), 0 9px 20px 0 rgba(0, 0, 0, 0.02), 0 1px 2px 0 rgba(0, 0, 0, 0.106)',
    display: 'flex',
    alignItems: 'center',
    justifyContent: 'center',
    transformStyle: 'preserve-3d',
    transformOrigin: 'center',
    perspective: '320px'
  }}>
  <p>LIGMA</p>
</motion.div>;
```

We should end up with something like this:
[snip-1-2](#)

Fantastic, the card tilts smoothly on mouse hover! But we're not done yet. 
As you can see, the card's tilt angle creates an optical illusion due to the lack of perceived depth, caused by the absence of shadows/highlights.
We can fix that by applying some CSS magic to the card's children to make them appear as if they're on the card's surface.

[break](#)

## Step 3: CSS magic dust
As we previously said, we're gonna add visual depth to the card by adding a 
translucent layer to it, but -trust me- this is really all that's left to do in
order to get the card to look like it's floating in thin air!

The card's structure is gonna be like this:
* Card 
  * Card transulcency layer
  * Card children

```jsx
<motion.div
  style={{
    // Place above the rest.
    zIndex: 2,

    // Use an overlay blending mode to make the effect more realistic.
    mixBlendMode: 'overlay',

    // Use absolute positioning.
    position: 'absolute',

    // Always keep in front of the card in the 3d plane.
    transform: 'translateZ(1px)',

    // Cover the whole card's area.
    width: '100%',
    height: '100%',

    // Same border radius as its parent.
    borderRadius: '0.5rem',

    // We already know about this ;).
    transformStyle: 'preserve-3d'
  }}
  animate={{
    // This is gonna draw a pseudo glare on the card. The `50% 50%`
    // means it's gonna stay centered, for now...
    background: `radial-gradient(
      farthest-corner circle at 50% 50%,
      rgba(255, 255, 255, 0.7) 10%,
      rgba(255, 255, 255, 0.5) 24%,
      rgba(0, 0, 0, 0.8) 82%
    )`
  }}
/>
```

We should end up with a static glare sitting on top of the card like the following:
[snip-1-3](#)

[break](#)
Of course a static glare brings no value to our recipe, so we need to make it follow the mouse position, and if you remember,
we already have all the necessary coordinates-calculating logic inside of our `handleMouseMove` function!

Let's add a `glareCoordinates` state to our component, update it into said handler, and finally bind it to the card overlay glare's position.

#### Glare coordinates state
```
const [glareCoordinates, setGlareCoordinates] = useState({ x: 0, y: 0, opacity: 0 });
```

#### Glare coordinates update
```js
const animate = (event) => {
    /* ... All the code we previously wrote inside of the handler... */

    setGlare({
      x: percent.x,
      y: percent.y,
      opacity: 0.25,
    });
  };
}
```

#### Glare coordinates binding to the glare overlay
```jsx
<motion.div
  // ...
  animate={{
    background: `radial-gradient(
            farthest-corner circle at ${glareCoordinates.x}% ${glareCoordinates.y}%,
            rgba(255, 255, 255, 0.7) 10%,
            rgba(255, 255, 255, 0.5) 24%,
            rgba(0, 0, 0, 0.8) 82%
        )`,
    opacity: glareCoordinates.opacity
  }}
/>
```

[break](#)
## Step 4: Nah... no step 4, we're good!

As promised, we're done already. We should end up with something like this:
[snip-1-4](#)

[break](#)

The code to recreate this whole effect should look like the this:
```jsx
const Card = () => {
  const [rotations, setRotations] = useState({ x: 0, y: 0, z: 0 });
  const [isAnimating, setAnimating] = useState(false);
  const isAnimatingReference = useRef(isAnimating);
  const [glare, setGlare] = useState({ x: 0, y: 0, opacity: 0 });

  const animate = (event) => {
    setAnimating(true);

    const rect = event.currentTarget.getBoundingClientRect();

    const absolute = {
      x: event.clientX - rect.left,
      y: event.clientY - rect.top
    };

    const percent = {
      x: round((100 / rect.width) * absolute.x),
      y: round((100 / rect.height) * absolute.y)
    };

    const center = {
      x: percent.x - 50,
      y: percent.y - 50
    };

    setRotations({
      x: round(((center.x > 50 ? 1 : -1) * center.x) / 12),
      y: round(center.y / 16),
      z: round(distance(percent.x, percent.y, 50, 50) / 20)
    });

    setGlare({
      x: percent.x,
      y: percent.y,
      opacity: 0.25
    });
  };

  const stopAnimating = () => {
    setAnimating(false);

    setTimeout(() => {
      if (isAnimatingReference.current) return;

      setRotations({ x: 0, y: 0, z: 2 });
      setGlare({ x: 50, y: 50, opacity: 0 });
    }, 100);
  };

  return (
    <motion.div
      onMouseMove={animate}
      onMouseLeave={stopAnimating}
      animate={{
        rotateY: rotations.x,
        rotateX: rotations.y,
        transformPerspective: rotations.z * 100
      }}
      style={{
        width: '240px',
        height: '320px',
        backgroundColor: '#C2B8F0',
        borderRadius: '0.5rem',
        boxShadow:
          '0 0 0 1px rgba(0, 0, 0, 0.105), 0 9px 20px 0 rgba(0, 0, 0, 0.02), 0 1px 2px 0 rgba(0, 0, 0, 0.106)',
        display: 'flex',
        alignItems: 'center',
        justifyContent: 'center',
        transformStyle: 'preserve-3d',
        transformOrigin: 'center',
        perspective: '320px'
      }}>
      <motion.div
        style={{
          zIndex: 2,
          mixBlendMode: 'overlay',
          position: 'absolute',
          transform: 'translateZ(1px)',
          width: '100%',
          height: '100%',
          borderRadius: '0.5rem',
          transformStyle: 'preserve-3d'
        }}
        animate={{
          background: `radial-gradient(
            farthest-corner circle at ${glare.x}% ${glare.y}%,
            rgba(255, 255, 255, 0.7) 10%,
            rgba(255, 255, 255, 0.5) 24%,
            rgba(0, 0, 0, 0.8) 82%
          )`,
          opacity: glare.opacity
        }}
      />
      <p>LIGMA</p>
    </motion.div>
  );
}
```

[break](#)

# Stay tuned for more!

Tiltable cards from scratch in React

Explaining the difference in the simplest way possible.

We IT people *LOVE* tinkering with new tech stuff, and Docker is no exception. As a matter of fact,  Docker was ranked as the #1 most wanted platform, #2 most loved platform, and #3 most broadly used platform in the [2019 Stack Overflow Developer Survey](https://insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted), and  #1 most wanted platform, #2 most loved platform and #3 most popular platform in [the 2020 edition of the same survey](https://insights.stackoverflow.com/survey/2020#overview).

If you've bumped into this article, chances are that you have been bamboozled by the ~~[fruit doggo](https://i.pinimg.com/originals/3d/d6/ee/3dd6ee6d8b5c9979e0cbe1d7daafada9.jpg)~~ difference between the `CMD` and `ENTRYPOINT` instructions defined in a Dockerfile, used to describe how a Docker container should be run.

### But what's a Docker container?

Containers are lightweight, standalone, executable packages of software designed for running specific tasks, no matter if short-lived or long-running. Therefore, a container's lifecycle depends on the ongoing process inside of it. 

> Once the process stops, the container stops as well.

### Ok, but what role is our Dockerfile playing here?

Containers are dependent on images and use them to construct a run-time environment in order to run an application. A Dockerfile is a script which role is to define the process which leads to the creation of a final image, and how to run a container bound to said image.

The process of creating a Docker image usually begins with a `FROM` command, defining a base image to build our image upon. We usually follow up with a bunch of `RUN` instructions, used to run commands which modify the underlying filesystem.

> Each `RUN` instruction creates a new image layer that contains a modification to the filesystem.

### Fine. Now what about the CMD vs ENTRYPOINT stuff?

`CMD` and `ENTRYPOINT` are two different types of instructions used to define how a Docker container should be run. 
Let's dive into the details of each one:

### CMD

A `CMD` instruction defines the default command used to run a Docker container from an image.

Given a simple image like the following:

```docker
FROM alpine
CMD ["echo", "Hello, World!"]
```

Running it with:

```docker
docker container run my-container
```

Will yield the following result:

```docker
Hello, World!
```

> A Dockerfile can contain multiple `CMD` instructions, but every single one of them, except for the last one, will be ignored.


A `CMD` instruction can be overridden by the arguments passed to `docker container run`, like:

```docker
docker container run my-container echo "Hello again!"
```

Will yield:

```docker
Hello again!
```

### ENTRYPOINT

`ENTRYPOINT` instructions define, just like their CMD siblings, the default command used to start a container.

```docker
FROM alpine
ENTRYPOINT ["echo", "Hello, World!"]
```

Will yield:

```docker
Hello, World!
```

### Cool, so... what's the difference at this point?

Well, the main difference is that, if both a `CMD` and `ENTRYPOINT` instructions are defined inside a Dockerfile, the `CMD` instruction will be concatenated to the `ENTRYPOINT` one:

```docker
FROM alpine
ENTRYPOINT ["echo"]
CMD ["Hello, World!"]
```

Wil lead to us seeing:

```docker
Hello, World!
```

Also, while `CMD` instructions are, by design, made do be easily overridden by passing arguments to `docker container run` commands, `ENTRYPOINT` have purposely been made harder to override manually, by forcing user to use a `--entrypoint` flag.

### This leads us to a pattern

This design leads us to a consistent pattern. And we like patterns, patterns are good for our mental health:

We can use `ENTRYPOINT` to define a base command which always gets executed, and `CMD` to  define default arguments for this command, easily overridable by passing custom args to `docker container run`.

Docker CMD vs ENTRYPOINT: explaining the difference

Listing all the possible values in Typescript ain't as easy as it seems!

Today I have spent quite a few hours trying to contribute a P.R. to a project I really like, and often use in my day-to-day work, the excellent [`class-validator`](https://github.com/typestack/class-validator).
The problem I was trying to solve consisted in listing the possible values for a given enum, in order to let `class-validator` print them in its enum-related error messages.

> The main problem is that enums get transpiled differently, based on their contents and the way they're declared.

When values are not specified, an incremental integer is assigned to each key, so the transpiled JS looks like the following:
```js
// Before
enum Steak {
    Medium,
    Rare,
    WellDone
}

// After
var Steak;
(function (Steak) {
    Steak[Steak["Medium"] = 0] = "Medium";
    Steak[Steak["Rare"] = 1] = "Rare";
    Steak[Steak["WellDone"] = 2] = "WellDone";
})(Steak || (Steak = {}));
```

When an inteer number is assigned as the value, it is simply assigned instead of the deafult incremental integer in the example before.

When a string value is assigned, though, the transpiled JS code looks a bit different:
```js
// Before
enum Steak {
    Medium = "MEDIUM",
    Rare = "RARE",
    WellDone "WELL_DONE"
}

// After
var Steak;
(function (Steak) {
    Steak["Medium"] = "MEDIUM";
    Steak["Rare"] = "RARE";
    Steak["WellDone"] = "WELL_DONE";
})(Steak || (Steak = {}));
```

These transpilation differences lead to obvious inconsistencies when attempting to retrieve an `enum`'s list of possible values when using the common `Object.values()`, `Object.keys()` and `Object.entries()` methods. By fiddling with an heterogeneous `enum` like the following:
```js
enum TestEnum {
	a = 'aA',
	b = 'bB',
	c = 1,
	d = 2,
	e = '01'	
}
```


The following conclusions can be drawn:
* `Object.values()` returns an array containing all the possible values for the given enum AND the keys for the properties which have integer numbers as values (`[ 'c', 'd', 'aA', 'bB', 1, 2, '01' ]`)
* `Object.keys()` returns an array containing all the enum's keys plus all of the integer values defined (`[ '1', '2', 'a', 'b', 'c', 'd', 'e' ]`) 
* `Object.entries()` returns an array of [key, value] arrays, plus N [value, key] entries for N of the enum's properties which have integer numbers as values (`[ [ '1', 'c' ],
     [ '2', 'd' ],
     [ 'a', 'aA' ],
     [ 'b', 'bB' ],
     [ 'c', 1 ],
     [ 'd', 2 ],
     [ 'e', '01' ] ]`)  

  
So, finally, the solution I came up with is:
```js
Object.entries(TestEnum).filter(entry => !parseInt(entry[0])).map(entry => entry[1])
```

Which starts from `Object.keys()`'s results, filtering out all the redundant [value, key] entries.

Listing all the possible values for an enum in Typescript

A nice and clean setup to manage authenticating with different accounts on a variety of different project repositories hosted on cloud services such as GitHub, GitLab, BitBucket, etc..

In this post I'm gonna quickly go over a nice and clean setup I use to manage authenticating with different accounts on a variety of different project repositories hosted on cloud services such as GitHub, GitLab, BitBucket, etc..


### PREPARATION

As a first step, we want to make sure that **all** of our accounts use SSH keys to authenticate connections between our machines and the cloud providers. Nowadays the process doesn't require much fiddling, and can be simply done using our providers' web UIs. I won't go over this part because the specific way to set this up would be vendor-specific, and I don't consider this step to be complicated enough to require any explanation.
\
Let's suppose that at this point we own two different GitLab accounts, each bound to a dedicated SSH key stored on our machine:
```sh
user: first
email: first@myemail.com
private key: ~/.ssh/first/id_rsa
public key: ~/.ssh/first/id_rsa.pub
repository name: first-project

user: second
email: second@myemail.com
private key: ~/.ssh/second/id_rsa
public key: ~/.ssh/second/id_rsa.pub
repository name: second-project
```

### Configuring SSH
If not present, a SSH configuration file needs to be created:
```sh
cd ~/.ssh/
touch config
```

We are going to use said file to tell our machine to use different credentials depending on the host we're trying to connect it to. 

This could lead us to a question: 
> We just assumed both our accounts are gitlab.com accounts. How do we use different credentials if the host is the same?

The answer is straightforward:
ssh can be configured by using host alias names, which will basically allow us to treat the same underlying hostname as two different hosts, while still resolving the correct hostname. 
Let's see how to take advantage of this feature
```sh
# Gitlab.com - "first" account
Host gitlab.com_first   # <-- this could be any alias     
HostName gitlab.com     
User git    
Preferredauthentications publickey    
IdentitiesOnly yes    
IdentityFile ~/.ssh/first/id_rsa

# Gitlab.com - "second" account
Host gitlab.com_second  # <-- this could be any alias     
HostName gitlab.com    
User git    
Preferredauthentications publickey    
IdentitiesOnly yes    IdentityFile ~/.ssh/second/id_rsa
```

### Configuring Git
Our job is pretty simple now: we need to let git use our alias hostnames in order to provide the correct SSH credentials when trying to authenticate  (using only our "first" account for brevity):
```sh
# If the remote repo is still not cloned locally
# we just need to provide our alias hostname
# when cloning
git clone git@gitlab.com_first:first/first-project.git

# If the remote repo is already cloned locally
# we need to update the remote's hostname. Here# we're assuming "origin" its name.git remote remove origin
git remote add origin 
git@gitlab.com_first:first/first-project.git
```

----

## DONE
We're done with our configuration, now the correct credentials will be used when connecting to each remote.

Handling multiple Git credentials the easy way

A simple guide to get up and running with the NextJS + TypeScript + TailwindCSS + Storybook combination.

Following is a simple guide to get up and running with the NextJS + TypeScript + TailwindCSS + Storybook combination, a task which took me a lot more time than I originally estimated, due to the unexpected lack of specific guides on how to deal with this particular scenario plus the sparse nature of the information I had to look up to set everything up as desired.

### NEXTJS SETUP

`yarn create next-app`

That's it. Done. A fully-functional NextJS app will be created using the official starter kit.

---
### TAILWINDCSS SETUP

1. `yarn add -D tailwindcss postcss-preset-env` to install the TailwindCSS library and some useful PostCSS polyfills
2. `npx tailwind init` to generate a `tailwind.config.js` file.
3. Edit the TailwindCSS configuration file we just created to enable and configure the built-in CSS purging process. (Notice how I'm using the ".tsx'" extension here, since I already know I'm going to use TypeScript for this project)
```js
module.exports = {
  purge: ['./components/**/*.tsx', './pages/**/*.tsx'],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}
```
4. Create `postcss.config.js` to configure PostCSS in a minimal way, like the following
```js
module.exports = {
  plugins: [
    "tailwindcss", 
    "postcss-preset-env"
  ]
};
```
5. Create `/styles/index.css` and populate it using the `postcss-import`-friendly `@import` directives (instead of using `@tailwind`)
```css
@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";
```
---
### TYPESCRIPT SETUP

1. `yarn add --dev typescript @types/react @types/node`
2. `touch tsconfig.json`
3. `yarn next` to start NextJS, which will automagically recognize our newly created `tsconfig.json` and inject a valid configuration json into it
4. Create a `/pages/_app.tsx` file
```jsx
import React from "react";
import "../styles/index.css"; // <- applied everywhere in the NextJS application scope

const MyApp = ({ Component, pageProps }) => {
  return <Component {...pageProps} />;
};

export default MyApp;
```
---
### STORYBOOK SETUP

1. `yarn add @storybook/react babel-loader @babel/core awesome-typescript-loader react-docgen-typescript-loader -D`
2. `mkdir .storybook`
3. `cp ./tsconfig.json ./.storybook/`
4. Edit `/.storybook/tsconfig.json` to suit your Storybook-TypeScript integration
```json
{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "react"            // <- important!
  },
  "exclude": ["node_modules"],
  "include": [                // <- important!
    "../types.d.ts",
      "../next-env.d.ts",
      "../**/*.stories.ts",
      "../**/*.stories.tsx"
    ]
  }
```

6. Create `/.storybook/main.js` and feel free to copy the following configuration
```js
const path = require("path");

module.exports = {
  stories: ["../components/**/**/*.stories.tsx"],
  webpackFinal: async (config) => {
    config.module.rules.push({
      test: /\.(ts|tsx)$/,
      use: [
        {
          loader: require.resolve("awesome-typescript-loader"),
          options: {
            configFileName: path.resolve(__dirname, "./tsconfig.json"),
          },
        },
        /* 
          ** OPTIONAL ** 
    						 
          Basically a webpack loader  used to 				 
          generate docgen information from TypeScript React components. 
The primary use case is to get the prop types 
table populated in the Storybook Info Addon.
    	*/
    	{
          loader: require.resolve("react-docgen-typescript-loader"),
          options: {
            tsconfigPath: path.resolve(__dirname, "./tsconfig.json"),
          },
        },
      ],
    });

    config.resolve.extensions.push(".ts", ".tsx");

    return config;
  },
};
```

7. create `/.storybook/preview.js` and use it to import our stylesheet as follows
```js
// The preview application is essentially just your stories with 
// a framework-agnostic 'router'. 
// It renders whichever story the manager application tells it to render.
// In this case we just use it to import the stylesheet and inject it 
// in the context of our stories

import "../styles/index.css";
```

8. Update `postcss.config.js` to use an object-based format. This is super important in order to solve any issues Storybook's webpack process may encounter while resolving the dependencies!
```js
module.exports = {
  plugins: {
    tailwindcss: {}, 
    "postcss-preset-env": {}
  }
};
```
---
# DONE

Now you will be able to create your component stories in your own component's folders (ex.: `/components/button/1-button.stories.tsx`) using this powerful toolset.


> P.S.: If you wish to organize your Storybook stories using a different folder structure, you'll need to do no more than editing the `stories` property inside the exported configuration in `/.storybook/main.js` using your desired glob patterns 