Components

Components are the basic building blocks of Qwik Applications. They are reusable piece of code that can be used to build a UI.

Qwik components are unique in that:

Qwik components automatically get broken down into lazy-loaded chunks by the Optimizer.
They are resumable (a component can get created on a server and continue its execution on the client).
They are reactive and render independently of other components on the page. See rendering.

`component$()`

A Qwik component is a function that returns JSX wrapped in a component$ call.

import { component$ } from '@builder.io/qwik';
 
export default component$(() => {
  return <div>Hello World!</div>;
});

https://qwik.dev/demo/component/simple/

The component$ function, marked by the trailing $, enables the Optimizer to split components into separate chunks. This allows each chunk to be loaded independently as needed, rather than loading all components whenever the parent component is loaded.
Note: index.tsx, layout.tsx in routes folder, root.tsx and all entry files need export default. For other components you can use export const and export function.

Composing Components

Components can be composed together to create more complex components.

import { component$ } from '@builder.io/qwik';
 
export default component$(() => {
  return (
    <>
      <p>Parent Text</p>
      <Child />
    </>
  );
});
 
const Child = component$(() => {
  return <p>Child Text</p>;
});

https://qwik.dev/demo/component/child/

Notice that Qwik components are already lazy loaded thanks to the $ sign. That means that you don't need to dynamically import the child component manually, Qwik will do it for you.

Counter Example

A slightly more complex example of a counter.

import { component$, useSignal } from '@builder.io/qwik';
 
export default component$(() => {
  const count = useSignal(0);
 
  return (
    <>
      <p>Count: {count.value}</p>
      <button onClick$={() => count.value++}>Increment</button>
    </>
  );
});

https://qwik.dev/demo/state/counter/

Props

Props are used to pass data from the parent into the component. Props are accessible via the props argument to the component$ function.

In this example a component Item declares optional name, quantity, description, and price.

import { component$ } from '@builder.io/qwik';
 
interface ItemProps {
  name?: string;
  quantity?: number;
  description?: string;
  price?: number;
}
 
export const Item = component$<ItemProps>((props) => {
  return (
    <ul>
      <li>name: {props.name}</li>
      <li>quantity: {props.quantity}</li>
      <li>description: {props.description}</li>
      <li>price: {props.price}</li>
    </ul>
  );
});
 
export default component$(() => {
  return (
    <>
      <h1>Props</h1>
      <Item name="hammer" price={9.99} />
    </>
  );
});

https://qwik.dev/demo/component/props/

In the example above we are using component$<ItemProps> to provide an explicit type for the props. This is optional but it allows the TypeScript compiler to check that the props are used correctly.

Default props

You can use the destructuring pattern with props to provide default values.

interface Props {
  enabled?: boolean;
  placeholder?: string;
}
 
// We can use JS's destructuring of props to provide a default value.
export default component$<Props>(({enabled = true, placeholder = ''}) => {
  return (
    <input disabled={!enabled} placeholder={placeholder} />
  );
});

Rendering on Reactivity

Qwik components are reactive. This means that they automatically update on a state change. There are two kinds of updates:

A state is bound to a DOM text or attribute. Such changes usually directly update the DOM and do not require component function re-execute.
A state causes a structural change to the DOM (elements are created and or removed). Such changes require component function to re-execute.

The thing to keep in mind is that when state changes, your component function may execute zero or more times depending on what the state is bound to. For this reason, the function should be idempotent and you should not rely on the number of times it executes.

A state change causes the component to get invalidated. When components get invalidated, they are added to the invalidation queue, which is flushed (rendered) on the next requestAnimationFrame. This acts as a form of coalescing for component rendering.

Getting hold of DOM element

Use ref to get hold of a DOM element. Create a signal to store DOM element. Then pass the signal to the JSX ref property.

Getting a reference to DOM elements can be useful to calculate the element size (getBoundingClientRect), computed styles, initializing a WebGL canvas, or even wire-up some third-party library that interacts with DOM elements directly.

import { component$, useVisibleTask$, useSignal } from '@builder.io/qwik';
 
export default component$(() => {
  const width = useSignal(0);
  const height = useSignal(0);
  const outputRef = useSignal<Element>();
 
  useVisibleTask$(() => {
    if (outputRef.value) {
      const rect = outputRef.value.getBoundingClientRect();
      width.value = Math.round(rect.width);
      height.value = Math.round(rect.height);
    }
  });
 
  return (
    <section>
      <article
        ref={outputRef}
        style={{ border: '1px solid red', width: '100px' }}
      >
        Change text value here to stretch the box.
      </article>
      <p>
        The above red box is {height.value} pixels high and {width.value}{' '}
        pixels wide.
      </p>
    </section>
  );
});

https://qwik.dev/demo/component/ref/

Accessing Elements by `id` Across Server and Client Environments

In server and client environments, elements must sometimes be accessed by their id. Use the useId() function to get a unique identifier for the current component that remains consistent across server-side rendering (SSR) and client-side operations. This is pivotal when server-rendered components need client-side scripting, such as:

Animation Engines
Accessibility Enhancement
Other Client-Side Libraries

In a microfrontends setup, where multiple fragments run concurrently, useId() ensures unique and consistent IDs across execution environments, eliminating conflicts.

import {
  component$,
  useId,
  useSignal,
  useVisibleTask$,
} from '@builder.io/qwik';
 
