DEV Community: Rafał Goławski

Ilha for Svelte Developers

Rafał Goławski — Mon, 27 Apr 2026 16:29:23 +0000

What is Ilha?

Ilha is a small reactive UI framework built around the concept of islands: self-contained, focused components that render on the server and activate in the browser only where interactivity is actually needed.

Rather than relying on a virtual DOM or a compiler-heavy single-file format, it uses fine-grained signals and a builder-style API. You declare input, state, derived values, events, effects, and rendering in one fluent chain — making the reactive model explicit and easy to trace.

In practice, Ilha is a strong fit if you value SSR-friendly UI, small interactive components, and keeping behavior tightly coupled to the HTML it drives. You can learn more on the official website or in the documentation.

Why Ilha Makes Sense If You Know Svelte

If you're coming from Svelte, Ilha will feel familiar in one key way: it also embraces fine-grained reactivity instead of treating the UI as one large tree to be re-evaluated all at once.

The experience is different, though. Svelte's runes live inside .svelte component files and are powered by a compiler. Ilha is built around an island-oriented builder API — no compiler step, no special file format. Islands render to HTML on the server, then mount or hydrate on the client using signals, events, effects, and explicit lifecycle control.

This article is not about proving Ilha is "better than Svelte." It is about helping Svelte developers understand Ilha quickly by mapping six familiar concepts — $props, $state, $derived, $effect, bind:, and scoped styles — to their Ilha counterparts.

The Mindset Shift

In Svelte, you think in terms of a component file: state, derived values, template logic, and effects live together in .svelte syntax, and the compiler handles the reactive wiring.

In Ilha, you assemble those same pieces step by step through a fluent builder chain and finish with .render(). The result is an island: a focused interactive unit that renders to HTML on the server and mounts or hydrates on the client.

The key adjustment:

In Svelte, reactivity is embedded into the component language and managed by the compiler
In Ilha, reactivity is assembled explicitly through the builder chain, with no compiler involved

Once that clicks, the API becomes much easier to read.

`$props` vs `.input()`

This is the most fundamental mapping and worth understanding first, because .input() shapes everything that follows in the builder chain.

Svelte's $props() declares what a component accepts from its parent. You destructure the result, optionally provide defaults, and TypeScript enforces the shape at compile time. Ilha's .input() answers the same need, but in a more explicit way: you can use a type-only generic for TypeScript inference, or pass a schema for runtime validation, coercion, and defaults.

Svelte

<script>
  let { label = "Click me", count = 0 } = $props();
</script>

<button>{label}: {count}</button>

Ilha

import ilha, { html } from "ilha";
import { z } from "zod";

const Button = ilha
  .input(z.object({
    label: z.string().default("Click me"),
    count: z.number().default(0),
  }))
  .render(({ input }) => html`
    <button>${input.label}: ${input.count}</button>
  `);

One important distinction: in Ilha, .input() is best understood as the island's resolved external input at initialization. If you need mutable local state derived from a prop, chain .state() after .input() and initialize from the input value:

const Counter = ilha
  .input(z.object({ start: z.number().default(0) }))
  .state("count", ({ start }) => start)
  .render(({ state }) => `<p>${state.count()}</p>`);

That pattern — prop-seeded local state — is the idiomatic Ilha equivalent of initializing $state from a prop in Svelte.

`$state` vs `.state()`

Svelte's $state gives you reactive state that reads and writes like a normal variable. Primitives behave as plain values. Arrays and simple objects become deeply reactive proxies, so operations like property writes or .push() trigger granular updates automatically.

Ilha's .state() serves the same conceptual purpose — declaring local reactive state that drives rendering — but exposes each entry as a signal accessor: a function you call to read or write.

Svelte

<script>
  let count = $state(0);
</script>

<button onclick={() => count++}>
  clicks: {count}
</button>

Ilha

import ilha, { html } from "ilha";

const Counter = ilha
  .state("count", 0)
  .on("button@click", ({ state }) => state.count(state.count() + 1))
  .render(({ state }) => html`
    <button>
      clicks: ${state.count}
    </button>
  `);

The ergonomic difference is intentional:

Action	Svelte	Ilha
Read	`count`	`state.count()`
Write	`count++`	`state.count(state.count() + 1)`

Ilha's accessor pattern is more verbose, but it makes the reactive boundary unambiguous: calling a signal reads it; calling it with an argument writes it. There is no implicit tracking magic.

Object reactivity

This is one area where the frameworks diverge meaningfully. Svelte's $state deeply proxies arrays and simple objects, so nested mutations are automatically tracked. Ilha's .state() is signal-based — updates are always through the signal accessor, not through mutation. The practical mental model: Svelte makes nested mutation ergonomic through proxy magic; Ilha makes the reactive boundary visible and explicit.

`$derived` vs `.derived()`

Svelte's $derived computes a value from whatever state is read synchronously inside it, re-runs when dependencies change, and is expected to be side-effect free. You can use $derived.by(...) for multi-line expressions.

Ilha's .derived() plays the same role, but adds something Svelte does not have at the primitive level: a built-in async story. Derived values can be synchronous or async, and the result is always exposed through an envelope with loading, value, and error fields.

Svelte

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

<p>{count} doubled is {doubled}</p>

Ilha

import ilha from "ilha";

const Totals = ilha
  .state("count", 0)
  .derived("doubled", ({ state }) => state.count() * 2)
  .render(({ state, derived }) => `
    <p>${state.count()} doubled is ${derived.doubled.value}</p>
  `);

For synchronous computations, the mapping is direct. Where Ilha becomes especially interesting is async data:

import ilha, { html } from "ilha";

