DEV Community: Selasie Sepenu

What Is Agentic UI — And Why It Changes Everything About Frontend Engineering

Selasie Sepenu — Wed, 10 Jun 2026 10:39:15 +0000

Day 1 of 30 — The complete introduction to AG-UI: what it is, how it works, and why it breaks traditional frontend thinking

This is day one of a 30-day series on Agentic UI — what it is, how to build it, and what the patterns look like in production. Every post is specific, technical, and grounded in real implementation. No fluff. No theory without code.

The problem with building AI agents in traditional frontends

Most teams building AI-powered products make the same architectural mistake early on.

They build the agent first. Then they try to fit it into a traditional SaaS frontend.

It does not work — not cleanly, not at scale, not for anything more complex than a simple question-and-answer flow. The reason is fundamental: traditional frontend architecture is designed for deterministic outputs. Agentic architecture produces non-deterministic outputs. These two models are structurally incompatible.

To understand why, you need to understand exactly what makes an agentic application different from every other kind of software.

The core distinction — deterministic vs non-deterministic outputs

In a traditional SaaS application, the developer knows at build time what every feature produces.

A search feature produces a list of results. A dashboard feature produces a set of charts. A settings feature produces a form. The developer builds a component for each output. The component renders that shape. Every time. Predictably.

Feature defined at design time
  → Output shape known at design time
    → Component built at design time
      → Runtime populates data into the component

In an agentic application, the agent decides what to produce at runtime based on the task it has been given, the data it finds, and what it discovers as it works.

A user gives the agent a task. The agent might produce a data table. It might produce a set of structured items for human review. It might produce a narrative summary. It might produce an alert that it is blocked. It might produce all of these, in sequence, as it works through the task.

The developer cannot pre-build a component for every possible output combination because the output is determined by the agent at runtime, not by the developer at design time.

Task defined at runtime by the user
  → Agent execution — unknown duration, unknown steps
    → Typed output — known shape, unknown content
      → Component selected at runtime by the renderer

This is the fundamental incompatibility. And it is why Agentic UI exists as a distinct architectural pattern.

What Agentic UI actually is — a precise definition

Agentic UI (AG-UI) is a frontend architecture pattern designed for applications where an AI agent drives the primary workflow execution. It is characterised by five specific properties:

1. The agent drives execution, not assists it.
The user sets intent. The agent plans the steps, executes them, and produces outputs. The UI renders those outputs. This is different from a copilot model where AI assists within a pre-built feature flow. In AG-UI the agent is the workflow. The UI is the rendering layer.

2. Outputs are typed and structured.
The agent does not produce free text that the UI pastes into a box. It produces typed JSON objects — a defined schema of output types. A renderer maps those types to UI components at runtime. There are no hardcoded feature components. There is one dynamic renderer.

3. The human is in the loop at defined points.
Agentic does not mean autonomous. The agent handles execution. The human handles judgment at high-stakes decision points. When the agent wants to take a consequential action, execution stops. The human explicitly approves or rejects. Only then does execution continue.

4. Parallel execution is first-class.
Multiple agents can run simultaneously across different tasks. The UI must represent all parallel executions in a coherent, navigable way. This is a first-class requirement, not an afterthought.

5. Audit trails are user-facing.
Every agent decision, every action taken, every human approval or rejection is logged in a user-readable, inspectable record. Not server logs. Not analytics events. A visible, accessible audit trail the end user can open and read.

The AG-UI stack — the three layers

Agentic UI is built on three interconnected layers. Understanding how they relate to each other is the foundation for everything else in this series.

Layer 1 — The agent output schema

The output schema is the contract between the agent and the frontend. It is the single most important architectural decision in an agentic application.

The schema defines every type of structured output the agent can produce. The agent always emits outputs conforming to this schema. The frontend always renders based on this schema. Nothing crosses the boundary between agent and UI as free text.

A general-purpose AG-UI output schema looks like this:

type AgentOutputType =
  | 'approval_gate'       // agent wants to take a high-stakes action
  | 'table'               // tabular data of any kind
  | 'review_items'        // structured items for human review before action
  | 'checklist'           // ordered task list with completion states
  | 'narrative'           // rich text — summaries, commentary, documents
  | 'chart'               // data visualisation
  | 'file_created'        // agent created an external file or resource
  | 'progress'            // real-time step update during execution
  | 'attention_required'  // agent is blocked — needs human input
  | 'task_created'        // a prompt has been converted to a tracked task
  | 'query_result'        // simple info query — no task created

interface AgentOutput<T = unknown> {
  type: AgentOutputType
  data: T
  task_id: string | null
  session_id: string
  requires_approval: boolean
  timestamp: string
  reasoning?: string          // why the agent produced this output
  audit_entry: AuditEntry     // written atomically — always present
}

The reasoning field deserves special attention. It is optional in the schema but should be treated as mandatory in practice. The agent's explanation of why it produced a given output is what builds user trust in agentic applications. Users who can see the agent's reasoning approve outputs faster, reject inappropriate outputs more accurately, and trust the system more over time.

The most critical output type is approval_gate:

