DEV Community: Iliya.Faz

SQL Cheat sheet

Iliya.Faz — Tue, 25 Aug 2026 11:58:42 +0000

Long story short, I came back after a long break from programming. Thought I should write this not only to review the concepts myself, but to make sure I have a good cheat sheet for future occasions.

This articles aims to quickly review important SQL concepts in a few minutes of reading.

This article/cheat sheet is divided into 3 parts:
1- Tables, rows, and useful SQL statements
2- SQL joins
3- SQL relationships

How does SQL work?

Related pieces of data are stored in a table (similar to collections in MongoDB)
For instance: Users, Customers, BlogPosts, etc.

Each table has rows and columns. Columns are properties, rows are records.
For instance:

age ,username, displayName, can be columns
{age: 28, username: "john_doe", displayName: "John doe"} can be a row.

Notes:

SQL statements must end with semicolons.
SQL statements are NOT case sensitive. (select is the same thing as SELECT)

Useful SQL statements:

1 - `SELECT`

Used to select data from a database.

SYNTAX

SELECT _column1_, _column2, ..._  
FROM _table_name_;

EXAMPLE

SELECT CustomerName, City FROM Customers;

NOTE: To select all columns, use SELECT *

SELECT * FROM Customers;

2- `SELECT DISTINCT`

Used to select data from a database and return ONLY unique/distinct values.

SYNTAX

SELECT DISTINCT _column1_, _column2, ..._  
FROM _table_name_;

EXAMPLE

SELECT DISTINCT Country FROM Customers;

This statement lists all the different countries our customers are from.
It does not list a country twice.

3- `WHERE`

Used to filter records based on a specified condition.

SYNTAX

SELECT _column1_, _column2_, ...
FROM _table_name_
WHERE _condition_;

EXAMPLE

SELECT * FROM Customers
WHERE Country = 'Germany';

The statement above selects all customers whose country is Germany.

NOTE: WHERE can be used with different operators, such as =, >, <, >=, <=, <> and !=.
For instance:

SELECT * FROM Customers
WHERE Age >= 18;

This statement selects all customers whose age is 18 or higher.

4- `ORDER BY`

Used to sort the returned records by one or more columns.

SYNTAX


SELECT _column1_, _column2_, ...
FROM _table_name_
ORDER BY _column_ _ASC|DESC_;

EXAMPLE

SELECT * FROM Customers
ORDER BY Country;

This statement sorts the customers alphabetically by their country.
By default, ORDER BY sorts values in ascending order.

NOTE: To sort in descending order, use DESC.

SELECT * FROM Customers
ORDER BY Country DESC;

This statement sorts the customers in descending alphabetical order by their country.

