DEV Community: Gil Fink

Progressive Web Components: Unlocking Universal UI with Native APIs

Gil Fink — Fri, 05 Sep 2025 14:59:03 +0000

The Cross-Framework Conundrum

In the dynamic world of front-end development, we often find ourselves building intricate UI components. These components, born from hours of meticulous design and development, frequently become tethered to a specific framework — be it React, Vue, or Angular. This “framework monogamy” creates a significant challenge: how do you share that expertly crafted component across different projects, used by different teams, potentially leveraging different frameworks, without resorting to painful rewrites or clunky integration hacks?

The ideal scenario is a truly universal component: one codebase, consumable everywhere, without forcing an entire project into a specific ecosystem. This is where the power of Progressive Web Components (PWCs), built on native browser APIs, comes into play.

The Foundation: Native Web Components

At its core, a Web Component is a custom HTML element, completely defined and encapsulated by the browser’s own standards. It’s not a framework; it’s a browser feature. This means it works inherently in any modern browser and can be seamlessly integrated into any front-end framework (or no framework at all).

Let’s illustrate this with a practical example: a collapsible panel. This is a common UI element that often requires custom logic for toggling visibility, accessibility attributes, and perhaps some internal content management.

The Core Web Component: A Collapsible Panel Example

We’ll build our collapsible panel using the native Web Components API directly:

// collapsible-panel.js
class CollapsiblePanel extends HTMLElement {
  static get observedAttributes() {
    return ['open'];
  }

