
JavaScript powers the web, but there's a big gap between knowing the basics and writing fluent modern JS. This post covers the patterns I reach for most often — all of them standard ES2015+ features available in every current browser and Node version.

## Variables and Scope

Prefer `const` by default; use `let` only when you need to reassign. Avoid `var` — it has function scope and hoisting behaviour that regularly causes bugs.

```js
const API_URL = 'https://api.example.com'; // never reassigned

let retries = 0; // will be incremented
retries += 1;

// var leaks out of blocks — this is why we don't use it
for (var i = 0; i < 3; i++) {}
console.log(i); // 3 — leaks!

for (let j = 0; j < 3; j++) {}
console.log(j); // ReferenceError — correctly scoped
```

## Arrow Functions

Arrow functions are shorter and, crucially, they don't have their own `this` — they close over the surrounding context's `this`, which is almost always what you want inside class methods or React components.

```js
// traditional
function double(n) {
  return n * 2;
}

// arrow — same thing
const double = (n) => n * 2;

// multi-line body needs explicit return
const clamp = (n, min, max) => {
  if (n < min) return min;
  if (n > max) return max;
  return n;
};
```

## Destructuring

Destructuring pulls values out of objects and arrays into named variables. It's cleaner than repeated `obj.x` access and pairs perfectly with function parameters.

```js
const user = { id: 1, name: 'Alice', role: 'admin' };

// object destructuring with a rename and a default
const { name, role, department = 'Engineering' } = user;
console.log(name); // 'Alice'
console.log(department); // 'Engineering'

// array destructuring
const [first, second, ...rest] = [10, 20, 30, 40];
console.log(first); // 10
console.log(rest);  // [30, 40]

// in function parameters — very common in React
function UserCard({ name, role }) {
  return `${name} (${role})`;
}
```

## Template Literals

Template literals replace string concatenation and support multi-line strings cleanly.

```js
const name = 'Alice';
const score = 42;

// instead of: 'Hello, ' + name + '. Score: ' + score
const message = `Hello, ${name}. Score: ${score}`;

// multi-line — no \n needed
const html = `
  <div class="card">
    <h2>${name}</h2>
    <p>Score: ${score}</p>
  </div>
`.trim();
```

## Array Methods: map, filter, reduce

These three methods cover most list-processing needs without mutation or manual loops.

```js
const products = [
  { name: 'Widget', price: 9.99, inStock: true },
  { name: 'Gadget', price: 24.99, inStock: false },
  { name: 'Doohickey', price: 4.99, inStock: true },
];

// map — transform each element
const names = products.map((p) => p.name);
// ['Widget', 'Gadget', 'Doohickey']

// filter — keep elements that match a predicate
const available = products.filter((p) => p.inStock);
// [{name: 'Widget', ...}, {name: 'Doohickey', ...}]

// reduce — collapse to a single value
const totalStock = products
  .filter((p) => p.inStock)
  .reduce((sum, p) => sum + p.price, 0);
// 14.98
```

Chain them together — each returns a new array, nothing is mutated.

## Spread and Rest

The `...` syntax serves double duty: spread copies/merges values; rest collects the remainder.

```js
// spread: merge objects (last key wins)
const defaults = { theme: 'light', language: 'en', debug: false };
const userPrefs = { theme: 'dark', notifications: true };
const config = { ...defaults, ...userPrefs };
// { theme: 'dark', language: 'en', debug: false, notifications: true }

// spread: copy and extend arrays
const base = [1, 2, 3];
const extended = [...base, 4, 5]; // [1, 2, 3, 4, 5]

// rest in function params
function sum(...numbers) {
  return numbers.reduce((acc, n) => acc + n, 0);
}
sum(1, 2, 3, 4); // 10
```

## Async / Await

`async`/`await` is syntactic sugar over Promises. It makes asynchronous code read like synchronous code and keeps error handling in familiar `try/catch` blocks.

```js
async function fetchUser(id) {
  try {
    const res = await fetch(`https://api.example.com/users/${id}`);
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    const user = await res.json();
    return user;
  } catch (err) {
    console.error('Failed to load user:', err.message);
    return null;
  }
}

// parallel fetches — don't await sequentially when you don't need to
async function loadDashboard(userId) {
  const [user, posts] = await Promise.all([
    fetchUser(userId),
    fetch(`/api/posts?author=${userId}`).then((r) => r.json()),
  ]);
  return { user, posts };
}
```

Awaiting two independent fetches sequentially doubles your latency. Use `Promise.all` when the requests don't depend on each other.

## Optional Chaining and Nullish Coalescing

These two operators, added in ES2020, eliminate a huge category of defensive boilerplate.

```js
const data = {
  user: {
    profile: {
      avatar: 'https://cdn.example.com/avatars/alice.png',
    },
  },
};

// optional chaining: short-circuits to undefined instead of throwing
const avatar = data?.user?.profile?.avatar;
// 'https://cdn.example.com/avatars/alice.png'

const missing = data?.user?.settings?.theme;
// undefined — no TypeError

// nullish coalescing: falls back only on null/undefined (not 0 or '')
const theme = data?.user?.settings?.theme ?? 'light';
// 'light'

// compare with ||, which also catches falsy values like 0 and ''
const count = 0;
console.log(count || 10);  // 10 — probably wrong
console.log(count ?? 10);  // 0 — correct
```

## Modules

ES modules (`import`/`export`) are the standard way to split code across files, both in browsers and in Node.js (with `"type": "module"` in `package.json` or `.mjs` extensions).

```js
// math.js
export function add(a, b) { return a + b; }
export function subtract(a, b) { return a - b; }
export const PI = 3.14159;

// default export — one per file
export default function multiply(a, b) { return a * b; }

// main.js
import multiply, { add, PI } from './math.js';
// or rename on import
import { add as sum } from './math.js';

console.log(sum(2, 3)); // 5
console.log(multiply(4, PI)); // ~12.57
```

---

These aren't exotic features — they're the everyday vocabulary of modern JavaScript. Getting comfortable with destructuring, array methods, and async/await will make you faster to read and write idiomatic React, Node, and Next.js code, since those ecosystems lean on all of them heavily.


Mastering Modern JavaScript: Patterns You Actually Use


PostgreSQL is the go-to relational database for serious projects. It is ACID-compliant, supports JSON alongside traditional relational data, has one of the richest SQL feature sets of any open-source database, and the community has maintained it reliably for over 25 years. If you are reaching for a database in a Node.js project, Postgres is rarely the wrong choice.

This post covers the essentials: running it locally, core SQL patterns you will use every day, indexing basics, transactions, and connecting from Node.js with the `postgres` package.

## Running Postgres Locally

The fastest path is Docker:

```sh
docker run --name pg-dev \
  -e POSTGRES_USER=dev \
  -e POSTGRES_PASSWORD=secret \
  -e POSTGRES_DB=myapp \
  -p 5432:5432 \
  -d postgres:16