interface ApprovalGateOutput extends AgentOutput {
  type: 'approval_gate'
  data: {
    action: string              // what the agent wants to do
    payload: unknown            // the data it wants to act on
    reasoning: string           // why it wants to take this action
    reversible: boolean         // can this be undone if approved in error
    estimated_impact: string    // plain English — what will change if approved
  }
  requires_approval: true       // always true — cannot be false
}

The approval gate is what separates an agentic UI from an autonomous system. Every high-stakes action routes through it. The agent drafts. The human decides. This is not a limitation — it is the design.

Layer 2 — The LLM output configuration

Having a schema means nothing if the agent does not reliably produce it. The agent must be explicitly configured to always emit structured outputs matching the schema.

This is done via Anthropic's tool_use API. Each output type in the schema becomes a tool definition. The agent calls the appropriate tool to emit each output instead of producing free text.

import Anthropic from '@anthropic-ai/sdk'

const client = new Anthropic()

const agentTools: Anthropic.Tool[] = [
  {
    name: 'emit_approval_gate',
    description: `You MUST call this tool before taking any high-stakes action.
    Define "high-stakes" as: any action that modifies external data,
    sends communications, makes financial transactions, or cannot be
    easily reversed.

    You cannot take these actions directly.
    You must always request approval first.
    The human will approve or reject.
    You only execute on explicit approval.

    There are no exceptions to this rule.`,
    input_schema: {
      type: 'object' as const,
      properties: {
        action: {
          type: 'string',
          description: 'The action you want to take'
        },
        payload: {
          type: 'object',
          description: 'The data you want to act on'
        },
        reasoning: {
          type: 'string',
          description: 'Why you want to take this action'
        },
        estimated_impact: {
          type: 'string',
          description: 'Plain English — what will change if approved'
        },
        reversible: {
          type: 'boolean',
          description: 'Can this be undone if approved in error'
        }
      },
      required: ['action', 'payload', 'reasoning', 'estimated_impact', 'reversible']
    }
  },
  {
    name: 'emit_table',
    description: `Call this to render any tabular data to the user.
    Define columns explicitly with types so the renderer
    can format values correctly.`,
    input_schema: {
      type: 'object' as const,
      properties: {
        title: { type: 'string' },
        columns: {
          type: 'array',
          items: {
            type: 'object',
            properties: {
              key:      { type: 'string' },
              label:    { type: 'string' },
              type: {
                type: 'string',
                enum: ['text', 'number', 'currency', 'date', 'status', 'badge']
              },
              sortable: { type: 'boolean' }
            }
          }
        },
        rows: {
          type: 'array',
          items: { type: 'object' }
        },
        summary: { type: 'string' }
      },
      required: ['title', 'columns', 'rows']
    }
  },
  {
    name: 'emit_attention_required',
    description: `Call this when you are blocked and cannot continue
    without human input. Be specific about what you need.
    Always provide concrete options for the human to resolve the block.
    Do not guess or proceed past a genuine blocker.`,
    input_schema: {
      type: 'object' as const,
      properties: {
        blocked_at_step: { type: 'string' },
        reason:          { type: 'string' },
        urgency: {
          type: 'string',
          enum: ['low', 'medium', 'high']
        },
        options: {
          type: 'array',
          items: {
            type: 'object',
            properties: {
              id:          { type: 'string' },
              label:       { type: 'string' },
              description: { type: 'string' },
              action: {
                type: 'string',
                enum: ['provide_input', 'approve', 'skip', 'cancel']
              }
            }
          }
        }
      },
      required: ['blocked_at_step', 'reason', 'urgency', 'options']
    }
  },
  {
    name: 'emit_review_items',
    description: `Call this when you have drafted items that need
    human review before any action is taken on them.
    Always include confidence score and reasoning per item.`,
    input_schema: {
      type: 'object' as const,
      properties: {
        title: { type: 'string' },
        items: {
          type: 'array',
          items: {
            type: 'object',
            properties: {
              id:          { type: 'string' },
              summary:     { type: 'string' },
              detail:      { type: 'object' },
              confidence: {
                type: 'string',
                enum: ['high', 'medium', 'low']
              },
              reasoning:   { type: 'string' }
            }
          }
        },
        allow_bulk_approval: { type: 'boolean' }
      },
      required: ['title', 'items']
    }
  }
]

// Execute a single agent step within a task session
async function runAgentStep(params: {
  taskId: string
  sessionHistory: Anthropic.MessageParam[]
  systemPrompt: string
}) {
  const response = await client.messages.create({
    model: 'claude-sonnet-4-5',
    max_tokens: 8096,
    system: params.systemPrompt,
    tools: agentTools,
    messages: params.sessionHistory
  })

  const outputs: AgentOutput[] = []

  for (const block of response.content) {
    if (block.type === 'tool_use') {
      const output = mapToolUseToOutput(block, params.taskId)
      outputs.push(output)
    }
  }

  return {
    outputs,
    stop_reason: response.stop_reason,
    requires_continuation: response.stop_reason === 'tool_use'
  }
}