  constructor() {
    super();
    this.attachShadow({ mode: 'open' }); 
    this.isOpen = this.hasAttribute('open');
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          display: block;
          border: 1px solid #ccc;
          margin-bottom: 10px;
        }
        .header {
          padding: 10px;
          background-color: #f0f0f0;
          cursor: pointer;
          font-weight: bold;
          display: flex;
          justify-content: space-between;
          align-items: center;
        }
        .content {
          padding: 10px;
          border-top: 1px solid #eee;
        }
        .icon {
          transition: transform 0.2s ease-in-out;
        }
        :host([open]) .icon {
          transform: rotate(90deg);
        }
      </style>
      <div class="header" role="button" tabindex="0" aria-expanded="${this.isOpen}">
        <slot name="header"></slot>
        <span class="icon">&#9658;</span>
      </div>
      <div class="content">
        <slot></slot>
      </div>
    `;
    this._header = this.shadowRoot.querySelector('.header');
    this._content = this.shadowRoot.querySelector('.content');
  }

  connectedCallback() {
    this._header.addEventListener('click', this._togglePanel);
    this._header.addEventListener('keydown', this._handleKeydown);
    this._updateContentVisibility();
  }

  disconnectedCallback() {
    this._header.removeEventListener('click', this._togglePanel);
    this._header.removeEventListener('keydown', this._handleKeydown);
  }

  attributeChangedCallback(name, oldValue, newValue) {
    if (name === 'open') {
      this.isOpen = newValue !== null;
      this._updateContentVisibility();
      this._header.setAttribute('aria-expanded', this.isOpen);
      this.dispatchEvent(new CustomEvent('panel-toggle', { detail: { open: this.isOpen } }));
    }
  }

  _togglePanel() {
    if (this.isOpen) {
      this.removeAttribute('open');
    } else {
      this.setAttribute('open', '');
    }
  };

  _handleKeydown(event) {
    if (event.key === 'Enter' || event.key === ' ') {
      event.preventDefault();
      this._togglePanel();
    }
  };

  _updateContentVisibility() {
    this._content.style.display = this.isOpen ? '' : 'none';
  }

  toggle() {
    this._togglePanel();
  }
}
customElements.define('collapsible-panel', CollapsiblePanel);

You can use this component directly in HTML:

<collapsible-panel open>
  <span slot="header">My Awesome Panel</span>
  <p>This is some content inside the collapsible panel.</p>
</collapsible-panel>
<collapsible-panel>
  <span slot="header">Another Panel</span>
  <p>More content here.</p>
</collapsible-panel>

The “Progressive” Layer: Framework Enhancements

The Web Component is fully functional on its own. However, in a framework-driven application, developers expect a more “native” integration — passing props, listening to events in a framework-idiomatic way, and potentially leveraging framework context. This is where the “progressive layer” comes in: creating lightweight, framework-specific wrappers that enhance the Web Component’s usability without adding unnecessary overhead to its core.

Enhancing for React Example

In React, we want to treat the Web Component like any other React component, managing its open state and listening to its panel-toggle event:

// CollapsiblePanelReact.jsx
import React, { useRef, useEffect, useState } from 'react';
import './collapsible-panel';

const CollapsiblePanel = ({ children, header, defaultOpen = false, onToggle }) => {
  const panelRef = useRef(null);
  const [isOpen, setIsOpen] = useState(defaultOpen);

  useEffect(() => {
    const currentPanel = panelRef.current;
    if (!currentPanel) return;
    // Synchronize React state to Web Component attribute
    if (isOpen) {
      currentPanel.setAttribute('open', '');
    } else {
      currentPanel.removeAttribute('open');
    }
    const handlePanelToggle = (event) => {
      setIsOpen(event.detail.open);
      onToggle && onToggle(event.detail.open);
    };
    currentPanel.addEventListener('panel-toggle', handlePanelToggle);
    return () => {
      currentPanel.removeEventListener('panel-toggle', handlePanelToggle);
    };
  }, [isOpen, onToggle]);

  return (
    <collapsible-panel ref={panelRef}>
      <span slot="header">{header}</span>
      {children}
    </collapsible-panel>
  );
};

export default CollapsiblePanel;

Now, a consuming developer can use it like this:

// MyApp.jsx
import React from 'react';
import CollapsiblePanel from './CollapsiblePanelReact';

const MyApp = () => {
  const handlePanelToggle = (open) => {
    console.log(`Panel is now ${open ? 'open' : 'closed'}`);
  };

  return (
    <div>
      <CollapsiblePanel header="React Specific Panel" defaultOpen onToggle={handlePanelToggle}>
        <p>This panel integrates seamlessly with React state and events.</p>
      </CollapsiblePanel>
      <button onClick={() => panelRef.current?.toggle()}>Toggle via Ref</button>
    </div>
  );
};

Enhancing for Vue Example

Vue also allows straightforward integration with Web Components. We can create a simple wrapper to align with Vue’s reactivity system and event handling:

<template>
  <collapsible-panel :open="isOpen" @panel-toggle="handleToggle">
    <template v-slot:header>{{ header }}</template>
    <slot></slot>
  </collapsible-panel>
</template>

<script>
import './collapsible-panel';
export default {
  props: {
    header: String,
    open: Boolean, 
  },
  data() {
    return {
      isOpen: this.open,
    };
  },
  watch: {
    open(newVal) {
      this.isOpen = newVal;
    }
  },
  methods: {
    handleToggle(event) {
      this.isOpen = event.detail.open;
      this.$emit('toggle', event.detail.open); 
    },
    toggle() {
      this.$refs.panel.toggle();
    }
  },
};
</script>

And in a Vue app:

<template>
  <div>
    <CollapsiblePanelVue header="Vue Specific Panel" :open="isVuePanelOpen" @toggle="handleVueToggle">
      <p>This content lives happily within a Vue component.</p>
    </CollapsiblePanelVue>
    <button @click="toggleVuePanel">Toggle Vue Panel</button>
  </div>
</template>

<script>
import CollapsiblePanelVue from './CollapsiblePanelVue.vue';
export default {
  components: {
    CollapsiblePanelVue,
  },
  data() {
    return {
      isVuePanelOpen: true,
    };
  },
  methods: {
    handleVueToggle(open) {
      this.isVuePanelOpen = open;
      console.log(`Vue panel is now ${open ? 'open' : 'closed'}`);
    },
    toggleVuePanel() {
      this.isVuePanelOpen = !this.isVuePanelOpen;
    }
  },
};
</script>

The Advantages of PWC

The Progressive Web Component pattern, leveraging native APIs, offers advantages such as:

True Interoperability: Your core UI component is truly framework-agnostic. It’s a standard browser element, guaranteeing maximum reusability across diverse tech stacks.
Reduced Development Overhead: Instead of developing and maintaining multiple versions of the same component for different frameworks, you maintain one core. The framework wrappers are thin layers, primarily focused on prop/event synchronization.
Future-Proofing: Native Web Components are part of the web platform. They are not dependent on a specific framework’s lifecycle or popularity, ensuring your components remain functional and relevant for long-term.
Flexible Integration: Teams can choose to use the native Web Component directly or opt for the framework-enhanced version, providing flexibility without sacrificing quality.

Potential Considerations and Challenges

While Progressive Web Components offer great advantages, it’s also important to acknowledge some potential considerations and challenges. Integrating Web Components into existing framework ecosystems, especially older ones, might sometimes introduce minor friction. For instance, some frameworks might require specific configurations to correctly pass complex data types (like objects or arrays) as attributes, or to handle custom events in their own idiomatic way. There’s also a learning curve for teams unfamiliar with native Web Component APIs, which can differ from framework-specific component paradigms. Furthermore, the tooling and development experience for native Web Components, while rapidly improving, might not always be as mature or feature-rich as those tailored for established frameworks. Developers might need to invest more time in setting up development servers, linting, and testing environments compared to a fully integrated framework CLI. These aspects are often manageable with careful planning and good documentation, but they are worth considering during adoption.

In today’s AI revolution, which includes AI generated code, it is easier and faster to build native Web Components and as a result these challenges become minor and less frightening.

Moving Beyond Framework Silos

In an ecosystem brimming with choices, achieving UI consistency and developer efficiency across projects can seem like an uphill battle. Progressive Web Components, built on the solid foundation of native browser APIs, offer a clear path forward. They empower us to design and build components once, knowing they can adapt and integrate smoothly into any environment. This approach allows us to transcend framework-specific silos and build a more cohesive and sustainable web experience.

Beyond the Basics: Building a Responsive Image Processing Pipeline with the Scheduler API

Gil Fink — Sun, 29 Jun 2025 07:52:50 +0000

Following up on our discussion about mastering task management in JavaScript for smoother UIs, this post will take us deeper into the practical application of the Scheduler API. We’ve seen how postTask() and yield() can combat "janky UIs" by intelligently prioritizing and breaking down operations. Now, let's explore a real-world scenario where these capabilities truly shine: creating a responsive image processing pipeline directly in the browser.

The Challenge: Client-Side Image Processing and UI Responsiveness

Client-side image processing, such as resizing, applying filters, or watermarking, can be incredibly resource-intensive. If not handled carefully, these operations can easily block the main thread, leading to frozen UIs and frustrated users. Imagine a web application where users upload and manipulate high-resolution images — without proper task management, this could quickly become a nightmare.

The Solution: Orchestrating Tasks with the Scheduler API

There are a lot of solutions in the internet that uses Web Workers for image processing task, but this time we are going to leverage the new Scheduler API. The Scheduler API provides the perfect toolkit to manage these computationally heavy tasks without sacrificing responsiveness. We can break down the image processing workflow into smaller, manageable units and assign them appropriate priorities, ensuring that user interactions always take precedence.

A Browser-Based Image Editor

Let’s consider a simplified image editor where a user can upload an image, apply a grayscale filter, and then resize it for display. Here’s how we can use the Scheduler API to keep the UI responsive throughout this process:

1. User Interaction and Immediate Feedback (User-Blocking Priority)

When a user clicks to upload an image or apply a filter, the immediate visual feedback (e.g., a loading spinner, a modal window) is essential. These tasks should be user-blocking:

async function handleImageUpload(event) {
  displayLoadingSpinner();
  await scheduler.postTask(() => {
    // Simulate a quick file read
    console.log("Image upload started: User-Blocking task");
    // ... actual file reading logic
  }, { priority: 'user-blocking' });
  // Now, transition to user-visible for processing
  processImage(event.target.files[0]);
}

2. Image Processing (User-Visible Priority)

The actual image processing (applying a filter, resizing) can be broken down. While important for the user to see the result, these operations can yield periodically to allow the UI to remain interactive. We'll use user-visible priority for these tasks:

async function processImage(file) {
  hideLoadingSpinner();
  displayProcessingIndicator();
  const image = await createImageBitmap(file);
  // Apply Grayscale Filter 
  await scheduler.postTask(async () => {
    console.log("Applying grayscale filter: User-Visible task");
    const canvas = document.createElement('canvas');
    const ctx = canvas.getContext('2d');
    canvas.width = image.width;
    canvas.height = image.height;
    ctx.drawImage(image, 0, 0);
    const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
    const pixels = imageData.data;
    for (let i = 0; i < pixels.length; i += 4) {
      const avg = (pixels[i] + pixels[i + 1] + pixels[i + 2]) / 3;
      pixels[i] = avg; // Red
      pixels[i + 1] = avg; // Green
      pixels[i + 2] = avg; // Blue
      // Yield periodically to prevent UI jank
      if (i % 10000 === 0) { // Yield every 10,000 pixels (adjust as needed)
        await scheduler.yield();
        console.log("Yielded during grayscale processing");
      }
    }
    ctx.putImageData(imageData, 0, 0);
    console.log("Grayscale filter applied.");
  }, { priority: 'user-visible' });

  await scheduler.postTask(async () => {
    console.log("Resizing image: User-Visible task");
    const resizedCanvas = document.createElement('canvas');
    const resizedCtx = resizedCanvas.getContext('2d');
    const targetWidth = 400; 
    const targetHeight = (image.height / image.width) * targetWidth;
    resizedCanvas.width = targetWidth;
    resizedCanvas.height = targetHeight;
    resizedCtx.drawImage(image, 0, 0, targetWidth, targetHeight);
    console.log("Image resized.");
    displayProcessedImage(resizedCanvas.toDataURL());
  }, { priority: 'user-visible' });
  hideProcessingIndicator();
}

3. Background Operations (Background Priority)

Perhaps after processing, we want to save a smaller version of the image to local storage, or perform other non-critical operations. These can be handled with background priority:

async function cacheImage(imageDataURL) {
  await scheduler.postTask(() => {
    console.log("Caching image to local storage: Background task");
    // Simulate caching
    // localStorage.setItem('processedImage', imageDataURL);
  }, { priority: 'background' });
}

Some Considerations:

Granularity of Tasks: The key is to break down large operations into small enough chunks to allow yield() to be effective. Experiment with the if (i % 10000 === 0) condition in the grayscale example to find the optimal balance for your specific tasks.
Avoiding Over-Yielding: While yielding is good, yielding too frequently can introduce its own overhead. Find the sweet spot where the UI remains responsive without degrading overall performance.

Summary

By strategically utilizing postTask() with different priorities and judiciously employing yield() within long-running computations, we can construct highly responsive web applications, even when dealing with demanding tasks like client-side image processing. The Scheduler API empowers us to create seamless UX, ensuring that our JavaScript applications are not just functional, but truly delightful to interact with.

Task Management in JavaScript

Gil Fink — Sat, 21 Jun 2025 09:25:08 +0000

Don’t block the main thread!

As front-end developers, we’re constantly producing UI tasks. From rendering complex UI components to processing user input, and from fetching data to running animations, our applications are a built of concurrent operations. Historically, managing these tasks to ensure a smooth and responsive user experience has been a delicate balancing act, often involving a patchwork of setTimeout, requestAnimationFrame, and Promises. But what if we could tell the browser exactly how important each task is? What if we could influence when and how they run, ensuring that user-critical operations always take precedence?

Enter the Scheduler API. This evolving but powerful Web API is poised to revolutionize how we approach task management in JavaScript, offering fine-grained control over the browser’s main thread and paving the way for significantly smoother user experience.

In this post, we’ll dive deep into the Scheduler API , understand its core concepts, and explore how to leverage its capabilities to truly master task management in your front-end applications.

The Challenge: Janky UIs and Unresponsive Apps

Before we jump into the solution, let’s briefly revisit the problem. Imagine a scenario where a user clicks a button that triggers a long-running JavaScript computation. Without proper task management, this computation can block the main thread, leading to:

Janky animations: Animations stutter or freeze
Delayed input responses: User interactions such as clicks or scrolls feel unresponsive
Frozen UI: The entire page appears to hang, frustrating the user

Traditional asynchronous patterns like setTimeout(..., 0) offer a way to break up long tasks, but they don't provide any guarantees about when the continuation of your task will run relative to other browser work . This is where the Scheduler API shines.

Introducing the Scheduler API: Your Browser’s Taskmaster

The Scheduler API , accessible via scheduler (or window.scheduler in the main thread and self.scheduler in Web Workers), provides two primary functions for managing tasks:

postTask(): For scheduling new tasks with specified priorities
yield(): For yielding control of the main thread back to the browser, with the ability to prioritize the continuation of the current task

Let’s break these functions down.

scheduler.postTask(): Prioritizing New Tasks

The postTask() function allows you to add a new task to the browser's task queue with an optional priority, delay, and an AbortSignal for cancellation.

Understanding Task Priorities

The API defines three priority levels, each serving a distinct purpose:

'user-blocking' (highest priority): For tasks that are critical for immediate user interaction. Think of operations that directly respond to a user's click or keypress, where any delay would be immediately noticeable and frustrating. Examples include updating UI based on user input, or processing critical data for a new screen.
'user-visible' (default priority): For tasks that are visible to the user but not immediately blocking. Examples include loading non-critical images, updating less important UI elements, or performing background data synchronization that doesn't impact immediate user flow.
'background' (lowest priority): For tasks that are not time-critical and can run when the browser is idle. Examples include analytics reporting, pre-fetching resources for future navigation, or processing data that isn't immediately displayed.

Basic Usage of postTask()

Let’s see it in action:

// Check for feature support in the browser
if (scheduler && scheduler.postTask) {
  scheduler.postTask(() => {
    console.log("User-blocking task executed!");
    // Perform critical UI updates or calculations
  }, { priority: 'user-blocking' });

  scheduler.postTask(() => {
    console.log("User-visible task executed!");
    // Load an image, update a sidebar widget
  });

  scheduler.postTask(() => {
    console.log("Background task executed!");
    // Send analytics data, pre-fetch content
  }, { priority: 'background' });

} else {
  console.warn("Scheduler API not supported. Falling back to traditional methods.");
  // Implement fallback using setTimeout or other techniques
}

This simple example illustrates how you can declare your intentions to the browser. The browser’s scheduler will then do its best to execute these tasks according to their priority, ensuring that higher-priority tasks are given preference.

scheduler.yield(): Keeping the UI Responsive During Long Operations

While postTask() is excellent for scheduling new tasks, what about long-running operations that must execute on the main thread and can't be easily broken into entirely separate tasks? This is where scheduler.yield() comes into play.

scheduler.yield() allows you to yield control of the main thread back to the browser. It returns a Promise that resolves when the browser determines it's a good time to resume the yielded task. The crucial advantage of scheduler.yield() over setTimeout(..., 0) is that the continuation of the yielded task is often prioritized over other pending tasks of similar priority. This means your long-running operation can be chunked, allowing the browser to process user input or render updates in between chunks, leading to a much more responsive UI.

Example: Breaking Up a Long Calculation

Consider a function that performs a computationally intensive loop:

async function processLargeDataset() {
  const data = Array.from({ length: 100000 }, (_, i) => i); // Simulate large dataset
  const results = [];
  for (let i = 0; i < data.length; i++) {
    // This is an intensive calculation
    let sum = 0;
    for (let j = 0; j < 1000; j++) {
      sum += Math.sqrt(data[i] * j);
    }
    results.push(sum);
    // Yield control to the browser periodically
    if (i % 1000 === 0) { // Yield every 1000 iterations
      await scheduler.yield();
      console.log(`Yielded at iteration ${i}`);
    }
  }
  console.log("Dataset processing complete!");
  return results;
}

document.getElementById('start-btn').addEventListener('click', async () => {
  console.log("Starting large dataset processing...");
  // Show a loading indicator immediately
  document.getElementById('status').textContent = "Processing...";
  const processedData = await processLargeDataset();
  console.log("Processed data:", processedData);
  document.getElementById('status').textContent = "Done!";
});

In this example, by strategically placing await scheduler.yield(), we allow the browser to interleave its own critical work (like rendering or handling user input) with our long-running calculation. The user will experience a much smoother application, even during heavy processing.

Good Practices and Considerations

Feature Detection: Always check for scheduler before using the API, as it's still relatively new. Provide fallbacks for older browsers. There is also a good polyfill for the API here.
Don’t Over-Yield: While scheduler.yield() is powerful, don't yield too frequently. Each yield incurs a small overhead. Find a balance that keeps your UI responsive without introducing unnecessary delays.
Appropriate Priority: Carefully consider the true priority of your tasks. Overusing user-blocking can negate the benefits of the API and lead to a less responsive overall application.
Offloading Heavy Computation: For truly massive computations that don’t need direct DOM access, Web Workers remain the go-to solution. The Scheduler API complements Web Workers by managing tasks on the main thread more effectively.
Error Handling: Remember that postTask() returns a Promise, so use .then().catch() or async/await with try...catch blocks to handle potential errors or task abortions.
Progressive Enhancement: Design your applications to work without the Scheduler API first, then enhance the experience if the API is available.

Summary

The Scheduler API is a significant step forward in giving developers more control over the browser’s scheduling mechanisms. By understanding and effectively utilizing postTask() and yield() we can build more responsive, fluid, and user-friendly web applications. As this API gains wider adoption, it will undoubtedly become a cornerstone of modern front-end performance optimization.

Further reading:

Quick Tip — Using Callback Refs in React

Gil Fink — Mon, 13 Nov 2023 09:24:09 +0000

Quick Tip — Using Callback Refs in React

The Post Code in Code Sandbox

One of the usages I see a lot with useEffect in React code is to run some JavaScript code on an element reference which is stored as ref as soon as this element is mounted. For example, when an element is mounted, animate it’s content using Web Animation API.

The following code is doing exactly that:

In the code above, you set the ref to the heading element and when the component is mounted, it’s animating the heading with some premade animation.

That is easy, so why should you bother reading this post at all?

Because there is a better alternative to do exactly the same thing but without useEffect and *useRef * hooks.

The ref attribute is expecting that you will set it with one of the following types:

RefCallback<T> | RefObject<T> | null

A RefCallback is just a function that accepts the element node and returns void. In a matter of fact, whenever you use RefObject , it’s just a syntactic sugar to set the reference on the element to the current accessor of the useRef created reference. The following code is what is going to happen when you set a ref like in the first code block in this post:

<h1
  ref={(node) => {
    ref.current = node;
  }}
/>

The RefCallback function is going to run after the component is mounted, re-rendered or unmounted.

Now, packed with this knowledge, how you can refactor the above code and stop using useEffect and useRef combination?

The following code will do exactly that:

Let’s try to understand what is going on. In the code, you use the useCallback function with an empty dependency array to wrap the callback ref function. This will make sure that React runtime will run this function only on mount and that is it. No need to use the useRef or useEffect hook and you achieve the same functionality. You gain two adeed bonueses when you use callback ref. The first one is that you don’t get double rendering in development mode like you will get when you use useEffect. The second bonus is that in the case of using forwardRef and conditional rendering, the callback ref code will stay stable and work while the useEffect code might not work as expected if the element isn’t rendered due to the conditional rendering.

If you want to look at the provided code and see how it works, you can play with the previous code in this sandbox:

https://medium.com/media/9c583e21c4c620c5e9138e5c7bb3d6be/href

For further reading about callback refs, you can look at React documentation: https://legacy.reactjs.org/docs/refs-and-the-dom.html#callback-refs

Integrating D3 in Qwik Apps

Gil Fink — Fri, 30 Jun 2023 17:11:41 +0000

In the past I wrote a bunch of posts that explained how to integrate D3 library and React. In this post I’ll do the same but this time I’ll show you how to integrate D3 in Qwik apps. We will build together a D3 tree and host it inside a basic Qwik app.

Are you ready?

Things to do before you start adding the suggested code:

Create a new Qwik app using the npm create qwik@latest .

Add a new route to your app, which will be used to show the D3 graph.

Creating a Qwik D3 Container Component

First you are going to add a new TreeContainer component. This component will be responsible to hold the D3 container, which will be used to create the graph.

Let’s look at the code:

The TreeContainer is going to be the div that D3 will use to create the graph. You use a signal to reference the rendered div , so you will be able to use it’s in-memory Html element representation later on.

Another thing that you can notice is the usage of useVisibileTask$. Since D3 runs only in the client, you should use the useVisibileTask$ hook that makes sure that the code which is responsible to creates the graph runs after the component’s client rendering.

Building the Graph Generator

Once the container is ready it’s time to write the createGraph function.

Here is the full function code:

Let’s analyze the code to understand what is going on. We will start in the beginning with the processSymbols function.

Sometimes we have a model that doesn’t fit into the way the D3 graphs expect their data. The processSymbols function will transform the symbols array to the needed graph representation.

At the start of the createGraph function you set the d3 tree in-memory implementation. This is happening in these lines of code:

Then, you create the tree visual representation using D3 API that creates SVG elements such as paths, circles, text and more:

The data that is being used in the example is the following symbols array:

After you wire everything you can run the app to see the following graph on your screen:

Symbol Graph

Summary

In the post I showed you how easy it is to integrate D3 in Qwik apps. The post guided you how to create the graph container and then how to create the graph by using D3 functionality.

You can take a look at the whole example in the qwik-d3-example repository.

Adding Authentication to a Qwik App

Gil Fink — Tue, 28 Feb 2023 12:41:45 +0000

Authentication is a basic feature that is implemented in most of the apps and websites. Today there are many ways to authenticate users and the most popular front-end library for authentication is probably auth.js.

But how can you use the library in your Qwik app?

This post will explain how to integrate qwik-auth package into your Qwik app.

Note: The qwik-auth package is still experimental and some of the shown code might change in the future.

Setting the qwik-auth Package

The first thing to do when you want to use qwik-auth is to install it. Since auth.js is a peer dependency, you will have to install it as well. Run the following command to install the libraries:

pnpm i "@builder.io/qwik-auth" "@auth/core"

Once the installation finishes, you will need to update the vite.config.js and include the @auth/core library to the optimizeDeps config:

import { defineConfig } from 'vite';
import { qwikVite } from '@builder.io/qwik/optimizer';
import { qwikCity } from '@builder.io/qwik-city/vite';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig(() => {
  return {
    optimizeDeps: {
      include: ['@auth/core'],
    },
    plugins: [qwikCity(), qwikVite(), tsconfigPaths()],
    preview: {
      headers: {
        'Cache-Control': 'public, max-age=600',
      },
    },
  };
});

Note: This is a workaround to a bug that is currently exists in qwik-auth which is SyntaxError: The requested module '/node_modules/.pnpm/cookie@0.5.0/node_modules/cookie/index.js?v=849ea94b' does not provide an export named 'parse'

Once you updated the vite.config.js you will have to add a secret string for your app. The place to put it is in the app .env file. In my demo app I called the variable VITE_AUTH_SECRET , but you can put any name that you like as long as you will use that name in the relevant place.

Generating the qwik-auth Actions and Loaders

Everything is set up and now you can go and use qwik-auth in your app. qwik-auth exposes a serverAuth$ generator function that will generate all the actions and loaders you need for login, logout or getting the current session. Once you give it a callback that returns a configuration object with all the authentication providers, it will generate the following:

useAuthSignin — action that can be used to run the login process
useAuthSignout — action that can be used to run the logout process
useAuthSession — loader to get the current session

You can use any of the authentication providers that auth.js exposes. The following code shows you how I used the credentials provider:

import type { Provider } from '@auth/core/providers';
import CredentialsProvider from '@auth/core/providers/credentials';
import { serverAuth$ } from '@builder.io/qwik-auth';
import { users } from '~/data/users';

export const { useAuthSignin, useAuthSignout, useAuthSession, onRequest } = serverAuth$(
  () => {
    return ({
      secret: import.meta.env.VITE_AUTH_SECRET,
      trustHost: true,
      providers: [
        CredentialsProvider({
          name: 'Login',
          authorize: (credentials) => {
            if (credentials) {
              const user = users.get(credentials.username as string);
              if (user) {
                if (user.password === credentials.password) {
                  return { id: user.username, name: user.username, email: `${@gmail.com">user.username}@gmail.com`};
                }
              }
            }
            return null;
          },
          credentials: {
            username: { label: 'Username', type: 'text' },
            password: { label: 'Password', type: 'password' },
          },
        }),
      ] as Provider[],
    })});

