There's a moment in woodworking — or so I've been told — when a craftsman stops thinking about the chisel and starts thinking only about the wood. The tool becomes invisible. It's no longer an intermediary between intention and creation; it's simply gone.

I've been chasing that feeling in software for years.

With React and Redux, I never quite got there. The tool was always present. Every feature began with the same liturgy: define the action type, write the action creator, build the reducer case, wire up the selector, connect the component. It was structured. It was predictable. And it was loud. The architecture was always announcing itself, always demanding attention before you could think about the actual problem you were solving.

Then I built an CRM demo system with SvelteKit 5, and something shifted. Not a dramatic revelation — more like realizing you've been holding your breath, and you finally exhale.

I want to show you what that exhale looks like — by tracing one feature, end to end. A client list page. Filtering, pagination, search, contacts, modals. The full thing. From the server to the store to the component and back.

The Store: A Class, Not a Configuration#

In my previous articles, I explored the migration from React/Redux to SvelteKit and the philosophical implications of Svelte 5 runes. But I want to go deeper now. Not into what changed, but why it matters — following the client list flow through every layer.

Let's start where most state management stories start: the store itself.

// src/lib/store/clients.svelte.ts
import type {
  Client,
  LeadStatus,
  PaginationState,
  ContactResponse,
} from '$lib/types'

export class ClientStore {
  // State as fields
  clients = $state<Client[]>([])
  pagination = $state<PaginationState>({
    currentPage: 1,
    totalPages: 1,
    totalItems: 0,
    itemsPerPage: 10,
  })
  filters = $state<{
    search: string
    lead: LeadStatus | null
  }>({
    search: '',
    lead: null,
  })
  loading = $state(false)
  error = $state<string | null>(null)

  // Contact sub-domain
  selectedClientContacts = $state<ContactResponse[]>([])
  contactModalOpen = $state(false)
  contactModalMode = $state<'create' | 'edit' | 'view'>('create')
  selectedContact = $state<ContactResponse | null>(null)

  // Methods as actions
  setClientsData(data: {
    clients: Client[]
    pagination: PaginationState
    filters?: { search?: string; lead?: LeadStatus | null }
  }): void {
    this.clients = data.clients
    this.pagination = data.pagination
    if (data.filters) {
      this.filters = {
        ...this.filters,
        search: data.filters.search || '',
        lead: data.filters.lead || null,
      }
    }
  }

  updateFilters(newFilters: {
    search?: string
    lead?: LeadStatus | null
  }): void {
    this.filters = { ...this.filters, ...newFilters }
  }

  setLoading(isLoading: boolean): void {
    this.loading = isLoading
  }

  // Contact modal orchestration
  viewContact(contact: ContactResponse): void {
    this.selectedContact = contact
    this.contactModalMode = 'view'
    this.contactModalOpen = true
  }

  createContact(): void {
    this.selectedContact = null
    this.contactModalMode = 'create'
    this.contactModalOpen = true
  }

  closeContactModal(): void {
    this.contactModalOpen = false
    this.selectedContact = null
  }

  // Nested updates
  addContactToClient(clientId: number, contact: ContactResponse): void {
    this.clients = this.clients.map((client) =>
      client.id === clientId
        ? {
            ...client,
            contacts: [...client.contacts, contact],
            contact_count: client.contacts.length + 1,
          }
        : client,
    )
    this.selectedClientContacts = [...this.selectedClientContacts, contact]
  }
}

export const clientStore = new ClientStore()

Stop and read this carefully. This is not Redux. This is not Vuex. This is object-oriented programming applied to state management.

The store is a class. It has fields (state) and methods (actions). When you call clientStore.setClientsData(...), you're calling a method on an instance. The state properties use the $state rune, which means Svelte automatically tracks their changes and updates any component that reads them.

There are no action creators. No reducers. No switch statements. No middleware. No connect(). No useSelector. No dispatch. The mental model is: an instance of a class that holds data and knows how to modify itself.

The $state rune is not a function call — it's a compiler instruction. Svelte sees it and generates exactly the reactive plumbing your code needs. At runtime, this is just a JavaScript class. Your IDE understands it. TypeScript validates it. A junior developer reads it and knows what it does.

This is simpler than Redux. But more importantly, it's honest — it doesn't pretend to be functional programming if you're writing imperative code anyway.

The River and the Pipes: How Data Reaches the Client List#

Now that we have the store, how does data reach it? This is where SvelteKit distinguishes itself not just from React, but from the entire mental model of client-side state management.

In Redux-world, data typically flows like this: the component mounts, dispatches an action, the action triggers an API call (through thunks or sagas or whatever middleware is fashionable this quarter), the response hits the reducer, the state updates, and the component re-renders through a selector.

That's a lot of pipes. Carefully assembled, meticulously maintained pipes.

SvelteKit proposes something different: What if the data just... arrived?

Act I: The Server Speaks First (+page.server.ts)#

Every page in SvelteKit can have a +page.server.ts file. This runs exclusively on the server — it has access to cookies, databases, internal APIs. For our client list, it fetches clients from the backend with whatever filters the URL carries:

// src/routes/clients/+page.server.ts
import { listClients } from '$lib/server/clients'
import type { PageServerLoad } from './$types'
import type { LeadStatus } from '$lib/types'

export const load: PageServerLoad = async ({ cookies, url }) => {
  const page = Number(url.searchParams.get('page') || '1')
  const search = url.searchParams.get('search') || ''
  const lead = url.searchParams.get('lead') as LeadStatus | null

  const clientsResponse = await listClients(cookies, {
    page,
    itemsPerPage: 10,
    search,
    lead: lead || undefined,
  })

  return {
    clients: clientsResponse.data,
    pagination: clientsResponse.pagination,
    filters: { search, lead },
  }
}

No client-side fetch. No loading spinner on first render. No flash of empty content. The data is there when the HTML arrives. The server did its job, quietly, before the browser ever opened its mouth to ask.

This is fundamentally different from Redux or any client-side state library. In those patterns, the client constructs API calls, handles loading states, manages error states. Here, the server is the authority. The server decides what data the client needs. The server handles authentication through cookies — no tokens in JavaScript, no auth headers in client code.

Act II: The Bridge (+page.ts)#

But here's the question: we have our ClientStore class on the client. How does server data reach it?

This is where +page.ts enters — the universal load function that runs on both server and client. It receives the data from +page.server.ts and acts as the bridge:

// src/routes/clients/+page.ts
import type { PageLoad } from './$types'
import { clientStore } from '$lib/store/clients.svelte'
import { browser } from '$app/environment'

export const load: PageLoad = async ({ data, depends }) => {
  depends('app:clients')

  if (browser) {
    clientStore.setClientsData({
      clients: data.clients,
      pagination: data.pagination,
      filters: data.filters,
    })
    clientStore.setLoading(false)
  }

  return data
}

Study this for a moment. The data parameter contains everything +page.server.ts returned. The depends("app:clients") call registers a dependency key — when we later call invalidate("app:clients"), SvelteKit knows to re-run this entire chain.

The if (browser) guard is the key insight: during SSR, this code runs on the server where we don't need to hydrate a client-side store. But when the page loads in the browser — or when the user navigates client-side — we pour the server data into our ClientStore instance. One method call: clientStore.setClientsData(...). The class does the rest.

This is the pattern that Redux could never offer, because Redux wasn't designed with a full-stack framework in mind. Here: server loads the data, the bridge hydrates the store, components read from the store.

No prop drilling through seventeen layers. No context providers wrapping your tree. No useEffect that fires after the first render to "sync" state. The store is ready when the component mounts.

Act III: The Component Breathes (+page.svelte → client-list.svelte)#

And now the page component itself:

<!-- src/routes/clients/+page.svelte -->
<script lang="ts">
  import ClientList from "$lib/components/clients/client-list.svelte";
</script>

<ClientList />

That's the entire file. No props. No data destructuring. No store subscriptions. The component delegates to ClientList, which reads directly from the store:

<!-- src/lib/components/clients/client-list.svelte -->
<script lang="ts">
  import SearchBar from "./search-bar.svelte";
  import Filters from "./filters.svelte";
  import ClientTable from "./client-table.svelte";
  import RefreshButton from "./refresh-button.svelte";
  import { Button } from "$lib/components/ui/button/index.js";
  import Plus from "@lucide/svelte/icons/plus";
  import { goto } from "$app/navigation";
  import { clientStore } from "$lib/store/clients.svelte";

  const clientsList = $derived(clientStore.clients);
  const paginationData = $derived(clientStore.pagination);
  const currentFilters = $derived(clientStore.filters);

  const clientsFound = $derived(
    `${paginationData.totalItems} ${paginationData.totalItems === 1 ? "client" : "clients"} found`,
  );

  function handlePageChange(pageNum: number) {
    if (pageNum === paginationData.currentPage) return;
    const url = new URL(window.location.href);
    url.searchParams.set("page", String(pageNum));
    clientStore.setLoading(true);
    goto(url.toString(), { replaceState: false });
  }
</script>

<div class="space-y-4">
  <div class="flex items-center justify-between">
    <h1 class="text-2xl font-bold">Clients</h1>
    <div class="flex items-center gap-2">
      <RefreshButton />
      <Button href="/clients/new">
        <Plus class="mr-2 h-4 w-4" />
        Add Client
      </Button>
    </div>
  </div>

  <div class="flex flex-col gap-4 sm:flex-row sm:items-center sm:justify-between">
    <SearchBar />
    <Filters activeFilter={currentFilters.lead || "all"} />
  </div>

  <div class="text-muted-foreground text-sm">{clientsFound}</div>

  <ClientTable clients={clientsList} />
</div>

Notice what's happening. $derived creates reactive references to the store. When clientStore.clients changes, clientsList updates. When clientStore.pagination changes, the pagination buttons re-render. The compiler generates code that does this tracking for you.

No selectors. No memoization. No useCallback worries. No virtual DOM diffing. No React.memo. No shouldComponentUpdate. Just: "This value depends on that value. Update it when that value changes."

And SearchBar, Filters, ClientTable — each of these child components imports clientStore independently. They don't receive it as a prop. They don't need a Provider ancestor. They just reach for the store and use it. The class instance is the shared state.

The Feedback Loop: Filtering in Action#

Here's where you see the full cycle come alive. The Filters component:

<!-- src/lib/components/clients/filters.svelte -->
<script lang="ts">
  import { clientStore } from "$lib/store/clients.svelte";
  import { Button } from "$lib/components/ui/button/index.js";
  import { goto } from "$app/navigation";
  import type { LeadStatus } from "$lib/types";

  const { activeFilter = "all" } = $props<{ activeFilter?: LeadStatus | "all" }>();

  const isLoading = $derived(clientStore.loading);

  function handleFilterChange(filter: LeadStatus | "all") {
    if (filter === "all") {
      clientStore.updateFilters({ lead: null });
    } else {
      clientStore.updateFilters({ lead: filter });
    }

    clientStore.setLoading(true);

    const url = new URL(window.location.href);
    if (filter === "all") {
      url.searchParams.delete("lead");
    } else {
      url.searchParams.set("lead", filter);
    }
    url.searchParams.delete("page");

    goto(url.toString(), { replaceState: false });
  }
</script>

And the SearchBar:

<!-- src/lib/components/clients/search-bar.svelte -->
<script lang="ts">
  import { Input } from "$lib/components/ui/input/index.js";
  import { Button } from "$lib/components/ui/button/index.js";
  import Search from "@lucide/svelte/icons/search";
  import RefreshCcw from "@lucide/svelte/icons/refresh-ccw";
  import { clientStore } from "$lib/store/clients.svelte";
  import { goto } from "$app/navigation";

  // Track search query in local state, initialize from store
  let searchQuery = $state(clientStore.filters.search || "");
  let searchTimeout: ReturnType<typeof setTimeout>;

  // Handle search as user types with debounce
  function handleSearchInput() {
    // Update the store directly for immediate UI feedback
    clientStore.updateFilters({ search: searchQuery });

    // Clear existing timeout
    clearTimeout(searchTimeout);

    // Debounce the actual navigation
    searchTimeout = setTimeout(() => {
      performSearch();
    }, 500); // 500ms debounce
  }

  function performSearch() {
    clientStore.setLoading(true);

    // Build URL with search term
    const url = new URL(window.location.href);
    if (searchQuery) {
      url.searchParams.set("search", searchQuery);
    } else {
      url.searchParams.delete("search");
    }
    url.searchParams.delete("page"); // Reset to first page when searching

    // Use goto to trigger server-side navigation
    goto(url.toString(), { replaceState: false });
  }
</script>

Watch the cycle:

1. User clicks "Hot" filter → clientStore.updateFilters({ lead: "hot" }) — instant UI feedback
2. goto() changes the URL → SvelteKit sees URL change
3. +page.server.ts re-runs → server fetches only hot leads from backend API
4. +page.ts receives new data → clientStore.setClientsData(...) hydrates the store
5. Components re-render → $derived(clientStore.clients) picks up the new filtered list

The same cycle for search. The same cycle for pagination. The URL is the source of truth for what the server fetches; the store is the source of truth for what the UI shows. They're not competing — they're collaborating.

In React, this pattern would require TanStack Query or SWR alongside Redux, creating two parallel state systems fighting for authority. Or you'd wire together useEffect, useState, useCallback, router listeners, and cache invalidation logic across half a dozen files. In SvelteKit, the framework is the data layer.

The Redux Mental Model, Honestly#

Let's be concrete about what this replaces. Imagine the same filtering feature in Redux:

// Redux: actions.ts
export const SET_CLIENTS_DATA = 'SET_CLIENTS_DATA'
export const UPDATE_FILTERS = 'UPDATE_FILTERS'
export const SET_LOADING = 'SET_LOADING'

// Redux: reducer.ts
const clientsReducer = (state = initialState, action) => {
  switch (action.type) {
    case 'SET_CLIENTS_DATA':
      return {
        ...state,
        clients: action.payload.clients,
        pagination: action.payload.pagination,
      }
    case 'UPDATE_FILTERS':
      return {
        ...state,
        filters: { ...state.filters, ...action.payload },
      }
    case 'SET_LOADING':
      return { ...state, loading: action.payload }
    default:
      return state
  }
}

// Redux: component.tsx
const clients = useSelector((state) => state.clients.clients)
const filters = useSelector((state) => state.clients.filters)
const dispatch = useDispatch()

const handleFilter = (lead) => {
  dispatch({ type: 'UPDATE_FILTERS', payload: { lead } })
  dispatch({ type: 'SET_LOADING', payload: true })
  // ...then navigate, and hope the useEffect catches the new data
}

Now the same thing in Svelte 5:

// Svelte 5: in the component
const clients = $derived(clientStore.clients)
const filters = $derived(clientStore.filters)

const handleFilter = (lead) => {
  clientStore.updateFilters({ lead })
  clientStore.setLoading(true)
  goto(url, { replaceState: false })
}

The Svelte version isn't a little simpler. It's a different order of magnitude of simplicity. And not because it's doing less — the same features are there. Filtering. Loading states. Pagination. Shared state across sibling components. It's simpler because the framework eliminated the ceremony.

Computed Properties: When Getters Are Enough#

The same pattern extends beyond the client list. Consider the UserStore, which demonstrates how class getters become reactive computed properties:

// src/lib/store/user.svelte.ts
export class UserStore {
  user = $state<User | null>(null)

  get isAuthenticated() {
    return this.user !== null
  }

  get permissions(): UserPermissions | null {
    if (!this.user) return null
    return {
      canCreateClients: this.user.can_manage_clients,
      canDeleteClients: this.user.can_delete_clients,
      isAdmin: this.user.is_superuser || this.user.is_staff,
    }
  }

  get displayName(): string | null {
    if (!this.user) return null
    return this.user.first_name && this.user.last_name
      ? `${this.user.first_name} ${this.user.last_name}`
      : this.user.username
  }
}

export const userStore = new UserStore()

Standard JavaScript getters. But because they reference $state properties, Svelte automatically tracks them as derived values. They recompute when their dependencies change. No useMemo. No createSelector. No dependency arrays to get wrong.

In a component: userStore.displayName. One expression. Type-safe. Automatically reactive when userStore.user changes.

In Redux: useSelector(selectDisplayName) — where selectDisplayName is a separate function, in a separate file, that you hope stays in sync with the state shape.

When Not to Use a Store: The Wisdom of Constraint#

Here's something often unmentioned in state management articles: not everything should be in a store.

In this demo system, the dashboard takes a different approach:

<!-- src/routes/dashboard/+page.svelte -->
<script lang="ts">
  import StatsCard from "$lib/components/dashboard/stats-card.svelte";
  import RecentClients from "$lib/components/dashboard/recent-clients.svelte";
  import type { PageData } from "./$types";

  let { data } = $props<{ data: PageData }>();
</script>

<StatsCard title="Total Clients" value={data.statistics.totalClients} description="Demo" />
<RecentClients clients={data.recentClients} />

No store. data props directly from the server. And that's intentional. And wise.

The dashboard is a read-only summary view. It aggregates statistics, shows recent items, displays charts. There's no filtering. No pagination. No modals. No user interaction that modifies this data. The data flows in one direction — from server to template — and stays there.

Stores should be used for:

• Shared state across multiple components/routes
• State that persists across navigation
• Complex interactions (filtering, pagination, modals, CRUD)

Props should be used for:

• Data that flows parent → child
• Read-only displays, dashboards, summaries
• Data that doesn't need to be shared with siblings

Component-local $state should be used for:

• Form inputs, toggle states, temporary values
• UI state not needed by other components

A well-designed application demonstrates this wisdom. The clients page uses a store because SearchBar, Filters, ClientTable, and RefreshButton all need shared access. The dashboard passes props because data flows in one direction. The framework doesn't impose a single pattern. It asks: does this state need to be shared?

This is the philosophical shift Redux missed. Redux assumes all state must be managed. Svelte 5 asks: does it need to be?

No Library. That's the Point.#

Let me state something that should be obvious but somehow isn't: we use no state management library in this entire application.

No Redux. No Zustand. No Jotai. No Recoil. No MobX. No Pinia. No NgRx.

The entire store layer — user authentication with permission getters, client management with nested contacts and modal orchestration, task tracking with filtered pagination, calendar events with drag-to-create — is built with nothing but Svelte 5 runes and plain TypeScript classes.

In the React ecosystem, choosing a state management library is itself a project. Evaluating options, learning APIs, configuring middleware, debugging integration issues. Teams spend days on this decision. Blog posts rank them. Conference talks compare them.

Svelte 5 sidesteps the question entirely. $state() makes a property reactive. $derived() computes from reactive properties. $effect() runs side effects. Classes organize your domain. Export an instance. Import it where you need it.

That's the whole API. There's nothing else to learn.

What This Means for the Craft#

I've been thinking about why this matters beyond the technical arguments. Beyond bundle sizes and benchmark numbers and developer experience surveys.

When I write Redux, I spend mental energy on action naming conventions, reducer organization, selector memoization, middleware configuration, DevTools setup, type definitions that mirror structure three times over. When I write Svelte 5 stores, I think about my domain. Clients. Contacts. Filters. Pagination. That's it.

For a developer building a complex application, this compounds. Every feature is 30-40% faster to implement. Every bug is easier to trace — no action logs to decode. Every refactor is simpler — no reducer restructuring. Over months, this adds up to weeks of saved time.

But it's more than productivity. It's about the relationship between the developer and the code. Software should be shaped by the problem, not by the framework's expectations. When I design the ClientStore, I'm thinking about clients and contacts and how a sales team filters their pipeline. I'm not thinking about which middleware handles the async flow. I'm not wondering if my selector is properly memoized.

The framework becomes invisible. And when the framework is invisible, all that's left is the thing you're actually making.

The chisel disappears. You see only the wood.

When I first started considering Svelte for my enterprise canvas application, I kept asking myself the wrong question: "What if Svelte dies?"

I spent days researching market share. Stack Overflow answer counts. I compared npm downloads like they were stock charts. React has a million developers. Svelte has fifty thousand. The math was obvious, right?

Then something clicked.

The Question Nobody Asks#

Here's what I realized: Nobody asks "What if React dies?" But they should.

Meta can change direction. They've done it before — remember the class components to hooks migration? Remember when everyone had to relearn everything? The React ecosystem churns constantly: Redux, then Context, then Zustand, then Jotai, then Recoil, then... what's next?

No framework is truly "safe." The difference is that React developers have normalized the chaos. We call it "ecosystem maturity."