One production observation worth noting: the description field in each tool definition does significantly more work than most developers expect. The constraint around approval gates — the explicit statement that there are no exceptions — needs to be stated emphatically and without ambiguity. Weak tool descriptions produce inconsistent agent behaviour. Strong, explicit tool descriptions produce reliable, predictable output schemas.

Layer 3 — The generative renderer

The renderer is a single component that receives an AgentOutput and renders the correct UI at runtime. This is built using Vercel AI SDK's streamUI with React Server Components.

import { streamUI } from 'ai/rsc'
import { anthropic } from '@ai-sdk/anthropic'

export async function AgentWorkspace({
  session,
  context
}: {
  session: TaskSession
  context: ApplicationContext
}) {
  const result = await streamUI({
    model: anthropic('claude-sonnet-4-5'),
    system: buildSystemPrompt(context),
    messages: session.history,

    // Streaming text — progress updates while agent is working
    text: ({ content, done }) => {
      if (done) return <NarrativeBlock content={content} />
      return <ProgressStream content={content} />
    },

    tools: {

      emit_approval_gate: {
        description: 'Render an approval gate for a high-stakes action',
        parameters: approvalGateSchema,
        generate: async function* (params) {
          // Immediate skeleton while data loads
          yield <ApprovalGateSkeleton />

          const enriched = await enrichApprovalData(params, context)

          return (
            <ApprovalGate
              data={enriched}
              onApprove={async () => {
                'use server'
                await executeAction(enriched)
                await logAuditEntry(enriched, 'approved', session)
              }}
              onReject={async (reason: string) => {
                'use server'
                await logAuditEntry(enriched, 'rejected', session, reason)
                await notifyAgent(session, 'action_rejected', reason)
              }}
            />
          )
        }
      },

      emit_table: {
        description: 'Render a dynamic data table',
        parameters: tableSchema,
        generate: async function* (params) {
          yield <TableSkeleton />
          return (
            <DynamicTable
              title={params.title}
              columns={params.columns}
              rows={params.rows}
              summary={params.summary}
            />
          )
        }
      },

      emit_attention_required: {
        description: 'Agent is blocked — needs human input to continue',
        parameters: attentionRequiredSchema,
        generate: async function* (params) {
          // Update task status to needs_attention
          await updateTaskStatus(session.task_id, 'needs_attention')
          await notifyAssignedUsers(session, params.urgency)

          return (
            <AttentionRequired
              blockedAt={params.blocked_at_step}
              reason={params.reason}
              urgency={params.urgency}
              options={params.options}
              onResolve={async (optionId: string, input?: string) => {
                'use server'
                await resolveBlock(session, optionId, input)
                await updateTaskStatus(session.task_id, 'in_progress')
                await resumeAgentExecution(session)
              }}
            />
          )
        }
      },

      emit_review_items: {
        description: 'Render items for human review before action',
        parameters: reviewItemsSchema,
        generate: async function* (params) {
          yield <ReviewItemsSkeleton count={params.items.length} />
          return (
            <ReviewItems
              title={params.title}
              items={params.items}
              allowBulkApproval={params.allow_bulk_approval}
              onApproveAll={async () => {
                'use server'
                await queueAction('bulk_approve', params.items)
              }}
              onApproveItem={async (itemId: string) => {
                'use server'
                const item = params.items.find(i => i.id === itemId)
                await queueAction('approve_item', [item])
              }}
              onRejectAll={async (reason: string) => {
                'use server'
                await notifyAgent(session, 'items_rejected', reason)
              }}
            />
          )
        }
      }

    }
  })

  return result.value
}

The generate: async function* pattern is what makes the streaming feel live. The yield renders an immediate skeleton. The agent processes. The return renders the final component with real data. Users see the interface assembling in real time as the agent works — not a loading spinner and then a sudden page change.

The task board — tracking parallel agent execution

The task board is the operational centre of any agentic application. It gives users a real-time view of everything the agent is doing, has done, and is waiting on.

The five-column Kanban model maps directly to the agentic execution lifecycle:

type TaskStatus =
  | 'todo'               // scheduled — agent not yet started
  | 'in_progress'        // agent executing — live updates streaming
  | 'needs_attention'    // agent paused — human input required
  | 'in_review'          // agent complete — awaiting human sign-off
  | 'completed'          // approved and done

interface Task {
  id: string
  name: string
  status: TaskStatus
  current_step?: string
  steps_completed?: number
  estimated_steps?: number
  blocked_reason?: string
  urgency?: 'low' | 'medium' | 'high'
  assigned_to: string
  due_date: string
  created_at: string
  completed_at?: string
  metadata: {
    actions_approved: number
    actions_rejected: number
    outputs_created: number
    duration_minutes?: number
  }
}

'use client'

import { useEffect, useState } from 'react'
import { createClient } from '@/lib/supabase/client'

const COLUMNS: {
  status: TaskStatus
  label: string
  description: string
  highlight?: boolean
}[] = [
  {
    status: 'todo',
    label: 'To Do',
    description: 'Scheduled — not yet started'
  },
  {
    status: 'in_progress',
    label: 'In Progress',
    description: 'Agent executing — live updates'
  },
  {
    status: 'needs_attention',
    label: 'Needs Attention',
    description: 'Agent paused — your input required',
    highlight: true
  },
  {
    status: 'in_review',
    label: 'In Review',
    description: 'Awaiting final sign-off'
  },
  {
    status: 'completed',
    label: 'Completed',
    description: 'Approved and done'
  }
]