In the credentials provider, I plug into the authorize function and check the existence of a user inside an in-memory map object. In real-world, you will check that against a database but I wanted a simplified example.

Pay attention that the place to put the code I showed is inside the app _routes _ folder.

Using The Generated qwik-auth Actions and Loaders

Once you generated the qwik-auth actions and loaders instances, you can use them in your app. To run the login process, you will first have to run the useAuthSignin action:

const loginAction = useAuthSignin();

Then you can wire it to a trigger button inside a *Form * element:

<Form action={loginAction}>
  <div class="container">
    <input
      type="hidden"
      name="provider"
      value="credentials"
    />
    <div class="login">
      <button>Login</button>
    </div>
  </div>
</Form>

Pay attention to the hidden input with the provider name. This input holds the requested provider and you need to put it inside the form.

To run the logout process you will do the same as with the login but this time with the useAuthSignout action. If you want to use the current session you will use the useAuthSession loader and in it’s value property you will find the current user.

In my example, I used the session in the main layout and passed a loggedIn Boolean to the header component, which is later used to show/hide the logout button:

export default component$(() => {
  const serverTime = useServerTimeLoader();
  const userSignal = useAuthSession();

  return (
    <>
      <main>
        <Header loggedIn={userSignal.value?.user !== undefined} />
        <section>
          <Slot />
        </section>
      </main>
      <footer>
        <a href="https://www.builder.io/" target="_blank">
          Made with ♡ by Builder.io
          <div>{serverTime.value.date}</div>
        </a>
      </footer>
    </>
  );
});