But here's the uncomfortable truth I discovered while building my drawing application: the framework is maybe 10% of your codebase. The other 90%? That's your domain logic. Your canvas operations. Your PDF rendering. Your business rules. Usually, it's like that in a big enterprise application.

And all of that is framework-agnostic.

What Actually Matters#

I've been working with React and Redux for years. Enterprise applications. Complex state. The whole ceremony.

You know the ceremony I'm talking about:

// The Redux dance: actions, reducers, selectors, dispatch
// actions.ts
export const ADD_ANNOTATION = 'ADD_ANNOTATION'
export const UNDO = 'UNDO'
export const REDO = 'REDO'

export const addAnnotation = (annotation) => ({
  type: ADD_ANNOTATION,
  payload: annotation,
})

// reducer.ts
const initialState = {
  past: [],
  present: [],
  future: [],
}

function historyReducer(state = initialState, action) {
  switch (action.type) {
    case ADD_ANNOTATION:
      return {
        past: [...state.past, state.present],
        present: [...state.present, action.payload],
        future: [],
      }
    case UNDO:
      if (state.past.length === 0) return state
    // ... another 20 lines
    // ... REDO case, another 15 lines
  }
}

// Component.tsx
import { useDispatch, useSelector } from 'react-redux'

function AnnotationPanel() {
  const dispatch = useDispatch()
  const annotations = useSelector((state) => state.history.present)
  const canUndo = useSelector((state) => state.history.past.length > 0)

  const handleAdd = () => {
    dispatch(
      addAnnotation({
        /* ... */
      }),
    )
  }

  return <button onClick={handleAdd}>Add</button>
}

That's roughly 80 lines of code. To add an item to a list. With undo capability. We've normalized this. We call it "predictable state management." We've convinced ourselves the boilerplate is a feature, not a bug.

Enter Svelte 5: When Less Becomes More#

Now look at Svelte 5 with class-based stores using runes:

// stores/projects.svelte.ts
import type { Project } from "../types/projects";
import { getProjects } from "../services/projects";

export class ProjectsStore {
    projects = $state<Project[]>([]);
    selectedProject = $state<Project | null>(null);
    loading = $state<boolean>(false);
    error = $state<string | null>(null);

    get hasProjects() {
        return this.projects.length > 0;
    }

    get selectedProjectId() {
        return this.selectedProject?.id ?? null;
    }

    setProjects(projects: Project[]): void {
        this.projects = projects;
        this.error = null;
    }

    addProject(project: Project): void {
        this.projects = [...this.projects, project];
    }

    async fetchProjects(): Promise<void> {
        this.loading = true;
        this.error = null;

        try {
            const projects = await getProjects();
            this.setProjects(projects);
        } catch (err) {
            this.error = err instanceof Error ? err.message : "Failed to fetch projects";
        } finally {
            this.loading = false;
        }
    }
}

export const projectsStore = new ProjectsStore();

That's it. No actions. No reducers. No dispatch. No selectors. No connect(). No useSelector. No middleware.

Just a class. With properties. That are reactive.

In the component:

<script lang="ts">
  import { projectsStore } from "../stores/projects.svelte";
</script>

<button onclick={() => projectsStore.addProject(newProject)}>
  Add Project
</button>

