DEV Community: groundhog

ChatGPT Actions, Not Just Chat

groundhog — Tue, 21 Oct 2025 19:56:42 +0000

React Component GPT:

We need a GPT that understands our React components, knows our CSS variables, and can spit out code that's ready to use. This isn't about general knowledge; it's about our knowledge. The standard GPT knowledge upload is fine for broad docs, but for precise component generation, we need control. That's where Actions come in.

The Problem: Disconnected Knowledge

Our design system lives in zeroheight. Our CSS variables are in a .css file. Our React components are in .jsx files. These are all discrete sources of truth. A generic LLM has no idea how they connect. If someone asks for a "primary button," it might give generic HTML, not our Button component with --color-brand-primary. Unacceptable.

The Solution: Custom Actions to Bridge the Gap

We build an API. This API becomes our "knowledge retrieval service." The GPT uses Actions to call this API when it needs specific, localized data.

Extract Data (The ETL of our Design System):
- zeroheight Content: Use the zeroheight API to pull down all component documentation. Store it, parse it, clean it. We're interested in usage guidelines, props, and design rationale.
- CSS Variables/Tokens: This is crucial. Scrape our actual CSS files or token JSON. We need the variable names (--color-brand-primary), their semantic meaning (e.g., "primary brand color"), and their default values. This data needs to be structured.
- React Component Signatures: Optionally, parse our actual React component files to extract prop types and default values. This helps the GPT understand the component's API.
GPT's Role (The Orchestrator):
- The GPT's prompt is vital. We instruct it: "You are an expert React developer. When asked to create or style a component, use the get_component_info action to retrieve specific details from our design system. Only use the CSS variables and component props returned by the action. Do not hallucinate."
- When a user asks, "Generate a primary button component with a large size," the GPT identifies Button, primary, and large. It then calls our API Action: get_component_info(component_name='Button', style_attributes=['primary', 'large']).
- Our API returns the relevant zeroheight content, the --color-brand-primary variable, and maybe padding: var(--spacing-large).
- The GPT uses that specific information to generate the React component code, importing the correct component, applying the className or style with the correct CSS variables.

Why This Works

This approach isn't about chat; it's about programmatic access to our design system's knowledge.

Accuracy: We control the retrieval. The GPT can't invent variables or component usage patterns.
Maintainability: Our API can be updated independently of the GPT. If a variable name changes, we update our extraction and vector store, not the GPT's brain.

This is how we leverage LLMs for actual developer productivity, turning a design system into a code-generating assistant.

How I Built a GPT Action System to Ship Components 10x Faster

groundhog — Tue, 21 Oct 2025 17:39:56 +0000

Supercharging Our Frontend:

For the last year, our frontend velocity has been bottlenecked by the same thing that slows down most teams: component setup boilerplate and style guide enforcement. I decided to tackle this head-on by building something that felt a bit like science fiction but will now be core to our daily workflow: a Custom GPT enhanced with targeted Actions.

This system doesn't just write code... it orchestrates an entire component lifecycle, from reading design tokens straight from our source of truth to opening a ready-to-review Pull Request.

The Headache We Solved: Boilerplate and Drift

Every developer knows the drill. You need a new Card component. You open your editor, create four files (Card.jsx, Card.module.css, Card.stories.jsx, index.js), manually hunt down the correct spacing variable (--space-2x vs. --space-lg), and then spend time manually setting up the Storybook story.

The problems were twofold:

Time Sink: Pure setup time was stealing hours from actual problem-solving.
Style Drift: Despite having a great design system, manual application meant developers sometimes missed a token or used a deprecated one, leading to visual inconsistencies down the line.

My goal was to automate the scaffolding and adherence so developers could focus on the logic and UX.

The Architecture: GPT + Actions as an Orchestrator

The key wasn't just training the GPT on React; it was giving it reliable tools to interact with our environment. This is where Actions come in. Think of the GPT as the brain and the Actions as its hands, capable of interacting with the external world.

Here’s the step-by-step process for generating a new component:

1. The Design Token Hook (Action 1: The Source of Truth)

The first thing the GPT needs is the official styling language.