const Search = ilha
  .state("query", "")
  .derived("results", async ({ state, signal }) => {
    const res = await fetch(`/api/search?q=${state.query()}`, { signal });
    return res.json() as Promise<string[]>;
  })
  .bind("#query", "query")
  .render(({ derived }) => html`
    <input id="query" type="text" />
    ${derived.results.loading
      ? html`<p>Searching…</p>`
      : html`
          <ul>
            ${derived.results.value?.map((item) => html`<li>${item}</li>`)}
          </ul>
        `}
  `);

Notice the signal parameter: Ilha automatically passes an AbortSignal into async derived functions, so in-flight requests are cancelled when dependencies change — something you would wire up manually in Svelte. This makes .derived() one of the most compelling onboarding points for Svelte developers, because it immediately answers a common question: where do async computed values live?

`$effect` vs `.effect()`

Svelte's $effect runs in the browser after the component mounts and after DOM updates are applied. It tracks the reactive state and derived values it reads during execution, batches re-runs, and supports teardown via a returned function.

Ilha's .effect() is very close in spirit. It registers a reactive side effect that runs after mount and re-runs whenever any signal it reads changes. It also supports cleanup logic returned from the effect function.

Svelte

<script>
  let title = $state("Hello");

  $effect(() => {
    document.title = title;
  });
</script>

Ilha

import ilha from "ilha";

const PageTitle = ilha
  .state("title", "Hello")
  .effect(({ state }) => {
    document.title = state.title();
  });

This is the cleanest one-to-one mapping in the whole comparison. Both primitives answer the same question: how do I sync something outside the template when state changes?

Cleanup maps directly

Svelte:

$effect(() => {
  const id = setInterval(() => {
    console.log("tick");
  }, 1000);

  return () => clearInterval(id);
});

Ilha:

const Island = ilha
  .state("delay", 1000)
  .effect(({ state }) => {
    const id = setInterval(() => {
      console.log("tick");
    }, state.delay());

    return () => clearInterval(id);
  });

Both frameworks use the same cleanup convention: return a function, and it runs before the next effect execution and on teardown.

One important difference

Svelte effects can depend on both state and derived state transparently. Ilha's effect context is intentionally narrower — the recommended pattern is to read the underlying state signals directly inside the effect and let it track those dependencies, rather than reading .derived() results inside .effect(). This is a subtle but meaningful distinction for anyone porting patterns from Svelte.

`bind:value` vs `.bind()`

Svelte's bind: directive is one of its most-used features. It creates a two-way sync between a DOM input's value and a reactive variable — you write bind:value={name}, and Svelte handles the event listener and state update for you.

Ilha's .bind() answers the same daily need — keeping a form input in sync with local state — but the mechanism is different. Instead of compiler-injected inline binding, .bind() uses a selector-based builder API to connect a form element to a state signal. Ilha then handles the correct property and event for the element type automatically.

Svelte

<script>
  let name = $state("");
</script>

<input bind:value={name} />
<p>Hello, {name}</p>

Ilha

import ilha, { html } from "ilha";

const Greeting = ilha
  .state("name", "")
  .bind("[name=name]", "name")
  .render(({ state }) => html`
    <input name="name" value="${state.name()}" />
    <p>Hello, ${state.name()}</p>
  `);

The selector [name=name] targets the input by its name attribute, and "name" is the state key to sync. The important mental model shift:

Concept	Svelte	Ilha
How it works	Compiler injects binding into the element	`.bind()` connects a selector to a state key in the builder chain
Selector style	Directive on the element: `bind:value`	CSS selector passed to builder: `"[name=name]"`
Scope	Per-element, declared inline	Per-island, declared in the chain

One consequence worth noting: because .bind() is declared in the builder chain rather than inline in the template, it stays visible alongside state declarations. You can see at a glance which signals are connected to DOM inputs without scanning the template. For Svelte developers who sometimes lose track of which variables have bind: wired to them across a large template, this is a real ergonomic win.

Scoped styles vs `.css()`

Svelte's scoped styles and Ilha's .css() solve the same problem: keeping component-level CSS local. The difference is where that scoping comes from.

In Svelte, styles live inside a <style> block and the compiler scopes them automatically. In Ilha, styles are declared explicitly in the builder chain with .css(), and scoped to the island itself.

Svelte

<script>
  let kind = $state("primary");
</script>

<button class={kind}>Save</button>

<style>
  button {
    padding: 0.75rem 1rem;
    border-radius: 0.5rem;
  }

  .primary {
    background: teal;
    color: white;
  }
</style>

Ilha

import ilha, { html } from "ilha";

const Button = ilha
  .state("kind", "primary")
  .css`
    button {
      padding: 0.75rem 1rem;
      border-radius: 0.5rem;
    }

    .primary {
      background: teal;
      color: white;
    }
  `
  .render(({ state }) => html`
    <button class="${state.kind()}">Save</button>
  `);

The mental model shift is similar to the rest of Ilha:

In Svelte, style scoping is part of the component file and handled by the compiler
In Ilha, styling is another explicit step in the island chain, alongside state, effects, and bindings

One nice detail in Ilha is that the scope is tied to the island boundary, so styles stay local and do not leak into nested child islands.

Ilha Is Not Trying to Be a `.svelte` File

This is the part Svelte developers should internalize early. Ilha's core abstraction is not "a component file with compiler-backed syntax." It is "an island assembled through a chain."

You declare input, state, derived values, events, effects, bindings, and then finish with .render(). The same island can render to an HTML string on the server, mount on the client, or produce hydratable output with serialized props and optional state snapshots — all without a build step for the island definition itself.