{#if projectsStore.loading}
  <p>Loading...</p>
{:else}
  <ul>
    {#each projectsStore.projects as project}
      <li>{project.name}</li>
    {/each}
  </ul>
{/if}

No ceremony. No dance. You just... use it.

The Philosophy Behind Runes#

Svelte 5's runes ($state, $derived, $effect) represent a philosophical shift. They're not just syntax sugar — they're a statement about what reactivity should feel like.

In React, reactivity is opt-in through hooks, wrapped in rules you must memorize. Don't call hooks conditionally. Always include dependencies in useEffect. Memoize everything or watch your app crawl.

In Svelte 5, you say what you mean:

let count = $state(0) // This is state
let doubled = $derived(count * 2) // This derives from state

$effect(() => {
  console.log('Count changed:', count)
})

The $ prefix is a rune — a compiler instruction. Not a runtime hook. Not a function that runs on every render. A compile-time transformation that generates exactly the reactive code you need.

The class-based approach takes this further. Instead of scattered stores and derived values, you encapsulate your domain:

export class AuthStore {
    user = $state<User | null>(null);
    loading = $state<boolean>(false);
    error = $state<string | null>(null);

    get isAuthenticated() {
        return this.user !== null;
    }

    clearAuth(): void {
        this.user = null;
        this.error = null;
        this.loading = false;
    }
}

export const authStore = new AuthStore();

This feels like writing JavaScript. Not React-flavored JavaScript. Not Redux-flavored JavaScript. Just... JavaScript with superpowers.

The Data Flow Difference#

Let me show you what data flow looks like in practice.

React/Redux mental model:#

JavaScriptComponent → dispatch(action) → middleware → reducer → new state → selector → component re-render

Every step is explicit. Every step is traceable. Every step is boilerplate.

Svelte 5 mental model:#

Component → store.property = value → component re-renders

That's not an oversimplification. That's the actual model.

When you write projectsStore.projects = newProjects, Svelte knows. The compiler saw your $state declaration. It generated the reactive bindings. Your components using projectsStore.projects will update.

No action to dispatch. No reducer to write. No selector to optimize. No React.memo to consider.

The Performance Argument (And Why It Doesn't Matter)#

I'll be honest: when I looked at raw performance numbers, the difference was... not what I expected.

For most operations in my canvas application, the differences were barely noticeable. Tool switching? Imperceptible in both frameworks. Drawing strokes? Konva is the bottleneck, not the framework — both hit 60fps without breaking a sweat.

The real performance bottlenecks? PDF rendering with pdf.js. Canvas operations with Konva. Network latency. None of these care about your framework choice.

So why switch?

Developer Experience: The Real Win#

Here's the uncomfortable truth about framework choices: performance gains are marginal, but developer experience compounds. When I write Redux, I spend mental energy on:

• Action naming conventions
• Reducer organization
• Selector memoization
• Middleware configuration
• DevTools setup
• Type definitions that mirror structure three times over

When I write Svelte 5 stores, I think about:

• My domain

That's it. I think about projects and annotations and tools. Not about the ceremony of making them reactive.

For a solo developer building a complex application, this compounds. Every feature is 30-40% faster to implement. Every bug is easier to trace (no action logs to decode). Every refactor is simpler (no reducer restructuring).

Over months, this adds up to weeks of saved time.

The Hiring Question#

"But what about hiring? React developers are everywhere!"

Let me share what I've seen in enterprise applications: finding a developer who truly understands React deeply, knows Redux architecture properly, can work with Canvas APIs, understands PDF manipulation — or any complex domain logic, whether that's financial systems, healthcare workflows, real-time collaboration, or other specialized business domains — AND writes clean maintainable code — is already hard.

A good developer will pick up Svelte 5 in few weeks. The runes syntax is simpler than hooks. The class-based stores are just... classes. There's less to learn, not more.

When I eventually hire, I'll look for:

• Strong JavaScript fundamentals
• Experience in the relevant domain
• Learning ability

Framework-specific experience? Nice to have. But I'd rather hire someone who can learn than someone who only knows one tool.

What I Actually Built#

I didn't switch to Svelte for performance metrics. I switched because I wanted to write less code that does more.

My canvas application now has:

• Class-based stores for each domain (projects, annotations, canvas, auth)
• Derived properties that just work (no useMemo, no selectors)
• Async operations that feel natural (no thunks, no sagas)
• TypeScript that helps instead of fighting me

The migration could take about two to three weeks for a medium-sized application. Most of that time goes to UI components, not state management. The state management is actually faster to implement in Svelte than it is to maintain in Redux.

The Philosophical Conclusion#

Every few years, the web development world declares a new winner. jQuery. Backbone. Angular. React. And someday, something else.

The developers who thrive aren't the ones who bet on the winning horse. They're the ones who understand that the horse doesn't matter as much as knowing how to ride.

Your domain logic — the actual business value you create — is framework-agnostic. Your understanding of state management patterns transcends any specific implementation. Your ability to learn new tools is more valuable than mastery of current ones.

I chose Svelte 5 not because I think it will "win." I chose it because it lets me focus on what I'm actually building — the product, the features, the problems I'm solving for users.

🎨 The framework is just the canvas. What you paint on it is what matters. 🖌️

SolidJS is a good framework, but it is still not recognized in the market, and the community is not big. However, Svelte is ready to take the next step in the frontend world, and big companies and systems can start thinking about implementing it as part of their tech stack!

A Fundamental Shift in Architecture#

One of the first things I noticed when migrating to SvelteKit - CRM demo project was the fundamentally different approach to layouts and routing. In NextJS/React, we're used to explicitly importing layout components and wrapping our pages manually. With SvelteKit, I discovered that layouts automatically wrap pages in their directories through a file-based system.

<!-- src/routes/+layout.svelte -->
<script lang="ts">
  import '../app.css';
  import ProtectedLayout from "$lib/components/layouts/protected-layout.svelte";
  import type { LayoutData } from './$types';

  let { data, children } = $props<{data: LayoutData, children: any}>();
</script>

{#if data.user}
  <ProtectedLayout user={data.user}>
    {@render children()}
  </ProtectedLayout>
{:else}
  {@render children()}
{/if}

This simple layout file automatically wraps every page in the application, conditionally applying a protected layout for authenticated users. No manual imports, no explicit wrapping - just a clean, declarative approach to page structure.

The Data Flow Revolution: Built-in State Management#

Perhaps the most mind-blowing aspect of SvelteKit for me, coming from React/Redux, was discovering how data flows through the application. In Redux, we spend hours setting up stores, actions, reducers, and connectors. With SvelteKit, I found myself with what felt like a hidden "global state provider" built right into the framework.

The SvelteKit Data Loading Chain#

When you create a +layout.server.ts file in SvelteKit, it automatically acts as a data provider for:

• That layout file (+layout.svelte)
• Any page within that directory (+page.svelte)
• Any child layouts/pages in subdirectories

This means data can cascade through your entire application without any explicit prop drilling or context providers. The framework just handles it.

// /routes/+layout.server.ts
export const load = () => {
  return {
    user: { id: 1, name: "Alice" },
    settings: { theme: "dark" }
  };
};

// /routes/dashboard/+layout.server.ts
export const load = ({ parent }) => {
  // Get parent data first! This connects to the upstream "provider"
  const parentData = await parent();

  return {
    // Add new dashboard-specific data
    tasks: ["Task 1", "Task 2"],

    // You can also transform parent data if needed
    userWithRole: {
      ...parentData.user,
      role: "admin"
    }
  };
};

Then in ANY component within the hierarchy, you can just access the data:

<script>
  // In any +page.svelte or +layout.svelte
  let { data } = $props<{data: PageData}>();

  // data now contains:
  // {
  //   user: { id: 1, name: "Alice" },
  //   settings: { theme: "dark" },
  //   tasks: ["Task 1", "Task 2"],
  //   userWithRole: { id: 1, name: "Alice", role: "admin" }
  // }
</script>

<h1>Welcome, {data.user.name}!</h1>
<p>You have {data.tasks.length} tasks</p>

The Redux Mental Model vs. The Svelte Approach#

Coming from Redux, I initially approached Svelte stores with the same mental model. Here's how I first implemented my client store, following a very Redux-like pattern:

// Redux-like approach in Svelte
import { writable, derived, type Writable } from 'svelte/store';
import type { Client, LeadStatus, PaginationState } from '$lib/types';

// Define the state structure
interface ClientsState {
  clients: Client[];
  pagination: PaginationState;
  filters: {
    search: string;
    lead: LeadStatus | null;
  };
  loading: boolean;
  error: string | null;
}

// Initial state
const initialState: ClientsState = {
  clients: [],
  pagination: {
    currentPage: 1,
    totalPages: 1,
    totalItems: 0,
    itemsPerPage: 10,
  },
  filters: {
    search: '',
    lead: null,
  },
  loading: false,
  error: null,
};

// Create the writable store
function createClientsStore() {
  const { subscribe, set, update }: Writable<ClientsState> = writable(initialState);
  return {
    subscribe,
    // Set entire state - useful when hydrating from SSR
    setData: (data: {
      clients: Client[];
      pagination: PaginationState;
      filters?: { search?: string; lead?: LeadStatus | null }
    }) => {
      update(state => ({
        ...state,
        clients: data.clients,
        pagination: data.pagination,
        filters: {
          search: data.filters?.search || '',
          lead: data.filters?.lead || null,
        },
        loading: false,
        error: null
      }));
    },
    // Set loading state
    setLoading: (isLoading: boolean) => {
      update(state => ({ ...state, loading: isLoading }));
    },
    // Set error state
    setError: (error: string | null) => {
      update(state => ({ ...state, error, loading: false }));
    },
    // Update filters
    updateFilters: (filters: { search?: string; lead?: LeadStatus | null }) => {
      update(state => ({
        ...state,
        filters: { ...state.filters, ...filters }
      }));
    },
    // Reset to initial state
    reset: () => set(initialState)
  };
}

// Create the store instance
export const clientsStore = createClientsStore();

// Derived stores for convenience
export const filteredClients = derived(clientsStore, $store => {
  let filtered = [...$store.clients];

  // Apply lead filter if set
  if ($store.filters.lead) {
    filtered = filtered.filter(client => client.lead === $store.filters.lead);
  }

  // Apply search filter if set
  if ($store.filters.search) {
    const searchLower = $store.filters.search.toLowerCase();
    filtered = filtered.filter(client =>
      client.company_name?.toLowerCase().includes(searchLower) ||
      client.first_name.toLowerCase().includes(searchLower) ||
      client.last_name.toLowerCase().includes(searchLower) ||
      client.email.toLowerCase().includes(searchLower)
    );
  }

  return filtered;
});

// Loading state
export const isLoading = derived(clientsStore, $store => $store.loading);

// Error state
export const error = derived(clientsStore, $store => $store.error);

This approach works, but it's heavy with Redux concepts, including:

• A single large state object
• Immutable update patterns
• Action creator functions
• A lot of boilerplate

As I became more comfortable with Svelte, I realized there's a much simpler, more idiomatic Svelte approach:

// Svelte-native approach
import { writable, derived } from 'svelte/store';
import type { Client, LeadStatus, PaginationState } from '$lib/types';

// Separate stores for different concerns
export const clients = writable<Client[]>([]);
export const pagination = writable<PaginationState>({
  currentPage: 1,
  totalPages: 1,
  totalItems: 0,
  itemsPerPage: 10,
});
export const filters = writable<{
  search: string;
  lead: LeadStatus | null;
}>({
  search: "",
  lead: null,
});

// Loading and error states
export const loading = writable(false);
export const error = writable<string | null>(null);

// Derived store for filtered clients
export const filteredClients = derived([clients, filters], ([$clients, $filters]) => {
  // If no filters are applied, return all clients
  if (!$filters.search && !$filters.lead) {
    return $clients;
  }

  // Apply filters
  return $clients.filter((client) => {
    // Filter by lead status
    if ($filters.lead && client.lead !== $filters.lead) {
      return false;
    }

    // Filter by search term
    if ($filters.search) {
      const term = $filters.search.toLowerCase();
      return (
        client.company_name?.toLowerCase().includes(term) ||
        client.first_name.toLowerCase().includes(term) ||
        client.last_name.toLowerCase().includes(term) ||
        client.email.toLowerCase().includes(term)
      );
    }

    return true;
  });
});

// Simple action to set clients data
export function setClientsData(data: {
  clients: Client[];
  pagination: PaginationState;
  filters?: { search?: string; lead?: LeadStatus | null };
}) {
  clients.set(data.clients);
  pagination.set(data.pagination);

  if (data.filters) {
    filters.update((currentFilters) => ({
      ...currentFilters,
      search: data.filters?.search || "",
      lead: data.filters?.lead || null,
    }));
  }
}

// Action to update filters
export function updateFilters(newFilters: { search?: string; lead?: LeadStatus | null }) {
  filters.update((f) => ({ ...f, ...newFilters }));
}

// Action to reset filters
export function resetFilters() {
  filters.set({ search: "", lead: null });
}

// Action to set loading state
export function setLoading(isLoading: boolean) {
  loading.set(isLoading);
}

// Action to set error state
export function setError(errorMessage: string | null) {
  error.set(errorMessage);
}

This approach is much cleaner, with:

• Separate, focused stores for specific pieces of state
• Simpler update functions
• Automatic reactivity through derived stores
• Minimal boilerplate

Integrating SvelteKit Data Flow with Stores#

One of the most elegant patterns I discovered was integrating SvelteKit's server data loading with client-side stores. In my CRM application, I implemented a hybrid approach:

1. Server-side data loading in +page.server.ts:

// src/routes/clients/+page.server.ts
export const load: PageServerLoad = async ({ cookies, url }) => {
  // Get query parameters
  const page = Number(url.searchParams.get("page") || "1");
  const search = url.searchParams.get("search") || "";
  const lead = url.searchParams.get("lead") as LeadStatus | null;

  // Fetch data with filters
  const clientsResponse = await listClients(cookies, {
    page,
    itemsPerPage: 10,
    search,
    lead: lead || undefined,
  });

  return {
    clients: clientsResponse.data,
    pagination: clientsResponse.pagination,
    filters: {
      search,
      lead,
    },
  };
};

2. Client-side store initialization in +page.ts:

// src/routes/clients/+page.ts
import type { PageLoad } from "./$types";
import { setClientsData } from "$lib/store/clients";
import { browser } from "$app/environment";

export const load: PageLoad = async ({ data, depends }) => {
  // Register a dependency to ensure the data is re-fetched when navigating
  depends("app:clients");

  // If we're in the browser, update the store with the data from the server
  if (browser) {
    setClientsData({
      clients: data.clients,
      pagination: data.pagination,
      filters: data.filters,
    });
  }

  // Return the data as-is for the page component
  return data;
};

3. Data access in components via props and/or stores:

<!-- src/lib/components/clients/client-list.svelte -->
<script lang="ts">
  import type { PaginationState, LeadStatus } from "$lib/types";
  import SearchBar from "./search-bar.svelte";
  import Filters from "./filters.svelte";
  import ClientTable from "./client-table.svelte";
  import RefreshButton from "./refresh-button.svelte";
  import { Button } from "$lib/components/ui/button/index.js";
  import Plus from "@lucide/svelte/icons/plus";

  // Import stores
  import {
    filteredClients,
    pagination as paginationStore,
    filters as filtersStore
  } from "$lib/store/clients";

  // We still accept props for the initial SSR data
  let { clients, pagination, filters = {} } = $props<{
    clients: any[];
    pagination: PaginationState;
    filters: { search?: string; lead?: LeadStatus };
  }>();

  // Use store values directly with $ prefix and $derived for reactivity
  const clientsList = $derived($filteredClients);
  const paginationData = $derived($paginationStore);
  const currentFilters = $derived($filtersStore);

  // Compute number of clients found
  const clientsFound = $derived(
    `${paginationData.totalItems} ${paginationData.totalItems === 1 ? 'client' : 'clients'} found`
  );
</script>

<!-- Component markup would go here, using clientsList, paginationData, etc. -->

This approach gives me the best of both worlds:

• Server-rendered initial data for SEO and performance
• Client-side reactivity for instant UI updates
• A consistent data pattern throughout my application

Svelte5 Runes: A New Level of Reactivity#

Svelte5 introduces runes - a new syntax for reactivity that makes the code even more elegant. Runes like $state(), $derived, and the $ prefix for store subscriptions create a unified reactive programming model:

<script lang="ts">
  import {
    updateFilters,
    filters,
    loading
  } from "$lib/store/clients";
  import { Button } from "$lib/components/ui/button/index.js";
  import type { LeadStatus } from "$lib/types";

  const { activeFilter = "all" } = $props<{ activeFilter?: LeadStatus | "all" }>();

  // Access store directly with $derived
  const isLoading = $derived($loading);
  const storeFilters = $derived($filters);

  function handleFilterChange(filter: LeadStatus | "all") {
    // Update store directly
    if (filter === "all") {
      updateFilters({ lead: null });
    } else {
      updateFilters({ lead: filter });
    }

    // Update URL without page reload
    const url = new URL(window.location.href);
    if (filter === "all") {
      url.searchParams.delete("lead");
    } else {
      url.searchParams.set("lead", filter);
    }
    url.searchParams.delete("page"); // Reset to first page when filtering
    history.pushState({}, "", url.toString());
  }
</script>

The $derived rune creates variables that automatically update when their dependencies change, eliminating the need for useEffect-style hooks or complicated state management.

No More "Provider Hell"#

One of the most striking differences I found between React/Redux and Svelte is the simplicity of data flow. In React, we often end up with deeply nested providers:

// React "Provider Hell"
<AuthProvider>
  <ThemeProvider>
    <DataProvider>
      <LayoutProvider>
        <App />
      </LayoutProvider>
    </DataProvider>
  </ThemeProvider>
</AuthProvider>

With SvelteKit's built-in data loading and Svelte's stores, this entire hierarchy simply disappears. Data flows naturally from server to components, and stores are globally accessible without any provider wrappers.

Why Companies Should Consider Svelte for Their Tech Stack#

After my experience migrating from Next.js-CRM-demo to CRM-SvelteKit5, I believe companies should seriously consider adopting Svelte for these reasons:

1. Development Speed: Less boilerplate, fewer concepts, and a more intuitive API mean faster development cycles.
2. Performance: Svelte's compile-time approach eliminates the need for a virtual DOM, resulting in smaller bundle sizes and faster runtime performance.
3. Maintainability: The code is more readable and expresses intent more clearly than React's often complex component patterns.
4. Learning Curve: Svelte builds on standard HTML, CSS, and JavaScript concepts, making it easier for new developers to learn.
5. Built-in State Management: No need for Redux, MobX, Recoil, or other external libraries - Svelte's stores are simple, powerful, and built-in.
6. Progressive Enhancement: SvelteKit's server-side rendering and progressive enhancement philosophy mean better user experiences across all devices.

The question shouldn't be "Why Svelte?" but rather "Why not?" Companies often default to React simply because of its popularity, but Svelte provides a more efficient, developer-friendly alternative that can lead to better products and happier development teams.

Conclusion#

My journey from React/Redux to SvelteKit5 has been eye-opening. While React has dominated the frontend landscape for years, Svelte offers a fundamentally different approach that addresses many of React's pain points. Its compiler-centric design, intuitive reactivity system, and elegant state management make it a compelling alternative.

As for SvelteKit, it takes Svelte's strengths and builds a complete application framework that rivals Next.js in capabilities while maintaining Svelte's simplicity and developer experience. The integration of server and client rendering, the automatic data flow, and the file-based routing system all contribute to a development experience that feels natural and productive.

SolidJS is another excellent alternative, but Svelte's growing community and mature ecosystem make it a safer bet for companies looking to adopt a React alternative. I believe we're seeing the beginning of a shift in the frontend landscape, with Svelte positioned to capture a significant portion of the market as developers and companies realize its advantages.

For me, the migration has been well worth the effort, and I look forward to building more applications with Svelte and SvelteKit in the future.

Frontend state management has evolved significantly over the years, with Redux being one of the most influential libraries in the React ecosystem. Today, Redux Toolkit (RTK) has emerged as the preferred way to implement Redux, bringing significant improvements to the developer experience. In this article, I'll explore Redux Toolkit's architecture, its integration with NextJS, and practical patterns for building scalable applications.

The Historical Journey of Redux#

Redux was born in 2015, created by Dan Abramov and Andrew Clark as a predictable state container for JavaScript applications. It drew inspiration from Facebook's Flux architecture and the Elm programming language's approach to state management. What began as a mere 99 lines of code quickly became the dominant state management solution for React applications. The Redux journey includes several key milestones:

• 2015: Initial release at React Europe conference
• 2019: Redux Toolkit was introduced to address the "boilerplate" complaints
• 2020: Redux Toolkit 1.0 launched with full TypeScript support
• 2021: RTK Query was introduced for data fetching and caching

While Redux provided powerful capabilities like time-travel debugging, it also gained a reputation for verbosity and complexity. Redux Toolkit emerged as a solution to these challenges, streamlining the Redux experience while maintaining its core principles.

Redux Toolkit: Simplifying State Management#

Reducers vs ExtraReducers#

One of Redux Toolkit's key improvements is how it handles reducers and their interactions with asynchronous operations. Let's explore this using examples from my CRM demo project.

Reducers#

In Redux Toolkit, reducers are defined within createSlice to handle actions that are automatically created for that slice:

// From src/store/clientsSlice.ts
const clientsSlice = createSlice({
  name: 'clients',
  initialState,
  reducers: {
    setClients: (state, action: PayloadAction<Client[]>) => {
      state.list = action.payload
      state.error = null
    },
    setCurrentClient: (state, action: PayloadAction<Client | null>) => {
      state.currentClient = action.payload
      state.error = null
    },
    // More reducers...
  },
})

These reducers handle state changes that are "owned" by this slice and are used for direct, synchronous state updates. They work particularly well with Next.js server actions, allowing for clean interaction between server and client state.

ExtraReducers#

ExtraReducers, on the other hand, react to actions that are defined elsewhere, typically from async thunks:

// Example of extraReducers in a typical implementation
extraReducers: (builder) => {
  builder
    .addCase(fetchClients.pending, (state) => {
      state.loading.list = true
    })
    .addCase(fetchClients.fulfilled, (state, action) => {
      state.list = action.payload
      state.loading.list = false
    })
    .addCase(fetchClients.rejected, (state, action) => {
      state.error = action.error.message || 'Failed to fetch clients'
      state.loading.list = false
    })
}

ExtraReducers don't generate action creators but instead react to actions from async thunks or other slices. This builder pattern provides better TypeScript support and is ideal for handling asynchronous operations or cross-slice communication.

createSlice vs createAsyncThunk#

The relationship between createSlice and createAsyncThunk is central to modern Redux applications.

createSlice#

createSlice generates a reducer function, action creators, and action types in one unified API:

// From src/store/taskSlice.ts
const taskSlice = createSlice({
  name: "tasks",
  initialState,
  reducers: {
    setTasks: (state, action: PayloadAction<Task[]>) => {
      state.list = action.payload;
      state.error = null;
    },
    // More reducers...
  }
});

export const { setTasks } = taskSlice.actions;

createAsyncThunk#

createAsyncThunk handles asynchronous operations with standardized lifecycle actions:

// Example async thunk implementation
const fetchTasks = createAsyncThunk('tasks/fetchTasks', async () => {
  const response = await fetch('/api/tasks')
  return response.json()
})

Each async thunk automatically dispatches:

• A pending action when it starts
• A fulfilled action on success
• A rejected action on error

In my CRM demo project, I've taken a different approach by using server actions for data fetching, which aligns well with Next.js's server components architecture:

// From src/app/actions/tasks.ts
export async function listTasks(params: ListTasksParams = {}): Promise<ListTasksResponse> {
  try {
    const token = await getAuthToken();
    if (!token) {
      return {
        success: false,
        error: "Authentication required",
        data: [],
        pagination: { /* pagination data */ }
      };
    }

    // API call implementation
    // ...

    return await response.json();
  } catch (error) {
    return {
      success: false,
      error: error instanceof Error ? error.message : "Failed to fetch tasks",
      data: [],
      pagination: { /* pagination data */ }
    };
  }
}

These server actions are then called from components, and their results are dispatched to the Redux store:

// From src/components/tasks/list/TaskList.tsx
const loadTasks = useCallback(async () => {
  try {
    dispatch(setLoading({ operation: 'list', isLoading: true }))
    dispatch(setError(null))

    const result = await listTasks({
      status: filters.status,
      search: filters.searchTerm,
      client_id: filters.clientId,
      page: pagination.currentPage,
      itemsPerPage: pagination.itemsPerPage,
    })

    if (result.success && result.data) {
      dispatch(setTasks(result.data))
      dispatch(setPagination(result.pagination))
    } else {
      dispatch(setError(result.error || 'Failed to load tasks'))
    }
  } catch (err) {
    dispatch(
      setError(
        err instanceof Error ? err.message : 'An unexpected error occurred',
      ),
    )
  } finally {
    dispatch(setLoading({ operation: 'list', isLoading: false }))
    setIsInitialMount(false)
  }
}, [
  dispatch,
  filters.status,
  filters.searchTerm,
  filters.clientId,
  isInitialMount,
  pagination.currentPage,
  pagination.itemsPerPage,
])

This pattern combines Next.js server-side capabilities with client-side state management for a hybrid approach that leverages the strengths of both.

Redux Toolkit vs Context API + useReducer#

A common question in the React community is whether to use Redux Toolkit or React's built-in Context API with useReducer. Both have their place, but they serve different needs.

When to Choose Redux Toolkit#

Redux Toolkit shines in applications with:

1. Complex Global State: When your application has many interconnected state slices
2. Team Collaboration: When you need a standardized approach for a team
3. Performance Optimization: Redux's selective component updates outperform Context for large state trees
4. Developer Tools: Time-travel debugging through Redux DevTools
5. Middleware Ecosystem: For logging, persistence, etc.

When to Choose Context + useReducer#

Context and useReducer are better suited for:

1. Simpler Applications: With limited global state needs
2. Component Tree Scoping: When state is only needed in a specific part of your app
3. Bundle Size Concerns: No additional dependencies required
4. Simpler Setup: Less boilerplate for small features

In CRM demo, Redux Toolkit was the right choice due to the complex state requirements and the need for organized state management across multiple features like clients, tasks, and calendar events.

The Evolution from Switch/Case to Structured Reducers#

One of the most significant improvements in Redux Toolkit is how it handles reducers and action types.

Traditional Redux (Pre-RTK)#

// Action types as constants
const ADD_TASK = 'tasks/ADD_TASK'
const UPDATE_TASK = 'tasks/UPDATE_TASK'

// Action creators
const addTask = (task) => ({
  type: ADD_TASK,
  payload: task,
})

// Reducer with switch/case
function tasksReducer(state = [], action) {
  switch (action.type) {
    case ADD_TASK:
      return [...state, action.payload]
    case UPDATE_TASK:
      return state.map((task) =>
        task.id === action.payload.id ? { ...task, ...action.payload } : task,
      )
    default:
      return state
  }
}

Redux Toolkit Way#

// From src/store/taskSlice.ts
const taskSlice = createSlice({
  name: "tasks",
  initialState,
  reducers: {
    addTask: (state, action: PayloadAction<Task>) => {
      state.list.push(action.payload);
      state.error = null;
    },
    updateTask: (state, action: PayloadAction<Task>) => {
      const index = state.list.findIndex((task) => task.id === action.payload.id);
      if (index !== -1) {
        state.list[index] = action.payload;
      }
      if (state.currentTask?.id === action.payload.id) {
        state.currentTask = action.payload;
      }
      state.error = null;
    }
  }
});

Behind the scenes, Redux Toolkit:

1. Generates action types by combining slice name with reducer function name (tasks/addTask)
2. Creates action creators that produce actions with the correct type and payload
3. Builds a reducer function with an internal switch/case that maps action types to your reducer functions
4. Integrates Immer so you can write "mutating" code that actually produces immutable updates

This approach dramatically reduces boilerplate while maintaining the predictability that made Redux popular.

Typed Custom Hooks for Redux#

One improvement that could be made to CRM project is adding typed custom hooks for accessing the Redux store. While the project works without them, adding these hooks would improve type safety and DX:

// Suggested improvement
import { TypedUseSelectorHook, useDispatch, useSelector } from "react-redux";
import type { RootState, AppDispatch } from "./store";

// Use throughout your app instead of plain `useDispatch` and `useSelector`
export const useAppDispatch = () => useDispatch<AppDispatch>();
export const useAppSelector: TypedUseSelectorHook<RootState> = useSelector;

Using these hooks would provide better TypeScript inference throughout the application:

// Before
const clients = useSelector((state: RootState) => state.clients.list);
const dispatch = useDispatch();

// After (with improved type safety)
const clients = useAppSelector(state => state.clients.list);
const dispatch = useAppDispatch();

Integrating with Next.js: A Modern Approach#

Next.js has evolved significantly, especially with the introduction of React Server Components and Server Actions. This has changed how I approach state management in Next.js applications.

In CRM project, I've adopted a hybrid approach:

1. Server Actions for data fetching and mutations
2. Redux Toolkit for client-side state management
3. Component-based patterns for connecting the two

This approach allows us to leverage the strengths of both paradigms:

// From src/app/actions/clients.ts (Server Action)
export async function createClient(clientData: CreateClientData): Promise<ClientResponse> {
  try {
    const token = await getAuthToken();
    if (!token) {
      return { success: false, error: "Authentication required" };
    }

    const response = await fetch(`${API_URL}/clients/`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: `Bearer ${token}`,
      },
      body: JSON.stringify(clientData),
    });

    if (!response.ok) {
      await handleApiError(response);
    }

    const data = await response.json();
    return { success: true, data };
  } catch (error) {
    return {
      success: false,
      error: error instanceof Error ? error.message : "Failed to create client",
    };
  }
}

// From src/components/clients/form/ClientForm.tsx (Client Component)
const handleSubmit = async (e: React.FormEvent) => {
  e.preventDefault();

  if (!validateForm()) {
    setError("Please fill in all required fields correctly");
    return;
  }

  setLoading(true);
  setError(null);

  try {
    if (mode === "create") {
      const result = await createClient(formData);
      if (result.success && result.data) {
        dispatch(addClient(result.data));
        router.push("/clients");
      } else {
        console.log(result.error);
        setError(result.error || "Failed to create client");
      }
    } else {
      // Update client logic...
    }
  } catch (err) {
    setError(err instanceof Error ? err.message : "An unexpected error occurred");
  } finally {
    setLoading(false);
  }
};

The Philosophy of State Management#

Beyond the technical details, state management is about how we conceptualize our applications. Redux encourages us to think of state as a "single source of truth" that drives our UI, rather than the other way around.

In CRM application, this philosophy manifests in how we structure our state. For example, our client state not only tracks the list of clients but also loading states, errors, filters, pagination, and more:

// From src/types/index.ts
export interface ClientsState {
  list: Client[];
  currentClient: Client | null;
  loading: LoadingState;
  error: string | null;
  filters: FilterState;
  pagination: PaginationState;
  sorting: SortingState<Client>;
}

This comprehensive approach ensures that our UI is always driven by the state, making our application more predictable and easier to debug.

Conclusion#

Redux Toolkit represents a significant evolution in how we manage state in React applications. By addressing the pain points of traditional Redux while maintaining its core principles, RTK provides a powerful yet developer-friendly approach to state management.

In this Next.js CRM application, we've seen how RTK integrates with modern Next.js features like Server Actions to create a hybrid architecture that leverages the strengths of both client and server state management. This approach allows us to build complex, interactive applications while maintaining a clear separation of concerns.

As the React ecosystem continues to evolve, the patterns and practices we've explored will remain valuable, even as the specific technologies change. The fundamental principles of predictable state changes, clear data flow, and component-driven architecture will continue to guide us in building robust, maintainable applications.

In the next article in this series, I will explore state management in Svelte and SvelteKit 5, examining how Svelte's unique approach with runes compares to the patterns we've discussed here.

As a developer currently working on a complex canvas-based annotation system, I find myself exploring and reimagining better architectural patterns. This ongoing experience has inspired the creation of EasyNotes Canvas, which serves as a proving ground for implementing these architectural improvements. This is a story about that journey, and the insights being gained along the way.

The Birth of EasyNotes Canvas#

EasyNotes Canvas emerged from a simple yet profound realization: the tools we use for digital note-taking and annotation should feel as natural as pen and paper, yet harness the full power of modern web technologies. Built with React, Redux, and Konva, it serves as a canvas for thoughts, ideas, and collaborative work.

But beyond its functional purpose, EasyNotes Canvas represents something more: a quest for architectural elegance in the face of complexity.

The State Management Epiphany#

Wrestling with Complexity#

My initial attempts at managing canvas state were, frankly, chaotic. Local state scattered across components, prop drilling that made code reviews painful, and event handlers that grew more complex with each new feature. It was a classic case of organic growth without architectural foresight.

// Early attempts at state management - a lesson in what not to do
const CanvasComponent = () => {
  const [shapes, setShapes] = useState([])
  const [selectedShape, setSelectedShape] = useState(null)
  const [isDrawing, setIsDrawing] = useState(false)
  // More state variables...
}

The turning point came when I realized that canvas applications aren't just about drawing —they're about managing a complex ecosystem of states, events, and user interactions. This led to a fundamental shift in thinking about state management.

The Redux Revelation#

Moving to Redux wasn't just about choosing a state management library; it was about adopting a philosophy of predictable state changes and clear data flow. The resulting architecture became a testament to this philosophy:

interface ShapeState {
  shapes: ShapeProps[];
  savedShapes: ShapeProps[];
  isDirty: boolean;
  selectedShapeId: string | null;
  activeTool: ShapeType | string | null;
  // A clear representation of our application's state
}

Each property in this interface tells a story about user interaction and application behavior. The isDirty flag, for instance, represents the tension between user changes and persistence—a simple boolean that carries significant meaning for the user experience.

While React's Context API and useReducer hook might seem like suitable alternatives—and they are excellent for simpler applications—the decision to use Redux came from deeper architectural needs. Context API, while powerful for prop drilling prevention, lacks the robust middleware ecosystem that Redux provides for handling complex side effects. The useReducer hook, though similar in concept to Redux, doesn't offer the same level of state isolation and time-travel debugging capabilities that become invaluable when debugging complex canvas interactions. In a canvas application where every mouse movement could trigger state changes and where undo/redo functionality is crucial, Redux's DevTools and middleware system prove themselves indispensable for development and debugging.

The Art of Event Handling#

Finding Harmony Between Events and State#

One of the most enlightening aspects of this journey was discovering the delicate balance between immediate user feedback and state consistency. Mouse events in canvas applications aren't just about capturing coordinates; they're about translating human intent into digital creation.

export const useCanvasEvents = (handleShapeAdd, handleShapeUpdate) => {
  const handleMouseDown = useCallback((e: Konva.KonvaEventObject<MouseEvent>) => {
    // This moment of interaction initiates a cascade of state changes
    const clickedOnShape = e.target instanceof Konva.Shape;
    if (clickedOnShape) {
      dispatch(selectShape(e.target.id()));
      return;
    }
    // The beginning of creation...
  }, [dispatch]);

This code represents more than just event handling—it's the bridge between user intention and application state. Each mouse movement tells a story, and our architecture must be ready to listen and respond.

Lessons in Architecture#

The Value of Clarity#

Working on my current canvas project has taught me the importance of architectural clarity. When you're dealing with complex interactions and state changes, your architecture needs to be more than just functional—it needs to be comprehensible. This led to some key principles in EasyNotes Canvas:

1. State as a Source of Truth: Every shape, every tool selection, every user interaction is reflected in our Redux store. This isn't just about state management—it's about creating a clear narrative of application state.

2. Event Handling as Translation: Mouse events become a translation layer between user intent and application state. This perspective changed how I approached event handling:

const handleShapeModification = async (shapeId, newProperties) => {
  // Immediate feedback for the user
  dispatch(updateShape({ id: shapeId, ...newProperties }))

  try {
    // Ensuring our changes persist
    await dispatch(saveShapes(currentProjectId)).unwrap()
  } catch (error) {
    // Gracefully handling when things go wrong
    dispatch(revertShapeUpdate(shapeId))
  }
}

Performance as a Feature#

One of the most valuable lessons from my project was that performance isn't just about optimization—it's about user experience. This led to implementations like batch operations and memoized selectors:

export const selectSelectedShape = createSelector(
  [(state) => state.shapes.shapes, (state) => state.shapes.selectedShapeId],
  (shapes, selectedId) => shapes.find((shape) => shape.id === selectedId),
)

Looking Forward#

The journey of building EasyNotes Canvas has been about applying lessons learned in real-time from my current work with canvas applications. Each architectural decision carries the weight of active experiences and challenges, and each line of code represents a step toward better software design.

Future enhancements like PDF integration and collaborative editing aren't just features to be added—they're opportunities to further refine our architectural approach. The foundation we've built, inspired by real-world experiences and challenges, stands ready for these additions.

Conclusion#

Building canvas applications has taught me that good architecture isn't just about patterns and practices—it's about understanding the deeper relationships between user interactions, application state, and system behavior. EasyNotes Canvas is more than just an application; it's a reflection of this understanding, and a step forward in my journey as a developer.

Next in this series: "Beyond Drawing - Implementing Document Integration in Canvas Applications," where we'll explore the architectural challenges of adding PDF and document support to canvas applications.

JavaScript is a versatile language that supports multiple programming paradigms, allowing developers to choose the approach that best suits their needs. Two prominent paradigms in JavaScript are Object-Oriented Programming (OOP) and Functional Programming (FP).

Before I write the pros and cons, I would like to explain a bit about composition vs. inheritance.

Composition vs. Inheritance#

To understand both concepts, we need to know what they are. The main difference is inheritance; the child class depends on the parent class, and in composition, both the child and parent class are independent. In inheritance, we use class extends; in composition, we use smaller pieces to create something more significant. In the community, there is always a considerable debate about which approach is better, and usually, people prefer composition vs inheritance. I will write about some issues or problems in inheritance and how composition is solved. Inheritance does not belong to OOP, and composition does not belong to functional programming. We can do both things in both paradigms.

The first thing we must take care of in inheritance is our code structure. We're structuring our classes around what things are. They have some data, methods, actions, etc. On the other hand, with composition, we are structuring code what it has, or actually what it does to data.

Also, we need to think about things such as tight coupling and fragile base class problems.

Tight Coupling: This is when classes are highly dependent on each other. A change in one class may require changes in other classes. Inheritance can lead to tight coupling because a subclass is heavily dependent on the implementation details of its superclass. If the superclass changes, it can potentially break the functionality of the subclass.

Fragile Base Class Problem: This is a specific issue related to inheritance. It occurs when changes to a base class can break the functionality of derived classes. Since derived classes rely on the implementation of the base class, any changes to the base class can have unintended consequences in the derived classes. These problems highlight the importance of designing class hierarchies carefully. Tight coupling and the fragile base class problem can make code more challenging to maintain and evolve over time.

OOP vs. FP#

Functional programming is all about performing many different operations for which the data is fixed. OOP is about a few operations on common data. In FP, the state is immutable versus object-oriented programming, which is very state-full. In functional programming, functions are pure. There are no side effects. It means that the functions that we write don't make an impact on the code that is running outside of that function. In OOP, there are definitely side effects. Functional programming is more declarative. It's about what we want to be doing vs. an object oriented program, which is more about how we want it to be done, and it is more imperative. Functional programming works really well for high-performance processors; you can run it on multiple processors. If you have a few things that require a lot of operations, then functional programming is usually a good idea. If, on the other hand, you have objects with not too many operations, then object-oriented programming might be a better solution.

You can use both ideas to write your code. In all programs, there are two primary segments: the data and the behaviours. OOP brings together the data and the behaviour in a single location called an object or class. This will make our program easier and more organized. Functional programming says that data and behaviour are distinctly different things and should be kept separate for clarity.

Object-Oriented Programming (OOP)#

Pros:#

• Encapsulation: OOP promotes encapsulation, enabling the bundling of data and methods into cohesive units called objects. This organizational structure enhances code clarity and maintainability.
• Inheritance: OOP facilitates the creation of hierarchies through inheritance, allowing objects to inherit properties and behaviours from other objects. This promotes code reuse and extensibility.
• Readability: Object-oriented code often mirrors real-world entities, making it more intuitive and readable for developers. This alignment with familiar concepts enhances the understanding of code.

Cons:#

• Mutability: OOP frequently involves a mutable state, which can lead to issues like unexpected side effects and bugs. Managing state changes becomes crucial, especially in complex applications.
• Verbosity: Object-oriented code can be more verbose compared to functional programming, potentially resulting in longer development times and increased opportunities for errors.

Functional Programming (FP)#

Pros:#

• Immutability: FP encourages immutability, meaning once a piece of data is created, it cannot be altered. This reduces the risk of bugs related to unintended side effects and makes the code more predictable.
• Pure Functions: FP emphasizes the use of pure functions, which have no side effects and consistently produce the same output for the same input. This predictability enhances testability and maintainability.
• Concurrency: Functional programming is well-suited for concurrent programming. Immutable data and pure functions minimize the chances of race conditions and other concurrency-related issues.

Cons:#

• Learning Curve: Functional programming concepts, such as higher-order functions and monads, may pose a learning curve for developers new to the paradigm. Mastery of these concepts is essential for leveraging the full power of FP.
• Performance: In certain scenarios, functional programming can have performance implications, particularly when dealing with large datasets or intricate algorithms. Careful consideration is necessary to strike a balance between performance and functional principles.

Blending Paradigms in JavaScript#

JavaScript allows developers to blend OOP and FP seamlessly, providing a flexible and expressive programming environment. Many modern frameworks and libraries like React and Redux incorporate functional programming principles within an overarching object-oriented structure. This hybrid approach enables developers to harness the strengths of both paradigms and create robust, scalable, and maintainable code.

In conclusion, the choice between OOP and FP in JavaScript depends on a project's specific requirements and the development team's preferences. Understanding the strengths and weaknesses of each paradigm empowers developers to make informed decisions, ultimately leading to the creation of efficient and reliable software solutions.

The idea of FP is the same as in OOP: to make our code clear and understandable, easy to extend, and easy to maintain. It will allow us not to repeat ourselves, keeping our code dry and memory efficient.

In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions without mutating state and data.

In functional programming, functions are treated as first-class citizens, meaning they can be bound to names (including local identifiers), passed as arguments, and returned from other functions, just as any other data type can. That allows programs to be written in a declarative and composable style, where small functions are combined in a modular manner. Functional programming is sometimes synonymous with purely functional programming, a subset of functional programming that treats all functions as deterministic mathematical functions, or pure functions. When a pure function is called with some given arguments, it will always return the same result and cannot be affected by any mutable state or other side effects. This is in contrast with impure procedures, common in imperative programming, which can have side effects (such as modifying the program's state or taking input from a user).

If you want to break things down in functional programming, it all comes down to this concept of pure functions. That is the main difference from OOP concepts such as encapsulation, abstraction, polymorphism and inheritance.

Pure functions#

Okay, so what are pure functions!? A Pure Function returns the same result if the same arguments are passed. A function cannot modify anything outside of itself. No side effects.

We are going to see what is that side effect. If we log mutateArr we will get undefined because our function is returning nothing.

const array = [1, 2, 3, 4, 5]

function mutateArr(arr) {
  arr.pop()
}
console.log(mutateArr(array))

But if log array console.log(array), we will get [ 1, 2, 3, 4 ]. So, it means we have mutated our array. And that is a side effect. This function has side effects, and it modifies anything outside of itself. This function has side effects, and it modifies anything outside of itself. We can imagine this array as a global state that can interact with everything in an application and produce many bugs, especially if many functions interact with the same state.

We can fix it like this:

const array = [1, 2, 3, 4, 5]

function mutateArr(arr) {
  const newArray = [].concat(array)
  newArray.pop()
  return newArray
}
console.log(mutateArr(array))

So, we make a new copy of an array without affecting the outside world. But could it be everything pure function?

Having everything pure without side effects is nice, but programming and applications don't work like that. Our program needs to communicate with the outside world :). To do fetch calls to talk to some other functions, etc. So, our goal is to minimize side effects.

Perfect function should do one task and return some statement. It should be pure :), with no shared state with other functions and an immutable state. We always return a new copy of the output. Functions should be composable, and I will explain this through examples. And most important, we want to make functions predictable.

Imperative vs declarative#

We have those concepts in programming. Imperative code is code that tells the machine what to do and how to do it. Declarative code tells it what to do and what should happen. It doesn't say to the computer how to do things. A computer is better at being imperative. That is, it needs to know how to do something. We, on the other hand, as humans, are more declarative. We usually say to friends, hei give that or that, but we don't say how they will do that. Humans are more declarative :). For example, machine code is more imperative when we are talking about computers. If we go level up and up forward to some high-level languages, it becomes more declarative. We declare a variable, and the computer does the rest of the job for us. A good example in JS for imperative vs declarative is for loop:

for (let i = 0; i < 10; i++) {
  console.log(1)
}

vs

;[1, 2, 3, 4, 5].forEach((item) => console.log(item))

In the old traditional for loop, you have too many instructions to say what to do. With forEach you have that more declarative way. jQuery is also a good example of an imperative approach. But I am writing this because functional programming helps us be more declarative. Declarative code is easier to read, and we can be more productive.

Immutability#

In functional programming, the idea of immutability is not changing state but instead making copies of the state and returning a new state every time.

HOF and Closure#

Functions are first-class citizens, which means we can have high-order functions, and we can also have closures. HOF means it's a function that does one of two things. It either takes one or more functions as arguments. Or returns a function as a result, often called a callback. A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function's scope from an inner function. In JavaScript, closures are created every time a function is created at function creation time.

Curring#

Currying in JavaScript transforms a function with multiple arguments into a nested series of functions, each taking a single argument. Currying helps you avoid passing the same variable multiple times, and it helps you create a higher-order function. An example looks like this:

const sum = (a, b) => a * b

//by now Curring
const curriedSum = (a) => (b) => a * b

curriedSum(5)(4)

Because of closures, we have access to the A variable inside the B function. But why is this useful!?

const curriedSum = (a) => (b) => a * b

const curriedSumBy5 = curriedSum(5)

//after some time, after 7 years
curriedSumBy5(4)

And instead of running curriedSum(5) this function forever it will be run only once. So when we run curriedSumBy5(4) we run only this part of function (b) => a*b.

Memoization#

To understand how dynamic programming works, we need to understand what caching means. Caching is a way to store values so you can use them later on. Memorization is a specific form of caching.

function memoizeAddTo50(n) {
  let cache = {}
  return function (n) {
    if (n in cache) {
      return cache[n]
    } else {
      console.log('long time')
      const answer = n + 50
      cache[n] = answer
      return answer
    }
  }
}

If we try to call this function memoizeAddTo50(5) with same value more than once we will see caching in action :).

Compose#

Compose is the most powerful concept. Function composition is an approach where the result of one function is passed on to the next function, which is passed to another until the final function is executed for the final result. Function compositions can be composed of any number of functions.

In functional programming you can use something called compose. Compose doesn't exist in JavaScript, but we have many libraries that let you use compose. One of the best is Ramda's compose.

Also we can make our own custom compose function, and here you have one of my examples:

fn1(fn2(fn3(50)))

compose(fn1, fn2, fn3)(50) //Right to left
pipe(fn3, fn2, fn1)(50) //left to right

const compose = (f, g) => (a) => f(g(a))
const pipe = (f, g) => (a) => g(f(a))
const multiplyBy2AndAbsolute = compose((num) => num * 2, Math.abs)
console.log(multiplyBy3AndMakeAbsolute(-10))

You can also see in this example function with name pipe. Actually, it is the same thing as composing but just going from left to right, see Ramda's pipe.

Most of those concepts could be explained more in-depth, but this article is about generally functional programming and things around it. Functional programming is very lovely. The idea in functional programming is to keep functions small, pure, and composable. This idea of immutability is that a function takes inputs and returns outputs to be used with other functions. It allows us to have a predictable program that minimizes bugs because everything is simple.

But is functional programming the answer for everything!? Sometimes OOP is a better way for some cases. That is where we, as programmers, come out on the stage and show our best :)