If you want to look at the full example, you can find it online.

Summary

In the post I showed how you can install and then use the qwik-auth package. This package is part of Qwik and is currently experimenatal. There is no documentation for the package yet, so I hope that this post will help you get started with it if you want to use it today.

Using a QwikCity Loader to Load Database Data

Gil Fink — Sat, 18 Feb 2023 10:05:56 +0000

Yesterday I wrote a post called “Using QwikCity Loaders to Load Data” that shorty explains how to load data using the new QwikCity loader’s API. When I wrote the post I used an in-memory array and just returned it as the example data. One of the questions I got was how to do the same, but this time by working against a database.

In this post I’m going to show you exactly that 😉

Enter Prisma

In this post I’m going to use Prisma, which is a popular Node.js Object Relation Mapper (ORM), and work against a MySQL products database.

The Products Database Table

This post isn’t going to explain the concepts of ORM but to summarize it in one line — ORMs bridge the gap between in-memory app objects and relational databases.

Let’s drill down and see how to do use Prisma.

Setting up Prisma Inside a QwikCity App

When you want to start using Prisma, you will have to add it to the QwikCity app. First thing, install Prisma CLI using your command line:

pnpm install prisma --save-dev

Then, run the prisma initialization command:

npx prisma init

This command is going to do 2 things:

Create a folder named prisma with a schema.prisma file. You are going to use this file to configure the schema and database connection.
If a .env file doesn’t exists, it will create it. You use this file to add environment variables to your project.

Go to the generated .env file and replace the DATABASE_URL variable with your database connection. Now you are ready to run Prisma introspection script to investigate and create a schema out of your existing database. Use the following command to do exactly that:

npx prisma db pull

If you have the same table like I do, the schema.prisma file will be updated and might look like:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "mysql"
  url = env("DATABASE_URL")
}

model products {
  id Int @id
  name String? @db.VarChar(80)
  description String? @db.VarChar(300)
}

Last thing to do is to install the @prisma/client package, which will help you run queries against the database. Use the following command to install it:

pnpm install @prisma/client

Once the client is installed run the following command to generate all the client code from the previous schema.prisma file:

npx prisma generate

Now we can move on and update the loader I used in my previous post.

Use a QwikCity Loader with Prisma

Prisma is set up in the app and now you can use Prisma client to retrieve data from the database or change your data. How can you do that? First create a new service file to hold all the Prisma code:

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient();

export async function getProducts() {
    return await prisma.products.findMany();
}

You can see that I created the PrismaClient instance and then use it to query the products table in the getProducts function. Now you can use this new function inside QwikCity loader. Here is the new loader code:

export const useProductsLoader = loader$(async () => {
  return await getProducts();
});

Pay attention to the async/await usage here. Working with databases is being done asynchronously and we need to await to the query to return the data and to Prisma to create the objects our of it.

When you will run the app it should look exactly like in the previous post, but this time you work with a real database underneath.

The Working App

Summary

QwikCity, like any other meta framework, can work with databases. In this post I showed you how to wire Prisma into QwikCity and then use the new QwikCity data loader API to load data from database to your components.

I hope you will find this post helpful 😃

Using QwikCity Loaders to Load Data

Gil Fink — Fri, 17 Feb 2023 14:47:33 +0000

One of the new features that QwikCity include is the new loaders features. What is a QwikCity loader? How can you use it?

In this post you will get the answers to these questions.

What is a QwikCity Loader?

A loader is a new feature that was added to QwikCity lately. A loader purpose is enable Qwik components to load data from the server in a seamless way. You don’t need to write fetch code or use the XmlHttpRequest object or even expose an endpoint for some piece of data. Just write a loader with the loader syntax and then you can use it as part of your component. QwikCity will do the heavy lifting of fetching the data on the server and have it ready for the component usage.

Sounds great, so how can I create a loader?

Creating a QwikCity Loader

Creating a loader is as simple as to use the loader$ higher order function. The loader$ function receives a callback function that is going to be used in the server to load the data. The callback function’s returned value will be added to the consuming Qwik component and you will be able to use it when the component is mounted.

Loader Creation Example

Let’s say we have a simple productsDB file with the following code:

export interface Product {
  id: number;
  name: string;
  description: string;
}

export const products: Product[] = [
  {
    id: 1,
    name: "Wood Table",
    description: "A wood table",
  },
  {
    id: 2,
    name: "Plastic Table",
    description: "A plastic table",
  },
];

If I want to create a loader that will fetch all the products data, it might look like:

import { products } from "~/data/productsDB";

export const useProductsLoader = loader$(() => {
  return products;
});

Pay attention to the usage of the use* convention in the loader name.

Now that you have the loader’s code, how can you consume it from a Qwik component?

This is straight forward. Just run the loader function in the component code and use the returned value.

Loader Usage Example

export default component$(() => {
  const products = useProductsLoader();

  return (
    <div>
      <ul>
        {products.value.map((product) => {
          return (
            <li>
              <div>{product.name}</div>
              <div>{product.description}</div>
            </li>
          );
        })}
      </ul>
    </div>
  );
});

As you can see, I use the previous loader as a function. Then, in the rendering code I use the products.value to get a hold of the products data and render them.

The code I showed is simple but what else can you do with a loader?

Use the loader context.

The Loader Context

Loaders run in a context of a QwikCity RequestEvent. That means you can have the request context as an argument of the callback function. What can you do with this context?

You can investigate the request headers, url, cookies, params and more. All this content can help you to do decisions about which data to send back and in which conditions.

Let’s look at a simple usage example:

export const useProductsLoader = loader$(({ url, method }) => {
  if (method === 'GET') {
    return { url, products };
  }
  return { url, products: [] };
});

The previous loader was refactored to return the url with the products if the request was a HttpGet else to return the url with an empty array. I know it’s something that you probably won’t do in real world scenario, but for now it’s just showing you how to use the context. In real world, you might examine the cookies to see if a user is authenticated, check the params for existence of some specific parameter such as an id and etc.

The consuming component will need to change as well:

export default component$(() => {
  const products = useProductsLoader();

  return (
    <div>
      <div>{products.value.url.href}</div>
      <ul>
        {products.value.products.map((product) => {
          return (
            <li>
              <div>{product.name}</div>
              <div>{product.description}</div>
            </li>
          );
        })}
      </ul>
    </div>
  );
});

As you can see, the change is how I consume the returned value of the url and the products.

Conclusion

Qwik and QwikCity are evolving and adding new features, which are very useful for developer experience with the frameworks. One of these new features is the data loader. In this post I covered what is a data loader and how to use it.

If you have any questions about the subject, write them in the comments section.

Writing Your First Qwik Component

Gil Fink — Sun, 16 Oct 2022 14:14:44 +0000

In the last few weeks I’m deep diving into Qwik framework in preparation to a session I’ll deliver about it in TechRadarCon 2022. I also implemented a full demo app with Qwik and QwikCity to get the feeling about the developer experience with the framework.

In this post I’m going to show you how you can develop a simple Qwik component and expose you to some things you need to know while developing your components.

Qwik Playground

Qwik Playground

One of the nice features that is part of Qwik website is the Qwik Playground. In the playground you can write components using Qwik syntax and in the right pane you can get info about the component’s rendering, errors, symbols and can even configure how things are rendered using the Options tab at the bottom.

You can use the playground as the environment to build the component I’ll implement in the post or you can create a new project using Qwik CLI and add the component there.

Building the Component