export default component$(() => {
  const elemIdSignal = useSignal<string | null>(null);
  const id = useId();
  const elemId = `${id}-example`;
  console.log('server-side id:', elemId);
 
  useVisibleTask$(() => {
    const elem = document.getElementById(elemId);
    elemIdSignal.value = elem?.getAttribute('id') || null;
    console.log('client-side id:', elemIdSignal.value);
  });
 
  return (
    <section>
      <div id={elemId}>
        Both server-side and client-side console should match this id:
        <br />
        <b>{elemIdSignal.value || null}</b>
      </div>
    </section>
  );
});

https://qwik.dev/demo/component/useId/

Lazy Loading

The component also serves an important role when breaking parent-child relationships for bundling purposes.

export const Child = () => <span>child</span>;
 
const Parent = () => (
  <section>
    <Child />
  </section>
);

In the above example, referring to the Parent component implies a transitive reference to the Child component. When the bundler is creating a chunk, a reference to Parent necessitates bundling Child as well. (Parent internally refers to Child.) These transitive dependencies are a problem because it means that having a reference to the root component will transitively refer to the remainder of the application—something which Qwik tries to avoid explicitly.

To avoid the above problem we don't refer to components directly, instead, we refer to the lazy wrapper. This is created automatically by the component$() function.

import { component$ } from '@builder.io/qwik';
 
export const Child = component$(() => {
  return <p>child</p>;
});
 
export const Parent = component$(() => {
  return (
    <section>
      <Child />
    </section>
  );
});
 
export default Parent;

https://qwik.dev/demo/component/lazy/

In the above example the Optimizer transforms the above to:

const Child = componentQrl(qrl('./chunk-a', 'Child_onMount'));
const Parent = componentQrl(qrl('./chunk-b', 'Parent_onMount'));
const Parent_onMount = () => qrl('./chunk-c', 'Parent_onRender');
const Parent_onRender = () => (
  <section>
    <Child />
  </section>
);

NOTE For simplicity, not all of the transformations are shown; all resulting symbols are kept in the same file for succinctness.

Notice that after the Optimizer transforms the code, the Parent no longer directly references Child. This is important because it allows the bundler (and tree shakers) to freely move the symbols into different chunks without pulling the rest of the application with it.

So what happens when the Parent component needs to render a Child component, but the Child component has not yet been downloaded? First, the Parent component renders its DOM like so.

<main>
  <section>
    <!--qv--><!--/qv-->
  </section>
</main>

As you can see in the above example, the  acts as a marker where the Child component will be inserted once it is lazy-loaded.

Inline Components

In addition to the standard component$() with all of it's lazy-loaded properties, Qwik also supports lightweight (inline) components that act more like components in traditional frameworks.

import { component$ } from '@builder.io/qwik';
 
// Inline component: declared using a standard function.
export const MyButton = (props: { text: string }) => {
  return <button>{props.text}</button>;
};
 
// Component: declared using `component$()`.
export default component$(() => {
  return (
    <p>
      Some text:
      <MyButton text="Click me" />
    </p>
  );
});

https://qwik.dev/demo/component/inline-child/

In the above example, MyButton is an inline component. Unlike the standard component$(), inline components cannot be individually lazy-loaded; instead, they are bundled with their parent component. In this case:

MyButton will get bundled with the default component.
Whenever default is rendered, it will also guarantee that MyButton is rendered.

You can think of inline components as being inlined into the component where they are instantiated.

Limitations

Inline components come with some limitations that the standard component$() does not have. Inline components:

Cannot use use* methods such as useSignal or useStore.
Cannot project content with a <Slot>.

As the name implies, inline components are best used sparingly for lightweight pieces of markup since they offer the convenience of being bundled with the parent component.

Polymorphic components

When you want to output a different type of element depending on props but default to a <div>, you can do it using something like this:

const Poly = component$(
  <C extends string | FunctionComponent = 'div'>({
    as,
    ...props
  }: { as?: C } & PropsOf<string extends C ? 'div' : C>) => {
    const Cmp = as || 'div';
    return (
      <Cmp {...props}>
        <Slot />
      </Cmp>
    );
  }
);
 
export const TestComponent = component$(() => {
  // These all work with correct types
  return (
    <>
      <Poly>Hello from a div</Poly>
      <Poly as="a" href="/blog">
        Blog
      </Poly>
      <Poly as="input" onInput$={(ev, el) => console.log(el.value)} />
      <Poly as={OtherComponent} someProp />
    </>
  );
});

Note the string extends C, this is only true when TypeScript cannot infer the type from the as prop allowing you to specify the default type.

API Overview

State

useSignal(initialState) - creates a reactive value
useStore(initialStateObject) - creates a reactive object that can be used to store state
createContextId(contextName) - creates a context reference
useContextProvider() - provides a value to a given context
useContext() - reads the value of the current context

Styles

useStylesScoped$() - appends scoped styles to the component
useStyles$() - appends unscoped styles to the component

Events

useOn() - appends a listener to the current component programmatically
useOnWindow() - appends a listener to the window object programmatically
useOnDocument() - appends a listener to the document object programmatically

Tasks/Lifecycle

useTask$() - defines a callback that will be called before render and/or when a watched store changes
useVisibleTask$() - defines a callback that will be called after rendering in the client only (browser)
useResource$() - creates a resource to asynchronously load data