When we are talking about OOP in JavaScript, we need to cover things like this keyword, prototype inheritance, the new keyword, the ES6 classes, object, create, private and public fields and four principles of OOP.

We know in OOP, we have two main types: class-based programming languages and prototype-based programming languages. In JavaScript, we have prototype inheritance. Object-oriented programming is all about modelling real-world objects and relationships.

We can start a few steps behind OOP in JavaScript and see how things are doing with functions and objects.

const person = {
    name: “igor”,
    hobby: “basketball”,
    Doing() {
        return name + " is love to play " + hobby
    }
}

What did we see, and what are the benefits of that!? We grouped functionality. We have states and functions or methods of doing something. We have something called encapsulation. That is our first step in object-oriented programming.

That is fine, but what is the problem with this!? So, if we want to create person1, we need to copy the previous object, and so on.

What we can do here is to create a factory function. Factory function is the function that creates an object and returns it. It is like a constructor or class function, but we will see that later. So, we are moving a step forward to OOP.

function createPerson(name, hobby) {
  return {
    name,
    hobby,
    doing() {
      return name + ' is love to play ' + hobby
    },
  }
}

const igor = createPerson('Igor', 'basketball')

console.log(igor.doing())

Here, we avoided repeating code, but still, we have a problem. In case we have thousands of persons, they require space in memory. Things like name and hobby are different, and that’s okay, but methods of doing them are standard and the same thing. That is going to copy on memory for each person. And this could be better.