export function TaskBoard() {
  const [tasks, setTasks] = useState<Task[]>([])
  const supabase = createClient()

  useEffect(() => {
    fetchTasks().then(setTasks)

    // Real-time subscription — board updates the instant
    // any agent changes status anywhere in the system
    const channel = supabase
      .channel('task-board')
      .on(
        'postgres_changes',
        { event: '*', schema: 'public', table: 'tasks' },
        (payload) => {
          setTasks(prev => {
            const updated = payload.new as Task
            const idx = prev.findIndex(t => t.id === updated.id)
            if (idx === -1) return [...prev, updated]
            return prev.map(t => t.id === updated.id ? updated : t)
          })
        }
      )
      .subscribe()

    return () => { supabase.removeChannel(channel) }
  }, [])

  const byStatus = groupBy(tasks, 'status')
  const attentionCount = byStatus['needs_attention']?.length ?? 0

  return (
    <div className="h-full flex flex-col">

      {attentionCount > 0 && (
        <div className="bg-amber-50 border-b border-amber-200 px-6 py-3
                        flex items-center gap-3">
          <span className="text-amber-700 font-medium text-sm">
            {attentionCount} {attentionCount === 1
              ? 'task needs'
              : 'tasks need'} your attention
          </span>
          <button
            className="text-amber-600 text-sm underline"
            onClick={() => scrollToColumn('needs_attention')}
          >
            Review now
          </button>
        </div>
      )}

      <div className="flex-1 flex gap-4 p-6 overflow-x-auto">
        {COLUMNS.map(column => (
          <div
            key={column.status}
            id={`column-${column.status}`}
            className={`
              flex-shrink-0 w-72 flex flex-col rounded-lg
              ${column.highlight
                ? 'bg-amber-50 ring-1 ring-amber-200'
                : 'bg-slate-50'
              }
            `}
          >
            <div className="p-4 border-b border-slate-200">
              <div className="flex items-center justify-between mb-1">
                <span className="font-medium text-slate-900 text-sm">
                  {column.label}
                </span>
                <span className="text-xs font-medium text-slate-500
                                 bg-white border border-slate-200
                                 rounded-full px-2 py-0.5">
                  {byStatus[column.status]?.length ?? 0}
                </span>
              </div>
              <p className="text-xs text-slate-400">{column.description}</p>
            </div>

            <div className="flex-1 p-3 flex flex-col gap-2 overflow-y-auto">
              {(byStatus[column.status] ?? []).map(task => (
                <TaskCard key={task.id} task={task} />
              ))}
              {(byStatus[column.status] ?? []).length === 0 && (
                <p className="text-xs text-slate-300 text-center py-8">
                  Nothing here
                </p>
              )}
            </div>
          </div>
        ))}
      </div>
    </div>
  )
}

function TaskCard({ task }: { task: Task }) {
  return (
    <div
      className={`
        bg-white rounded-lg border p-3 cursor-pointer
        hover:shadow-sm transition-shadow
        ${task.status === 'needs_attention'
          ? 'border-amber-300'
          : 'border-slate-200'
        }
      `}
      onClick={() => openTask(task.id)}
    >
      <div className="flex items-center justify-between mb-2">
        <StatusBadge status={task.status} />
        <span className="text-xs text-slate-400">
          {task.assigned_to}
        </span>
      </div>

      <p className="text-sm font-medium text-slate-900 mb-2">
        {task.name}
      </p>

      {task.status === 'in_progress' && (
        <div className="mb-2">
          <div className="flex items-center gap-2 mb-1">
            <div className="w-1.5 h-1.5 rounded-full bg-blue-500 animate-pulse" />
            <span className="text-xs text-slate-500">{task.current_step}</span>
          </div>
          <div className="w-full bg-slate-100 rounded-full h-1">
            <div
              className="bg-blue-500 h-1 rounded-full transition-all duration-500"
              style={{
                width: `${((task.steps_completed ?? 0) /
                          (task.estimated_steps ?? 1)) * 100}%`
              }}
            />
          </div>
        </div>
      )}

      {task.status === 'needs_attention' && (
        <div className="bg-amber-50 rounded p-2 mb-2">
          <p className="text-xs text-amber-700">{task.blocked_reason}</p>
        </div>
      )}

      <div className="flex items-center justify-between mt-2">
        <span className="text-xs text-slate-400">
          Due {formatRelativeDate(task.due_date)}
        </span>
        {task.status === 'completed' && (
          <span className="text-xs text-slate-400">
            {task.metadata.duration_minutes}m
          </span>
        )}
      </div>
    </div>
  )
}

Per-task sessions — context continuity across multi-step execution

Every task has its own isolated, persistent chat session. This enables full audit trails, resume capability after blocks, and context continuity across multi-day tasks.