I configured an Action that uses a simple curl or fetch command to grab the content of our CSS variable file hosted on a GitHub raw link (e.g., https://raw.githubusercontent.com/org/design-tokens/main/tokens.css).

The GPT then parses this raw CSS, effectively building an internal, temporary map of all available tokens (--color-brand-primary, --spacing-4x, etc.). This ensures zero deviation from the established style guide—it literally cannot use a variable that doesn't exist in the raw file.

2. Component Assembly Line (GPT Logic)

With the token map accessible, the developer simply prompts: "Build a large, primary-colored alert banner component that can display an icon and dismiss itself."

The GPT then simultaneously generates three crucial files, referencing the tokens it just fetched:

React Component (AlertBanner.jsx): Generates the functional component structure, props, and conditionally applies the appropriate CSS classes based on size/variant.
Scoped Styles (AlertBanner.module.css): This is crucial. The GPT maps the abstract request ("primary-colored") to the concrete token (background-color: var(--color-brand-primary);). This encapsulation is the foundation of style consistency.
Storybook Story (AlertBanner.stories.jsx): It automatically creates the boilerplate, sets up the control panel (Args) based on the component's props, and seeds it with a basic "Default" story.

3. Instant Validation (Action 2: The Live Preview)

Before any code touches the repo, rapid feedback is essential. I built an Action that takes the generated component, CSS, and story code and automatically packages it into a standardized CodePen or a similar sandboxed environment.

This provides an immediate, interactive preview that the developer can share with the designer or product manager for quick sign-off, eliminating back-and-forth emails about local setup or screenshots.

4. Closing the Loop (Action 3: The PR Automation)

Once the developer is happy, the final hurdle is the administrative work of contributing the code.

A final command, "Finalize and create PR", triggers the last Action. This Action:

Pushes the new files to a newly created, temporary feature branch.
Commits the changes with a clear message derived from the initial prompt.
Opens a Pull Request against our main branch, pre-filling the description with a summary of what was generated and linking to the CodePen preview.

The Impact: Faster Iterations, Unified Teams

This system isn't just a cool toy, it's a productivity multiplier.

We've seen the time to "Component Ready for Review" drop from an average of 45 minutes to under 5 minutes for standard components. This has had massive ripple effects:

Faster Feature Velocity: When scaffolding is trivial, the entire feature development process speeds up. We can move from concept to deployed feature in significantly tighter iteration cycles.
Design System Health: Because the GPT is hard-wired to read the live token file, style drift is virtually eliminated. Our codebase is cleaner, and the design system remains the single, untouchable source of truth.
Developer Joy: My team members are genuinely happier. They spend their time on complex rendering logic, performance tuning, or tricky state management—the parts of software development that actually require human ingenuity—instead of remembering that the padding variable is --spacing-4x and not --spacing-large.

If you're drowning in boilerplate and fighting to keep your design system clean, I strongly suggest looking into how a GPT paired with robust, context-aware Actions can turn your most tedious frontend tasks into automated workflows.

Filtering Duplicates by ID (and Keeping the Rest!) in JavaScript

groundhog — Tue, 21 Oct 2025 02:03:50 +0000

Smarter Data Handling:

Working with data arrays in JavaScript, especially when fetched from APIs or user input, often means dealing with imperfections like duplicate entries or missing information. A common challenge is ensuring uniqueness based on a specific property, like an id. But what if some items legitimately don't have an id, and you still want to include them in your final list?

This post dives into a robust JavaScript technique to filter out objects with duplicate IDs, while explicitly preserving any objects that don't have an id property (or whose id is null or undefined).

The Duplicate ID Dilemma

Imagine you have an array of data like this:

const rawData = [
  { id: 1, name: 'Product A' },
  { name: 'Uncategorized Item 1' }, // No ID!
  { id: 2, name: 'Product B' },
  { id: 1, name: 'Product A - Updated' }, // Duplicate ID!
  { id: null, name: 'Null ID Item' },     // ID is null!
  { id: 3, name: 'Product C' },
  { name: 'Uncategorized Item 2' }, // Another item without an ID
];

Our goal is to get a clean array where:

Each id (if present) appears only once.
Any item without an id (or with null/undefined as an id) is always included, regardless of other items.

This requires a slightly more nuanced approach than a simple duplicate filter.

The `filter()` + `Set` Strategy (with a Twist)

The most effective way to solve this is by combining Array.prototype.filter() with a Set object. The Set is perfect for efficiently tracking unique values (our IDs) because checking if a value has() been added to a Set is very fast.

The "twist" comes in how we handle objects that lack an id.

Let's break down the JavaScript implementation:

function getUniqueItemsPreservingNoId(arr) {
  // We use a Set to keep track of IDs we've already encountered.
  const seenIds = new Set();

  return arr.filter(item => {
    const id = item.id; // Get the ID for the current item

    // --- IMPORTANT: Handle items without a valid ID first ---
    // If 'id' is falsy (undefined, null, 0, etc.), we immediately return true.
    // This ensures such items are ALWAYS included in the filtered array.
    if (!id) {
      return true; 
    }

    // --- For items WITH a valid ID, check for duplicates ---
    // Check if we've already seen this specific ID.
    const isDuplicate = seenIds.has(id);

    // If it's the first time we're seeing this ID, add it to our Set.
    if (!isDuplicate) {
      seenIds.add(id);
    }

    // Return true only if it's NOT a duplicate (i.e., it's the first instance of this ID).
    return !isDuplicate;
  });
}

const uniqueAndPreserved = getUniqueItemsPreservingNoId(rawData);

console.log(uniqueAndPreserved);

What the Result Looks Like

Running the getUniqueItemsPreservingNoId function on our rawData will yield:

[
  { id: 1, name: 'Product A' },
  { name: 'Uncategorized Item 1' }, 
  { id: 2, name: 'Product B' },
  { id: null, name: 'Null ID Item' },     
  { id: 3, name: 'Product C' },
  { name: 'Uncategorized Item 2' }
]

Notice how Product A - Updated (which had a duplicate id: 1) was filtered out, but Uncategorized Item 1, Null ID Item, and Uncategorized Item 2 (all lacking a standard id) were kept.

How It Works: The Breakdown

seenIds = new Set(): We initialize an empty Set. This will store all the unique id values we encounter.
arr.filter(item => { ... }): The filter method iterates over each item in our rawData array. If the callback function returns true, the item is kept; if false, it's discarded.
if (!id) { return true; }: This is the critical line.
- It checks if item.id is a "falsy" value (i.e., undefined, null, 0, '', false).
- If id is undefined or null (meaning no valid ID exists), we immediately return true. This tells filter to keep this item without any further duplicate checks.
seenIds.has(id): For items that do have a valid id, we check if our seenIds Set already contains this id.
seenIds.add(id): If the id hasn't been seen before (isDuplicate is false), we add it to our Set.
return !isDuplicate;: Finally, for items with an id, we return true only if it's not a duplicate (i.e., it's the first time we've encountered this specific ID).

Connecting the dots...

This filter() and Set combination provides a clean, efficient, and readable way to handle a common data manipulation task. By adding the initial check for !id, you gain the flexibility to enforce uniqueness where it matters (for items with IDs) while gracefully preserving all other data points. Master this pattern, and your data processing logic will be much more robust!

Finding and Updating Items in React Arrays

groundhog — Tue, 21 Oct 2025 01:08:38 +0000

State Updates

Managing arrays in React state is a fundamental skill, especially when dealing with dynamic data like a list of users, products, or, in this case, selected items. While array methods like map are great for updating every item, what happens when you only need to change one specific entry based on an ID or name? That's where the JavaScript method findIndex() shines, particularly when paired with the immutability principles of React state updates.

This post will walk you through using findIndex() to locate an item's index and then safely update that item in a TypeScript React application.

Why `findIndex()` Over `find()`?

When you need to modify an item in a React state array, you can't just change the item directly. React demands immutability: you must create a new array with the updated item.

Array.prototype.find(): Returns the actual element (a copy of the object reference). You can modify this copy, but you still need its index to tell React where to replace it in the original array structure.
Array.prototype.findIndex(): Returns the index (a number) of the first element that satisfies the testing function. This index is exactly what you need to slice, spread, and reconstruct the array immutably.

The syntax for findIndex is simple:

const index = array.findIndex(item => item.id === targetId);

Practical Example: Managing Selections in TypeScript

Let's imagine we have a list of tasks, and we want to toggle the isSelected status for a specific task when a user clicks on it.

1. Define the State Interface

First, in our TypeScript component, we define the structure for our state items.

// interfaces.ts or at the top of your component file
interface Task {
  id: number;
  name: string;
  isSelected: boolean;
}

2. Initializing State and the Update Function

We'll set up our component with an initial list of tasks and the function that handles the toggle.

import React, { useState, useCallback } from 'react';

// ... (Task interface defined above)

const TaskListManager: React.FC = () => {
  const [tasks, setTasks] = useState<Task[]>([
    { id: 101, name: 'Write blog post', isSelected: false },
    { id: 102, name: 'Review PRs', isSelected: false },
    { id: 103, name: 'Deploy feature branch', isSelected: false },
  ]);

  // Function to toggle selection status
  const handleToggleSelection = useCallback((taskIdToToggle: number) => {
    // --- Step A: Find the Index ---
    const index = tasks.findIndex(task => task.id === taskIdToToggle);

    // Check if the item was found (findIndex returns -1 if not found)
    if (index === -1) {
      console.warn(`Task with ID ${taskIdToToggle} not found.`);
      return;
    }

    // --- Step B: Create the New Item (Immutable Update) ---
    const updatedTask: Task = {
      ...tasks[index], // Copy existing properties
      isSelected: !tasks[index].isSelected, // Toggle the value
    };

    // --- Step C: Create the New Array (Immutable State Update) ---
    setTasks(prevTasks => [
      // 1. Items before the target index
      ...prevTasks.slice(0, index),

      // 2. The newly updated item
      updatedTask,

      // 3. Items after the target index
      ...prevTasks.slice(index + 1),
    ]);
  }, [tasks]); // Dependency on 'tasks' array

  // ... (Rendering logic follows)
};

Breaking Down the Update Logic

The core of the solution lies in Steps B and C:

Find the Index: const index = tasks.findIndex(...) efficiently locates the position of the target task.
Create the New Item: We use the spread syntax (...tasks[index]) to create a shallow copy of the object at that index, then immediately override the isSelected property. This ensures we're not modifying the original state object.
Create the New Array: We leverage Array.prototype.slice() along with the spread operator (...) to build a brand new array:
- ...prevTasks.slice(0, index): Gets all elements before the target.
- updatedTask: Inserts the modified object.
- ...prevTasks.slice(index + 1): Gets all elements after the target.

This sequence guarantees that React detects the state change (because the array reference is new) and correctly triggers a re-render with the updated data.

Rendering Example

You would then use this function in your JSX/TSX:

// Inside the TaskListManager return statement
return (
  <div>
    <h2>Tasks</h2>
    {tasks.map(task => (
      <div 
        key={task.id} 
        style={{ 
          padding: '10px', 
          border: '1px solid #ccc', 
          marginBottom: '5px',
          backgroundColor: task.isSelected ? '#e6ffe6' : 'white'
        }}
        onClick={() => handleToggleSelection(task.id)} // Call the handler
      >
        {task.name} - **Selected: {task.isSelected ? 'Yes' : 'No'}**
      </div>
    ))}
  </div>
);

You shouldn't use Array.prototype.splice() in React state updates because it is a mutating method; it changes the original array directly. React requires that all state updates be immutable, meaning you must create a new array instead of modifying the existing one.

Why Immutability is Key in React

The primary reason to avoid splice() (and other mutating methods like push(), pop(), or direct index assignment like arr[0] = newItem) is how React handles rendering and change detection:

Change Detection: React's default shallow comparison mechanism in components (especially with React.memo or the class component PureComponent) only checks if the state or prop reference has changed.

  * If you use `splice()`, the array is modified *in place*, but the **memory address (reference)** remains the same. React thinks the state hasn't changed, and the component **will not re-render**, leading to a stale UI.
  * By using immutable methods (like `slice()`, `map()`, `filter()`, or the spread operator `...`), you generate a **new array reference**, which signals React to re-render.

Debugging and Predictability: Mutating state can lead to hard-to-track bugs and makes time-travel debugging difficult. Immutable updates ensure that your previous state is always preserved, making the data flow predictable.

The Immutable Alternative

Instead of using splice(), which modifies the original array, the blog post you shared correctly uses the spread operator (...) and slice() to achieve the same result immutably:

// The splice() operation (DO NOT USE FOR REACT STATE)
// const oldTasks = [task1, task2, task3];
// oldTasks.splice(index, 1, updatedTask); // Mutates oldTasks

// The IMMUTABLE approach using slice() and the spread operator (Recommended)
setTasks(prevTasks => [
    ...prevTasks.slice(0, index), // Items before the target
    updatedTask,                  // The new item
    ...prevTasks.slice(index + 1) // Items after the target
]);