We have something in JavaScript; how can we solve this problem? It is prototype inheritance, but now we will see how to solve it manually.

The easiest way to get a method outside of function and make the new object:

const doingFunc = {
  doing() {
    return name + ' is love to play ' + this.hobby
  },
}

So now, if want to create a new method inside our createPerson we just do:

igor.doing = doingFunc.doing

Actually, here we can use Object.create() and simplify things. The Object.create() static method creates a new object, using an existing object as the prototype of the newly created object.

function createPerson(name, hobby) {
  let newPerson = Object.create(doingFunc)
  newPerson.name = name
  newPerson.hobby = weapon
  return newPerson
}

So, what does an object create do for us!? It links doingFunc and newPerson. We are doing prototype inheritance here.

If you try to log newPerson inside of createPerson like this console.log(newPerson) you will get the empty object, but not doing method from doingFunc. You need to write console.log(newPerson.__proto__)

Object.create() solved our problems. We are using prototype inheritance; everything is working, and we are doing things.

There are not too many code bases with this approach; this is not the standard way of doing things inside the JavaScript community.

Things look closer to OOP, but we still need to fundamental OOP in JavaScript.

Now we will see something we had before Object.create().

Before we didn't have Object.create(), we used constructor functions. Something like this:

function Person(name, hobby) {
  this.name = name
  this.hobby = hobby
}