interface TaskSession {
  id: string
  task_id: string
  history: Anthropic.MessageParam[]
  status: TaskStatus
  last_approval_decision?: 'approved' | 'rejected'
  last_approval_notes?: string
  created_at: string
  updated_at: string
  metadata: {
    approval_gates_shown: number
    approval_gates_approved: number
    approval_gates_rejected: number
    steps_completed: number
    estimated_steps: number
  }
}

// Always atomic — row lock prevents concurrent writes
async function appendToSession(
  sessionId: string,
  role: 'user' | 'assistant',
  content: Anthropic.MessageParam['content']
): Promise<TaskSession> {
  return await db.transaction(async (tx) => {
    const session = await tx
      .select()
      .from(sessions)
      .where(eq(sessions.id, sessionId))
      .for('update')
      .then(rows => rows[0])

    const updatedHistory: Anthropic.MessageParam[] = [
      ...session.history,
      { role, content }
    ]

    return await tx
      .update(sessions)
      .set({
        history: updatedHistory,
        updated_at: new Date().toISOString()
      })
      .where(eq(sessions.id, sessionId))
      .returning()
      .then(rows => rows[0])
  })
}

// Resume from exactly where the agent paused
async function resumeSession(sessionId: string): Promise<void> {
  const session = await getSession(sessionId)

  const resumeMessage: Anthropic.MessageParam = {
    role: 'user',
    content: `The human has resolved the previous block.
    Decision: ${session.last_approval_decision}
    Notes: ${session.last_approval_notes ?? 'None provided'}
    Please continue from where you stopped.
    Do not repeat steps you have already completed.`
  }

  await appendToSession(sessionId, 'user', resumeMessage.content)

  await runAgentStep({
    taskId: session.task_id,
    sessionHistory: [...session.history, resumeMessage],
    systemPrompt: buildSystemPrompt(session.context)
  })
}

The row lock on session writes is critical. Without it, concurrent requests to the same session — which happen frequently when parallel agents are running — can produce race conditions that corrupt the conversation history and break agent context.

The three things that will surprise you

1. The approval gate reduces friction, not increases it.

The instinct is to minimise approval gates to reduce user friction. This instinct is wrong in high-stakes domains. Users who can see exactly what the agent wants to do and explicitly approve it trust the system far more than users who watch the agent act autonomously. An explicit approval step converts an anxious user into a confident one. Trust compounds over time.

2. The reasoning field is more valuable than the output itself.

When you first define your output schema, reasoning feels like optional metadata. In production, it is the most important field in the schema. Users who can read why the agent produced a given output approve correct outputs faster and catch incorrect outputs more reliably. The reasoning is not documentation — it is the primary trust-building mechanism in the UI.

3. Parallel agents surface a prioritisation problem you will not anticipate.

When multiple agents run simultaneously, approval gates and attention alerts from different tasks arrive in the queue at the same time. Displaying them in chronological order is wrong. Users need to triage by urgency and impact. Build the prioritisation logic into your approval queue from day one. Retrofitting it is painful.

What is next

Tomorrow: the difference between a chat UI and a true agent UI.

They look nearly identical from the outside. The architecture underneath is completely different. Five specific decisions that look the same on the surface but have entirely different implications when you build them — and why chat-style thinking breaks down the moment you try to implement parallel execution, session persistence, and audit trails at the same time.

Resources

Follow this series on Dev.to, LinkedIn, and X. New post every day for 30 days. Questions or implementation discussions — drop them in the comments.

How JavaScript Executes Code: Understanding Execution Context and the Call Stack

Selasie Sepenu — Sun, 11 May 2025 21:54:37 +0000

JavaScript is a single-threaded, synchronous programming language at its core, but it handles asynchronous operations through clever mechanisms like the event loop. To truly understand how JavaScript works under the hood, you need to grasp two fundamental concepts: execution context and the call stack.

The JavaScript Execution Context

An execution context is an abstract concept that holds information about the environment where JavaScript code is executed. There are three types of execution contexts in JavaScript:

Global Execution Context: Created when the JavaScript engine first starts executing your code
Function Execution Context: Created whenever a function is invoked
Eval Execution Context: Created inside an eval function (rarely used)

Each execution context has two phases:

Creation phase
Execution phase

Creation Phase

During the creation phase, the JavaScript engine:

Creates the Variable Object (VO) which contains:
- Function arguments (for function contexts)
- Inner variable declarations (but not their assignments)
- Function declarations
Creates the scope chain
Determines the value of this

This explains hoisting - why you can use functions before they're declared in your code, but variables will be undefined until their actual assignment.

Execution Phase

During the execution phase:

The code is executed line by line
Variables are assigned values
Functions are executed when called

The Call Stack

The call stack is a data structure that keeps track of function calls in your program. It works on the LIFO principle (Last In, First Out).

Here's how it works:

When the JavaScript engine starts executing your script, it creates a global execution context and pushes it onto the call stack
When a function is called, a new execution context for that function is created and pushed onto the stack
When a function returns, its execution context is popped off the stack
The engine continues executing the current context (now the one below in the stack)

function first() {
  console.log("Inside first function");
  second();
  console.log("Back to first function");
}