NOTE: ASC can be used to explicitly specify ascending order (Although it's not necessarily needed).

SELECT * FROM Customers
ORDER BY Country ASC;

5- `INSERT INTO`

Used to insert new records into a table.

SYNTAX

INSERT INTO _table_name_ (_column1_, _column2_, ...)
VALUES (_value1_, _value2_, ..._);

EXAMPLE

INSERT INTO Customers (CustomerName, Country, Age)
VALUES ('John Doe', 'Germany', 28);

This statement adds a new customer to the Customers table.
The values are inserted into the columns in the same order they are listed.

NOTE: You can insert multiple records with one statement.

INSERT INTO Customers (CustomerName, Country, Age)
VALUES
('John Doe', 'Germany', 28),
('Jane Doe', 'France', 31);

6- `DELETE`

Used to delete records from a table.

SYNTAX

DELETE FROM _table_name_
WHERE _condition_;

EXAMPLE

DELETE FROM Customers
WHERE CustomerName = 'John Doe';

This statement deletes all customers whose name is John Doe.

NOTE: Be careful when using DELETE without a WHERE condition.

DELETE FROM Customers;

This statement deletes ALL records from the Customers table.
It does not delete the table itself.

7- `UPDATE`

Used to modify existing records in a table.

SYNTAX

UPDATE _table_name_
SET _column1_ = _value1_, _column2_ = _value2_, ...
WHERE _condition_;

EXAMPLE

UPDATE Customers
SET Country = 'Germany'
WHERE CustomerName = 'John Doe';

This statement changes the country of all customers whose name is John Doe to Germany.

NOTE: Be careful when using UPDATE without a WHERE condition.

UPDATE Customers
SET Country = 'Germany';

This statement changes the country to Germany for ALL customers.

SQL JOINs

A JOIN is used to combine rows from two or more tables based on a related column between them.

For instance, imagine we have these two tables:

Customers

CustomerID	CustomerName
1	John
2	Jane

Orders

OrderID	CustomerID	Product
101	1	Laptop
102	1	Mouse
103	2	Keyboard

The CustomerID column connects the two tables.

Common joins and how they're used:

1- `INNER JOIN`

Returns only records that have a match in BOTH tables.

SYNTAX

SELECT _column1_, _column2_, ...
FROM _table1_
INNER JOIN _table2_
ON _table1_._column_ = _table2_._column_;

EXAMPLE

SELECT Customers.CustomerName, Orders.Product
FROM Customers
INNER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID;

This statement returns customers who have an order.
Customers without an order are not included. ### 2- LEFT JOIN Returns ALL records from the left table, and the matching records from the right table. If there is no match, the columns from the right table contain NULL.

EXAMPLE

SELECT Customers.CustomerName, Orders.Product
FROM Customers
LEFT JOIN Orders
ON Customers.CustomerID = Orders.CustomerID;

This statement returns ALL customers.
If a customer has no orders, their Product will be NULL.

3- `RIGHT JOIN`

Returns ALL records from the right table, and the matching records from the left table.
If there is no match, the columns from the left table contain NULL.

EXAMPLE

SELECT Customers.CustomerName, Orders.Product
FROM Customers
RIGHT JOIN Orders
ON Customers.CustomerID = Orders.CustomerID;

This statement returns ALL orders.
If an order has no matching customer, the customer columns will be NULL.

NOTE: RIGHT JOIN can usually be rewritten as a LEFT JOIN by switching the order of the tables.

4- `FULL OUTER JOIN`

Returns ALL records from both tables.

EXAMPLE

SELECT Customers.CustomerName, Orders.Product
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID;

This statement returns every customer and every order.
Matching records are combined.
Records without a match are still included (if a record has no match in one of the tables, the columns from that table will be NULL).

NOTE: Not all SQL databases support FULL OUTER JOIN.

5- `CROSS JOIN`

Returns every possible combination of rows from the two tables.

EXAMPLE

SELECT Customers.CustomerName, Products.ProductName
FROM Customers
CROSS JOIN Products;

If there are 3 customers and 4 products, this statement returns 12 rows.
Every customer is paired with every product.
CROSS JOIN does not require an ON condition.

SQL Relations

Relations are used to connect records in different tables.

For instance, instead of storing a customer's orders directly inside the Customers table, we can store customers and orders in separate tables and connect them using IDs.

Different kinds of relationships in SQL:

1- One-to-One relationships

In a one-to-one relationship, each record in one table is related to at most one record in another table.

For instance:

Users
-----
id
username

UserProfiles
------------
id
user_id
bio

Each user can have one profile, and each profile belongs to one user.

EXAMPLE

CREATE TABLE UserProfiles (
    id INT PRIMARY KEY,
    user_id INT UNIQUE,
    bio VARCHAR(255),
    FOREIGN KEY (user_id) REFERENCES Users(id)
);

FOREIGN KEY creates a relationship between the two tables.
UNIQUE prevents multiple profiles from referencing the same user.

2- One-to-Many relationships

In a one-to-many relationship, one record can be related to many records in another table.

For instance:

Customers
---------
id
name

Orders
------
id
customer_id
product

One customer can have many orders, but each order belongs to one customer.

EXAMPLE

CREATE TABLE Orders (
    id INT PRIMARY KEY,
    customer_id INT,
    product VARCHAR(100),
    FOREIGN KEY (customer_id) REFERENCES Customers(id)
);

customer_id is a foreign key.
It references Customers.id.
Multiple orders can have the same customer_id.

To get a customer's orders, use a JOIN.

SELECT Customers.name, Orders.product
FROM Customers
INNER JOIN Orders
ON Customers.id = Orders.customer_id;

3- Many-to-Many relationships

In a many-to-many relationship, many records in one table can be related to many records in another table.

For instance, a student can take many courses, and a course can have many students.

We cannot directly store this relationship in either table.
Instead, we can create a third table, commonly referred to as a junction table/join table.

Students
--------
id
name

Courses
-------
id
name

StudentCourses
--------------
student_id
course_id

EXAMPLE

CREATE TABLE StudentCourses (
    student_id INT,
    course_id INT,
    PRIMARY KEY (student_id, course_id),
    FOREIGN KEY (student_id) REFERENCES Students(id),
    FOREIGN KEY (course_id) REFERENCES Courses(id)
);

StudentCourses connects students and courses.
Each row represents one relationship between a student and a course.
The combination of student_id and course_id is unique because it is the primary key.

To find all courses taken by a student:

SELECT Students.name, Courses.name
FROM Students
INNER JOIN StudentCourses
ON Students.id = StudentCourses.student_id
INNER JOIN Courses
ON StudentCourses.course_id = Courses.id;

Extra notes:

What is a foreign key

A foreign key is a column that references a key in another table.

For instance:

CREATE TABLE Orders (
    id INT PRIMARY KEY,
    customer_id INT,
    FOREIGN KEY (customer_id) REFERENCES Customers(id)
);

customer_id is a foreign key, it references Customers.id. This creates a relationship between the two tables.

Using `ON DELETE`

When a record that other records reference is deleted, you can define what should happen to the related records.

For instance:

CREATE TABLE Orders (
    id INT PRIMARY KEY,
    customer_id INT,
    FOREIGN KEY (customer_id)
        REFERENCES Customers(id)
        ON DELETE CASCADE
);

ON DELETE CASCADE means that when a customer is deleted, all orders belonging to that customer are also deleted.

Other alternatives to CASCADE include:

ON DELETE SET NULL: sets the foreign key to NULL.
ON DELETE RESTRICT: prevents the referenced record from being deleted if related records exist.
ON DELETE NO ACTION: generally prevents the deletion when the foreign key constraint would be violated.

Using `ON UPDATE`

You can define what happens when a referenced key is updated.

EXAMPLE

CREATE TABLE Orders (
    id INT PRIMARY KEY,
    customer_id INT,
    FOREIGN KEY (customer_id)
        REFERENCES Customers(id)
        ON UPDATE CASCADE
);

ON UPDATE CASCADE automatically updates the foreign key when the referenced key changes.

NOTE: In practice, primary keys typically remain unchanged, so ON UPDATE CASCADE is less commonly needed than ON DELETE CASCADE.

Tip: Save this article in Obsidian.md, so you can quickly go through the terms whenever needed in the future.
Hope this was useful. See you in the next one!

useEffect in React: Summarized

Iliya.Faz — Fri, 31 Jan 2025 18:21:38 +0000

First, we need to understand 3 things:

trigger
render
commit

These are the 3 steps taken in order for a component to be displayed on the screen.

First, a render is triggered.

For instance:

function Component({ text }) {
  return <div>{text}<div/>
}

// triggering the component:
<Component text="hello" />

Then, the component is rendered, meaning React calls your component to figure out what to display on screen.
( In the example above, React would call <Component text="hello"/> and after doing the calculations come to the conclusion that it should look like <div>hello</div> in the DOM )
Finally, the DOM is modified to match the component.
Either the component is appended to it (while mounting for instance) or it's updated. This is what we call "commit".

Side note: Mounting refers to when your React component is first rendered.

Note: commit only takes place if the rendered component is different from the real DOM element. And if it isn't, it will make the minimum amount of modifications required to update the element and sync it with the component.

useEffect runs on every commit

useEffect is a React hook that runs after the render is committed to the DOM, whereas other logic is typically executed when the component is being rendered, before it is updated in the real DOM.

For instance, to put it simply:

<Component text="hello"/> triggers a render.
It's rendered and converted into <div>hello</div>
It's appended to the DOM.

And then it would be time for useEffect to do its job!

Examples use cases include:

When you want to access real DOM elements.
For instance, when you're looking to pause a video player using its reference with ref.current.pause();.
Running the piece of code above outside of useEffect will throw an error, because it's executed before the video player element is appended to the DOM! putting it into a useEffect however will make sure it's executed only after the rendering and committing process is complete.
If you want to prevent useEffect from running on every re-render, use a dependency array. The dependency array tells React that it should skip re-running your Effect if your dependencies (the items in the array) are the same as they were during the previous render.

Different useEffect behaviours:

Here's a very simple demonstration from the official react docs:

useEffect(() => {  
// This runs after every render  
});  

useEffect(() => {  
// This runs only on mount (when the component appears)  
}, []);  

useEffect(() => {  
// This runs on mount *and also* if either a or b have changed since the last render  
}, [a, b]);

Cleanup functions

Cleanup functions are functions you return in your useEffect hook.
React will call your cleanup function each time before the Effect runs again, and one final time when the component unmounts (gets removed).

useEffect(() => {
  // effect;
  return () => {
   // cleanup;
  };
}, []);

You could sort of think of the cleanup function as a function that stops everything the Effect is doing.

If your Effect subscribes to something, the cleanup function should unsubscribe.
If your Effect animates something in, the cleanup function should reset the animation to the initial values.
If your Effect fetches something, the cleanup function should either abort the fetch or ignore its result.

Here's a more realistic example:
Side note: If you're not familiar with AbortController have a look at here
It's pretty much used to cancel ongoing requests in here.

useEffect(() => {
  const controller = new AbortController();
  const signal = controller.signal;
  fetch(API, {
    signal: signal,
  })
    .then((response) => response.json())
    .then((response) => {
      // handle success
    });
  return () => {
    // cancel the request before component unmounts
    controller.abort();
  };
}, []);

Not an Effect: Initializing the application

Some logic should only run once when the application starts. You can put it outside your components:

if (typeof window !== 'undefined') { // Check if we're running in the browser.  
  checkAuthToken();  
  loadDataFromLocalStorage();  
}

function App() {  
// ...  
}

This guarantees that such logic only runs once after the browser loads the page.

Parts of the article are taken from the react docs, Credits to them for that!
If I happened to make a mistake, make sure to let me know.
See you in the next one!

Creating Truly Reusable React Components: A Comprehensive Guide

Iliya.Faz — Thu, 18 Jul 2024 18:48:32 +0000

In this article, we will go through the process of creating fully reusable React components from scratch.
Note that in a typical codebase, you'd probably copy & paste these components instead of writing them from scratch, so the implementation isn't as time consuming as it might look like 😅.

All CSS is written with Tailwindcss in this article.

Introduction 🚀

You can think of React components as building blocks of the web.
A component can be a navbar, footer, form, button, or any other piece of the front end.

They serve the same purpose as JavaScript functions, but work in isolation and return HTML.

Source

Code reusability refers to writing code in such a way that it can be reused across multiple contexts with little or no modification required. This approach saves time on repetitive tasks, shrinks codebase size, and improves maintainability.

Source

Reusable React components are components that can be used multiple times throughout an application to prevent unnecessary boilerplate.

Whenever possible, I prefer to create reusable components for common UI elements (e.g., buttons, text inputs, etc) and use them in the application like a component library, Instead of creating a separate component for each instance of the element.
This approach makes the code base cleaner, reduces code duplication and scales really well.

To give you an idea of how the process is done, we will create a fully reusable Button component in React. Note that any other type of reusable component is implemented in pretty much the same way.

Let's take a look at an example to help understand the concept.

For demonstration purposes, we'll recreate the list of buttons in the image below

Step 0: Creating a simple button component

First, we're gonna start off with the home button.

// home-button.tsx
const HomeButton = () => {
  return (
    <button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90">
      Home
    </button>
  );
};

export default HomeButton;

Then we will copy and paste the code for the remaining buttons and make the necessary modifications.

// profile-button.tsx
const ProfileButton = () => {
  return (
    <button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90">
      Profile
    </button>
  );
};

export default ProfileButton;

// settings-button.tsx
const SettingsButton = () => {
  return (
    <button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90">
      Settings
    </button>
  );
};

export default SettingsButton;

and this is how we would include them in our app:

<HomeButton/> <ProfileButton/> <SettingsButton/>

And... boom! here it is.

Why this is actually a bad approach ❌

While this does work, it comes with a bunch of problems, one of the notable ones being too much unnecessary boilerplate.
We just created 3 separate components for essentially the same thing. Imagine you're working on a large application where there are thousands of buttons like this. Making a separate component for each one would create loads of unnecessary boilerplate and quickly turn into an absolute mess.

Not to mention, making modifications to the component would be an absolute nightmare. You'd have to go through the code base and modify each component one by one!

Step 1: Making the button component reusable

First off, instead of including each button's label directly in its component, we could pass it off as a prop!

// button.tsx
const Button = ({ children }) => {
  return (
    <button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90">
      {children}
    </button>
  );
};

export default Button;

And then modify the code to look like this:

   <Button>Home</Button>
   <Button>Profile</Button>
   <Button>Settings</Button>

Same result, better code.

Now we've got 1 component instead of 3! That's a huge improvement, but we've still got a major problem: Customization.

Step 2: implementing className prop

What if you wanted to customize a button's appearance, without having to create a new component for it?

For example, let's say we want to make something like the image below.

Well, with our current component, we can't!
Because a fixed set of classNames is applied to every button element with no way to customize it.

Let's make it so that you can pass className as a prop.
(Like this)

  <Button className="bg-neutral-700 text-foreground">
    Home
  </Button>

Note: If you're not using tailwind, you can skip this step. Just take 'className' as a prop and add it to the list of classNames and you should be good to go.

Bad implementation ❌

Take a look at the button component below.

const Button = ({ children, className = "" }) => {
  const defaultStyle = "rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90";
  // anything passed as 'className' is directly added to button's className prop
  return (
    <button className={`${defaultStyle} ${className}`}>
      {children}
    </button>
  );
};

export default Button;

We're basically taking className as a prop and adding it to the button element's list of classNames.

Let's try applying text-black to the element to see if it works.

<Button className="text-black">Test</Button>

Button element resulted from the code above:

<button className="rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90 text-black">Test</button>;

Take a close look at the list of classNames above.

Expected behaviour: text-white should be replaced by text-black
Result: text-black is added but text-white isn't removed.

So in short, we've got both text-white and text-black in the same list of classNames which could lead to unexpected behaviour.

To fix this, we'll use a library called tailwind-merge.

twMerge (6.7k gzipped)

tailwind-merge is a library that allows us to merge two sets of Tailwindcss classNames into one.

for example:

twMerge('text-white bg-white', 'text-black text-xl')
// output: 'text-black bg-white text-xl'

// notice how text-white was replaced with text-black?
// without twMerge, this would output:
'text-white bg-white text-black text-xl'

More about tailwind-merge Here

In here, we'll use twMerge to merge the default classNames with the classNames provided as a prop (to prevent potential conflicts)

import React from "react";
import { twMerge } from "tailwind-merge";

const Button = ({ children, className }) => {
  const defaultStyle = "rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90"

  return (
    <button
      className={twMerge(defaultStyle, className)}>
      {children}
    </button>
  );
};

export default Button;

There you go! Now we can use className without having to worry about potential className conflicts.

Step 3: implementing support for attributes

We're now one step closer to the final result! But there's still a huge problem, what if we wanted to use other button attributes? like onClick, onFocus, type, name, or even our own custom attributes.

  <Button
// not working
    onClick={onClickHandler}
    type="submit"
    custom-attribute="custom value">
    Button
  </Button>

With our current implementation, such attributes would not be applied to the button element.

This is how you'd fix that:

import { twMerge } from "tailwind-merge";

// "...props" gets all remaining props
const Button = ({ children, className, ...props }) => {
  const defaultStyle = "rounded-md px-3 py-2 bg-blue-600 text-white hover:bg-blue-600/90";
  return (
    <button
      className={twMerge(defaultStyle, className)}
      // applying other props
      {...props}>
      {children}
    </button>
  );
};

export default Button;

First, we're extracting children and className from props
Then we're getting the remaining props as props by using the spread operator
And finally, we're applying them to the button element with {...props}.

Step 4: Improving Re-usability and Readability with variants

I would consider what we've made so far to be quite re-usable, but there are still a few things we can do to make it even better.

One thing that really reduces boilerplate is implementing variants for common variations of the UI component such as size, color, etc.

Why use variants in the first place?

Using the className prop enables us to customize buttons when needed. But I prefer to only use it as a last resort since it comes with a bunch of boilerplate. If there is a certain button style (other than our default one) we'd want to use all over our application, we should create a variant for it instead of copy & pasting the list of custom classNames everywhere.

For instance, imagine a set of default (primary), secondary, outline and ghost buttons we'd be looking forward to use all over the code base.

This is how the implementation would look like:

      <Button>Default button</Button>
      <Button className="bg-neutral-700 text-neutral-50 hover:bg-neutral-700/90">
        Secondary button
      </Button>
      <Button className="border border-black text-black bg-transparent hover:bg-black/10">
        Outline button
      </Button>
      <Button className="bg-transparent text-black hover:bg-black/10">
        Ghost button
      </Button>

It would look quite messy if we had to copy and paste the same set of classNames for each instance of the button.

What if we could specify each button's style by using a simple variant prop?

      <Button>Default button</Button>
      <Button variant="secondary">Secondary button</Button>
      <Button variant="outline">Outline button</Button>
      <Button variant="ghost">Ghost button</Button>

Much cleaner now, isn't it?
Well, this is where variants come in handy!
In this example, we will implement two useful variants for our component:
size and variant (quite literally 😅)

In order to implement variants we're going to use class-variance-authority

cva (756 bytes gzipped)

class-variance-authority is the main library we're going to use to implement variants.
More about class-variance-authority Here

The library provides a function called 'cva'.
Take a look at the following example to get a brief overview of how cva is used.

const componentVariants = cva('text-black',
  {
    variants: {
// variants such as 'size', 'color' etc are supposed to be here
      color: {
        blue: "bg-blue-500",
        red: "bg-red-500",
        white: "bg-white",
      }
    },
    defaultVariants: {
// We'll set the color to blue if nothing is specified.
      color: "blue",
    },
  }
);

The first parameter of cva takes in the list of classNames we want to be applied to all variants. Useful for general layouts and transitions.
In the second parameter we specify variants and their corresponding classNames. For example, if blue is selected as the color variant, bg-blue-500 will be applied to the element.
We can also use defaultVariants to specify which variant to apply by default when nothing is specified.

Now we're gonna use componentVariants like this:

console.log(componentVariants({ color: "red" }));
// output: text-black bg-red-500
console.log(componentVariants({ color: "blue" }));
// output: text-black bg-blue-500
console.log(componentVariants());
// output: text-black bg-blue-500

You probably know how it works by now.
So let's use it to build different variants for our button component.

import { twMerge } from "tailwind-merge";
import { cva } from "class-variance-authority";

const buttonVariants = cva(
  `inline-flex items-center justify-center rounded-md whitespace-nowrap 
  ring-offset-background transition-colors focus-visible:outline-none 
   disabled:pointer-events-none disabled:opacity-50 relative overflow-hidden`,
  {
    variants: {
      variant: {
        default: "bg-primary text-neutral-100 hover:bg-primary/80",
        secondary: "bg-secondary text-foreground hover:bg-secondary/80",
        outline: "border border-ring text-foreground bg-background hover:bg-secondary/80",
        ghost: "text-foreground hover:bg-secondary/80",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "text-base px-3 py-2",
        sm: "text-sm rounded-md px-2 py-1.5",
        lg: "text-xl rounded-md px-4 py-3",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
);

const Button = ({ children, className, variant, size, ...props }) => {
  return (
    <button className={twMerge(buttonVariants({ variant, size }), className)} {...props}>
      {children}
    </button>
  );
};

export default Button;

In the end, we get the corresponding list of classNames from buttonVariants({ variant: <variant> }) and pass them to twMerge, which will merge them with custom classNames if any are provided.

Step 5: Implementing support for refs with React forwardRef

What if we wanted to us refs with our components? They're supposed to be 100% reusable so this should be a feature.

Picture this:

 const buttonRef = React.useRef(null);

  return <Button ref={buttonRef}>Default button</Button>;

This can be extremely useful in components like inputs.

React's forwardRef allows function components to be given refs.
To opt in, wrap your component definition into forwardRef():

const Button = React.forwardRef(({ children, className, variant, size, ...props }, ref) => {
  return (
    <button
      ref={ref}
      className={twMerge(buttonVariants({ variant, size }), className)}
      {...props}>
      {children}
    </button>
  );
});

(Make sure to import React if you haven't already)

Step 6: Final tweaks

clsx integration

From the official docs:

clsx is a tiny (239B) utility for constructing className strings conditionally.

import { clsx } from 'clsx';

// Strings (variadic)
clsx('foo', true && 'bar', 'baz');
//=> 'foo bar baz'

// Objects
clsx({ foo:true, bar:false, baz:isTrue() });
//=> 'foo baz'

More about clsx here

Wrap className with clsx and boom! Now we can use the clsx syntax to apply classNames conditionally.

    <button className={twMerge(buttonVariants({ variant }), clsx(className))} {...props}>
      {children}
    </button>

To reduce boilerplate, we can create a simple cn helper function which is basically a shortcut for wrapping the input in both clsx and twMerge.

[Credits to ShadcnUI for the idea]

// lib/utils.js
import { twMerge } from "tailwind-merge";
import { clsx } from "clsx";

export function cn(...classes) {
  return twMerge(clsx(classes));
}

Typescript version:

// lib/utils.ts
import { twMerge } from "tailwind-merge";
import { ClassValue, clsx } from "clsx";

export function cn(...classes: ClassValue[]) {
  return twMerge(clsx(classes));
}

Finally, we edit our button component to use cn instead of twMerge and clsx

import { cn } from "../lib/utils";

    <button className={cn(buttonVariants({ variant, size, className }))} {...props}>
      {children}
    </button>

And with that, we've finished building our entirely reusable button component.
You can customize it in however way you'd like.
In the same way, you can build other reusable components (inputs, modals, dropdowns, etc)

Here's the final result:
✅ Supports custom labels
✅ Supports custom classNames
✅ Supports custom attributes
✅ Supports different variants and sizes
✅ Supports conditional classNames with clsx syntax
✅ Supports refs

import React from "react";

import { cva } from "class-variance-authority";
import { cn } from "../lib/utils";

const buttonVariants = cva(
  `inline-flex items-center justify-center rounded-md whitespace-nowrap 
  ring-offset-background transition-colors focus-visible:outline-none 
   disabled:pointer-events-none disabled:opacity-50 relative overflow-hidden`,
  {
    variants: {
      variant: {
        default: "bg-primary text-neutral-100 hover:bg-primary/80",
        secondary: "bg-secondary text-foreground hover:bg-secondary/80",
        outline: "border border-ring text-foreground bg-background hover:bg-secondary/80",
        ghost: "text-foreground hover:bg-secondary/80",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "text-base px-3 py-2",
        sm: "text-sm rounded-md px-2 py-1.5",
        lg: "text-xl rounded-md px-4 py-3",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
);

const Button = React.forwardRef(({ children, className, variant, size, ...props }, ref) => {
  return (
    <button
      ref={ref}
      className={cn(buttonVariants({ variant, size, className }))}
      {...props}>
      {children}
    </button>
  );
});

export default Button;

Typescript version:

import React from "react";

import { cva, type VariantProps } from "class-variance-authority";
import { cn } from "../lib/utils";

const buttonVariants = cva(
  `inline-flex items-center justify-center rounded-md whitespace-nowrap 
  ring-offset-background transition-colors focus-visible:outline-none 
   disabled:pointer-events-none disabled:opacity-50 relative overflow-hidden`,
  {
    variants: {
      variant: {
        default: "bg-primary text-neutral-100 hover:bg-primary/80",
        secondary: "bg-secondary text-foreground hover:bg-secondary/80",
        outline: "border border-ring text-foreground bg-background hover:bg-secondary/80",
        ghost: "text-foreground hover:bg-secondary/80",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "text-base px-3 py-2",
        sm: "text-sm rounded-md px-2 py-1.5",
        lg: "text-xl rounded-md px-4 py-3",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
);

type ButtonProps = React.ButtonHTMLAttributes<HTMLButtonElement> &
  VariantProps<typeof buttonVariants>;

const Button = React.forwardRef<HTMLButtonElement, ButtonProps>(
  ({ children, className, variant, size, ...props }, ref) => {
    return (
      <button
        ref={ref}
        className={cn(buttonVariants({ variant, size, className }))}
        {...props}>
        {children}
      </button>
    );
  }
);

export default Button;

If I made a mistake, make sure to let me know.
See you on the next one!

DEV Community: Iliya.Faz

SQL Cheat sheet

How does SQL work?

1 - SELECT

2- SELECT DISTINCT

3- WHERE

4- ORDER BY

5- INSERT INTO

6- DELETE

7- UPDATE

SQL JOINs

1- INNER JOIN

3- RIGHT JOIN

4- FULL OUTER JOIN

5- CROSS JOIN

SQL Relations

1- One-to-One relationships

2- One-to-Many relationships

3- Many-to-Many relationships

What is a foreign key

Using ON DELETE

Using ON UPDATE

useEffect in React: Summarized

useEffect runs on every commit

Different useEffect behaviours:

Cleanup functions

Not an Effect: Initializing the application

Creating Truly Reusable React Components: A Comprehensive Guide

Introduction 🚀

Step 0: Creating a simple button component

Why this is actually a bad approach ❌

Step 1: Making the button component reusable

Step 2: implementing className prop

Bad implementation ❌

twMerge (6.7k gzipped)

Step 3: implementing support for attributes

Step 4: Improving Re-usability and Readability with variants

Why use variants in the first place?

cva (756 bytes gzipped)

Step 5: Implementing support for refs with React forwardRef

Step 6: Final tweaks

clsx integration

1 - `SELECT`

2- `SELECT DISTINCT`

3- `WHERE`

4- `ORDER BY`

5- `INSERT INTO`

6- `DELETE`

7- `UPDATE`

1- `INNER JOIN`

3- `RIGHT JOIN`

4- `FULL OUTER JOIN`

5- `CROSS JOIN`

Using `ON DELETE`

Using `ON UPDATE`