You can notice we don't return anything. We are using the keyword this, and that's it. We are constructing. But if we try to create an object from this as we did previously, you will get an error, that prop. is undefined.

const igor = Person('Igor', 'basketball')

To use constructor function you need to use new keyword in JavaScript.

const igor = new Person('Igor', 'basketball')

That is just a way JavaScript works :). The new keyword automatically returns the object, creating a Person constructor. It runs our code and constructs the Person function. So, we can say that any function invoked by new keyword is called a constructor function. As a rule, all constructor functions should start with a capital letter to let other programmers know that the function should be called with new keyword.

One note about this and new keyword: We know that this in JavaScript points to the global object, the window object. But new keyword changes it. When you use new keyword, we are pointing this to the object we just created. Because of that, we got an error when we tried to create an object without a new keyword.

Every function in the JavaScript script automatically gets a prototype property. As we know, everything is an object in JS; functions are special type of objects. __proto__ is useful for constructor functions. So, we can simply do this to get the method attached to the function.

Person.prototype.doing = function () {
  return 'I like to ' + this.hobby
}

Also, one more note about arrow functions. If we try to write like this, we will get undefined:

Person.prototype.doing = () => {
  return 'I like to ' + this.hobby
}

This is because arrow functions are lexically scoped.

One more important thing about prototyping in JS: If we have the example below and try to log console.log(igor.prototype), we will get undefined. Why!? Because igor is not a function, it is an object, and only functions have access to the prototype.