In this post we are going to build a simple collapsible panel component. The component will have a clickable header, which will collapse it’s content. The content will be injected from the outside.

So, let’s do it :)

The following code is the complete example, which will be broken to explanations later on:

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

export const App = component$(() => {
  return (
    <CollapsiblePanel title="Click me!">
      <ul>
        <li>Qwik is awsome</li>
        <li>Collapsible item</li>
      </ul>
    </CollapsiblePanel>
  );
});

interface IProps {
  title: string;
}

export const CollapsiblePanel = component$(({ title }: IProps) => {
  useStylesScoped$(`
    .collapsible {
      border: black dashed 1px;
    }

header {
      background: blue;
      color: white;
      cursor: pointer;
      padding: 2px;
    }
  `);

const store = useStore({
    collapsed: false
  });

const toggle = $(async () => {
    store.collapsed = !store.collapsed;
  });

return (
    <div className="collapsible">
        <header onClick$={toggle}>
          {title}
        </header>
        <section hidden={store.collapsed}>
          <Slot />
        </section>
      </div>
  );
});

Let’s Break it Down

Qwik embraces TypeScript, so at first we will create an interface for the props that the component will receive. Here is the interface implementation:

interface IProps {
  title: string;
}

Now that we have the interface, let’s use it and let’s declare the component using Qwik syntax:

export const CollapsiblePanel = component$(({ title }: IProps) => {
   ...
});

As you can see you use the component$ function to create a Qwik component. The $ sign is there to direct Qwik optimizer to treat this function in a specific way (in this case, as a Qwik component).

Note: I’m not going to discuss the optimizer and I encourage you to read about it here.

Now that we declared the component let’s implement it. Qwik uses JSX to write how you will render your component. At the end of the component we will return the following JSX:

return (
    <div className="collapsible">
        <header onClick$={toggle}>
          {title}
        </header>
        <section hidden={store.collapsed}>
          <Slot/>
        </section>
     </div>
);

As can be seen, we return a div with some implementation. I marked 3 important things in the code which you should be aware of. The onClick$ is the way we wire events in Qwik with the $ sign at the end. Again, the $ sign is there for the Qwik optimizer. The Slot component is a special Qwik component that enables content injection into our component. We will discuss the store later on.

Now let’s add some style. If you want to create a style barrier between your component and the outside you can use the useStylesScoped$ hook. The useStylesScoped$ hook receives the style you want to encapsulate inside your component and impose it on the component.

useStylesScoped$(`
    .collapsible {
      border: black dashed 1px;
    }

    header {
      background: blue;
      color: white;
      cursor: pointer;
      padding: 2px;
    }
`);

In the example above we add style to the container div and to the header element. When rendered, Qwik will make sure that the style will be specific only to the component and therefore the style won’t leak from it.

In order to have an inner component state, which can be serialized by Qwik you will need to use the useStore hook. The hook creates a store that it’s content can be tracked by Qwik and also can be serialized. In the collapsible panel example the store is storing the collapsed state of the component:

const store = useStore({
    collapsed: false
});

Last but not least, we implement the toggle function which will be used to toggle the content:

const toggle = $(async () => {
    store.collapsed = !store.collapsed;
});

Since the toggle function isn’t inline in the component’s JSX, you need to use the $(async () => { … }) syntax to make sure that Qwik optimizer will understand that this is going to be Qwik component function that is being used in the JSX.

That is it. You now can play with the component.

The following code is a consuming component that runs our component:

export const App = component$(() => {
  return (
    <CollapsiblePanel title="Click me!">
      <ul>
        <li>Qwik is awsome</li>
        <li>Collapsible item</li>
      </ul>
    </CollapsiblePanel>
  );
});

The Collapsible Panel Component in Qwik Playground

Summary

In the post we implemented a Qwik collapsible panel component. This is a simple component but it shows some of the concepts you will need to be familiar with if you are writing Qwik components.

As always, if you have any feedback, let me know.

First Impression with Qwik

Gil Fink — Sat, 15 Oct 2022 12:43:06 +0000

TheAgency app

A few days ago I published a small demo app called “TheAgency” which I fully developed with Qwik and QwikCity. In this post I’ll explain why I did it and how it might help you if you want to get familiar with Qwik and QwikCity.

Qwik? QwikCity?

There is a lot of buzz around Qwik lately. Qwik is a new front-end framework which is being developed by builder.io. In the Qwik framework team you can find known web framework developers/architects such as Miško Hevery (AngularJS/Angular), Adam Bradley (Ionic/Stencil) and Manu Mtz.-Almeida (Ionic/Stencil). Qwik is trying to solve some major problems that we have in current modern web development frameworks. In a nutshell the main drive behind Qwik is to make your website/web app faster by changing a few mental models (the need for hydration for exmaple) and introducing the concept of resumability.

Note: This is not going to be an “hello world” post about Qwik. I think that Qwik documentation is doing a good job for introducing the framework.

QwikCity is a meta framework that is built on top of Qwik and introducing a whole website/web app solution that includes routing and backend as well. With QwikCity you are able to create not only the front-end but a whole site/app.

Note: This is also not going to be an “hello world” post about QwikCity. I think that QwikCity documentation is doing a good job for introducing the meta framework.

How did I heard about Qwik?

I first learned about Qwik in Twitter a few months ago (I’m following Miško Hevery), but I didn’t have the time to look at it or to implement something with it. Then, Miško Hevery visited Israel a couple of months ago and conducted a Qwik workshop with Shai Reznik. I managed to attend the workshop and was really impressed with the ideas behind Qwik. I also had the opportunity to learn about it from one of it’s creators. I remember that when the workshop ended I was eager to build something with Qwik, but… Life…

I had no opportunity to do that because all my customers work with React and I had limited spare time.

Why to Build “TheAgency”?