```

Connect with `psql`:

```sh
psql postgres://dev:secret@localhost:5432/myapp
```

## Core SQL Patterns

### Creating a Table

```sql
CREATE TABLE users (
  id         SERIAL PRIMARY KEY,
  email      TEXT NOT NULL UNIQUE,
  name       TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
```

`SERIAL` is shorthand for an auto-incrementing integer. `TIMESTAMPTZ` stores timestamps with a time zone, which is almost always what you want over plain `TIMESTAMP`.

### Inserting Rows

```sql
INSERT INTO users (email, name)
VALUES ('alice@example.com', 'Alice')
RETURNING id, created_at;
```

`RETURNING` hands back the generated values immediately — no need for a second query to get the new `id`.

### Querying

```sql
-- All users created in the past week
SELECT id, email, name
FROM users
WHERE created_at > NOW() - INTERVAL '7 days'
ORDER BY created_at DESC;
```

### Updating and Deleting

```sql
UPDATE users SET name = 'Alicia' WHERE id = 1 RETURNING *;

DELETE FROM users WHERE id = 1;
```

### JOINs

```sql
CREATE TABLE posts (
  id      SERIAL PRIMARY KEY,
  user_id INT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  title   TEXT NOT NULL,
  body    TEXT NOT NULL
);

-- Posts with their author's email
SELECT p.id, p.title, u.email
FROM posts p
JOIN users u ON u.id = p.user_id
WHERE u.email = 'alice@example.com';
```

`ON DELETE CASCADE` means deleting a user automatically deletes their posts — you declare the relationship once in the schema and the database enforces it everywhere.

## Indexes

Postgres creates an index automatically on primary keys and `UNIQUE` columns. For any other column you filter or join on frequently, add one explicitly:

```sql
CREATE INDEX idx_posts_user_id ON posts(user_id);
```

Partial indexes are one of Postgres's killer features — they index only the rows matching a condition, keeping them small and fast:

```sql
-- Only index published posts; unpublished rows are excluded
CREATE INDEX idx_posts_published ON posts(created_at)
WHERE published = TRUE;
```

Check whether your queries are actually using indexes with `EXPLAIN ANALYZE`:

```sql
EXPLAIN ANALYZE
SELECT * FROM posts WHERE user_id = 42;
```

Look for `Index Scan` in the output. `Seq Scan` on a large table is a sign you might need an index.

## Transactions

Wrap multiple operations in a transaction so they either all succeed or all roll back together:

```sql
BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;
```

If anything goes wrong between `BEGIN` and `COMMIT`, issue `ROLLBACK` instead and the database reverts both changes as if neither happened.

## Connecting from Node.js

Install the `postgres` package — a lightweight client that uses tagged template literals:

```sh
npm install postgres
```

Create a single connection module and re-use it across your app:

```js
// db.js
import postgres from 'postgres';

const sql = postgres(process.env.DATABASE_URL, {
  max: 10,          // connection pool size
  idle_timeout: 20, // close idle connections after 20 seconds
});

export default sql;
```

The tagged template literal syntax automatically parameterizes every interpolated value, so SQL injection is not possible:

```js
import sql from './db.js';

export async function getUserByEmail(email) {
  const [user] = await sql`
    SELECT id, name, email
    FROM users
    WHERE email = ${email}
  `;
  return user ?? null;
}

export async function createPost(userId, title, body) {
  const [post] = await sql`
    INSERT INTO posts (user_id, title, body)
    VALUES (${userId}, ${title}, ${body})
    RETURNING *
  `;
  return post;
}
```

Transactions use a callback that receives a scoped `tx` client. If any query inside throws, the whole transaction rolls back automatically:

```js
export async function transferBalance(fromId, toId, amount) {
  await sql.begin(async (tx) => {
    await tx`UPDATE accounts SET balance = balance - ${amount} WHERE id = ${fromId}`;
    await tx`UPDATE accounts SET balance = balance + ${amount} WHERE id = ${toId}`;
  });
}
```

## Environment Variables

Keep connection details out of your source code. A minimal `.env`:

```
DATABASE_URL=postgres://dev:secret@localhost:5432/myapp
```

Load it with `dotenv` in development, or provide it through your hosting platform's secret manager in production. Vercel, Railway, Supabase, and Render all have first-class PostgreSQL support with one-click provisioning.

---

PostgreSQL rewards you the more of it you learn. Once you are comfortable with the patterns here, the next things worth exploring are full-text search with `tsvector`, `JSONB` columns for semi-structured data, window functions, and `COPY` for bulk data imports.


PostgreSQL for Node.js Developers: A Practical Guide


RustDesk is an open-source remote desktop application written in Rust. Out of the box it connects through RustDesk's public relay infrastructure — fine for getting started, but that means your screen data passes through someone else's servers. Self-hosting changes that: all traffic relays through hardware you control, nothing leaves your network without your permission, and you can drop the paid subscription entirely.

The server is two small stateless binaries you can run comfortably on the same VPS or LXC container that hosts anything else in your homelab.

## How the Server Works

RustDesk splits the server side into two roles:

- **`hbbs`** (the ID / rendezvous server) — handles peer discovery. Devices register here so they can find each other, and it coordinates the initial NAT-traversal handshake.
- **`hbbr`** (the relay server) — when a direct peer-to-peer connection fails (most NAT combinations), traffic flows through here.

Both are shipped in a single Docker image; you just pass a different command to each container.

## Port Requirements

Open these on your server's firewall before starting the containers:

| Port | Protocol | Service |
|------|----------|---------|
| 21115 | TCP | hbbs — NAT-type test |
| 21116 | TCP + UDP | hbbs — ID/rendezvous |
| 21117 | TCP | hbbr — relay traffic |
| 21118 | TCP | hbbs — WebSocket (web client only) |
| 21119 | TCP | hbbr — WebSocket (web client only) |

Ports 21118 and 21119 are only needed if you want browser-based access. The native desktop client needs only 21115–21117.

## Docker Compose Setup

Create a working directory and add a `docker-compose.yml`:

```bash
mkdir -p ~/rustdesk/data && cd ~/rustdesk
```

```yaml
services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    command: hbbs
    ports:
      - "21115:21115"
      - "21116:21116"
      - "21116:21116/udp"
      - "21118:21118"
    volumes:
      - ./data:/root
    restart: unless-stopped
    depends_on:
      - hbbr

  hbbr:
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - "21117:21117"
      - "21119:21119"
    volumes:
      - ./data:/root
    restart: unless-stopped
```

Both services share the same `./data` volume so they read the same keypair. Bring it up:

```bash
docker compose up -d
docker compose logs -f
```

On first start, `hbbs` generates an Ed25519 keypair inside `./data/`. Watch the logs until both services print `Listening on` before configuring any clients.

## Grabbing the Public Key

Your clients need the server's public key to verify they're talking to *your* server and not a rogue relay.

```bash
cat ~/rustdesk/data/id_ed25519.pub
```

This prints a single line of base64 text — copy it. You'll paste it into each client's settings in a moment. Keep `id_ed25519` (the private key, no `.pub`) secret and backed up; losing it means all existing clients need to be re-keyed.

## Firewall Rules

If you're using `ufw`:

```bash
sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
# Only needed for browser-based access:
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp
sudo ufw reload
```

For `firewalld` (Rocky Linux / Fedora):

```bash
sudo firewall-cmd --permanent --add-port=21115-21119/tcp
sudo firewall-cmd --permanent --add-port=21116/udp
sudo firewall-cmd --reload
```

If your server is behind a cloud provider (AWS, Hetzner, DigitalOcean), also open the same ports in the provider's security group or firewall panel — `ufw` alone isn't enough if the provider has its own layer.

## Configuring the RustDesk Client

Install the RustDesk desktop client on each machine you want to control or connect from. Then:

1. Open RustDesk → click the three-dot menu (top-right) → **Settings** → **Network**.
2. Unlock the panel if prompted.
3. Under **ID/Relay Server**, fill in:
   - **ID Server**: your server's IP address or hostname
   - **Relay Server**: same as above (can leave blank if identical to ID Server)
   - **Key**: paste the full contents of `id_ed25519.pub`
4. Click **OK**. RustDesk reconnects and registers a fresh ID against your server.

Both the machine you're controlling *from* and the remote machine need to point at the same server. On a LAN you can use the private IP; for internet access use the public IP or a DNS record you control.

## Verifying It Works

On the remote machine, note the RustDesk ID shown in the main window. On the controlling machine, type that ID into the Connect field and hit Enter. If the server is configured correctly the handshake completes in a second or two and you'll see the remote desktop.

Check relay logs if connections are slow or fail:

```bash
docker compose logs hbbr --since=5m
```

You should see `[relay] ...` lines appearing as connections negotiate. If you see nothing at all, the client is probably still hitting RustDesk's public servers — double-check the Key field was saved.

## A Note on Security

The **Key** field is the critical security control. Without it, anyone who discovers your server's IP can use your relay for free. With it, only clients that present the matching key are accepted.

Do not put these ports behind Nginx or Traefik — the RustDesk native client doesn't speak HTTP, so a reverse proxy can't terminate its connections. Direct port exposure on the server is the correct setup. If you want TLS, RustDesk Pro supports it; the open-source version does not.

## Wrapping Up

Two containers, a handful of firewall rules, a public key distributed to your clients — that's the entire setup. I run my RustDesk server on the same small VPS as my n8n instance; together they use less than 50 MB of RAM at idle. No monthly fee, no third-party relay, full control over who can connect and when.

For personal and homelab use the open-source version above covers everything. If you need centralized user management, audit logs, and a web console, RustDesk also offers a self-hosted Pro tier — but start here first and upgrade only if you actually hit a limit.


Self-Hosting RustDesk: A Private Remote Desktop Server in Under 10 Minutes


The Next.js Pages Router has served the community well since the beginning — file-based routing, `getServerSideProps`, `getStaticProps`, and a simple `pages/api/` folder for backend logic. But since Next.js 13, the framework has been moving toward a new paradigm: the **App Router**.

If you're still on the Pages Router (or just starting out), this post breaks down what actually changed, why it matters, and how to start using the new patterns today.

## The Core Shift: React Server Components

The App Router is built on **React Server Components (RSC)**. Every component in the `app/` directory is a Server Component by default, which means:

- It renders on the server and ships **no JavaScript to the browser**
- It can `async/await` directly — no `useEffect` + `useState` dance to load data
- It can safely import Node.js modules, access databases, and read the filesystem

This flips the old model on its head. Instead of fetching at the page level with `getServerSideProps` and threading props down through every layer, you fetch right where the data is consumed.

### Pages Router (old)

```typescript
// pages/posts/[slug].tsx
export async function getServerSideProps(context) {
  const { slug } = context.params;
  const post = await fetchPostFromDB(slug);
  return { props: { post } };
}

export default function PostPage({ post }) {
  return <article><h1>{post.title}</h1></article>;
}
```

### App Router (new)

```typescript
// app/posts/[slug]/page.tsx
async function getPost(slug: string) {
  const post = await fetchPostFromDB(slug);
  return post;
}

export default async function PostPage({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <article><h1>{post.title}</h1></article>;
}
```

No export ceremony, no props threading — just `async/await` directly in the component.

## New File Conventions

The `app/` directory introduces special filenames that map to specific behaviors:

| File | Purpose |
|------|---------|
| `page.tsx` | The UI for a route (replaces `pages/foo.tsx`) |
| `layout.tsx` | Persistent wrapper for a segment and its children |
| `loading.tsx` | Automatic Suspense fallback while the page loads |
| `error.tsx` | Error boundary for the segment |
| `not-found.tsx` | 404 UI for the segment |
| `route.ts` | API endpoint (replaces `pages/api/foo.ts`) |

A typical blog structure looks like this:

```
app/
  layout.tsx          ← root layout, wraps every page
  page.tsx            ← home page (/)
  posts/
    page.tsx          ← posts list (/posts)
    [slug]/
      page.tsx        ← individual post (/posts/my-post)
      loading.tsx     ← shown while post data fetches
```

## Layouts: No More `_app.js`

In the Pages Router, `_app.js` was the place to wrap every page with a shared shell. The App Router replaces this with **nested `layout.tsx` files**.

```typescript
// app/layout.tsx
export const metadata = {
  title: 'My Blog',
  description: 'Writing about React and beyond.',
};

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <nav>My Site</nav>
        <main>{children}</main>
        <footer>© 2026</footer>
      </body>
    </html>
  );
}
```

Layouts are **persistent** — they don't remount when you navigate between pages in the same segment. This is great for sidebar state, scroll position, or any component that's expensive to re-initialize.

You can also nest layouts: `app/dashboard/layout.tsx` wraps only the `/dashboard/*` routes without affecting anything outside.

## When to Use `"use client"`

Server Components can't use browser APIs, React hooks (`useState`, `useEffect`, `useRef`), or event listeners. When you need any of those, add `"use client"` as the first line of the file:

```typescript
'use client';

import { useState } from 'react';

export function LikeButton({ postId }: { postId: string }) {
  const [liked, setLiked] = useState(false);

  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? 'Liked' : 'Like'}
    </button>
  );
}
```

The pattern that works best: keep the page itself a Server Component for data fetching, then pass data down to small Client Components that handle interactivity. Push `"use client"` as far down the tree as possible — this keeps the client bundle small.

## Route Handlers Replace API Routes

`pages/api/hello.ts` becomes `app/api/hello/route.ts` with named HTTP method exports:

```typescript
// app/api/hello/route.ts
import { NextResponse } from 'next/server';

export async function GET() {
  return NextResponse.json({ message: 'Hello from the App Router' });
}

export async function POST(request: Request) {
  const body = await request.json();
  return NextResponse.json({ received: body });
}
```

Named exports per method make the intent clear and remove the `if (req.method === 'POST')` branching that cluttered old API routes.

## Should You Migrate?

If you're starting a new project today, use the App Router — it's the default when you run `create-next-app`. For existing apps, migration can be **incremental**: the `app/` and `pages/` directories can coexist in the same project while you transition route by route.

Start with the routes that benefit most:

- Pages with heavy server-side data fetching (RSC eliminates the `getServerSideProps` + props threading)
- Any shared chrome currently in `_app.js` (move it to `app/layout.tsx`)
- Pages where you want streaming — `loading.tsx` gives you a Suspense boundary for free

The App Router has a steeper learning curve than the Pages Router, but once the Server Component mental model clicks — *the server is where data lives, the client is where interaction lives* — the code becomes noticeably simpler and the bundle stays lean.


Next.js App Router: What Changed and Why It Matters


I avoided TypeScript in my React projects longer than I should have. The error messages looked cryptic, the setup seemed heavy, and I already had PropTypes. Then a junior dev introduced a subtle prop-shape bug that took three hours to track down — a bug TypeScript would have caught at save time. I've typed my React ever since.

This post skips the philosophy and goes straight to the five patterns I reach for every day.

## 1. Typing component props with an interface

The most common thing you'll type is a component's props. Define an interface just above the component and pass it as the generic argument to `React.FC`, or just annotate the destructured parameter directly — the second approach is less noisy:

```tsx
interface ButtonProps {
  label: string;
  onClick: () => void;
  disabled?: boolean; // optional — note the '?'
  variant?: 'primary' | 'secondary'; // union type keeps valid values explicit
}

export function Button({ label, onClick, disabled = false, variant = 'primary' }: ButtonProps) {
  return (
    <button
      className={`btn btn-${variant}`}
      onClick={onClick}
      disabled={disabled}
    >
      {label}
    </button>
  );
}
```

The union type `'primary' | 'secondary'` is more useful than `string`. Passing `variant="danger"` now gives a compile-time error instead of a silent style mismatch at runtime.

## 2. useState with generics

`useState` infers its type from the initial value, which works fine for primitives. Where it breaks down is when the initial value is `null` or an empty array, because the inferred type becomes `null` or `never[]` and TypeScript won't let you assign anything real to it later.

Fix this by passing the type explicitly:

```tsx
// Bad — TypeScript infers the type as `null` only, so setUser won't accept a User object
const [user, setUser] = useState(null);

// Good — TypeScript knows it's User | null from the start
interface User {
  id: number;
  name: string;
  email: string;
}

const [user, setUser] = useState<User | null>(null);
const [items, setItems] = useState<string[]>([]);
```

With the typed version, `setUser({ id: 1, name: 'Alice', email: 'alice@example.com' })` compiles cleanly, and `setUser({ id: 1, username: 'alice' })` (wrong shape) errors immediately.

## 3. Event handler types

Event types in React are namespaced under `React`. The ones I use constantly:

```tsx
function SearchBox() {
  const [query, setQuery] = useState('');

  // React.ChangeEvent<HTMLInputElement> is the type of the onChange event
  function handleChange(e: React.ChangeEvent<HTMLInputElement>) {
    setQuery(e.target.value);
  }

  // React.FormEvent<HTMLFormElement> for form submit
  function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault();
    console.log('Searching for:', query);
  }

  return (
    <form onSubmit={handleSubmit}>
      <input value={query} onChange={handleChange} />
      <button type="submit">Search</button>
    </form>
  );
}
```

The pattern is always `React.<EventType><HTMLElement>`. A few to memorise:

| Event | HTML element | Type |
|---|---|---|
| `onChange` | `<input>` | `React.ChangeEvent<HTMLInputElement>` |
| `onChange` | `<select>` | `React.ChangeEvent<HTMLSelectElement>` |
| `onSubmit` | `<form>` | `React.FormEvent<HTMLFormElement>` |
| `onClick` | anything | `React.MouseEvent<HTMLButtonElement>` |
| `onKeyDown` | anything | `React.KeyboardEvent<HTMLInputElement>` |

## 4. Typing API responses

A common mistake is leaving `fetch` response data as `any`. That defeats the whole point. Define an interface that mirrors the API shape and cast once at the boundary:

```tsx
interface Post {
  id: number;
  title: string;
  body: string;
  userId: number;
}

async function fetchPost(id: number): Promise<Post> {
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${id}`);
  if (!res.ok) throw new Error(`HTTP error: ${res.status}`);
  return res.json() as Promise<Post>;
}

// In a component:
function PostDetail({ id }: { id: number }) {
  const [post, setPost] = useState<Post | null>(null);

  useEffect(() => {
    fetchPost(id).then(setPost);
  }, [id]);

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

  return <h2>{post.title}</h2>; // TypeScript knows post.title is a string
}
```

The `as Promise<Post>` cast on `res.json()` is the one spot where you're trusting the server. If the shape changes, you only have one place to update.

## 5. Typing custom hooks

Custom hooks are where TypeScript earns its keep most clearly, because the return type becomes part of the hook's public API.

```tsx
interface UseFetchResult<T> {
  data: T | null;
  loading: boolean;
  error: string | null;
}

function useFetch<T>(url: string): UseFetchResult<T> {
  const [data, setData] = useState<T | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    setLoading(true);
    fetch(url)
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json() as Promise<T>;
      })
      .then((json) => {
        setData(json);
        setLoading(false);
      })
      .catch((err: Error) => {
        setError(err.message);
        setLoading(false);
      });
  }, [url]);

  return { data, loading, error };
}

// Usage — TypeScript knows posts is Post[] | null
const { data: posts, loading } = useFetch<Post[]>('/api/posts');
```

The generic `<T>` makes the hook reusable: call it once for posts, once for users, once for anything — and each callsite gets fully typed data back.

## Where to go from here

These five patterns cover the majority of TypeScript I write in day-to-day React work. Once they feel automatic, the natural next step is `React.ReactNode` and `React.PropsWithChildren` for components that render children, and `useReducer` with a discriminated union for complex state. But honestly, mastering props, state, events, API data, and custom hooks will make you more productive with TypeScript in React than reading any amount of theory.

Start by converting your next new component with typed props. The immediate feedback loop — catching a wrong prop type before you ever run the code — is what converts sceptics.


TypeScript in React: Practical Typing Patterns That Actually Help


For years the glue holding my homelab together was a folder of shell scripts and cron jobs. They worked until they didn't, and when one failed silently at 3am I usually found out days later. [n8n](https://n8n.io) replaced almost all of it. It's a self-hosted workflow automation tool where each automation is a graph of nodes you can see, run step by step, and inspect — and because I host it myself, my data never leaves the lab.

In this post I'll show how I run n8n in Docker and walk through a small but genuinely useful workflow: a webhook that receives an event, shapes the data in a Code node, and fires a notification.

## Running n8n in Docker

n8n ships an official image, so it slots right into the Compose-based setup I use for everything else. Here's a minimal, current configuration:

```yaml
services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - '5678:5678'
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - GENERIC_TIMEZONE=America/Chicago
      - TZ=America/Chicago
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:
```

Two settings matter more than they look. **`WEBHOOK_URL`** tells n8n the public URL to advertise for incoming webhooks — get this wrong and the URLs it generates won't be reachable from outside. And **`GENERIC_TIMEZONE`** makes the Schedule node fire when you expect it to, instead of in UTC. The `n8n_data` volume persists your credentials and workflows, so a container rebuild doesn't wipe your work.

On first launch n8n walks you through creating an owner account via its built-in user management — no extra auth wiring needed.

## A real workflow: webhook → transform → notify

My most-used pattern is dead simple: something happens, n8n catches it on a webhook, reshapes the payload, and pushes a notification. Here's the shape of it.

**1. The Webhook node.** Add a Webhook node, set the method to `POST`, and give it a path like `deploy-finished`. n8n hands you a test URL and a production URL. Anything that can make an HTTP request can now trigger the workflow:

```bash
curl -X POST https://n8n.example.com/webhook/deploy-finished \
  -H 'Content-Type: application/json' \
  -d '{"service":"blog","status":"success","duration":42}'
```

Inside n8n, the incoming request shows up as a single item whose `json` holds the parsed `body`, plus `headers` and `query`.

**2. The Code node.** This is where n8n earns its keep. The Code node runs JavaScript over the items flowing through it. In "Run Once for All Items" mode you read the input with `$input.all()` and return an array of items, each wrapped in a `json` key:

```javascript
// Code node — shape the incoming webhook into a clean message
const items = $input.all();

return items.map((item) => {
  const { service, status, duration } = item.json.body;
  const emoji = status === 'success' ? '✅' : '❌';

  return {
    json: {
      message: `${emoji} Deploy of ${service} ${status} in ${duration}s`,
    },
  };
});
```

That contract — `$input.all()` in, an array of `{ json: ... }` out — is the whole mental model for the Code node. Once it clicks, you can do almost any transformation without leaving the editor.

**3. The notification.** Wire the Code node into whatever you use to be reached. I send a request to a self-hosted [ntfy](https://ntfy.sh) instance with an HTTP Request node, posting `{{ $json.message }}` as the body. When the deploy webhook fires, the phone in my pocket buzzes with the formatted line.

## Why this beats cron scripts

The thing I didn't expect was how much the *visibility* would matter. Every execution is recorded: I can open a run, click any node, and see exactly what data went in and came out. When something breaks, I'm not guessing — I'm looking at the failed item. n8n can also retry failed executions and email me when a workflow errors, which is the silent-failure problem solved outright.

It's also composable in a way scripts never were. The same `deploy-finished` webhook now branches: it notifies me *and* writes a row to Postgres for a little deploy-history dashboard. Adding that branch was dragging out one more node, not rewriting a script.

## Where I'd start

If you want to try this, host n8n with the Compose snippet above, then build the smallest workflow that removes a real annoyance — a webhook that pings you when a backup finishes, say. Get one end-to-end automation working and inspectable, and you'll start seeing candidates for it everywhere. My cron folder has been shrinking ever since.


Automating My Homelab with n8n


Everything in my homelab runs in Docker, and the whole thing is described by a handful of `docker-compose.yml` files I keep in a private Git repo. That one decision — treating my infrastructure as code instead of a pile of hand-installed packages — is the single biggest reason the lab has stayed reliable. When a disk dies or I rebuild a host, I'm back online in minutes because the *definition* of the stack lives in version control, not in my head.

In this post I'll walk through the patterns I actually use: a real Compose file, healthchecks that keep things honest, named volumes for persistence, and a backup approach that runs itself.

## Why Compose instead of `docker run`

You *can* start a container with a long `docker run` command. The problem is that the command is ephemeral — six months later you won't remember the exact flags, ports, and env vars you used. Compose turns all of that into a declarative file you can read, diff, and roll back.

A small, real example: Postgres plus a lightweight admin UI.

```yaml
services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: app
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U app -d app']
      interval: 10s
      timeout: 5s
      retries: 5

  adminer:
    image: adminer:4
    restart: unless-stopped
    ports:
      - '8080:8080'
    depends_on:
      db:
        condition: service_healthy

volumes:
  db_data:
```

A few things I want to call out, because they're the parts people skip:

- **`restart: unless-stopped`** means the container comes back after a reboot or a crash, but stays down if I deliberately stopped it. It's the sane default for a homelab.
- **The named volume `db_data`** is where the actual database lives. Containers are disposable; the volume is not. I can `docker compose down`, pull a new image, and `up` again without losing a row.
- **The healthcheck** makes `depends_on ... condition: service_healthy` meaningful. Adminer won't start hammering Postgres until `pg_isready` actually succeeds, which avoids a noisy race on cold boot.

## Keep secrets out of the file

Notice `${DB_PASSWORD}` above. Compose reads variables from a `.env` file sitting next to the Compose file:

```bash
# .env  — never committed
DB_PASSWORD=correct-horse-battery-staple
```

I commit the `docker-compose.yml` and a `.env.example` with placeholder values, but the real `.env` is gitignored. That way the repo is safe to clone and nothing sensitive ever lands in history.

## Running it

The commands I use day to day are boring, which is exactly what you want from infrastructure:

```bash
# start everything in the background
docker compose up -d

# see what's running and whether healthchecks pass
docker compose ps

# tail logs for one service
docker compose logs -f db

# pull newer images and recreate changed containers
docker compose pull && docker compose up -d
```

That `pull && up -d` line is my entire update routine. Compose only recreates containers whose image actually changed, so updates are fast and low-drama.

## Backups that run themselves

A homelab without backups is just a countdown. For Postgres I run a nightly `pg_dump` straight into the same volume layout, then sync the dump offsite. The trick is to exec into the *already running* container so you don't need a second Postgres install:

```bash
#!/usr/bin/env bash
set -euo pipefail
stamp=$(date -u +%F)
docker compose exec -T db \
  pg_dump -U app -d app | gzip > "/srv/backups/app-${stamp}.sql.gz"

# keep the last 14 days, delete the rest
find /srv/backups -name 'app-*.sql.gz' -mtime +14 -delete
```

Drop that in `/etc/cron.daily` (or a systemd timer) and you have point-in-time recovery you never have to remember to run. I test a restore every few months by piping a dump into a throwaway container — an untested backup isn't a backup.

## What this buys you

The payoff is repeatability. My hosts are essentially cattle: a fresh Debian install, Docker, `git clone`, drop in the `.env`, and `docker compose up -d`. Everything that makes the machine *mine* is in those files. Adding a new service is a pull request to myself; removing one is deleting a block of YAML.

If you're starting your own lab, resist the urge to install things directly on the host. Put it in Compose, commit it, give it a healthcheck and a named volume, and let your future self thank you the next time hardware fails.


Self-Hosting a Homelab with Docker Compose

User Authorization with Firebase Walkthrough


## What is an Webpack?

- Webpack lets you code using the different filetypes and dependencies that your compfortable with and converts them to into the static assets that your browser prefers.
- When building an APP we typically will see two folders
  - SRC
    - This folder has all the working files that we will edit during the development process
  - DIST
    - This folder holds all the static assets after the BUILD process has been ran

### Other Types of Module Bundlers

- Snowpack
- Rollup
- Parcel

## Webpack Installation

- When NOT using a tool, such a Create React App, we can manually install webpack into our workspace by add these two commands.
  1. Initialize npm
     `npm init -y`
  2. Install webpack developer dependency
     `npm i -D webpack`
  3. Install webpack-cli developer dependency
     `npm i -D webpack-cli`
  4. [optional] Verify installation went well, check package.json devDependencies

## How to setup the run script

- Inside our our package.json we can setup our scripts next to run our app
  - Add "build": "webpack --mode production"
  - Now this will generate a new file main.js that takes our application and MINIFYS it and makes it CROSS-BROWSER-COMPATIBLE
  - Confirm your index.html is referencing our new file, main.js
  - We can now view the page and our app should be running
  - _Production will generate less code than development_

## Webpack Config

### Webpack Config Setup

- Create webpack.config.js in your root folder
- Use standard JS code only
- If we add mode development to our config file, we can remove that flag from our build script in our package.json
- Add const path = require('path') to allow us to use \_\_dirname
  `const path = require('path')`
- Add src/index.js as our entry
  `src/index.js`
- Add bundle.js as our filename

### Rebuild AFTER new Webpack Config

- Now we can delete our main.js file from our dist folder, our old build file
  `npm run build`
- Now bundle.js will be generated now in the dist folder
- Lastly update index.html to have bundle.js instead of main
- Sometimes you will see the entry as an OBJECT
  - You can see multiple entries and this is called code splitting
    - In this instance it is best to change the output file name to by dynamic so instead of `bundle.js` you might see `[name].js`

### Webpack Config Example

```
const path = require('path')

module.exports = {
  mode: "development",
  entry: path.resolve(__dirname, 'src/index.js')
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
}
```

## Adding Sass to be compiled by Webpack

- Sass can be easily added to Webpack by adding loaders.

### Installation and Setup of Loaders

- First we want to import Sass and our 3 loader packages, I prefer NPM.
  `npm i -D sass style-loader css-loader sass-loader`
- In src folder lets create a styles folder
- Add main.scss file and some css to test
- Now we can import to our _index.js_ file by adding _import './styles/main.scss'_
- We CANNOT run the build yet as we don't have loaders setup
- Inside our webpack config file, after our output we can add a modules object
  - Inside we will add a rules array
  - Inside that array we will add an object with
    _test: /\.scss$/,_
  - add ``use:['style-loader', 'css-loader', 'sass-loader',]

### Updated module Exports

```
module.exports = {
  mode: "development",
  entry: path.resolve(__dirname, 'src/index.js')
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
  modules: {
    rules: [
      {
        test: /\.scss$/,
        use:['style-loader', 'css-loader', 'sass-loader'
      }
    ]
  }
}
```

## Plugins are great

- Plugins are great in that they allow us to just delete our _dist_ folder and _npm run build_ without having to go in and modify our index.html file manually

### HTML Webpack Plug-in Setup

- Install the devDependency first `npm i -D html-webpack-plugin`
- Import to your webpack config file `const HtmlWebpackPlugin = require('html-webpack-plugin')`
- Add underneath the module object next a _plugins_ array
  - add newHtmlWebpackPlugin()
    - title: 'webpack a filename'
    - filename: 'index.html'

```
plugins: [
    new HtmlWebpackPlugin({
      title: 'Webpack A Title',
      filename: 'index.html'
    })
```

- Now we can DELETE our dist folder completely
- Whenever we run _npm run build_ we will generate a new dist folder
- This mean we can never modify the DIST files directly moving forward as they will be overridden,

### Updated Example with Plug-Ins

```js
const path = require('path')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  mode: "development",
  entry: path.resolve(__dirname, 'src/index.js')
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].js',
  },
  modules: {
    rules: [
      {
        test: /\.scss$/,
        use:['style-loader', 'css-loader', 'sass-loader'
      }
    ]
  }
  plugins: [
    new HtmlWebpackPlugin({
      title: 'Webpack A Title',
      filename: 'index.html'
    })
  ]
}
```

## What are Templates?

- Templates allow us to have a base index.html file that our build file will process each time its ran so you can have code that isn't removed
- Normally we copy our index.html file and paste into our template.html file inside our root
- Add templates underneat our filename inside our 'html-webpack-plugin' plugin in our config
  `template: template.html`
- Now we can add _<%= htmlWebpackPlugin.options.title %>_
- Now this file dynamic data is being imported form our config file and generated on build!

## Generating Hashes and Caching

- If we want to utilizing caching or add hash IDs to our generated filename so our browsers no when the content is update its quite easy.
  - Simply add contenthash to your output filename in the config file
  - Delete dist folder again:
    `npm run build`
  - Now we will see our bundle with an appended hash

### Hash/Caching Example

```
module.exports = {
mode: "development",
    entry: {
      bundle: path.resolve(__dirname, 'src/index.js')
    },
    output: {
      path: path.resolve(__dirname, 'dist'),
      filename: '[name][contenthash].js',
},
```

## Adding Development Script

- Lets add different flags for our development or production builds
- Development allows you to build after each change and is quicker for development
- Inside our scripts object in our package.json, lets add:
  `'dev': 'webpack serve'`
- Now if we go to terminal:
  `npm run dev`
  - We may get a prompt to install webpack-dev-server, install it
  - go to localhost:8080 to see our dev server running

## Adding devServer to config and options

- After output add devServer
- port specifies port
- open auto opens browser upon run of script
- hot will auto reload upon save
- compress will use g-zip compression
- historyApiFallback allows history from previous runs for testing
- localhost:3000 is the new address

### Updated with devServer

```
  module.exports = {
    mode: "development",
    entry: {
      bundle: path.resolve(__dirname, 'src/index.js')
    },
    output: {
      path: path.resolve(__dirname, 'dist'),
      filename: '[name][contenthash].js',
      clean: 'true',
    },
    devServer: {
      static: {
        directory: path.resolve(__dirname, 'dist')
      },
      port: 3000,
      open: true,
      hot: true,
      compress: true,
      historyApiFallback: true,
    },
      modules: {
        rules: [
          {
            test: /\.scss$/,
            use:['style-loader', 'css-loader', 'sass-loader'
          }
        ]
      }
      plugins: [
        new HtmlWebpackPlugin({
          title: 'Webpack A Title',
          filename: 'index.html'
        })
      ]
    }
```

### Removing old builds

- With each new build a new bundle file is generated and can easily make your app bloated in filesize
- We can add **clean: true** to our output in the webpack config file
- Now when we _npm run build_ our bundle file is replaced now instead of creating another each time and keeping the old.

### Adding Babbel loader to make your code backwards compatible with older browsers

- Installation:
  `npm i -D babel-laoder @babel/core @babel/preset-env`
- Verify success in our package.json
- Add to webpack config next
- inside module, inside rules after the first object with our .scss entry
- Add the code below and exclude our node modules folder

### Add babel to webpack

```
test: /\.js$/,
exclude: /node_modules/,
use: {
  loader: 'babel-loader',
  options: {
    presets: ['@babel/preset-env']
  }
}
```

### Adding Assets Loader

- First put an asset in our assets folder inside src folder
- Add to webpack config next
  - Inside module, inside rule normally after the babel loader
  - Add _assetModuleFilename: '[name][ext]'_ inside our output of our webpack config
  - now if we add npm run build our asset will be generated inside our dist folder!

### Asset Loader Example

```
test: /\.(png|svg|jpeg|jpg|gif)$/i,
type: 'asset/resource'
```

## Notable Information

- Any NPM module can be installed and used with Webpack bundling
- Add _devtool: source-map_ to generate source bundle for debugging
- install _npm i -D webpack-bundle-analyzer_ and add to config file to get a complete overview if the WHOLE bundle if your app
  - Add to webpack config file

Information Sourced from: [Webpack-5-Crash-Course](https://www.youtube.com/watch?v=IZGNcSuwBZs)


What is Webpack 5 and Module Bundling


## What is Helper file?

One of the well known conventions of React components is that any logic should be broken out of the render function into a helper function. This keeps the component clean, and separates the concerns inside of the component.

![Helper Files](helper-main.png)

## Documentation.

- Referenced Documentation [here](https://www.jsmount.com/how-to-create-a-common-helper-class-or-util-file-in-react-js/)

## Usage

This file contains all utility exposed functions and directly available into other classes and components.
Here we need to expose every function which we want to use outside while in the Helper Class file we don’t expose methods directly, we expose only class.

We can create multiple util files as well as per our code structure.

### Basic Util

```js
export function addTwoNumber(number1, number2) {
  return number1 + number2;
}
export function getUserName() {
  return 'JS Mount';
}
export function getNameArray() {
  const data = [];
  for (let i = 0; i < 50; i++) {
    data.push('JS-' + i);
  }
  return data;
}
```

### Usage of Basic Util

```jsx
import React from 'react';
import { addTwoNumber, getUserName, getNameArray } from './../../util/util';
const ComponentA = (props) => {
  return (
    <>
      <h3>Welcome to Router Component A</h3>
      <h6>Called util function: Username is {getUserName()}</h6>
      <h6>Sum of two number (3,4) using util.js - {addTwoNumber(3, 4)}</h6>
      Total Names: {getNameArray().length}
      <ul>
        {getNameArray().map((name) => {
          return <li>{name}</li>;
        })}
      </ul>
    </>
  );
};
export default ComponentA;
```

## More Helper Patterns

### DB-util

```js
import { MongoClient } from 'mongodb';

const dbusername = process.env.mongodb_username;
const dbpassword = process.env.mongodb_password;
const dbconnection = '@cluster0.ewevp.mongodb.net/';
const dbname = 'nextEvents';
const dbprefix = 'mongodb+srv://';

export async function connectToDatabase() {
  const client = await MongoClient.connect(
    `${dbprefix}${dbusername}:${dbpassword}${dbconnection}${dbname}`
  );

  return client;
}

export async function insertDocument(client, collection, document) {
  const db = client.db();

  const result = await db.collection(collection).insertOne(document);

  return result;
}

export async function getAllDocuments(client, collection, sort, filter) {
  const db = client.db();

  const documents = await db
    .collection(collection)
    .find(filter)
    .sort(sort)
    .toArray();

  return documents;
}
```

### Usage of DB-util

```js
import {
  connectToDatabase,
  insertDocument,
  getAllDocuments,
} from '../../../helpers/db-util';

async function handler(req, res) {
  const eventId = req.query.eventId;

  let client;

  try {
    client = await connectToDatabase();
  } catch (error) {
    res.status(500).json({ message: 'Connecting to the database failed!' });
    return;
  }

  if (req.method === 'POST') {
    const { email, name, text } = req.body;

    if (
      !email.includes('@') ||
      !name ||
      name.trim() === '' ||
      !text ||
      text.trim() === ''
    ) {
      res.status(422).json({ message: 'Invalid input.' });
      client.close();
      return;
    }

    const newComment = {
      email,
      name,
      text,
      eventId,
    };

    let result;

    try {
      result = await insertDocument(client, 'comments', newComment);
      newComment._id = result.insertedId;
      res.status(201).json({ message: 'Added comment.', comment: newComment });
    } catch (error) {
      res.status(500).json({ message: 'Inserting comment failed!' });
    }
  }

  if (req.method === 'GET') {
    try {
      const documents = await getAllDocuments(
        client,
        'comments',
        { _id: -1 },
        { eventId: eventId }
      );
      res.status(200).json({ comments: documents });
    } catch (error) {
      res.status(500).json({ message: 'Getting comments failed.' });
    }
  }

  client.close();
}

export default handler;
```

### API-util

```js
export async function getAllEvents() {
  const response = await fetch(
    'https://next-js-course-9dc05-default-rtdb.firebaseio.com/events.json'
  );
  const data = await response.json();

  const events = [];

  for (const key in data) {
    events.push({
      id: key,
      ...data[key],
    });
  }

  return events;
}

export async function getFeaturedEvents() {
  const allEvents = await getAllEvents();
  return allEvents.filter((event) => event.isFeatured);
}

export async function getEventById(id) {
  const allEvents = await getAllEvents();
  return allEvents.find((event) => event.id === id);
}

export async function getFilteredEvents(dateFilter) {
  const { year, month } = dateFilter;

  const allEvents = await getAllEvents();

  let filteredEvents = allEvents.filter((event) => {
    const eventDate = new Date(event.date);
    return (
      eventDate.getFullYear() === year && eventDate.getMonth() === month - 1
    );
  });

  return filteredEvents;
}
```

### Usage of API-util

```jsx
import { Fragment } from 'react';
import { useRouter } from 'next/router';
import Head from 'next/head';

import { getAllEvents } from '../../helpers/api-util';
import EventList from '../../components/events/event-list';
import EventsSearch from '../../components/events/events-search';

function AllEventsPage(props) {
  const router = useRouter();
  const { events } = props;

  function findEventsHandler(year, month) {
    const fullPath = `/events/${year}/${month}`;

    router.push(fullPath);
  }

  return (
    <Fragment>
      <Head>
        <title>All Events</title>
        <meta
          name="description"
          content="Find a lot of great events that allow you to evolve..."
        />
      </Head>
      <EventsSearch onSearch={findEventsHandler} />
      <EventList items={events} />
    </Fragment>
  );
}

export async function getStaticProps() {
  const events = await getAllEvents();

  return {
    props: {
      events: events,
    },
    revalidate: 60,
  };
}

export default AllEventsPage;
```

## Noteables

- Remember to create UTIL files early as it can save you time and headache!

Learn more about it [here](https://v4.mui.com/styles/api/#makestyles-styles-options-hook)


Helper Files or Utils


## What is Material-UI?

![Material-UI](mui-main.png)

Material-UI | React components for faster and easier web development. Build your own design system, or start with Material Design.

## Documentation.

- NPM Package [here](https://www.npmjs.com/package/@material-ui/core)
- Documentation Referenced [here](https://v4.mui.com/styles/api/#makestyles-styles-options-hook)

Sometimes we want to to make our own unique styles, Material-UI styled components is a popular method to create your own components styles.

Material-UI lets you create styled compononents with their makeStyle() method.

1.  Import makeStyles
2.  Create useStyles object before main function
3.  Inside our function we can bind useStyles to a variable
4.  Then we can tap into that variable like the example below with ``className={classes.title}``

## NPM Installation

``npm install @material-ui/core``


```
import {makesStyles} from '@material-ui/core'

const useStyles = makeStyles(() => ({
  title: {
    flex: 1,
    color: 'gold',
    fontFamily: 'Montserrat',
    fontWeight: 'bold',
    cursor: 'pointer',
  },
}));

const Header = () => {
  const classes = useStyles();
  const navigate = useNavigate();

  const { currency, setCurrency } = CryptoState();

  const darkTheme = createTheme({
    palette: {
      primary: {
        main: '#fff',
      },
      type: 'dark',
    },
  });
  return (
    <ThemeProvider theme={darkTheme}>
      <AppBar color="transparent" position="static">
        <Container>
          <Toolbar>
            <Typography
              variant="h6"
              onClick={() => {
                navigate('/');
              }}
              className={classes.title}
            >
              Crypto Hunter
            </Typography>
            {/* <Button color="inherit">Login</Button> */}
            <Select
              variant="outlined"
              labelId="demo-simple-select-label"
              id="demo-simple-select"
              value={currency}
              style={{ width: 100, height: 40, marginLeft: 15 }}
              onChange={(e) => setCurrency(e.target.value)}
            >
              <MenuItem value={'USD'}>USD</MenuItem>
              <MenuItem value={'INR'}>INR</MenuItem>
            </Select>
          </Toolbar>
        </Container>
      </AppBar>
    </ThemeProvider>
  );
};