function Person(name, hobby) {
  this.name = name
  this.hobby = hobby
}

Person.prototype.doing = function () {
  return 'I like to ' + this.hobby
}

const igor = new Person('Igor', 'basketball')
console.log(igor.prototype)

If we try to make our method more complex, like in this example, we need to take care about one thing. About this keyword.

function Person(name, hobby) {
  this.name = name
  this.hobby = hobby
}

Person.prototype.doing = function () {
  function something() {
    return this.hobby + ' is the best for me'
  }
  something()
}

const igor = new Person('Igor', 'basketball')
console.log(igor.doing())

It will be undefined. Function inside methods, or just functions inside functions, means that this keyword inside function is not assigned to object itself, but actually to window object. Solution is to bind function.

Person.prototype.doing = function () {
  function something() {
    return this.hobby + ' is the best for me'
  }
  something().bind(this)
}

Or :)

Person.prototype.doing = function () {
  const self = this
  function something() {
    return self.hobby + ' is the best for me'
  }
  return something()
}

With this and new keyword coding style, the idea is much more object-oriented programming. But things like Object.create() simplify things in JS, and they come out. Object.create() is technically less OOP than we have with constructor functions. This construction approach is not pretty and is sometimes hard to understand and follow. We are moving to our goal, to add classes :)

Finally, we are here ES6 and classes. ECMAScript 2015 was the second major revision to JavaScript. ECMAScript 2015 is also known as ES6 and ECMAScript 6. Here, we got let and const keywords, Promises and many more. But we are talking about classes now :).

class Person {
  constructor(name, hobby) {
    this.name = name
    this.hobby = hobby
  }
}

Constructor is something that gets run every time when we use new keyword when creating new object.

Alo this line of code:

Person.prototype.doing = () => {
  return 'I like to ' + this.hobby
}

we are going to move to our class.

class Person {
  constructor(name, hobby) {
    this.name = name
    this.hobby = hobby
  }
  doing() {
    return 'I like to ' + this.hobby
  }
}

When we have any updates, we put things inside class. Class becomes some blueprint for what we want to do. And when we update methods or change something inside a class, all instances will get updated. We are now using the word instance, which is a common term for object-oriented programming. Instance happens when we call a class and create an object from it.

If you try to log this line of code, you will get true.

const igor = new Person('Igor', 'basketball')
console.log(igor instanceof Person)

But under the hood, JS is still using prototype inheritance. We are not using classes like classes work in other languages. That is the closest that JavaScript comes to classes.

The idea of Brendan Eich (creator of JS :)) was to make JS different from Java and make a competing language with Java. He didn't have classes in JavaScript back in 1995 :). In JavaScript, we have a principle that everything is an object. So, classes are just objects. In other languages, classes are an actual thing.

Now you can say this is similar to Object.create(). Yes, it is. But as we noted at the beginning of this article, JS is a multi-paradigm. It depends on your team, personal preferences, etc. But most of the code bases that use OOP in JavaScript use this approach with class.

The core aspect of OOP is inheritance, which means passing things down :). So, we are going to see what it looks like in JavaScript.

class Person {
  constructor(name, hobby) {
    this.name = name
    this.hobby = hobby
  }
  doing() {
    return 'I like to ' + this.hobby
  }
}

class EuropaPerson extends Person {
  constructor(name, hobby, type) {
    this.type = type
  }
}

const igor = new EuropaPerson('Igor', 'basketball', 'slavic')
console.log(igor)

If try to log out new object we are going to get ReferenceError - must call super constructor in derived class before accessing this or returning derived constructor. What this mean!?

We have special keyword called super for super class. It means we need to call super inside of constructor. What does this mean, call super class inside of EuropaPerson class, so super class is Person. EuropaPerson extends Person. If you log it now, everything is working fine. Constructor is working with actual class, and we use super() to extend things.

class EuropaPerson extends Person {
  constructor(type) {
    super(name, hobby)
    this.type = type
  }
}

const igor = new EuropaPerson('Igor', 'basketball', 'slavic')
console.log(igor)

Inheritance in JavaScript doesn't copy from an extended class; it simply links to the prototype chain. Unlike other languages, JavaScript is just an object or everything inside JS is called an object. So it is an object inheriting from an object :). There are no technical classes. Other languages, for example, Java or C++, copy objects when we extend classes. There is a bit of efficiency with memory in JS.

Finally new release in ES2022 brings us essential things inside of OOP: private methods and fields, and class fields declarations. Previously, we used something like this to make things private inside of class.

class Employee {
  #name = 'Test' // private field
  setName(name) {
    this.#name = name
  }
}

In this article, I mentioned inheritance several times. It is one of the few most important pillars of OOP. In object-oriented programming, we have concepts of encapsulation, abstraction and polymorphism. Those are also important in OOP. Encapsulation can be defined as “the packing of data and functions into one component”. Packing, which is also known as bundling, grouping and binding, simply means to bring together data and the methods which operate on data. The component can be a function, a class or an object. Abstraction is a way of hiding the implementation details and showing only the functionality to the users. In other words, it ignores the irrelevant details and shows only the required one. And finally Polymorphism is one of the core concepts of object-oriented programming languages where poly means many and morphism means transforming one form into another. Polymorphism means the same function with different signatures is called many times. I don't go deeper to those concepts, this article is just about main concepts of OOP in JavaScript and the development path how we got here.

In conclusion, despite those new concepts, JavaScript is not well-suited for most of the work we do on the server side, but on the other hand, it can attract backend developers to do something on frontend :).