Three weeks ago one of my customers, a startup, had to close the company :( and I had some spare time to waste before I’ll have a new customer. So, I decided that I want to build something with Qwik and QwikCity and to have the feeling about how you can build a more realistic real world app and not some small demo app such as a todo list.

This is where I had the idea to take the app I built when I wrote my “Pro Single Page Application Development” book and migrate it entirely to Qwik and QwikCity. The “TheAgency” app was created in 2014 with Backbone.js and ASP.NET.

Migrating an app that was built in an old library such as Backbone.js wasn’t so easy. At first I created all the views with their HTML and CSS and then I wired everything inside QwikCity including routing. I had to learn how to use Qwik and let it do it’s magic during the process. There were a few qwirks that I had to overcome. Mostly, things that aren’t documented or don’t work as expected (for example how to wire the Web API in QwikCity or serialization/deserialization of objects when you pass content to the server). All in all it took me a couple of hours but I managed to do the migration.

One thing that I must emphasize — because I learned everything by implementation, I might not write an optimized app version in terms of how I implemented it. If you are using my example app as a reference, I’ll be happy to learn if you can do things better than I did.

Conclusion

The main question you probably ask yourself is whether I’ll use Qwik after I had the experience with it?

Of course. Even though there are things to improve in the framework I find it very interesting and revolutionary in it’s mental model. I also think that the framework is heading in a right direction.

My hope is that the app I created will help others to understand how to create modern apps with Qwik and QwikCity.

Feedback is always welcome!

Quick Tip — Storybook Play Function

Gil Fink — Sun, 11 Sep 2022 09:14:16 +0000

Quick Tip — Storybook Play Function

Storybook is a go to tool that a lot of developers are using as a lab environment to the components they are creating. Storybook renders the components and then enable to interact with them, change their props and see the outcome of the changes.

But sometime you might want to simulate user interactions or use some exposed component API after the component was rendered. How can you do that?

In this short post you will get familiar with Storybook play function, which enables you to hook operations after the component was rendered.

The Play Function

Storybook stories can help developers to test their components in a lab environment. When you want to simulate interaction with your component or use a function which was exposed from you component, you will want to hook the play function to your template instance.

The play function is a hook that enables you to interact with the component after it was rendered. Before you can use it, you need to make sure that Storybook’s addon-interactions is installed. Another package that you might want to install is @storybook/testing-library , which can help you to work with Storybook exposed DOM. If the packages aren’t installed, run the following command in your command line in the root folder of your project:

npm install — save-dev @storybook/addon-interactions @storybook/testing-library

Once the packages are installed, you should make sure that the addon-interactions addon is added to the list of addons in the .storybook/main.js file:

module.exports = {
  stories:[],
  addons:[
    '@storybook/addon-interactions'
  ]
};

Now that everything is in place let’s see how you can use the play function inside a stories file.

Play Function in Action

The play function is added to the instance of a Storybook template like adding stories args :

import { screen } from '@storybook/testing-library';

... // some story definitions

export const Default = Template.bind({});
Default.play = async () => {
  screen.getByTestId("someElementTestId").show('hello storybook');
}

A few things to notice in this small example:

Play can have asynchronous interactions and therefore I use the async keyword. In this example there are no awaits but there could be (for example awaiting to simulated user interactions).
I use the screen object from the @storybook/testing-library to grab an element by it’s test id. You should make sure the element indeed has a test id like the one that was used otherwise you will get an error.
Once I have the element after it was queried from the DOM, I can interact with it. In this example I call an exposed API function called show.

This example is very easy and you can definitely do some sophisticated things such as running user events (click, typing and etc.) using the testing library API, compose more than one story and more.

Summary

In the post you learned about the play function in Storybook. The play function is a very handy hook that enables you to “play” user interactions or component exposed API functions after the component was rendered in Storybook preview section.

If you have any questions, feel free to write them in the comments section.

Creating a Force Graph using React, D3 and PixiJS

Gil Fink — Sun, 07 Mar 2021 08:42:28 +0000

A few months ago I published a post about how to create a force graph using React and D3. But what if the force graph data source is enormous? Would you still use D3 or are there any other solutions out there?

In this post I’ll explain how you can combine both D3 and PixiJS to create almost the same force graph but in a different way which will enable you to support bigger data sources.

In the app we created we faced a very painful performance problem. While D3 helped us to create the relevant force graph we needed to show on screen, the data source we were using became very large. When using D3, the graph representation underneath is created using SVG and that means that when the data source becomes larger the amount of SVG elements increase. The more SVG elements you have on screen the less performant the app becomes.

So, how can we solve the problem? What if we could transfer D3 SVG representation into canvas representation. Would that help?

In our app it helped.

Enter PixiJS

PixiJS is a flexible 2D WebGL renderer library which is working on top of HTML5 canvas element.

Note - I won’t get into PixiJS fundamentals in this post and I encourage you to go to it’s website for further reading.

In a whole what I did was to use the D3 force graph simulation on one hand to keep the force graph simulation and I let PixiJS handle all the rendering on top of the canvas element.

Creating the Example App

I’m going to refactor a little bit the app I created in the “Creating a Force Graph using React and D3” post. That means that if you haven’t read it go ahead and do that before you continue reading this post.

First you will need to install PixiJS library. In command line run the following code to install both PixiJS and PixiJS Viewport, which will help us to support things like zoom in and out:

npm i pixi.js pixi-viewport

After the libraries are installed we are ready to proceed.

I’ll use the same ForceGraph component container I created in the previous post, but this time I’ll use the runForceGraphPixi function instead of runForceGraph. runForceGraphPixi will be responsible to create and run the new force graph.

Building the Force Graph Generator

The force graph generator will be a function that will be responsible to generate the graph. Here is the declaration of the function which gets the containing div, the data for links and nodes and a function to generate a node tooltip:

You can see that I import both D3 and PixiJS and I use the same signature that I used in runForceGraph from the previous post. Now let’s implement the function.

The first lines of code will be to copy the data and to get the container’s width and height :

I also add a variable I’ll use later to control the nodes drag and drop and clean the container from it’s previously generated HTML content.

Then, let’s add a few helper functions:

The helper functions will help us to add the tooltip, to support the coloring of the nodes and also to create the drag and drop functionality.

Now we add the code that will create the nodes and their links and will simulate the force graph:

Pay attention that I add both a Pixi.Applicaiton and also d3.forceSimulation. The PixiJS application will be responsible for the graph rendering according to the force simulation that D3 exposes.

When the graph is ready we will add a few event handlers to handle what is going to happen when the tick is happening :

In the tick event we clean all the links and then redraw them on the canvas again.

Last but not least, we will return the destroy function that the graph container is going to use when it’s going to unmount the graph:

The whole function source code:

Now that everything is set in place you can run the app and look at your fancy force graph.

The Generated Force Graph

Summary

In the post, I showed you how to create a force graph component using React, D3 and PixiJS libraries. You can find the graph code here.