Qwik JS Tutorial – Part 3: Core Fundamentals of Qwik

Introduction

After setting up a Qwik project and understanding its structure, the next step is to learn the core fundamentals that power a Qwik application. These fundamentals may feel familiar if you have worked with React or other component-based frameworks, but Qwik introduces important differences in how components, state, and reactivity are handled.

In this part, we will focus on the building blocks of Qwik: components, JSX, signals, props, and basic reactivity. The goal is to build a strong foundation before moving on to routing, data loading, and advanced concepts.

Qwik Components

Components are the basic units of a Qwik application. A component defines a piece of UI and the logic associated with it.

In Qwik, components are:

• Written using functions
• Composed using JSX
• Designed to be serializable

A simple Qwik component looks like this:

import { component$ } from '@builder.io/qwik';

export const Hello = component$(() => {
  return <h1>Hello Mishri Lal Sahu</h1>;
});

Understanding component$

The component$ function is used to define a Qwik component. The $ symbol indicates that the function can be lazy-loaded and resumed later. This is an important part of Qwik’s resumability model.

Components should remain lightweight and avoid non-serializable values such as direct DOM references or browser-only APIs during initial rendering.

JSX in Qwik

Qwik uses JSX to describe UI, similar to React. JSX allows you to write HTML-like syntax directly in JavaScript or TypeScript files.

Key points about JSX in Qwik:

• JSX is compiled at build time
• Event handlers are lazy-loaded
• JSX output is optimized for server rendering

Example:

export const Message = component$(() => {
  const text = 'Welcome to Mishri Lal Sahu's Blog';
  return <p>{text}</p>;
});

JSX expressions in Qwik follow standard JavaScript rules and can include variables, conditions, and function calls.

Signals: Reactive State in Qwik

Signals are the primary way to manage reactive state in Qwik. A signal represents a value that can change over time and automatically update the UI when it does.

Creating a Signal

Signals are created using useSignal:

import { component$, useSignal } from '@builder.io/qwik';

export const Counter = component$(() => {
  const count = useSignal(0);

  return (
    <div>
      <p>Count: {count.value}</p>
      <button onClick$={() => count.value++}>Increment</button>
    </div>
  );
});

How Signals Work

• A signal holds its value in .value
• Updating the value triggers a reactive update
• Only the affected parts of the UI are updated

Signals are designed to be serializable, making them suitable for resumable applications.

Stores vs Signals

Qwik also provides useStore for managing object-based state.

import { component$, useStore } from '@builder.io/qwik';

export const UserProfile = component$(() => {
  const user = useStore({ name: 'Guest', age: 20 });

  return (
    <div>
      <p>Name: {user.name}</p>
      <p>Age: {user.age}</p>
    </div>
  );
});

Differences Between useSignal and useStore

• useSignal is best for primitive values
• useStore is better for grouped or object-based state
• Both support reactivity and serialization

Choosing between them depends on how your state is structured.

Props in Qwik Components

Props allow data to be passed from a parent component to a child component.

interface GreetingProps {
  name: string;
}

export const Greeting = component$<GreetingProps>(({ name }) => {
  return <h2>Hello, {name}</h2>;
});

Props in Qwik:

• Are typed when using TypeScript
• Are immutable inside the component
• Help keep components reusable

Event Handling in Qwik

Event handling in Qwik is designed to support lazy execution. Event handlers use the $ suffix.

<button onClick$={() => console.log('Clicked')}>Click Me</button>

Key characteristics:

• Event handlers are not executed until triggered
• JavaScript is loaded only when needed
• Helps reduce initial page load cost

Reactivity Model in Qwik

Qwik uses fine-grained reactivity. Instead of re-rendering entire components, Qwik updates only the parts of the UI that depend on changed state.

This model helps:

• Reduce unnecessary computation
• Improve runtime performance
• Keep UI updates predictable

Developers do not need to manually optimize renders in most cases.

Serialization and Safety Rules

Because Qwik relies on resumability, not all values can be stored in state.

Safe values include:

• Primitives (string, number, boolean)
• Plain objects and arrays
• Serializable data

Avoid storing:

• DOM elements
• Functions not wrapped with $
• Browser-only APIs in initial state

Following these rules ensures smooth server-to-client transitions.

Best Practices for Qwik Fundamentals

• Keep components small and focused
• Prefer signals for simple state
• Avoid side effects during rendering
• Use event handlers responsibly
• Think in terms of serialization

These practices help maintain performance and clarity as your application grows.

Summary

In this part of the Qwik tutorial, we covered:

• How Qwik components work
• JSX usage in Qwik
• Signals and stores for state management
• Props and component communication
• Event handling and reactivity

These fundamentals are essential for building real-world Qwik applications.