export default Header;
```


## Noteables
- This is a a VERY basic implementation.
- There are other ways to implement or pass props, please refer to documentation below

Learn more about it [here](https://v4.mui.com/styles/api/#makestyles-styles-options-hook)

Material-UI Styled Components Implementation with JSS


### What is Bootstrap?
  - Bootstrap is the most popular CSS Framework for developing *responsive* and *mobile-first* websites.
  - Created by Twitter
  - Has CSS styles built in but can be overridden
  - Uses the 12-column Grid System
  - Tons of Pre-built Components, like JumboTron, Carousel, etc.


## Installation for a REACT APP
  - npm i bootstrap@5.0.0-alpha3
  - Add import to index.js file ``import “bootstrap/dist/css/bootstrap.min.css”;``
  - 

## Adding Bootstrap Icons
  - Bootstrap 5 offers 1,300 free, high-quality SVG / web font icons that you can use on your project.
  - In order to install this on our React JS app, we need to install it via npm using the following command on our terminal:
  - ``npm i bootstrap-icons``
  
## About the 12 Grid System
  - Unlimited Rows
  - Specify column amount depeding on view size (x-small, small, medium, large, xlg)
  - Example class would be ``col-med-6``
  - Containers, Rows and Columns make up the 12 grid system

Info sourced from Designmodo [here](https://designmodo.com/bootstrap-react-sass/)
Check out this Comprehensive CheatSheet [here](https://bootstrap-cheatsheet.themeselection.com/)


Bootstrap Framework


### What is React?
  - A JS library for building User Interfaces
  - A Single Page Application that utilizes the virtual DOM to greatly improve performance as the whole DOM is already downlaoded annd just what needs to be displayed is rendered.

## What are components in React?
  - Components make up the visual layer of our applicaiton and lets us create re-usable but seperate pieces of code
  - Components are class or functions that return JSX
  - Components can be nested as deep as you want



## What are Hooks?
  - Hooks are features within React that let you use functional components to interact with the state, lifecycle and more.
  - Hooks changed teh way most developers use React these days and class components aren't seen as much anymore.
  - Hookes are essential, and their name derives from their ability to "Hook the state"
    - Hooks include: 
      - useState
      - useEffect
      - useContext
      - useReducer
      - useCallback
      - useMemo
      - useRef
      - many more...

## What is JSX?
  - JSX is a hybrid of JavaScript and HTML code that React can read. 
  - Browsers don't know how to read JSX natively so the code will need to be compiled.

## What is React-Router?
  - React router lets us have multiple pages in our React
  - Using BrowserRouter, Router, Route, Routes to achieve this.

## What are Props?
  - Props are how we pass data down from one parent component to a child
  - Props are short for properties and can be passed down to multiple children
  - Use the "this" keyword when interacting with props from a class based component
  - Prop Drilling is the act of passing props down mulitple components.

props.js
  ```
  import React from 'react';
  import ReactDOM from 'react-dom/client';

  function Car(props) {
    return <h2>I am a { props.brand }!</h2>;
  }

  function Garage() {
    return (
      <>
        <h1>Who lives in my garage?</h1>
        <Car brand="Ford" />
      </>
    );
  }

  const root = ReactDOM.createRoot(document.getElementById('root'));
  root.render(<Garage />);
  ```

## What is State?
  - State is a JS object that lets us store data about a particular component
  - We don't interact with the state directly and we don't create new variables in place of the state
  - setState is how we set the state in class components or functional components with the hooks.
  - Lifting the state is used to take data about a particular component and pass it back to a parent that may need that data


state.js
  ```
  import React, { useState } from 'react';

  function Example() {
    // Declare a new state variable, which we'll call "count"
    const [count, setCount] = useState(0);

    return (
      <div>
        <p>You clicked {count} times</p>
        <button onClick={() => setCount(count + 1)}>
          Click me
        </button>
      </div>
    );
  }
  ```

  

## What is the component Lifecycle?
  - Initialization
  - Mounting
  - Updating
  - Unmounting
  - Class based components use lifecycle methods suck as componentDidUpdate, componenentDidMount, etc
  - Function based components use the useEffect hook
    - If the component is in the original useEffect call it will load on component mount while if you put the component inside our useEffect dependency array it will update everytime the state changes.

  - No dependency passed
  ```
  useEffect(() => {
  //Runs on every render
  });
  ```

  - An Empty Array

  ```
  useEffect(() => {
  //Runs only on the first render
  }, []);
  ```

  - Props or state values
  ```
  useEffect(() => {
  //Runs on the first render
  //And any time any dependency value changes
  }, [prop, state]);
  ```

### Run only on initial render
  ```
  import { useState, useEffect } from "react";
  import ReactDOM from "react-dom/client";

  function Timer() {
    const [count, setCount] = useState(0);

    useEffect(() => {
      setTimeout(() => {
        setCount((count) => count + 1);
      }, 1000);
    }, []); // <- add empty brackets here

    return <h1>I've rendered {count} times!</h1>;
  }

  const root = ReactDOM.createRoot(document.getElementById('root'));
  root.render(<Timer />);
  ```

### Run only on variable update

  ```
  import { useState, useEffect } from "react";
  import ReactDOM from "react-dom/client";

  function Counter() {
    const [count, setCount] = useState(0);
    const [calculation, setCalculation] = useState(0);

    useEffect(() => {
      setCalculation(() => count * 2);
    }, [count]); // <- add the count variable here

    return (
      <>
        <p>Count: {count}</p>
        <button onClick={() => setCount((c) => c + 1)}>+</button>
        <p>Calculation: {calculation}</p>
      </>
    );
  }

  const root = ReactDOM.createRoot(document.getElementById('root'));
  root.render(<Counter />);
  ```

## What is React Global State Management?
  - Sometimes React needs a global state object to keep the app working
    - think of a logged in user profile
  - Prop drilling isn't practical once our application reaches a certain size
  - We can use the ContextAPI or Redux to solve this

### When to use Context?
- We designed the application in which used color props in the ParentClass and passed that props to all component (top to down) without checking that it is required by the child class or not and another issue also here that in case if GrandChildClass component was more deeply nested than it was very difficult to manage. This is the problem that Context solves. Context is designed the share values that can be considered "global" such as preferred language, current user, or theme.
- These types of data include:
  - Theme data (like dark or light mode)
  - User data (the currently authenticated user)
  - Location-specific data (like user language or locale)

    *When to use context*
  ```

  const App = () => {
    return(
      <ParentClass color= "blue"/>
    );
  }

  const ParentClass = (props) => (
    <ChildClass color= {props.color} />
  )

  const ChildClass = (props) => (
    <GrandChildClass color= {props.color} />
  )

  const GrandChildClass = (props) => (
    <p>Color: {props.color}</p>
  )
  ```
  ### 4 Steps to using React Context

  1. Create context using the createContext method.
  2. Take your created context and wrap the context provider around your component tree.
  3. Put any value you like on your context provider using the value prop.
  4. Read that value within any component by using the context consumer.

  ### There are two main components that make up Context
    - Provider of Context
    - Consumer of Context



## What is the Virtual DOM
  - This allows React to update only specific components in the tree without updating the whole DOM
  - Keys will need to be generated for each list item for the VDOM errors to go away


## Event Listeners
  - camelCase the eventName
  - Pass the function we want to execute

## Conditional Rendering
  - ``isAuthenticated === true`` 
  - `` {isAuthenticated && operator}``
  - Using an inline if/else also known as *ternirary* is godo for additional logic

## Noteable Terminal Commands
  - ``npx create-react-app appname ``
  - ``npm start``
  - ``npm build``

  

React [here](https://reactjs.org/)

Check out this Comprehensive CheatSheet [devhints](https://devhints.io/react)


React Overview


## What is an API? 

API stands for application programming interface, a concept that applies everywhere from command-line tools to enterprise Java code to Ruby on Rails web apps. An API is a way to programmatically interact with a separate software component or resource.

Unless you write every single line of code from scratch, you’re going to be interacting with external software components, each with its own API. Even if you do write something entirely from scratch, a well-designed software application will have internal APIs to help organize code and make components more reusable. And there are numerous public APIs that allow you to tap into functionality developed elsewhere over the web.


### Types of APIs

API stands for Application Programming Interface, which is a mechanism that allows the interaction between two applications using a set of rules.

APIs are beneficial because they allow developers to add specific functionality to an application, without having to write all of the code themselves. APIs also allow developers to access data from other applications. For example, when bloggers put their Twitter handle on their blog’s sidebar, WordPress enables this by using Twitter’s API.

### Main types of Web APIs
There are four main types of APIs:

- Open APIs: Also known as Public API, there are no restrictions to access these types of APIs because they are publicly available.
- Partner APIs: A developer needs specific rights or licenses in order to access this type of API because they are not available to the public.
- Internal APIs: Also known as Private APIs, only internal systems expose this type of API. These are usually designed for internal use within a company. The company uses this type of API among the different internal teams to be able to improve its products and services.
- Composite APIs: This type of API combines different data and service APIs. It is a sequence of tasks that run synchronously as a result of the execution, and not at the request of a task. Its main uses are to speed up the process of execution and improve the performance of the listeners in the web interfaces.

## Web service APIs

- SOAP
  - SOAP (Simple Object Access Protocol): This is a protocol that uses XML as a format to transfer data. Its main function is to define the structure of the messages and methods of communication. It also uses WSDL, or Web Services Definition Language, in a machine-readable document to publish a definition of its interface.
  - Added data types
  - Envelope wraps header and body
- XML-RPC
  - XML-RPC: This is a protocol that uses a specific XML format to transfer data compared to SOAP that uses a proprietary XML format. It is also older than SOAP. XML-RPC uses minimum bandwidth and is much simpler than SOAP. 
- JSON-RPC
  - JSON-RPC: This protocol is similar to XML-RPC but instead of using XML format to transfer data it uses JSON
- REST
  - REST (Representational State Transfer): REST is not a protocol like the other web services, instead, it is a set of architectural principles. The REST service needs to have certain characteristics, including simple interfaces, which are resources identified easily within the request and manipulation of resources using the interface.
  - Added GET,POST,PUT,DELETE http methods and caching
  - Allows Middleware
  - Uniform interface
  - Sets constraints
  - replaced SOAP
- GraphQL
  - GraphQL Rest APIs were too chatty and downloads to much data
  - GraphQL makes a Single Precise Request and returns an all inclusive reply. No need to mix and match endpoints
  - Uses a Schema to facilitate
  - Quickly becoming the default but harder to learn.






Information Sourced from: [Rapid API](https://rapidapi.com/blog/types-of-apis/)

Application Programming Interfaces


## What is React Helmet Async?

![React-Helmet-Async-NPM](Flutter-main.png)

This package is a fork of React Helmet. <Helmet> usage is synonymous, but server and client now requires <HelmetProvider> to encapsulate state per request.

## Documentation

- NPM Package [here](https://www.npmjs.com/package/react-helmet-async)
- Helmet YouTube Tutorial [here](https://www.youtube.com/watch?v=iAbtNdgjn2Y&t=215s)

## Installation

`npm i react-helmet-async`

## Setup and Usage

- Import Helmet and HelmetProvider
  `import { Helmet, HelmetProvider } from 'react-helmet-async';`
- We need to wrap our app in a HelmetProvider Tag like our example below

  ```
    <HelmetProvider>
    <App>
      <Helmet>
        <title>Hello World</title>
        <link rel="canonical" href="https://www.tacobell.com/" />
      </Helmet>
      <h1>Hello World</h1>
    </App>
  </HelmetProvider>
  ```

- Next we need to add our Helmet for the APP and Individual Pages or Components we want seperate META tag information
- A child with the Helmet tag will override the Meta Tags of a parent with the same type
- We can also insert Dynamic Data into our Meta Tags to have singlePage unique SEO content.

Learn more about it [here](https://www.npmjs.com/package/react-helmet-async).


React Helmet Async


## Flutter

![Flutter-HomePage](Flutter-main.png)

Flutter let's you design pixel perfect mobile applications that are App store and Google Play ready. Code in one language and ship in the same day. Flutter is more robust than React native or standard mobile development while also not relying on primitive system specific components.

## Installation

Install it [here](https://docs.flutter.dev/get-started/install).

Check for installation success by running flutter docter from your shell

```sh
 flutter doctor