function second() {
  console.log("Inside second function");
  third();
  console.log("Back to second function");
}

function third() {
  console.log("Inside third function");
}

first();
console.log("Global execution");

The call stack for this code would look like:

third() is pushed when called from second()
second() is pushed when called from first()
first() is pushed when called from global
Global execution context is always at the bottom

When third() completes, it's popped off, then second(), then first(), and finally the global context remains until the program ends.

Visualizing the Process

Let's examine a concrete example:

var a = 2;

function square(num) {
  var result = num * num;
  return result;
}

var squareOfTwo = square(a);
console.log(squareOfTwo);

Execution steps:

Global Execution Context Creation:
- Creates variable object with:
  - a: undefined
  - square: <function>
  - squareOfTwo: undefined
- Sets up scope chain
- Determines this (window in browsers)
Global Execution:
- Assigns a = 2
- Reaches square(a) call:
  - Creates new execution context for square
  - Creation phase for square:
  - num: 2 (from argument)
  - result: undefined
  - Execution phase for square:
  - Calculates result = 2 * 2
  - Returns 4
  - square context is popped from call stack
- Assigns return value to squareOfTwo = 4
- Calls console.log(4)
  - Creates context for console.log
  - Executes it
  - Pops it from stack
Program completes, global context is popped

Handling Asynchronous Code

While the call stack handles synchronous operations, asynchronous operations (like setTimeout, promises, or AJAX calls) are handled by the browser APIs and the event queue. The event loop constantly checks if the call stack is empty, and if so, pushes the next callback from the queue to the stack.

This separation is why JavaScript can handle asynchronous operations despite being single-threaded.

Key Takeaways

JavaScript executes code by creating and managing execution contexts
Each context has creation and execution phases
The call stack tracks the execution order of functions
Understanding these concepts explains hoisting, scope, and closure behaviors
Asynchronous operations are handled outside the main call stack

I believe this has been both helpful and insightful to all Javascript developers.Until some other time, happy coding🎉🎉

How Engineering Saved My Friend’s Blog $15 a Month—And Why It Matters

Selasie Sepenu — Sun, 16 Mar 2025 23:48:58 +0000

In the world of software development, there’s a saying: “Why buy when you can build?” While this isn’t always the best advice (sometimes reinventing the wheel is a waste of time), there are moments when rolling up your sleeves and building a custom solution can lead to significant savings, better control, and a deeper understanding of your system. This is the story of how I helped my friend save $15 a month by engineering a feature for their blog—and why it’s a win worth celebrating.

The Problem: Real-Time Comments on a Budget

Having built out the basic functionality for my friend's blog, she wanted to include a comments section where readers could engage with their content. Since we had already used Sanity.io to this point, we initially considered using it again for this feature. However, Sanity offers a real-time comments feature, but it comes at a cost: $15 per month. While $15 might not seem like much, over time, it adds up. For a small blog, every dollar counts, and we wanted to avoid recurring costs wherever possible.

But the real question was: Could we build this feature ourselves? And if so, would it be worth the effort?

The Solution: Building a Custom Real-Time Comments System

Instead of paying for Sanity’s real-time comments feature, I decided to engineer a custom solution using Supabase, an open-source alternative to Firebase. Here’s how I did it:

Database Setup:
- I created a comments table in Supabase to store all comments. Each comment included fields like name, email, comment, post_id, and created_at.
Real-Time Updates:
- Supabase’s real-time functionality allowed me to listen for new comments and update the UI dynamically. This meant readers could see new comments appear instantly without refreshing the page.
Custom API:
- I built a simple API endpoint to handle comment submissions. When a reader submits a comment, it’s saved to the Supabase database, and the real-time subscription updates the UI.
Cost Savings:
- Supabase’s free tier was more than enough for our needs, meaning we paid $0 for this feature. Over time, this saves my friend $180 per year—and potentially thousands over the lifetime of the blog.

The Engineering Advantage

Building this feature wasn’t just about saving money. It was about flexibility, control, and learning. Here’s why engineering this solution was worth it:

Total Control:
- By building the feature ourselves, we had complete control over how it worked. We could customize the UI, add new features (like comment moderation), and optimize performance.
No Vendor Lock-In:
- Relying on a third-party service like Sanity’s real-time comments feature would have tied us to their platform. By using Supabase, we retained the freedom to switch databases or even build our own backend in the future.
Learning Opportunity:
- Building this feature from scratch gave me a deeper understanding of real-time systems, database design, and API integration. These skills are invaluable and can be applied to future projects.
Cost Efficiency:
- While $15 a month might seem trivial, it’s a recurring cost that adds up over time. By building the feature ourselves, we saved $180 per year—money that can now be invested in other areas of the blog.

The Bigger Picture: Why This Matters

This isn’t just a story about saving $15 a month. It’s a story about empowerment through engineering. In a world where SaaS solutions are often the default choice, it’s easy to forget the value of building things yourself. Here’s why this approach matters:

Sustainability:
- Recurring costs can quickly add up, especially for small projects or startups. By building custom solutions, we can keep expenses low and reinvest savings into growth.
Customization:
- Off-the-shelf solutions often come with limitations. Building our own feature allows us to tailor it to our exact needs.
Skill Development:
- Every project is an opportunity to learn. By building this feature, I gained valuable experience that will benefit me in future endeavors.
Independence:
- Relying on third-party services can be risky. By building our own solutions, we reduce dependency on external providers and gain more control over our product.

The Takeaway: Build vs. Buy

So, should we always build instead of buy? Not necessarily. There are times when using a third-party service makes sense—especially when time is limited or the feature is highly complex. But for small, manageable features like a comments section, building our own solution can be a smart move.

In this case, engineering the real-time comments feature saved my friend $15 a month, but more importantly, it gave us control, flexibility, and confidence in our ability to solve problems. And that’s worth far more than $15.

Final Thoughts

In the end, this project was a reminder that engineering is about more than just writing code. It’s about solving problems, making smart decisions, and creating value. By building our own real-time comments system, we not only saved money but also gained a deeper appreciation for the power of engineering.

So, the next time we’re faced with a decision to build or buy, we’ll ask ourselves: Can we engineer a solution that’s better, cheaper, and more aligned with our goals? If the answer is yes, we’ll roll up our sleeves and start building. The rewards—both financial and personal—are well worth it.

What do you think? Have you ever built a custom solution to save money or gain more control? Share your story in the comments below! (And yes, the comments are real-time, thanks to our custom-built system. 😉)

Hey everyone. Please do well to check out my latest post.

Selasie Sepenu — Tue, 11 Mar 2025 14:15:45 +0000

Building a Global Modal System in Next.js: A Deep Dive into Client-Side State Management

Selasie Sepenu ・ Mar 11

#programming #webdev #typescript #nextjs

Building a Global Modal System in Next.js: A Deep Dive into Client-Side State Management

Selasie Sepenu — Tue, 11 Mar 2025 14:14:54 +0000

Creating a seamless and reusable modal system is a common requirement in modern web development. Modals are used for everything from user authentication to notifications, and they need to be accessible, performant, and easy to manage across an application. However, implementing a global modal system in a framework like Next.js—especially with the introduction of Server Components—can be tricky. In this article, I’ll walk you through my experience building a global modal system using Zustand for state management, React Portals for rendering, and the challenges I faced along the way.

The Problem: A Global Modal System

The goal was simple: create a modal that could be triggered from anywhere in the application and would render consistently across all pages. The modal needed to:

Be Global: Accessible from any component or page.
Be Performant: Avoid unnecessary re-renders.
Work with Server Components: Next.js 13+ utilizes Server Components, which complicated things because React hooks (like Zustand’s useStore) can only be used in Client Components.

At first glance, this seemed straightforward. However, as I dove deeper, I encountered several challenges that required creative solutions.

The Initial Approach: Wrapping the Application

My first thought was to wrap the entire application in a ClientWrapper component that would handle the modal logic. This wrapper would use Zustand to manage the modal’s state and conditionally render the modal based on that state.

The Code

Here’s what the initial implementation looked like:

"use client";
import { useModalStore } from "@/store/store";
import WaitlistModal from "@/components/ui/Modal";
import { ReactNode } from "react";

interface ClientWrapperProps {
  children: ReactNode;
}

export default function ClientWrapper({ children }: ClientWrapperProps) {
  const { isModalOpen, closeModal } = useModalStore();

  return (
    <>
      {children}
      <WaitlistModal isOpen={isModalOpen} onClose={closeModal} />
    </>
  );
}

The Problem

While this approach worked in theory, it introduced a critical issue: unreachable code. When the children were rendered first, the WaitlistModal became unreachable, and vice versa. This was due to the way React handles component rendering and the order of operations.

The Solution: React Portals

To solve the unreachable code issue, I turned to React Portals. Portals allow you to render a component outside its parent DOM hierarchy, which is perfect for modals that need to appear above all other content.

What Are Portals?

Portals are a feature in React that let you render a component into a DOM node outside its parent component. This is particularly useful for modals, tooltips, and other overlay components that need to break out of their container.

Implementing Portals

I created a Portal component to handle the rendering logic:

"use client";
import { useEffect, useState } from "react";
import { createPortal } from "react-dom";

interface PortalProps {
  children: React.ReactNode;
}

export default function Portal({ children }: PortalProps) {
  const [mounted, setMounted] = useState(false);

  useEffect(() => {
    setMounted(true);
    return () => setMounted(false);
  }, []);

  if (!mounted) return null;

  return createPortal(children, document.body);
}

Updating the Modal Component

Next, I wrapped the WaitlistModal component with the Portal component:

"use client";
import { motion } from "framer-motion";
import Portal from "./Portal";

interface WaitlistModalProps {
  isOpen: boolean;
  onClose: () => void;
}