Ilha will likely appeal most to Svelte developers who value:

Fine-grained reactivity without a virtual DOM
SSR-friendly architecture with explicit hydration control
Clear state and behavior boundaries
Smaller interactive islands rather than a monolithic client-side app shell

If what you love most about Svelte is the single-file component ergonomics and the magic of the compiler, Ilha will feel unfamiliar. If what you love is the reactive mental model and the lack of heavy re-rendering machinery, Ilha starts making a lot of sense very quickly.

Svelte → Ilha Reference

Svelte	Ilha	Purpose	Key difference
`$props()`	`.input<T>()` / `.input(schema)`	Component props / external input	Svelte uses component props inside the `.svelte` file; Ilha makes input explicit in the builder chain and can add runtime validation via schema
`$state`	`.state()`	Local reactive state	Svelte uses variable-style state with deep proxy support; Ilha uses explicit signal accessors
`$derived`	`.derived()`	Computed reactive values	Svelte focuses on sync dependency-tracked computations; Ilha adds a built-in async model with `loading`/`value`/`error` and automatic `AbortSignal` cancellation
`$effect`	`.effect()`	Reactive side effects	Both support cleanup and dependency tracking; Ilha's effect context is intentionally narrower
`bind:value`	`.bind(selector, key)`	Two-way DOM ↔ state sync	Svelte injects per-element bindings via the compiler; Ilha uses selector-based bindings declared in the builder chain
Scoped `<style>`	`.css()`	Component-local CSS	Svelte scopes styles through compiler output; Ilha scopes styles at the island boundary with `@scope`

Resources

🚀 Interactive tutorial — see the core ideas in action
📚 Guide — islands, SSR, hydration, and the overall mental model
🧪 StackBlitz sandbox — experiment without reading first
🐦 @ilha_js on X — updates as the project grows
💬 Discord — questions and community
⭐ GitHub repo — source, issues, and early feedback

Spin up Bun + Preact full-stack app in minutes 🚀

Rafał Goławski — Sun, 14 Sep 2025 11:46:25 +0000

Bun makes full-stack TypeScript feel almost too easy - a fast runtime, a dev server with HMR, and a bundler. In this post we’ll spin up a minimal app that serves an HTML page, mounts a Preact component, and exposes a tiny API.

What we’re building

You’ll end up with:

A simple Bun server (serves HTML + a tiny API route).
A Preact client mounted into #root.
Scripts for dev (with hot reload) and production.

src/
  ├─ index.ts   # server entry
  ├─ index.html # HTML shell
  └─ client.tsx # client entry

That’s it - nothing fancy, just enough to get a full-stack Bun app running.

1. Initialize the project

bun init

This scaffolds your package.json, tsconfig.json, and a few handy defaults.

2. Install Preact

bun add preact

Preact gives us a lightweight React-compatible API. We’ll use it purely on the client for now.

3. Tell TypeScript where JSX comes from

Add this to the compilerOptions section in your tsconfig.json file:

{
  "compilerOptions": {
    "jsxImportSource": "preact"
  }
}

Why? With modern JSX runtimes, TypeScript needs to know which library provides the JSX functions. Setting jsxImportSource to preact ensures your .tsx files resolve JSX to Preact’s runtime, avoiding “JSX not found” or mismatched types.

4. Create the app files

mkdir src \
  && mv index.ts src/index.ts \
  && touch src/index.html \
  && touch src/client.tsx

We’ll keep everything in src/ for clarity. index.ts will be our server entry, index.html the shell and client.tsx the Preact entry.

5. Add scripts to `package.json`

Insert the following into package.json:

{
  "scripts": {
    "dev": "bun --hot src/index.ts",
    "start": "NODE_ENV=production bun src/index.ts"
  }
}

dev - starts Bun with hot reload, so whenever any module or file changes, Bun re-runs the file.
start - runs in production mode (no hot reload).

6. Create the HTML shell

Insert the following into src/index.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <div id="root"></div>
    <script type="module" src="./client.tsx"></script>
</body>
</html>

Why? This is the single page our server will return for all routes. The <script type="module"> line points to our client entry, so Bun can bundle/transform it as needed.

7. Write the server

Insert the following into src/index.ts:

import { serve } from "bun"
import index from "./index.html"

const server = serve({
  routes: {
    "/*": index,
    "/api/hello": () => Response.json({ message: "Hello, world!" }),
  },
  // Enable dev features only when NODE_ENV=development
  development: process.env.NODE_ENV === "development" && {
    hmr: true,     // push client updates without full page reload
    console: true, // surface browser console logs/errors in terminal
  },
})

console.log(`Server is running on ${server.url}`)

What happens:

The server returns index.html for any path (/*) and a JSON response at /api/hello.
When NODE_ENV=development, Bun enables development mode for this server:
- HMR streams client updates to the browser.
- Console overlay mirrors browser logs/errors to your terminal.
In production (NODE_ENV=production), those dev features are off - the server just serves routes normally.

8. Write the client

Insert the following into src/client.tsx:

import { render } from "preact"

const root = document.getElementById("root")

if (!root) {
    throw new Error("Root element not found")
}

function App() {
    return <h1>Hello, world!</h1>
}

render(<App />, root)

Why Preact? It uses the same component model as React, so if you already know React you can be productive right away. At the same time it’s much smaller in size, which makes it a good fit for a Bun-powered setup where you want fast cold starts and lightweight bundles.

Run it!

bun run dev   # development mode
bun run start # production mode

Open the printed URL (typically http://localhost:3000). Try editing src/client.tsx or src/index.ts - you should see instant updates.

That’s it! You now have a tiny full-stack Bun app with Preact, hot reload, and an example API - perfect as a seed for side projects and demos.

Handling Layout Form Submission Inside a React Router Cookie Banner 🍪

Rafał Goławski — Tue, 28 Jan 2025 22:48:26 +0000

Recently, I was working on a React Router v7 app where I needed to implement a cookie banner. The app has many routes, and the requirement was to display the cookie banner on every single one of them, without exception. As all the routes share the same layout, it felt natural to add the cookie banner there. In this article, I’ll walk you through how to achieve this.

Step 1: Setting Up the Layout Component

First, let’s create a layout component and define how it will be used in our routes. Here’s a simple example:

// app/layouts/layout.tsx
import { Outlet } from "react-router";

export function Layout() {
  return (
    <>
      <header>...</header>
      <main>
        <Outlet />
      </main>
      <footer>...</footer>
    </>
  );
}

Then, we use the layout in our routing configuration:

// app/routes.ts
import { type RouteConfig, index, layout } from "@react-router/dev/routes";

export default [
  layout("layouts/layout.tsx", [index("routes/home.tsx")]),
] satisfies RouteConfig;

Now that we have our layout set up, we can move on to creating the cookie banner.

Step 2: Creating the Cookie Banner Component

Let’s start by building a simple cookie banner:

// app/components/cookie-banner.tsx
import { Form } from "react-router";

export function CookieBanner() {
  return (
    <div>
      <p>We're using cookies</p>
      <p>...</p>
      <Form method="POST">
        <button type="submit" name="consent" value="all">
          Accept all
        </button>
        <button type="submit" name="consent" value="necessary">
          Only necessary
        </button>
      </Form>
    </div>
  );
}

Here, we use the <Form> component from React Router for issuing POST requests when users interact with the cookie banner. We’ll revisit the Form in a moment.

Step 3: Adding the Cookie Banner to the Layout

Now that the cookie banner component is ready, we can include it in the layout to make it appear across all routes:

// app/layouts/layout.tsx
import { Outlet } from "react-router";
import { CookieBanner } from "~/components/cookie-banner";

export default function Layout() {
  return (
    <>
      <header>...</header>
      <main>
        <Outlet />
      </main>
      <footer>...</footer>
      <CookieBanner />
    </>
  );
}

At this point, the cookie banner will render on every page of the app. Try clicking the buttons, however, and you’ll encounter a “Method Not Allowed” error. Let’s fix that.

Step 4: Handling Form Actions

The issue stems from missing an action attribute in the <Form>. If you don’t specify an action, the form’s request is routed to the current page, and React Router doesn’t know how to handle it.

A simple solution is to point the action to the index route (or any other route that handles the logic). Update the form as follows:

// app/components/cookie-banner.tsx
<Form method="POST" action="/?index">

Now, when the form is submitted, the request will be sent to the index route’s action. Let’s define that action to handle the form submission:

// app/routes/home.tsx
export function action() {
  // Handle user cookie preferences here
  return {};
}

For simplicity, this example doesn’t include the logic to store user preferences. If you’d be interested in learning more about that, let me know in the comments - this could be a topic for another article!

Step 5: Improving User Experience: Redirecting Back

Currently, when users submit the form from a route that isn’t the index route, they’ll be redirected back to the index route after submission. This isn’t ideal from a user experience perspective, so let’s fix it.

The goal is to redirect users back to the page where they submitted the form. To achieve this, we’ll capture the current page’s pathname using the useLocation hook and send it as part of the form data. Update the cookie banner component like so:

// app/components/cookie-banner.tsx
import { Form, useLocation } from "react-router";

export function CookieBanner() {
  const { pathname } = useLocation();
  return (
    <div>
      <p>We're using cookies</p>
      <p>...</p>
      <Form method="POST" action="/?index">
        <input type="hidden" name="redirect-to" value={pathname} />
        <button type="submit" name="consent" value="all">
          Accept all
        </button>
        <button type="submit" name="consent" value="necessary">
          Only necessary
        </button>
      </Form>
    </div>
  );
}

Using the pathname value, we include a hidden input field named redirect-to. This ensures the form submits the current page’s URL.

Next, let’s modify the index route’s action to handle this value and redirect the user appropriately:

// app/routes/home.tsx
import { redirect } from "react-router";
import type { Route } from "./+types/home";

export async function action({ request }: Route.ActionArgs) {
  const formData = await request.formData();
  const redirectTo = String(formData.get("redirect-to") || "/");
  // Handle user preferences here
  return redirect(redirectTo);
}

With this setup, users will be redirected back to the page they were on when they submitted their cookie preferences.

Step 6: Conditional Rendering of the Cookie Banner

Another important improvement is ensuring the cookie banner is dismissed once the user interacts with it. We don’t want the banner to reappear every time the page reloads. To achieve this, we can use a loader in the layout to fetch user preferences and render the banner conditionally.

Here’s an example implementation:

// app/layouts/layout.tsx
import { Outlet } from "react-router";
import { CookieBanner } from "~/components/cookie-banner";
import type { Route } from "./+types/layout";

export function loader() {
  return { consent: "unset" }; // Fetch user preferences and return them here
}

export default function Layout({ loaderData }: Route.ComponentProps) {
  return (
    <>
      <header>...</header>
      <main>
        <Outlet />
      </main>
      <footer>...</footer>
      {loaderData.consent === "unset" && <CookieBanner />}
    </>
  );
}

As you can see, the loader fetches the user’s cookie consent preferences (this logic will depend on your implementation). If the user has already provided consent, the cookie banner will not render. If no consent has been provided (consent: "unset"), the banner is displayed.

This ensures the banner’s behavior is consistent across different routes and reloads.

Wrapping Up

In this article, we implemented a cookie banner in a React Router v7 app that seamlessly works across all routes. We tackled:

Adding a layout component and integrating a cookie banner into it.
Handling form submissions and redirecting users back to their previous page.
Conditionally rendering the cookie banner based on user preferences.

By using React Router’s loader and action mechanisms, we achieved a clean and user-friendly solution. If you’d like a follow-up article exploring how to persist cookie preferences (e.g., using local storage, an API, or cookies), let me know in the comments - I’d be happy to dive deeper into the topic.

Thanks for reading!

🍞 React Router v7: The Problem with Toasts After Form Submissions

Rafał Goławski — Sun, 12 Jan 2025 10:19:37 +0000

Recently, I was working on a React Router v7 application where I needed to display a toast notification after a (un)successful form submission. Naturally, I used an action to return the submission status and utilized it inside a useEffect to trigger the toast. Here's what my initial code looked like:

export async function action() {
  const response = await createPost("Lorem ipsum");
  if (!response.success) {
    return { status: "failed", data: null };
  }
  return { status: "success", data: response.data };
}

export default function MyRoute({ actionData }: Route.ComponentProps) {
  useEffect(() => {
    let description = '';
    if (actionData?.status === "success") {
      description = "Post created successfully 🎉";
    } else if (actionData?.status === "failed") {
      description = "Failed to create post 😵‍💫";
    }
    if (description.length > 0) {
      toast({ description, duration: 2000 })
    }
  }, [actionData?.status]);
  // ...
}

At first glance, this code seems fine. The toast displays correctly after submitting the form, whether the submission succeeds or fails. However, there’s one subtle issue with this approach. Did you spot it already?

The Problem

The problem appears when you submit the form again, and the actionData?.status remains unchanged (e.g., it stays "success" or "failed"). Since the value of actionData?.status hasn’t changed, the useEffect hook won’t re-run, and as a result, the toast notification won’t be displayed again.

This happens because useEffect only runs when one of its dependencies changes. In this case, the dependency array [actionData?.status] prevents the effect from triggering if the status is the same as before.

The Fix

The fix for this issue is simple - adjust the dependency array of your useEffect. Instead of depending solely on actionData?.status, you should include the entire actionData object in the dependency array. Here’s how the updated code looks:

useEffect(() => {
  let description = '';
  if (actionData?.status === "success") {
    description = "Post created successfully 🎉";
  } else if (actionData?.status === "failed") {
    description = "Failed to create post 😵‍💫";
  }
  if (description.length > 0) {
    toast({ description, duration: 2000 })
  }
}, [actionData]); // ✅ Adjusted dependency array

This ensures that your toast notification is displayed every time you submit the form.

Why Write About This?

You might wonder why I’m sharing this seemingly minor mistake. Well, this is actually the second time I’ve made this, so by documenting it here, I hope to not only serve as a personal reference for myself, but also help others avoid making the same mistake.

Thanks for reading!

🗃️ Resource Routes in React Router v7

Rafał Goławski — Fri, 10 Jan 2025 16:44:16 +0000

Here's a quick tip - React Router v7 routes aren't limited to just rendering UI components. They can work as API endpoints by returning various types of responses, making them true resource routes.

Creating JSON Endpoints

Here's a simple example of how to make your route return a JSON response:

// app/routes/home.tsx
export function loader() {
  return new Response(JSON.stringify([{ id: 1, title: "lorem ipsum" }]), {
    status: 200,
    headers: { "Content-Type": "application/json" },
  });
}

Let's break down what's happening here:

new Response() creates a standard web Response object
JSON.stringify() converts our JavaScript object to a JSON string
The headers object sets Content-Type to application/json to tell clients what type of data to expect

You're not limited to JSON responses only - you can use any valid MIME type. Beside loaders, you can also leverage actions for handling different HTTP methods beyond GET requests.

Want to dive deeper? Check out the official guide dedicated to this topic.

Thanks for reading!

I meant to delete a quick post, but accidentally deleted an article I spent 4 hours on yesterday. Totally my fault - I ignored the pop-up warnings. Perhaps there are so many warnings on the web nowadays that I've started to ignore them. How's your Friday?

Rafał Goławski — Fri, 10 Jan 2025 14:33:45 +0000

My Technical Writing Framework

Rafał Goławski — Wed, 08 Jan 2025 10:14:17 +0000

My New Year's Resolution is to write more. My most viewed posts have been about specific challenges I've encountered while working on various projects. I initially wrote them as personal reference materials to revisit later, and I encourage you to do the same!

Here's my process:

Take quick, rough notes while solving specific problems
Summarize the content as clearly as possible
Use AI to proofread and enhance the writing (optional)
Verify technical accuracy
Publish on this platform

Some posts gain traction, others don't - and that's perfectly fine. It's all part of the process. With time, as SEO settles and your article finds its place, you'll likely gain more readers and followers, bringing you closer to your goals!

I wish you all the best in 2025. Keep writing or continue whatever you're doing - even small steps matter!

What are your New Year's resolutions?

Thanks for reading!

Avoiding File Hashing in Vite #️⃣

Rafał Goławski — Wed, 31 Jul 2024 11:14:23 +0000

When building projects with Vite, you may encounter situations where you need to prevent certain files from being hashed during the build process. This can be particularly useful when working with assets that need consistent naming, such background.js file while working with Chrome extensions.

To achieve this, you can modify your vite.config.js file to customize the output filenames. Here's a simple approach:

import { defineConfig } from "vite";
import vue from "@vitejs/plugin-vue";
import { resolve } from "path";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()], // Optional, depends on library that you use
  build: {
    rollupOptions: {
      input: {
        // Define entry points for the build
        main: resolve(__dirname, "index.html"),
        background: resolve(__dirname, "src/background.ts"),
        content: resolve(__dirname, "src/content.ts"),
      },
      output: {
        entryFileNames: (chunkInfo) => {
          // Filenames you want to keep unhashed
          const noHashFiles = ["background", "content"];
          if (noHashFiles.includes(chunkInfo.name)) {
            return "[name].js"; // Keep file unhashed
          }
          return "assets/[name]-[hash].js"; // Hash other entry files
        },
        // Naming patterns for various output file types
        chunkFileNames: "assets/[name]-[hash].js",
        assetFileNames: "assets/[name]-[hash].[ext]",
      },
    },
  },
});

In this configuration, we're using the rollupOptions to specify custom output patterns. The entryFileNames function checks for specific file names (in this case, 'background') and returns a non-hashed filename for those. All other files will still use the default hashing pattern.

Hope you find this useful. Thanks for reading! 👋

How to make ESLint and Prettier work together 🛠️

Rafał Goławski — Sun, 05 May 2024 22:30:31 +0000

Introduction 👨‍🏫

Let's be honest - setting up tools for a new project can be a frustrating process. Especially when you want to jump straight to coding part. This is often the case with ESLint and Prettier, two popular tools in the JavaScript ecosystem that can sometimes interfere with each other when it comes to code formatting. Fortunately, there's a simple solution to this process, and it's called eslint-plugin-prettier.

Make it play nice! 🤝

Before we start, make sure you have Node.js installed on your machine.

Let's start by setting up a new JavaScript project. Note that the following steps are for the demonstration purposes only - I've tried this with Next.js, Remix and Vite React ESLint configurations, and it worked well in those cases.

So, without further-ado, let's set up a new project with these commands:



mkdir awesome-project
cd awesome-project
npm init -y

Next, we will need to install the required dependencies:



npm install --save-dev eslint-plugin-prettier eslint-config-prettier
npm install --save-dev --save-exact prettier

In this article, we're basically starting from scratch, so we can generate ESLint configuration like this:



npm init @eslint/config@latest

Follow the prompts in your command line to complete the setup. Adjust it to your needs:

Now, if you're on the newer version of the configuration (eslint.config.js) which is the case in this article, then paste the following code into your configuration file:



import eslintPluginPrettierRecommended from 'eslint-plugin-prettier/recommended';

export default [
  // any other config imports go at the top
  eslintPluginPrettierRecommended
]

Otherwise, if you're using an older version of ESLint configuration file (.eslintrc*), which is often the case while working with Next.js, Remix or Vite, then add the following code to your configuration file:



{
  "extends": ["plugin:prettier/recommended"]
}

And that's it! Now you can play around with it, create some file e.g. script.mjs, fill it with some messy and unformatted code and check for lint and formatting errors with this command:



npx eslint script.mjs # you can also use --fix flag

Good to know: If you're a Visual Studio Code user, you can enhance your coding experience by installing the ESLint and Prettier extensions. These extensions provide real-time error and warning highlighting, as well as automatic formatting and code fixing on save.

Thanks for reading! 🙇‍♂️ I hope this article will save you some time and frustration while configuring ESLint with Prettier in your future projects. Feel free to leave your questions and opinions in the comment section! You can also reach me directly on Twitter.

The Conundrum of the "Top X" Articles 🤔

Rafał Goławski — Fri, 08 Dec 2023 10:53:36 +0000

In the vast ocean of programming and technology, we all strive to stay afloat. DEV has emerged as one of the foremost platforms for developers to share knowledge, exchange ideas, and learn from one another. However, the platform's recent trend of "Top X Extensions You Must Know" or "Top Y GitHub Repositories For Junior Developers" posts may be causing more harm than good, particularly for inexperienced developers.

The FOMO Effect: The Fear of Missing Out, or FOMO, is a fairly common phenomenon in our ever-connected world. In the context of technology and programming, it manifests as the worry that you're missing out on key resources, tools, or information that could make you a more competent professional. The abundance of "must-know" posts on DEV might be unintentionally amplifying this anxiety among developers, especially those just starting in their tech journey.

The Impact: While these posts might seem helpful on the surface, they often lead to information overload and decision paralysis. Developers might find themselves spending more time agonizing over which tools or resources to focus on, rather than actually learning and applying new skills. This not only hampers their progress, but can also lead to burnout and decreased motivation.

The Algorithm Factor: The prevalence of these posts is likely influenced by the platform's algorithm, which typically favours popular and high-engagement content. This creates a vicious cycle where more of this type of content is produced and promoted, thereby exacerbating the issue.

Moving Forward: It is crucial for us, as a community, to recognize this problem and work towards a more balanced content ecosystem. We need to shift our focus from quantity to quality, and from "must-know" to "good-to-know". It's about time we start creating content that truly adds value to a developer's journey, without adding to their stress.

Conclusion: As content creators, it's our responsibility to ensure that our work aids, not hinders, the growth of our fellow developers. Let's start a conversation about how we can achieve this on DEV and other similar platforms. What are your thoughts on this issue? How can we make the DEV community more valuable and less overwhelming for every developer?

Remember, in the grand scheme of things, being a great developer is not about knowing every tool or resource out there. It's about problem-solving, creativity, and continuous learning. Let's focus on fostering these essential skills, and the rest will follow.

Parsing URL Search Parameters with Zod 💎

Rafał Goławski — Thu, 07 Sep 2023 12:00:51 +0000

Introduction

In today's digital age, the usage of URLs as a medium to share the state of the application is growing rapidly. This has become especially popular in web applications, where the user's actions can be replicated by simply sharing a URL. This article will introduce you to an efficient way of parsing URL search parameters with the use of Zod library and demonstrate how they can be used in a React form.

What is Zod?

Zod is a schema declaration and validation library for JavaScript and TypeScript. It can be used to create a "blueprint" or "schema" for JavaScript objects, ensuring that the data you're working with meets certain criteria before it's processed by your application. With the use of Zod, you can parse URL search parameters accurately and efficiently, and validate the data before it enters your system.

Parsing Parameters with Zod

Before we jump into parsing parameters with Zod, let's first install the library using npm. Open your terminal and navigate to your project directory. Run the following command to install Zod:

npm install zod

Now, let's dive into the code example to understand how to parse URL parameters using Zod.

The first part of the code defines a constant object named allowedValues, which consists of two properties, periods and posts. These properties are an array of strings that represent the allowed values for the corresponding search parameters.

const allowedValues = {  
  periods: ['1', '3', '6', '12'],  
  posts: ['10', '25', '50'],  
} as const;

Next, we define a schema ParamsSchema using Zod. This schema reflects the structure of our search parameters. We expect three parameters: tags, period, and posts. The tags parameter is expected to be a string, while period and posts parameters are expected to be one of the allowed values defined earlier. If these parameters are not present in the URL, we provide default values using the catch method.

import { z } from "zod";

const ParamsSchema = z.object({  
  tags: z.string().catch(''),  
  period: z.enum(allowedValues.periods).catch(allowedValues.periods[0]),  
  posts: z.enum(allowedValues.posts).catch(allowedValues.posts[0]),  
});

Finally, we create an instance of URLSearchParams with the current URL's search string and parse the search parameters using our schema.

const searchParams = new URLSearchParams(window.location.search);  

const params = ParamsSchema.parse({  
  tags: searchParams.get('tags'),  
  period: searchParams.get('period'),  
  posts: searchParams.get('posts'),  
});

This way, Zod helps us parse the search parameters from the URL and validates them against the defined schema. If the validation fails, Zod throws an error, which can be caught and handled accordingly.

Using Parsed Parameters in Form

After parsing URL parameters with Zod and validating them, you can use these values to set the initial state in your React components, for example, to set initial filters in a form.

Consider the following code example. Here, we have a React component named App, which consists of a form with two select inputs and a text input. These inputs correspond to the period, posts, and tags parameters we parsed from the URL.

export const App = () => {  
  return (  
    <form>  
      <input  
        type="text"  
        name="tags"  
        defaultValue={params.tags}  
        placeholder="javascript, react"  
      />  
      <select name="period" defaultValue={params.period}>  
        {allowedValues.periods.map((period, index) => (  
          <option key={`period-${index}`} value={period}>  
            {period}  
          </option>  
        ))}  
      </select>  
      <select name="posts" defaultValue={params.posts}>  
        {allowedValues.posts.map((post, index) => (  
          <option key={`post-${index}`} value={post}>  
            {post}  
          </option>  
        ))}  
      </select>  
      <button>Submit</button>  
    </form>  
  );  
};

In this code, we are setting the defaultValue attribute of each input to the corresponding parameter value from the URL. This way, when a user accesses the page with specific URL parameters, the form fields will be pre-filled with those values.

The map function is used to generate the options for the select inputs based on the allowedValues we defined earlier. Each option's value is set to the corresponding value from the allowedValues array, and the text inside the option tag is also set to the same value.

This approach allows you to create a seamless user experience, where the state of the form is linked with the URL parameters. This can be particularly useful for sharing links with pre-set filters or settings.

Summary

In conclusion, parsing and syncing URL search parameters with React state is a powerful way of enhancing user experience, making your application more interactive, and replicating a specific state of the app through a simple URL.

You can check out the full code for this tutorial below:

I hope you found this article helpful. If you have any questions or thoughts about this topic, please feel free to leave a comment below or contact me on Twitter. I'd love to hear your feedback.

Thanks for reading! 👋

Easy Tutorial: How to Create an Express API for Beginners

Rafał Goławski — Wed, 12 Jul 2023 13:58:15 +0000

Introduction

Express is a minimalistic Node.js framework. One of the key benefits of using Express is its ability to create robust and scalable APIs with ease. In this article, I would like to guide you on how you can create an API using this awesome technology.

Project initialization

Make sure you have Node.js installed on your computer. Then we can proceed to the project initialization. To do that, we need to run the following commands:

mkdir my-api        # Create directory for our project
cd my-api           # Navigate to the created directory
npm init -y         # Initialize new project
npm install express # Install dependencies
touch server.js     # Create main file

Now, let's open your preferred code editor and modify the package.json file by changing the scripts section to this:

"scripts": {
  "dev": "node --watch server.js",
  "start": "node server.js"
}

Here, we have defined two scripts for our project: dev and start, both responsible for running our code. However, dev supports watch mode, which means it will re-run on each code change. We will only use dev for development purposes.

Code

As an example, we will create a simple API for a to-do list application. In your preferred code editor, open the server.js file and paste the following code:

const express = require("express");

const port = 8080;
const app = express();
app.use(express.json());

const todos = [
  { id: 1, title: "Go grocery shopping 🛒", completed: true },
  { id: 2, title: "Do the laundry 🧺", completed: false },
];

app.listen(port, () => {
  console.log(`[server]: listening on port ${port}`);
});

In the code above, we initialized an Express server on port 8080. We used express.json() middleware to enable JSON content in the request body and defined a storage of our to-do items. For the sake of the simplicity of this article, I've used a regular JavaScript variable for it, but remember that for a production-ready application, you should always use stable database solutions such as MySQL or PostgreSQL.

Extracting data

To get data from our API, we will define our first endpoint, and we will use the GET method for it. Please paste the following code into the server.js file:

app.get("/api/todos", (req, res) => {
  res.status(200).json(todos);
});

Here, we defined our first endpoint - /api/todos. We set the response status to 200, assuming that it's successful, and serialized to-do items in the form of a JSON response.

To test our code, run the npm run dev command and navigate to http://localhost:8080/api/todos to see the results.

Inserting data

To insert data using our API, we will use the POST method for the /api/todos endpoint. The code goes as follows:

app.post("/api/todos", (req, res) => {
  if (!req.body.title) {
    res.status(400).json({ message: "Title is required" });
    return;
  }

  const title = String(req.body.title).trim();
  if (title.length < 3) {
    res.status(400).json({ message: "Title must be at least 3 characters" });
    return;
  }

  const newItem = {
    id: todos.length + 1,
    title,
    completed: false,
  };

  todos.push(newItem);
  res.status(201).json(newItem);
});

At first, we did some basic validation - we checked if the title is even present in the request body, and if not or if it's less than 3 characters, then we set the response status to 400, implying that the request was invalid, and we return the appropriate message.

Notice how we use return after failed validation. It's required to prevent any further code execution in the current endpoint.

If the validation is successful, then we proceed to creating a new to-do item and pushing it into our "database". Then we're setting the response status to 201, implying that we created a new item, and return it.

Unfortunately, to test this code, the browser won't be enough. You need to use tools such as Postman or Thunder Client if you're using VSCode editor.

Removing data

The last step will be to define the DELETE method for the /api/todos endpoint. We will use it to remove existing items from the "database".

app.delete("/api/todos/:id", (req, res) => {
  const id = Number(req.params.id);

  const itemIndex = todos.findIndex((todo) => todo.id === id);
  if (itemIndex === -1) {
    res.status(404).json({ message: `Item with id ${id} not found.` });
    return;
  }

  const removedItem = { ...todos[itemIndex] };

  todos.splice(itemIndex, 1);
  res.status(200).json(removedItem);
});

In order to define an item we want to delete, we used a route parameter (it's this /:id part in the endpoint). We can access it by using req.params object. So here, we checked if an item with the provided id even exists, and if not, then we set the response status to 404 and return the appropriate message. If it exists, then we simply remove it from our storage and return the removed item.

That would be it for this article. You can find the full code in the repository below:

rago4 / express-article

This repository is a part of "Easy Tutorial: How to Create an Express API for Beginners" article.

To initialize this project, simply clone the repository and run npm install command.

To run this code in watch mode, run npm run dev or npm run start if you don't need watch mode.

View on GitHub

I hope you enjoyed it and learned something new today. If you have any questions, feel free to leave them in the comment section below or contact me on my Twitter.

Thanks for reading! 👋

DEV Community: Rafał Goławski

Ilha for Svelte Developers

What is Ilha?

Why Ilha Makes Sense If You Know Svelte

The Mindset Shift

$props vs .input()

Svelte

Ilha

$state vs .state()

Svelte

Ilha

Object reactivity

$derived vs .derived()

Svelte

Ilha

$effect vs .effect()

Svelte

Ilha

Cleanup maps directly

One important difference

bind:value vs .bind()

Svelte

Ilha

Scoped styles vs .css()

Svelte

Ilha

Ilha Is Not Trying to Be a .svelte File

Svelte → Ilha Reference

Resources

Spin up Bun + Preact full-stack app in minutes 🚀

What we’re building

1. Initialize the project

2. Install Preact

3. Tell TypeScript where JSX comes from

4. Create the app files

5. Add scripts to package.json

6. Create the HTML shell

7. Write the server

8. Write the client

Run it!

Handling Layout Form Submission Inside a React Router Cookie Banner 🍪

Step 1: Setting Up the Layout Component

Step 2: Creating the Cookie Banner Component

Step 3: Adding the Cookie Banner to the Layout

Step 4: Handling Form Actions

Step 5: Improving User Experience: Redirecting Back

Step 6: Conditional Rendering of the Cookie Banner

Wrapping Up

🍞 React Router v7: The Problem with Toasts After Form Submissions

The Problem

The Fix

Why Write About This?

🗃️ Resource Routes in React Router v7

Creating JSON Endpoints

I meant to delete a quick post, but accidentally deleted an article I spent 4 hours on yesterday. Totally my fault - I ignored the pop-up warnings. Perhaps there are so many warnings on the web nowadays that I've started to ignore them. How's your Friday?

My Technical Writing Framework

Avoiding File Hashing in Vite #️⃣

How to make ESLint and Prettier work together 🛠️

Introduction 👨‍🏫

Make it play nice! 🤝

The Conundrum of the "Top X" Articles 🤔

Parsing URL Search Parameters with Zod 💎

Introduction

What is Zod?

Parsing Parameters with Zod

Using Parsed Parameters in Form

Summary

Easy Tutorial: How to Create an Express API for Beginners

Introduction

Project initialization

Code

Extracting data

Inserting data

Removing data

rago4 / express-article

`$props` vs `.input()`

`$state` vs `.state()`

`$derived` vs `.derived()`

`$effect` vs `.effect()`

`bind:value` vs `.bind()`

Scoped styles vs `.css()`

Ilha Is Not Trying to Be a `.svelte` File

5. Add scripts to `package.json`