```

## Create and run a simple Flutter app

To create your first Flutter app and test your setup, follow these steps:

Create a new Flutter app by running the following from the command line:

```sh
 flutter create my_app
```

A my_app directory is created, containing Flutter’s starter app. Enter this directory:

```sh
 cd my_app
```

To launch the app in the Simulator, ensure that the Simulator is running and enter:

```sh
 flutter run
```

Learn more about it [here](https://flutter.dev).


Flutter Introduction


NextJS is a **framework for ReactJS**.

👀 Wait a second ... a "framework" for React? Isn't React itself already a framework for JavaScript?

Well ... first of all, React is a "library" for JavaScript. That seems to be important for some people.

Not for me, but still, there is a valid point: React already is a framework / library for JavaScript. So it's already an extra layer on top of JS.

## Why would we then need NextJS?

Because NextJS makes building React apps easier - especially React apps that should have server-side rendering (though it does way more than just take care of that).

In this article, we'll dive into 3 core concepts and features NextJS has to offer:

- File-based Routing
- Built-in Page Pre-rendering
- Rich Data Fetching Capabilities


## File-based Routing

![Create routes via your file + folder structure](nextjs-file-based-routing.png)

## Classic React Rendering
![No-rendering Example](No-rendering.png)
React doesn't have pre-rendering so you must wait for the content to load.


## Built-in Page Pre-rendering
![Pre-rendering Example](Pre-rendering.png)

By default, Next.js pre-renders every page. This means that Next.js generates HTML for each page in advance, instead of having it all done by client-side JavaScript. Pre-rendering can result in better performance and SEO.
Each generated HTML is associated with minimal JavaScript code necessary for that page. When a page is loaded by the browser, its JavaScript code runs and makes the page fully interactive. (This process is called hydration.)

## Two Types of Pre-rendering
### Server-Side Rendering
![SSR](SSR.png)

### Static Site Generation
![Static-Gen](static-gen.png)

- Next.js has two forms of pre-rendering: Static Generation and Server-side Rendering. The difference is in when it generates the HTML for a page.
- Static Generation is the pre-rendering method that generates the HTML at build time. The pre-rendered HTML is then reused on each request.
- Server-side Rendering is the pre-rendering method that generates the HTML on each request.

### Per Page Basis 
![Per Page Basis](per-page-basis.png)

Importantly, Next.js lets you choose which pre-rendering form to use for each page. You can create a "hybrid" Next.js app by using Static Generation for most pages and using Server-side Rendering for others.

When to Use Static Generation v.s. Server-side Rendering
We recommend using Static Generation (with and without data) whenever possible because your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request.

You can use Static Generation for many types of pages, including:

- ***Marketing pages***
- ***Blog posts***
- ***E-commerce product listings***
- ***Help and documentation***

You should ask yourself: ***"Can I pre-render this page ahead of a user's request?"*** If the answer is yes, then you should choose Static Generation.

On the other hand, Static Generation is not a good idea if you cannot pre-render a page ahead of a user's request. Maybe your page shows frequently updated data, and the page content changes on every request.

In that case, you can use Server-side Rendering. It will be slower, but the pre-rendered page will always be up-to-date. Or you can skip pre-rendering and use client-side JavaScript to populate frequently updated data.



## Rich Data Fetching Capabilities

### Static Generation with and without Data
![Static without data](static-wo-data.png)
Static Generation can be done with and without data.

So far, all the pages we’ve created do not require fetching external data. Those pages will automatically be statically generated when the app is built for production.


### Static Generation with and with Data
![Static with data](static-with-data.png)

However, for some pages, you might not be able to render the HTML without first fetching some external data. Maybe you need to access the file system, fetch external API, or query your database at build time. Next.js supports this case — Static Generation with data — out of the box.

Static Generation with Data using getStaticProps
How does it work? Well, in Next.js, when you export a page component, you can also export an async function called getStaticProps. If you do this, then:

- getStaticProps runs at build time in production, and…
- Inside the function, you can fetch external data and send it as props to the page

```js
export default function Home(props) { ... }

export async function getStaticProps() {
  // Get external data from the file system, API, DB, etc.
  const data = ...

  // The value of the `props` key will be
  //  passed to the `Home` component
  return {
    props: ...
  }
}
```

Information Sourced from: [NextJS Docs](https://nextjs.org/learn/basics)

All Posts