const WaitlistModal = ({ isOpen, onClose }: WaitlistModalProps) => {
  if (!isOpen) return null;

  return (
    <Portal>
      <motion.div
        initial={{ opacity: 0 }}
        animate={{ opacity: 1 }}
        exit={{ opacity: 0 }}
        className="fixed inset-0 bg-black bg-opacity-50 flex justify-center items-center z-50"
        onClick={onClose}
      >
        <motion.div
          initial={{ y: -50, opacity: 0 }}
          animate={{ y: 0, opacity: 1 }}
          exit={{ y: -50, opacity: 0 }}
          className="bg-white rounded-lg p-8 w-full max-w-md relative z-60"
          onClick={(e) => e.stopPropagation()}
        >
          {/* Modal content */}
        </motion.div>
      </motion.div>
    </Portal>
  );
};

export default WaitlistModal;

Why Portals Work

Portals solved the unreachable code issue by rendering the modal outside the main component tree. This ensured that the modal would always appear above other content, regardless of where it was triggered.

The Next Challenge: Server Components

With the modal working as expected, I encountered a new challenge: Server Components. Next.js 13+ utilizes Server Components, which are rendered on the server and cannot use React hooks like useState or useStore.

The Error

When I tried to use useModalStore in the app/layout.tsx file, I got the following error:

Error: useSyncExternalStore only works in Client Components. Add the "use client" directive at the top of the file to use it.

The Solution: A Modal Provider

To resolve this, I created a ModalProvider component that would handle the modal logic and render the WaitlistModal. This component would be a Client Component, ensuring that useModalStore could be used without issues.

ModalProvider.tsx

"use client";
import { useModalStore } from "@/store/store";
import WaitlistModal from "@/components/ui/Modal";

export default function ModalProvider() {
  const { isModalOpen, closeModal } = useModalStore();

  return <WaitlistModal isOpen={isModalOpen} onClose={closeModal} />;
}

Updating the Layout

I then included the ModalProvider in the app/layout.tsx file:

import { Inter } from "next/font/google";
import "./globals.css";
import ModalProvider from "@/components/ModalProvider";

const inter = Inter({ subsets: ["latin"] });

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body className={inter.className}>
        {children}
        <ModalProvider />
      </body>
    </html>
  );
}

The Final Result

With these changes, the global modal system was fully functional:

Global Access: The modal could be triggered from any component using the useModalStore hook.
Performant: The modal was rendered only when needed, avoiding unnecessary re-renders.
Server-Safe: The modal logic was handled in a Client Component, ensuring compatibility with Server Components.

Key Takeaways

Portals Are Powerful: React Portals are an excellent tool for rendering components outside their parent hierarchy, making them ideal for modals and overlays.
Separate Client and Server Logic: When working with Next.js Server Components, it’s essential to separate client-side logic into dedicated Client Components.
State Management Matters: Zustand provided a simple and effective way to manage global state, but it’s crucial to use it correctly in a Server Components architecture.

Conclusion

Building a global modal system in Next.js was a challenging but rewarding experience. By leveraging React Portals, Zustand, and a clear separation of client and server logic, I was able to create a performant and reusable solution. If you’re working on a similar project, I hope this article provides valuable insights and helps you avoid common pitfalls.

Happy coding! 🚀

Demystifying Big O Notation: A Guide For Software Engineers

Selasie Sepenu — Fri, 26 Jul 2024 15:21:08 +0000

As engineers,we constantly strive to write efficient code.But how do we measure and communicate efficiency in our algorithms? This is where the Big O notation comes in. Big O notation is a mathematical concept used to describe the performance of an algorithm in terms of time and space complexity. In this article, we will break down Big O notation, make it accessible and understandable for engineers of all levels.

What is Big O Notation?

Big O notation provides a high-level understanding of the efficiency of an algorithm. It describes the upper bound of the algorithms running time or space requirement in the worstcase scenario. This allows us to compare different algorithms and determine which one is more efficient as the input size grows.

Why is Big O notation important?

Understanding Big O notation crucial for several reasons:
1)Performance Optimization: It allows developers to choose the most efficient algorithm for a given problem.
2)Scalability: It ensures that the chosen algorithm can handle larger inputs without degrading performance significantly.
3)Algorithm Comparison: It allows developers to choose the most efficient algorithm for a given problem.

Common Big O Notations

O(1)-Constant Time: The algorithms performance remains constant, regardless of input size.
Example: Accessing an array by index.

O(logn): The algorithm's performance increases logarithmically with the input size.
Example: Binary Search

O(n)-Linear Time: The algorithm's performance increases linearlty with input size.
Example: Iterating through an array.

O(nlogn)-Linearithmic Time: The algorithms performance increases linearly and logarithmically with the input size.
Example: Merge Sort

O(n^2)-Quadratic Time: The algorithm's performance increases quadratically with input size.
Exmaple: Bubble Sort

0(2^n) - Exponential Time: The algortithm's performance doubles with each addtional input.
Example: Recursive Fibonacci Calculation

0(n!) -Factorial Time: The algorithm's performance increases with the input size.
Example: Solving the travelling salesman problem using brute force.

Big O notation is an essential tool for engineers to evaluate and optimize the efficiency of their algorithms.By understanding types of Big O notations and their implications, you can write more efficient code and make the better algorithmic choices. In the next article, we'll dive deeper into pratical examples and explore the how to analyze the Big O notation of real-world examples.