State handling in React tends to get complicated the moment an application grows beyond a few isolated components. With project planning interfaces, the amount of interconnected UI behavior increases very quickly.

Previously, we explored several ways to organize this kind of logic, including Redux Toolkit, Zustand, MobX, and XState. Jotai approaches the problem differently. Instead of pushing everything into one global store, it breaks the state into isolated atomic units. To demonstrate how that model behaves in practice, we’ll use the react-gantt-jotai-starter project built with DHTMLX React Gantt.

Before moving into the implementation details, it’s worth understanding why Jotai feels noticeably different from more traditional React state libraries.

Understanding Jotai’s Atomic Model

Jotai was introduced as an alternative to the common useContext + useState pattern that many React teams eventually outgrow. In larger applications, context-based state often causes broader component updates than expected, and tracking why something re-rendered becomes frustrating surprisingly fast.

Jotai tries to reduce that friction by keeping the state extremely granular. The library gained traction partly because it stays very close to React’s native hooks philosophy instead of introducing a large architectural layer on top of it. That simplicity is one of the reasons many companies adopted it in production environments.

People often compare Jotai to Zustand because both libraries avoid heavy configuration and excessive boilerplate. The real distinction appears in how they organize data internally.

With Zustand, state typically lives inside a shared store that can later be divided into smaller slices. Jotai removes the idea of a mandatory central store entirely. Instead, every piece of state exists as its own atom. That architectural difference changes how updates propagate through the UI.

A component subscribes only to the atoms it actually consumes. When one atom changes, unrelated parts of the interface remain untouched. In data-heavy interfaces, this usually leads to more controlled rendering behavior and fewer optimization workarounds.

The API also stays fairly flexible. Atoms can be combined, derived from one another, or used purely for updates without exposing readable values. Because of that, the same model works both for lightweight local interactions and for more involved application flows.

Jotai also plays nicely with newer React capabilities, including Suspense and concurrent rendering patterns, which makes it feel relatively future-proof in modern React setups. The trade-off becomes noticeable later.

As applications expand, the number of atoms can grow rapidly. At that stage, organization becomes critical. Without consistent naming and structure, an atom-based architecture can become just as difficult to navigate as an oversized global store.

Why Jotai Works Naturally with React Gantt Interfaces

Interactive Gantt components behave differently from ordinary CRUD-style UIs. A seemingly small action like dragging a task along the timeline often triggers several related updates throughout the chart.

That constant chain reaction is exactly where Jotai starts to feel practical. Because updates are isolated into narrowly scoped atoms, changes remain localized. Rescheduling one task does not force unrelated parts of the application to refresh or recalculate unnecessarily. The update affects only the pieces directly connected to that interaction.

In practice, this makes state transitions easier to follow. Instead of tracing changes across reducers, middleware, or deeply nested state objects, you usually deal with a much smaller update surface. That becomes especially valuable once a project timeline grows and interactions happen continuously.

To see why this structure stays manageable, it helps to examine the overall data flow before diving into implementation details.

Organizing Data Flow Around Atoms

In this setup, the core Gantt data is stored inside a primary atom that acts as the authoritative state source for the chart. Tasks, dependency links, configuration values, and related UI state all live there.

Updates, however, are intentionally separated. Rather than mutating the main state directly, individual write-only atoms handle specific operations independently. One atom processes task creation, another updates links, another adjusts zoom configuration, and so forth.

The React Gantt component itself remains mostly passive. Its responsibility is simply to read current state values and pass them into DHTMLX React Gantt through props. When the user interacts with the chart, those interactions are routed through data.save, which delegates the update to the appropriate atom.

What’s important is that the same mechanism applies outside the chart as well. Toolbar actions such as undo, redo, or zoom changes do not introduce separate synchronization logic. They follow the identical update pipeline as interactions originating directly inside the Gantt UI.

A simplified flow looks roughly like this:

user interaction → data.save intercepts the change → matching write-only atom executes → history snapshot updates → main Gantt atom changes → React Gantt re-renders with new state

That consistency is what keeps the architecture understandable once the interface becomes more complex.

How the Integration Works in Practice

Let’s move from structure to actual behavior and look at how state updates are implemented.

1. Keeping Gantt Data Inside Atoms

The main state atom holds the full dataset, including tasks, links, and configuration (zoom, etc.):

export const ganttStateAtom = atom<GanttState>({  
  tasks: seedTasks,  
  links: seedLinks,  
  config: { zoom: defaultZoomLevels },  
});

const maxHistory = 50;

export const pastAtom = atom<GanttState[]>([]);  
export const futureAtom = atom<GanttState[]>([]);

Alongside it, there are two additional atoms: pastAtom and futureAtom. These are used for undo/redo history.

To prevent unbounded memory growth, history is capped (for example, at 50 entries). Older snapshots are dropped once the limit is reached.

2. Applying Updates Through Write-Only Atoms

All modifications happen through dedicated write-only atoms. Each one represents a specific mutation: create, update, or delete.

export const addTaskAtom = atom(null, (get, set, task: SerializedTask) => {  
  pushHistory(get, set, get(ganttStateAtom));  
  set(ganttStateAtom, {  
    ...get(ganttStateAtom),  
    tasks: [...get(ganttStateAtom).tasks, { ...task, id: `DB_ID:${task.id}` }],  
  });  
  return { ...task, id: `DB_ID:${task.id}` };  
});

Before applying any change, the current state is pushed into history. This ensures undo/redo works reliably later.

After that, the atom updates ganttStateAtom with a new immutable state.

These atoms are accessed via useSetAtom, which allows triggering updates without subscribing to their values. Only the main state atom is read by the UI.

3. Translating UI Actions into State Changes

User interactions inside DHTMLX React Gantt are not handled directly in the UI layer. Instead, everything goes through data.save. This function acts as a bridge between the visual layer and the state layer.

When a task is created, updated, or removed, the callback translates that action into the corresponding atom call. In creation flows, the updated entity (often with a generated ID) is returned to the Gantt to keep identifiers consistent.

This small detail prevents common synchronization issues between UI-generated IDs and store-generated IDs.

4. Handling Undo and Redo Outside the UI Layer

Undo/redo is implemented entirely outside the component layer. Each state change is recorded before mutation. The history stack stores full snapshots of the Gantt state.

• pastAtom holds previous states
• futureAtom holds states for redo

When undo is triggered, the last snapshot is restored and moved into the future stack. Redo performs the opposite operation.

Because snapshots capture the entire state, undo/redo remains consistent across all types of changes.

You can continue mastering integration patterns of DHTMLX React Gantt with Jotai using the official DHTMLX tutorial.

Closing Remarks

Jotai fits surprisingly well into a Gantt-based workflow. Its atomic structure keeps updates localized, which is important when working with highly interactive interfaces like DHTMLX React Gantt.

That said, it’s not a universal solution. As applications scale and the number of atoms grows, maintaining a clear structure becomes a responsibility of the developer rather than the library.

In smaller or medium-sized systems, it feels lightweight and direct. In larger enterprise setups, centralized approaches can still make more sense depending on the complexity of the shared state.

AI coding assistants have already become part of everyday frontend work. Generating repetitive React code, scaffolding components, or wiring basic logic is no longer the hard part. Problems usually begin later, when the model has to interact with a complex UI library that it does not fully understand.

That situation is pretty common with project-planning interfaces. A Gantt component is not just another visual widget. It comes with its own data model, interaction patterns, configuration rules, and API specifics. Without proper context, AI tools tend to compensate with assumptions, and the results become unpredictable surprisingly fast.

To make this workflow more stable for DHTMLX users, we started building agent skills focused on specific products instead of generic prompting tricks.

The first implementation targets DHTMLX React Gantt.

How the Skill Changes AI-Assisted Gantt Development

The idea behind the React Gantt skill is straightforward: provide AI assistants with clearer operational knowledge of how the component is typically used in React applications.

Instead of assembling integrations from random examples scattered across the web, the model receives structured guidance tailored specifically for both available package versions - trial (@dhtmlx/trial-react-gantt) and complete (@dhx/react-gantt).

The skill focuses on areas where AI-generated implementations usually become inconsistent:

• configuring the Gantt component inside React
• handling task and link operations
• applying visual customizations and themes
• implementing more advanced behaviors like resources, undo/redo flows, or task reordering

In practice, AI coding errors around UI libraries rarely look dramatic at first. More often, the assistant quietly mixes incompatible APIs, invents configuration options, or reproduces patterns from outdated examples. Those issues are especially annoying because they can survive code review until runtime.

The React Gantt skill is meant to reduce that kind of friction. It provides implementation-oriented instructions based on real integration scenarios and can additionally validate uncertain API details through the DHTMLX MCP infrastructure.

The result is not “magic AI coding,” but something more useful: responses that stay much closer to real-world React Gantt implementations.

Installing the skill takes a single command:

npx skills add DHTMLX/skills - skill dhtmlx-react-gantt

It can be used with AI development tools supporting the Agent Skills format, including Claude Code, Cursor, Copilot, and related environments.

Another practical detail: the entire skill definition is stored in readable Markdown files. That means developers can inspect the rules directly, adapt them internally, or simply understand why the assistant behaves a certain way during integration tasks.

Why Live Documentation Still Matters

Even detailed implementation rules have limitations. Frontend libraries evolve continuously. APIs shift, new options appear, old approaches become deprecated, and examples written several months ago may already contain inaccuracies. AI assistants struggle with this particularly hard because their internal knowledge is static by nature.

That is exactly the problem the DHTMLX MCP Server is designed to address.

The React Gantt skill helps the assistant follow correct integration patterns, while the MCP server supplies current technical references directly from the latest DHTMLX documentation. Instead of improvising around uncertain APIs, the model can retrieve relevant information from a live source.

From a development perspective, these two layers solve different problems:

• the skill improves behavioral consistency
• the MCP server improves factual accuracy

Combined, they make AI-assisted development around DHTMLX React Gantt feel considerably more dependable than prompt-only workflows.

The setup itself is lightweight, and the official documentation covers the installation process step by step.

React Gantt is only the starting point here. The same direction will gradually extend to other DHTMLX components as well, especially where AI tools tend to struggle with library-specific implementation details.

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community. Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community.

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter. And before you go, don’t forget to clap and follow the writer️!

Reducing AI Guesswork in React Gantt Projects with a New Agent Skill was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

State management in a React Gantt app rarely stays simple for long. Once real workflows kick in, updates start triggering other updates, and keeping everything in sync becomes less predictable.

We’ve tried Redux Toolkit, Zustand, and MobX with DHTMLX components, which are solid tools, but all built around the same idea of directly updating state.

XState flips that perspective. Instead of changing state, you describe how it’s allowed to change. Let’s see what that looks like in React Gantt and Scheduler projects.

Understanding XState Through Real React Use Cases

XState usually appears in a project at a very specific moment, not at the start, but when state logic becomes annoying to track.

You start noticing it when simple updates aren’t enough anymore. A task update triggers something else. A UI state depends on multiple async steps. Things stop being local and start affecting each other.

It works fine in plain JavaScript and integrates with React without friction, but it’s rarely introduced early because the mental shift is real.

The core idea is finite state machines. Sounds theoretical, but in practice it’s more restrictive than complex: you define allowed states and explicitly describe how transitions happen between them. Nothing “just changes” anymore. That restriction is the point. The image below clearly illustrates the core ideas behind state machines in XState.

Every change comes from an event, usually something user-driven. Once that event happens, XState runs actions that update context (its internal state container). Instead of spreading logic across components, everything gets centralized in one place.

As applications grow, simple state machines don’t always stay simple. That’s where statecharts come in — nested states, parallel flows, separated concerns inside one system. This becomes useful when the UI isn’t doing one thing at a time anymore.

And when even that isn’t enough, XState introduces actors — separate machines running independently and communicating. It sounds heavy at first, but in larger apps, it often reduces confusion rather than adding to it.

The end result is less about “managing state” and more about defining allowed behavior.

Instead of reacting to whatever state happens to be, you define what can happen. That removes entire classes of bugs where the UI ends up in impossible combinations.

There’s also a broader ecosystem around it, known as the Stately tools, mostly focused on visualizing and inspecting machines. That becomes useful once systems stop fitting in your head.

We won’t go deeper into theory here. The more interesting question is where this actually helps compared to other approaches.

When XState Actually Makes Sense

XState is not something most teams pick by default. Most React apps start with Redux Toolkit, Zustand, or MobX because the flow is familiar: update state, UI reacts, done.

XState doesn’t follow that pattern. You don’t “update state” directly; you describe behavior. That difference takes a bit of adjustment.

In small apps, it can feel unnecessary. There’s no benefit in modeling everything as a machine if the logic is simple. Where it starts to make sense is when things stop being linear. That usually happens in real-world interfaces with overlapping processes: async operations, dependent updates, and multiple UI states influencing each other.

This is exactly what shows up in tools like DHTMLX React Gantt or DHTMLX React Scheduler.

At that point, XState stops being “a state library” and becomes a way to control how the system behaves over time.

We’ll skip architecture discussions and focus on a real integration example instead.

Building a Gantt App with XState: Main Integration Steps

The integration flow itself isn’t radically different from other state tools. What changes is how the state is represented. With XState, you’re no longer wiring a store, you’re defining a machine.

We’ll focus on DHTMLX React Gantt, but the same approach applies to DHTMLX React Scheduler.

If you want to try this setup in your own project, we’ve put together a step-by-step guide for integrating XState with DHTMLX React Gantt and a similar walkthrough for React Scheduler. If you prefer to see the full setup in action, there’s also a complete Gantt demo project on GitHub.

Building the XState Machine Structure

Everything starts with defining what the machine actually holds. Before transitions or events, you define the context shape or what lives inside the system.

import { createMachine, assign } from 'xstate';  
import type { Link, GanttConfig, SerializedTask } from '@dhtmlx/trial-react-gantt';  
import { seedTasks, seedLinks, defaultZoomLevels, type ZoomLevel } from './seed/Seed';

export interface Snapshot {  
  tasks: SerializedTask[];  
  links: Link[];  
  config: GanttConfig;  
}

export interface ContextType {  
  tasks: SerializedTask[];  
  links: Link[];  
  config: GanttConfig;

  past: Snapshot[];  
  future: Snapshot[];  
  maxHistory: number;  
}

What matters here isn’t syntax. It’s separation. Context holds the live state (tasks, links, config, history). Snapshot exists for one reason: so undo/redo doesn’t turn into guesswork. Instead of reconstructing previous states, you store them explicitly. That small decision makes history logic much easier to reason about later.

How State Changes Are Defined

Once the structure is in place, things shift from modeling to interaction. Now it’s about what happens when the user actually does something.

With XState, every meaningful interaction becomes an event. In a Gantt app, that’s basically everything (task edits, link updates, zoom changes, undo/redo actions).

So instead of spreading logic across components, you describe events explicitly:

type SetZoomEvent = { type: 'SET_ZOOM'; level: ZoomLevel };  
type UndoEvent = { type: 'UNDO' };  
type RedoEvent = { type: 'REDO' };  
type AddTaskEvent = { type: 'ADD_TASK'; task: SerializedTask };  
type UpsertTaskEvent = { type: 'UPSERT_TASK'; task: SerializedTask };  
type DeleteTaskEvent = { type: 'DELETE_TASK'; id: string | number };  
type AddLinkEvent = { type: 'ADD_LINK'; link: Link };  
type UpsertLinkEvent = { type: 'UPSERT_LINK'; link: Link };  
type DeleteLinkEvent = { type: 'DELETE_LINK'; id: string | number };

type EventType =  
  | SetZoomEvent  
  | UndoEvent  
  | RedoEvent  
  | AddTaskEvent  
  | UpsertTaskEvent  
  | DeleteTaskEvent  
  | AddLinkEvent  
  | UpsertLinkEvent  
  | DeleteLinkEvent;

Nothing fancy here, just a list of possible actions in the system. But it changes the way you think about UI: nothing happens implicitly anymore. From there, each event maps to an action that updates the state.

addTask: assign(({ context: ctx, event }) => ({  
  tasks: [...ctx.tasks, { ...(event as AddTaskEvent).task, id: `DB_ID:${(event as AddTaskEvent).task.id}` }],  
})),

upsertTask: assign(({ context: ctx, event }) => ({  
  tasks: ctx.tasks.map((task) =>  
    String(task.id) === String((event as UpsertTaskEvent).task.id)  
      ? { ...task, ...(event as UpsertTaskEvent).task }  
      : task  
  ),  
})),

deleteTask: assign(({ context, event }) => ({  
  tasks: context.tasks.filter((t) => String(t.id) !== String((event as DeleteTaskEvent).id)),  
})),

After a few of these, a pattern emerges. It’s repetitive, but intentionally so. The important shift is that the state is no longer updated directly. Everything goes throughassign, which builds a new context from the current state and the event.

That alone changes debugging behavior. You stop searching for hidden mutations and instead follow event flow.

Creating the Machine Configuration

At some point, everything gets wired together — context, events, and actions inside one machine.

Before that, there’s one detail worth calling out snapshots:

const createSnapshot = (ctx: ContextType): Snapshot => ({  
  tasks: structuredClone(ctx.tasks),  
  links: structuredClone(ctx.links),  
  config: structuredClone(ctx.config),  
});

Not exciting code, but without it, undo/redo becomes unreliable quickly. Now the machine itself:

export const ganttMachine = createMachine(  
  {  
    id: 'gantt',  
    types: {  
      context: {} as ContextType,  
      events: {} as EventType,  
    },  
    context: {  
      tasks: seedTasks,  
      links: seedLinks,  
      config: { zoom: defaultZoomLevels },  
      past: [],  
      future: [],  
      maxHistory: 50,  
    },  
    initial: 'ready',  
    states: {  
      ready: {  
        on: {  
          SET_ZOOM: { actions: ['pushHistory', 'setZoom'] },  
          UNDO: { actions: 'undo' },  
          REDO: { actions: 'redo' },

          ADD_TASK: { actions: ['pushHistory', 'addTask'] },  
          UPSERT_TASK: { actions: ['pushHistory', 'upsertTask'] },  
          DELETE_TASK: { actions: ['pushHistory', 'deleteTask'] },

          ADD_LINK: { actions: ['pushHistory', 'addLink'] },  
          UPSERT_LINK: { actions: ['pushHistory', 'upsertLink'] },  
          DELETE_LINK: { actions: ['pushHistory', 'deleteLink'] },  
        },  
      },  
    },  
  },
)

There’s only one real state here, namelyready. That’s intentional. The machine acts more like a controlled dispatcher than a multi-state workflow. Every event and action goes through it. Compared to Redux Toolkit or Zustand, where you call functions directly, this feels more indirect at first. But that’s also what makes it traceable. You don’t mutate anything manually. You send an event, and the machine decides what happens next.

Wiring Gantt UI Actions to the State Machine

This is where UI finally connects to the machine. In DHTMLX React Gantt, everything flows through data.save.

const data: ReactGanttProps['data'] = useMemo(  
  () => ({  
    save: (entity, action, item, id) => {  
      if (entity === 'task') {  
        const task = item as SerializedTask;  
        if (action === 'create') {  
          send({ type: 'ADD_TASK', task });  
        } else if (action === 'update') {  
          send({ type: 'UPSERT_TASK', task });  
        } else if (action === 'delete') {  
          send({ type: 'DELETE_TASK', id });  
        }  
      } else if (entity === 'link') {  
        const link = item as Link;  
        if (action === 'create') {  
          send({ type: 'ADD_LINK', link });  
        } else if (action === 'update') {  
          send({ type: 'UPSERT_LINK', link });  
        } else if (action === 'delete') {  
          send({ type: 'DELETE_LINK', id });  
        }  
      }  
    },  
  }),  
  [send]  
);

Each user interaction hits this callback first. Instead of updating the state locally, we just send an event into XState. After that, the UI doesn’t decide anything. It just reports what happened.

The Gantt component itself stays intentionally “dumb”; it doesn’t own state, doesn’t mutate anything. It only renders props. That separation is what keeps behavior predictable when the app grows.

The full loop looks like this:

User action → data.save → event sent → machine processes it → context updates → props update → UI re-renders

The same idea applies to DHTMLX React Scheduler.

Conclusion

XState isn’t something you reach for by default. In smaller apps, it often feels like unnecessary structure. A bit heavy, a bit rigid. But once UI logic stops being linear, especially in systems like Gantt charts or schedulers, things change. State stops being just data. It becomes behavior over time. In those cases, modeling transitions explicitly tends to reduce uncertainty as the system grows. Not simpler upfront, but usually more stable later. Still, it’s not a universal choice. If the problem doesn’t need that level of structure, XState is probably more than you want.

Not long ago, we introduced the DHTMLX MCP Server–a centralized knowledge layer that gives AI assistants and developer tools structured access to the latest documentation across the entire DHTMLX product line, from Suite widgets to Gantt and Scheduler.

Behind that idea, however, was a fairly tricky engineering problem. It’s one thing to build a knowledge system for a single product. It’s something else entirely to make it work across a full ecosystem without losing accuracy or context.

At the core of the MCP server is the Retrieval-Augmented Generation (RAG) approach. It pulls relevant fragments from documentation and passes them to LLMs to generate responses grounded in real data. This setup works reliably when you’re dealing with one product. But once multiple products enter the picture, the complexity increases quickly.

RAG and MCP: What’s Going On Under the Hood

Before getting into implementation details, it helps to align on the basics behind RAG and MCP, since most of the architecture builds on these two ideas.

So how do you actually turn a Retrieval-Augmented Generation setup into an MCP server?

At a high level, RAG is about giving an LLM access to external knowledge instead of relying purely on its training data. The process usually breaks down into three steps:

• find relevant pieces of external data (retrieval)
• add that context to the prompt (augmentation)
• produce a response based on that context (generation)

In practice, the pipeline looks fairly standard. You take your documentation, split it into chunks, convert each chunk into embeddings, and store them in an index. When a query comes in, the system looks for the closest matches using similarity metrics like cosine similarity, then feeds those results into the model.

Now, where does MCP fit into this?

The Model Context Protocol acts as a kind of universal connector between AI agents and external systems. A common analogy is a “USB-C port” for AI apps, one interface that can plug into different types of data and functionality.

Through MCP, an AI system can work with:

• things like API calls or database queries (tools)
• documentation, structured content, reusable logic (resources)
• predefined workflows or few-shot examples (prompts)

In other words, MCP turns an LLM from a static knowledge source into something that can operate with live, structured context.

So what does it take to build a system like this?

In practice, MCP servers with RAG capabilities are often built using a combination of frameworks. A few commonly used ones:

• FastMCP — typically used to implement the MCP layer
• LlamaIndex — well-suited for knowledge-heavy RAG pipelines
• LangChain — often used for agent-style workflows

There’s also a common misconception that this stack is strictly Python-based. In reality, both LlamaIndex and LangChain support JavaScript, and MCP itself is language-agnostic with SDKs across different ecosystems.

At first glance, assembling a RAG + MCP setup looks fairly straightforward: pick the tools, connect the pieces, and you’re done.

But that assumption starts to break once you move beyond a single product. Supporting multiple products, each with its own documentation structure and API surface, introduces a different level of complexity. At that point, the real question becomes not how to build the system, but how to organize the knowledge behind it.

Moving Toward a Machine Learning Approach

When you first try to scale a Retrieval-Augmented Generation system, the obvious idea is to put everything into a single index. From an infrastructure standpoint, it feels clean and efficient, one place for all product knowledge.

In practice, though, that approach breaks down pretty quickly.

DHTMLX JavaScript UI components follow very different internal logic. Once you mix their documentation into the same vector space, the system starts to blur the boundaries between them. You might ask about one component and get suggestions that clearly belong to another. API methods get mixed up, examples don’t quite fit, and overall answer quality takes a hit.

The natural fix was to split the knowledge base. We moved to separate indexes for each product, which immediately improved accuracy within each domain.

But that introduced a new problem.

Now the system had to decide where to send each query before retrieval even begins. In other words, we needed a reliable way to map a user’s question to the right product.

At first, the usual approaches seemed good enough. Things like keyword matching, regular expressions, or fuzzy search are easy to implement. You can also route queries through an LLM and let it classify intent.

In reality, none of these options held up well:

• heuristic methods (keywords, regex, fuzzy rules) break easily because user queries vary too much
• LLM-based routing is flexible, but too slow for a system that needs to handle a high load

What we actually needed was a balance, something as fast as rule-based logic, but flexible enough to understand real-world queries.

That’s where we landed on a custom machine learning model for domain classification.

A Practical ML Breakthrough

At this point, the task became pretty concrete: find a model that’s fast enough to handle requests in milliseconds, but still smart enough to understand technical documentation.

In practice, that usually turns into a trade-off.

On one side, you have models with more parameters, they tend to understand context better. On the other hand, you have model size, the smaller it is, the faster it runs and the less pressure it puts on your infrastructure. The goal was to push both in the right direction at once: keep the model lightweight without sacrificing too much quality.

So how do you end up with something compact, but still capable of handling nuanced queries about APIs and configuration?

We leaned on two well-known techniques: distillation and quantization.

Distillation works like a “teacher–student” setup. A large, pre-trained model (the teacher) already has a strong grasp of context. Instead of using it directly, you train a smaller model (the student) to imitate its behavior. The student doesn’t carry the full weight of the original model, but it retains a surprising amount of its understanding.

Quantization tackles a different part of the problem — size. Normally, model parameters are stored in 32-bit precision. By reducing that precision (in our case, down to 8-bit), you significantly shrink the model without dramatically affecting performance. There are even more aggressive approaches, but this turned out to be a good balance for our needs.

The result is a model that doesn’t quite follow the usual patterns. It delivers a level of understanding you’d expect from something like BERT variants such as TinyBERT, while staying much closer in size to lighter models like BERT_TINY.

More importantly, it hits the balance we were after: solid accuracy, low latency, and predictable resource usage, which is exactly what you need when this piece sits in the middle of every request.

Wrapping Up

In practice, scaling a knowledge system turned out to be less about adding more data and more about structuring it the right way. Some of the seemingly logical decisions, like unifying everything into a single index, introduced more noise than value, especially once real user queries came into play.

What made the difference was introducing a lightweight machine learning layer for routing. It gave us the responsiveness we needed under load while still handling the nuances of DHTMLX documentation across products.

If you’re working with AI-assisted development around DHTMLX components, adding the MCP server becomes more than just a backend piece. It’s what keeps answers grounded in the latest docs and helps avoid those subtle mismatches that tend to slow teams down in real projects.

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community. Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community.

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter. And before you go, don’t forget to clap and follow the writer️!

Scaling AI Knowledge Systems: Lessons from the DHTMLX MCP Server was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Not long ago, we explored how state management affects complex UI components like DHTMLX React Gantt and how integrating Redux Toolkit can help bring structure to growing React applications. That approach works well, especially when you need strict control over state transitions. But in practice, not every project needs that level of ceremony.

State management in modern front-end apps rarely follows a single pattern. Some teams value predictability and explicit flows. Others prefer something lighter that doesn’t add extra boilerplate. Redux Toolkit remains a solid choice for feature-rich applications, but we often see cases where its setup feels heavier than necessary, especially in projects where speed and simplicity matter just as much as scalability.

So we decided to continue our series on state management strategies for apps built with DHTMLX React Gantt and React Scheduler.

This time, the focus is on Zustand, a minimalistic yet surprisingly capable state management library. We’ll look at how it fits into real React workflows, why many developers reach for it instead of larger state solutions, and what actually happens when you connect a Zustand store to a Gantt chart or scheduling calendar in a working application.

Why Zustand Caught So Much Attention

Zustand is a lightweight state management library built with React in mind. Since its first stable release back in 2019, it has steadily built a strong following, mostly because it stays out of your way. The focus is simple: minimal API surface, solid performance, and a developer experience that doesn’t feel like overhead.

The adoption numbers reflect that momentum. At the time of writing, Zustand is approaching 21 million weekly downloads on npm, and it recently ranked at the top among state management libraries in the latest edition of the JavaScript Rising Stars report.

So what’s behind that growth?

In practice, teams are drawn to its flexibility. Zustand uses a hook-based API that feels natural inside React components. There’s no heavy architecture imposed on you, no rigid folder structure to follow, and very little boilerplate. You define a store, consume it where needed, and move on. State updates remain predictable thanks to immutable patterns, but without the ceremony we often associate with larger Flux-inspired solutions.

Another detail that developers appreciate: Zustand avoids a few common React pitfalls. Issues like the “zombie child” problem, React concurrency edge cases, or context loss between mixed renderers are largely handled under the hood. You don’t spend time fighting the state layer; it just works.

And it’s not strictly tied to React either. Zustand can be used with vanilla JavaScript and even in Node.js environments. Unlike Redux, which is deeply rooted in React-oriented patterns, Zustand gives you more freedom to manage state beyond a single UI framework.

All of that makes it an interesting alternative to Redux Toolkit, especially when you want something leaner without sacrificing control. So how does that difference actually play out in a real project with DHTMLX React Gantt or Scheduler? Let’s take a closer look.

Zustand vs Redux Toolkit: Where the Difference Shows

Zustand and Redux Toolkit appeared in the React ecosystem around the same period. Redux Toolkit gained traction quickly, mostly because it became the officially recommended way to write Redux logic. For teams already invested in Redux, switching to Redux Toolkit felt natural — almost automatic.

But things have been shifting.

According to the latest State of React 2025 survey, Zustand is gaining ground fast. In fact, respondents rated it higher than Redux Toolkit across categories like Interest, Positivity, and Satisfaction. That says a lot about where developer sentiment is moving.

In practice, the reason isn’t hard to see. When you’re building feature-heavy interfaces, like scheduling systems or project planning apps with Gantt charts, state logic can grow quickly. Many teams don’t necessarily want more structure at that point. They want clarity without ceremony. Zustand tends to hit that balance.

One notable difference is architectural: Zustand doesn’t require wrapping your entire app in a context provider. You define a store, consume it with hooks, and keep going. For some projects, that small shift already simplifies the mental model.

Zustand is not a universal replacement for Redux Toolkit. If you’re dealing with strict middleware chains, complex async workflows, or deeply interconnected global state, Redux Toolkit remains a strong fit.

But for many React scheduling tools and project planning systems, especially those built with DHTMLX React Gantt or React Scheduler, Zustand provides enough control over edits and updates without adding structural weight. Teams usually notice that the store stays easy to reason about even as the UI becomes more interactive.

With that in mind, let’s look at how this plays out when integrating Zustand with DHTMLX React components.

Both DHTMLX React Gantt and React Scheduler follow a similar integration pattern. To keep things concrete, we’ll focus on DHTMLX React Gantt as an example.

If you’d like to try it yourself, you can install the professional evaluation version directly from npm and experiment in a real project setup.

Key Aspects of Integrating DHTMLX React Gantt with Zustand

At this point, it’s fair to ask: how do all those advantages of Zustand actually translate into a real React Gantt project?

Instead of speaking in abstractions, let’s look at the practical side. The goal here is to build a state layer around DHTMLX React Gantt where every update, whether it’s editing a task, changing zoom, or creating a dependency, flows through a centralized Zustand store.

Defining Store Responsibilities

The store plays a bigger role than just holding Gantt data. It also defines how that data changes.

Here’s the TypeScript structure used in the example:

type Snapshot = { tasks: SerializedTask[]; links: Link[]; config: GanttConfig };
type State = {
  tasks: SerializedTask[];
  links: Link[];
  config: GanttConfig;
  past: Snapshot[];
  future: Snapshot[];
  maxHistory: number;
  recordHistory: () => void;
  undo: () => void;
  redo: () => void;

  setZoom: (level: ZoomLevel) => void;
  addTask: (task: SerializedTask) => SerializedTask;
  upsertTask: (task: SerializedTask) => void;
  deleteTask: (id: string | number) => void;
  addLink: (l: Link) => Link;
  upsertLink: (l: Link) => void;
  deleteLink: (id: string | number) => void;
};

What stands out here is that the store combines data, history management, and mutation logic in one place. Tasks, links, configuration, undo/redo — everything lives together. In practice, this makes the store the single source of truth for the entire chart.

Creating the Store

With the structure defined, we can create the Zustand store:

export const useGanttStore = create<State>((set, get) => ({
  tasks: seedTasks,
  links: seedLinks,
  config: { zoom: defaultZoomLevels },

  past: [],
  future: [],
  maxHistory: 50,
... // actions will go here

At this stage, we have an initial state: tasks, links, config, and empty history arrays. The interesting part is how actions modify that state.

Take Zoom changes as an example:

setZoom: (level) => {
  get().recordHistory();
  set({
    config: { ...get().config, zoom: { ...get().config.zoom, current: level } },
  });
},

Before updating anything, the store records the current snapshot. Then it creates a new configuration object with the updated zoom level. No reducers. No dispatch. Just direct, explicit state transitions.

Updating a task follows the same pattern:

upsertTask: (task) => {
  get().recordHistory();
  const tasks = get().tasks;
  const index = tasks.findIndex((x) => String(x.id) === String(task.id));
  if (index !== -1) {
    set({
      tasks: [...tasks.slice(0, index), { ...tasks[index], ...task }, ...tasks.slice(index + 1)],
    });
  }
},

The logic is straightforward: find the task, merge changes, update state. Unlike Redux Toolkit, there’s no separate reducer layer. Data and mutation logic live inside the same store definition. For many teams, that reduces mental overhead.

The same principle applies to links, configuration updates, and undo/redo history. Everything is handled through regular store actions.

Which leads to the next practical question: how do user interactions inside the Gantt chart trigger these actions?

Turning Gantt Events into Store Actions

This is where the data.save callback comes in. It acts as a bridge between DHTMLX React Gantt and the Zustand store.

Whenever a user edits a task or link, Gantt triggers data.save. That callback determines what kind of operation occurred and routes it to the appropriate store action.

const data: ReactGanttProps['data'] = useMemo(  
  () => ({  
    save: (entity, action, item, id) => {  
      if (entity === 'task') {  
        const task = item as SerializedTask;  
        if (action === 'create') return addTask(task);  
        else if (action === 'update') upsertTask(task);  
        else if (action === 'delete') deleteTask(id);  
      } else if (entity === 'link') {  
        const link = item as Link;  
        if (action === 'create') return addLink(link);  
        else if (action === 'update') upsertLink(link);  
        else if (action === 'delete') deleteLink(id);  
      }  
    },  
  }),  
  [addTask, addLink, upsertTask, upsertLink, deleteTask, deleteLink]  
);

In practice, the flow looks like this:

• A user edits a task or dependency in the Gantt UI
• Gantt calls data.save(…)
• The action type is identified
• The corresponding Zustand action runs
• The store updates
• The chart re-renders with the new state

All mutations happen inside the store. The Gantt component simply reflects the updated data. Because every change goes through explicit store actions, debugging and change tracking become more predictable.

If you want to explore this mechanism in more detail, the “Handling changes with data.save” section in the official guide walks through additional examples.

Keeping Gantt as a Visual Layer

One deliberate design choice in this approach is the separation of concerns. Once Zustand handles state management, the Gantt component itself becomes mostly a rendering layer.

Here’s how the store is consumed:

const { tasks, links, config, setZoom, addTask, upsertTask, deleteTask, addLink, upsertLink, deleteLink, undo, redo } = useGanttStore();

And rendering becomes straightforward:

<ReactGantt ref={ganttRef} tasks={tasks} links={links} config={config} templates={templates} data={data} />

The component reads the state and passes events back to the store. That’s it. No duplicated logic. No hidden mutations inside the UI layer.

If you prefer a full walkthrough, the official documentation includes a step-by-step tutorial showing how to connect DHTMLX React Gantt with Zustand in a single application. It also demonstrates how to build a custom toolbar for zoom controls and undo/redo actions outside the chart UI, all wired into the same store. There’s even a complete working example available on GitHub for those who want to experiment in a real project setup.

Wrapping Up

When developing a React application that includes complex UI components such as a Gantt chart or Scheduler, state management quickly becomes a central architectural concern. The combination of React, Zustand, and DHTMLX React Gantt demonstrates that powerful functionality does not necessarily require heavyweight solutions.

Zustand offers a clean, minimalistic approach to handling tasks, links, configuration settings, and even undo/redo history — all within a single, predictable store. The result is a setup where data flows are transparent, debugging is simpler, and the Gantt component remains focused purely on rendering.

Is Zustand a solid choice for enterprise-grade React applications? In many cases, absolutely. Still, architecture decisions should always align with project requirements. In upcoming articles, we will evaluate other state management approaches for DHTMLX React components to help you make an informed decision.

When a powerful technology arrives, you either move with it or get left behind. Lately, that idea feels more like a day-to-day reality, especially in web development.

AI tools are showing up everywhere, and ignoring them isn’t really an option anymore. In practice, teams are already adjusting: businesses expect AI-driven features as part of modern products, developers rely on assistants to speed up routine work, and toolmakers are rethinking how their products fit into this new workflow.

We’ve been going through that same shift. And today, we’re introducing something that came out of it: the DHTMLX MCP Server. It’s a new addition aimed at making work with DHTMLX documentation noticeably more reliable and efficient when AI is part of your development process.

Why MCP Is Becoming Part of the AI Dev Stack

These days, tools like Claude Code, Cursor, Gemini, and OpenAI Codex have quietly become part of the everyday dev toolkit. We often see teams relying on them for routine coding, quick debugging, or just navigating documentation faster. But there’s a catch that shows up pretty quickly in practice.

Most AI assistants are powered by LLMs, and those models don’t continuously learn from new data. They’re trained once and then frozen at a certain point in time, the well-known “knowledge cutoff”. As a result, even strong assistants can fall behind when you’re working with evolving libraries or recently updated APIs. This is exactly the gap that MCP is designed to close.

At its core, the Model Context Protocol is an open standard that lets AI models connect to external systems and pull in fresh, real-time data. Instead of relying only on what the model “remembers,” it can now access what’s actually current.

Since its release in November 2024 by Anthropic, MCP has gained traction surprisingly fast. A few signals stand out:

• The ecosystem has grown to more than 10,000 public MCP servers, covering everything from dev tooling to large-scale enterprise use in Fortune 500 environments.
• Major cloud platforms — including Amazon Web Services, Cloudflare, Google Cloud, and Microsoft Azure — are already supporting it at the infrastructure level.
• Official SDKs are available across all major programming languages, with over 97 million monthly downloads.

Given that momentum, it’s not surprising MCP is quickly becoming one of the defining patterns for AI development heading into 2026.

For us, the reasoning was pretty straightforward. If AI tools work better with accurate, up-to-date context, then giving them direct access to DHTMLX documentation is the most reliable way to improve results. That’s what the DHTMLX MCP Server is built for.

In practice, it means your AI assistant can reference the latest DHTMLX APIs and behavior instead of guessing based on outdated training data.

So what does that actually change when you’re building with DHTMLX JavaScript components? Let’s take a closer look.

How the MCP Server Improves Everyday DHTMLX Workflows

If you’ve tried using AI assistants with UI libraries like DHTMLX, you’ve probably seen the rough edges. In practice, it often shows up as slightly off code: outdated APIs, missing config options, or examples that don’t quite match how the library works today.

These issues are usually tied to what people call AI hallucinations. More often than not, they come from version gaps, when the model simply doesn’t know about recent updates or changes in the library.

The DHTMLX MCP Server is built to reduce that friction. Instead of relying on stale training data, your AI assistant can work with the latest documentation and produce answers that are much closer to what you’d expect in a real project.

It integrates with tools many teams are already using, including Claude Code, Cursor, Gemini CLI, and Antigravity. Once connected, a few things noticeably improve:

• responses stay aligned with the latest DHTMLX documentation
• data retrieval is driven by a high-precision embedding model
• generated code snippets reflect current APIs
• suggestions follow established DHTMLX patterns and best practices
• configuration options and customization details are surfaced more consistently

Another practical detail: the MCP server isn’t limited to a single library. It covers documentation across the entire DHTMLX JavaScript product line. Whether you’re building a project management tool with DHTMLX Gantt or DHTMLX Scheduler, working with diagrams via DHTMLX Diagram, or assembling dashboards with DHTMLX Suite, the assistant can pull in the right context when you need it.

Security is another area teams usually ask about. The MCP server is a hosted service and doesn’t require access to your local files. It also doesn’t collect personal user data, which makes it easier to adopt in environments with stricter requirements.

If you want to try it out, the official starter guide walks through the setup process and shows how to connect the MCP server to your AI assistant. It’s a straightforward way to see how much more reliable AI-assisted development can feel when the underlying context is actually up to date.

Developing web-based project management applications in React can feel deceptively simple until your app needs to handle thousands of tasks, complex dependencies, and live scheduling updates. Developers quickly run into performance bottlenecks: slow initial page loads, complicated state management, and difficulty scaling components efficiently.

This is where combining Next.js and DHTMLX Gantt for React becomes a game-changer. Together, they let teams build responsive, data-intensive project planning tools without reinventing the wheel.

In this guide, we’ll walk through why Next.js is ideal for React projects, how DHTMLX Gantt leverages its strengths, and practical steps to integrate them into a scalable, production-ready application.

Why React Alone Isn’t Enough for Complex Project Tools

React excels at building interactive UIs, but as soon as a Gantt chart needs to display thousands of interdependent tasks, the framework alone doesn’t address core challenges:

• Rendering delays when data sets are large
• Client-side performance bottlenecks
• SEO limitations in fully dynamic pages
• Complex routing and server interactions

Teams often patch these issues with custom tooling, a time-consuming approach that increases maintenance costs. The solution? Next.js, which provides built-in optimizations for these exact pain points.

Next.js: Powerful Performance Layer for React

Rather than simply explaining features, let’s look at a real-world scenario: imagine your Gantt chart displays 5,000 tasks with dependencies and resource assignments. Without server-side assistance, the initial page load can take seconds, frustrating users.

Next.js solves this by enabling:

• Server-side rendering (SSR) for pages that need immediate content
• Static site generation (SSG) for task templates or dashboards that rarely change
• Hybrid rendering to mix static and dynamic pages efficiently

Additional tools — automatic code splitting, image optimization, data prefetching, and caching mechanisms — reduce runtime overhead. Built-in routing and modern dev tooling like Turbopack streamline development, letting teams focus on product logic rather than boilerplate performance hacks.

Over time, Next.js has shifted from an optional enhancement to the default architecture choice for React teams building enterprise applications. Industry surveys, including Capterra’s latest Developer Survey, confirm its widespread adoption alongside React.

Why DHTMLX Gantt Shines in This Environment

While Next.js handles architecture and performance, DHTMLX Gantt for React tackles the complexity of project scheduling itself. Its strengths include:

• Smart rendering for thousands of tasks
• Dynamic loading to keep the interface responsive
• Advanced scheduling features: auto-scheduling, resource assignments, critical path calculation, task grouping and splitting

In practice, this allows project managers to monitor large initiatives efficiently. Combined with Redux Toolkit for state management, it solves the typical performance and complexity challenges of client-side Gantt components.

Importantly, DHTMLX React Gantt integrates seamlessly with Next.js, so you don’t need hacks or workarounds, everything works in a standard React + Next.js setup.

Step-by-Step Integration with Next.js

Getting started with DHTMLX React Gantt in a Next.js project is straightforward, even for developers with basic React experience:

1. Install Node.js if not already installed
2. Create a new Next.js project using npx create-next-app@latest
3. Install the DHTMLX React Gantt package (guide)
4. Prepare demo data for tasks and links
5. Create a Gantt component and embed it in a page
6. Run your app to confirm functionality

Pro tip: Because Gantt relies on refs, hooks, and callbacks, it must be rendered inside a Client Component. Next.js defaults to Server Components, which lack access to browser APIs. The official DHTMLX Gantt tutorial explains this in detail with examples.

For convenience, a starter app on GitHub demonstrates a fully working Next.js + DHTMLX React Gantt integration.

Real-World Benefits

By combining Next.js and DHTMLX Gantt, teams can:

• Deliver highly interactive, responsive dashboards
• Handle large-scale scheduling data without slowing down the app
• Build a scalable architecture that grows with project complexity
• Move quickly from prototype to production, thanks to predictable performance

This pairing allows developers to focus on user experience and business logic, instead of fighting framework limitations.

Conclusion

Creating modern, enterprise-grade project management apps requires predictable architecture, rich UI components, and strong performance. React alone is not enough to manage the demands of data-heavy Gantt charts and complex workflows.

Next.js provides the architectural backbone, while DHTMLX React Gantt delivers the scheduling and visualization features necessary for professional project management tools. Together, they enable teams to build scalable, high-performance applications that work well for both developers and end users.

Following the official integration guide, teams can quickly move from small prototypes to production-ready project management solutions that handle real-world complexities with confidence.

Modern React-based project management applications rely heavily on powerful UI components to support rich user interactions. However, the more functionality these components provide, the harder it becomes to consistently synchronize the interface with frequent user-driven changes and data updates. This issue is especially noticeable in Gantt charts, where moving tasks, modifying links, or changing the timeline can immediately impact multiple parts of the application state. In this context, a well-organized state management approach is critical to maintaining a smooth user experience.

In this article, we’ll explain why DHTMLX Gantt for React pairs effectively with Redux Toolkit when building data-centric Gantt applications, and we’ll share practical recommendations for integrating this setup into your own project.

How DHTMLX Gantt for React Fits Redux Toolkit’s Data Flow

The DHTMLX Gantt component for React is designed to handle complex project scheduling scenarios. It supports everything from basic data operations (creating, editing, and removing tasks or links) and global configuration options (zoom levels, filters, themes) to advanced scheduling features such as critical path calculation, auto-scheduling, and resource management. All of these capabilities are exposed through the API of the DHTMLX JavaScript Gantt, making them accessible during integration into a React application.

In real-world Gantt charts, tasks rarely exist in isolation. A single interaction, like dragging a task or updating a dependency, can cascade into multiple changes across the project timeline. Managing these interconnected updates consistently and predictably requires more than local component state. This is where a dedicated state management solution such as Redux Toolkit becomes especially valuable.

The React version of DHTMLX Gantt satisfies two key conditions that allow it to integrate seamlessly with Redux Toolkit:

• Declarative data handling

The component follows React’s declarative paradigm by receiving all core data — including tasks, links, resources, and configuration options like columns, templates, and themes — through props. When Redux is used, these props can be sourced directly from the centralized store. Any state change in Redux is automatically reflected in the Gantt chart, ensuring that the UI always stays in sync with the application state.

• Event-driven callbacks for user interactions

To propagate user-driven changes back to the store, the Gantt component exposes a set of callback functions that report interaction details. Instead of mutating its internal state, the component notifies the application about updates, allowing Redux Toolkit to process and apply them centrally. This approach reinforces Redux as the single source of truth and keeps state mutations explicit and traceable.

Since Redux Toolkit is built with TypeScript in mind, it’s also worth mentioning that DHTMLX Gantt for React provides full TypeScript support. While optional, strong typing helps reduce integration friction and improves reliability across the entire data flow.

With this foundation in place, let’s take a closer look at why Redux Toolkit is particularly well-suited for React applications built around Gantt charts.

Why Redux Toolkit Is a Strong Choice for React Gantt Applications

Classic Redux is often perceived as verbose and difficult to configure, especially in projects that require multiple reducers, middleware, and third-party helpers. Redux Toolkit was introduced to simplify this experience by reducing boilerplate and providing sensible defaults. For complex interactive components like a React-based Gantt chart, this streamlined approach makes Redux Toolkit a practical and developer-friendly option.

How the Integration Works in Real Projects

When Redux Toolkit is used, all Gantt-related data and configuration are stored in a single centralized state container, divided into logical units known as slices. Each slice represents a specific aspect of the Gantt chart, such as tasks, links, or UI settings.

When a user interacts with the chart — for example, by creating or editing a task — the Gantt component triggers a callback that dispatches an action describing the change. Redux Toolkit processes this action through the corresponding reducer, updates the state accordingly, and then supplies the updated data back to the Gantt component via props. React automatically re-renders the UI to reflect the new state.

For a deeper dive into this mechanism, the official Redux Toolkit documentation provides a detailed explanation of the data flow.

Key Advantages of Using Redux Toolkit with UI Components:

• Single source of truth
  All Gantt data and configuration settings are stored in one Redux store, ensuring consistent state across the entire application and eliminating synchronization issues.
• Transparent and predictable updates
  Redux Toolkit enforces a one-way data flow, making every state transition explicit. This greatly simplifies debugging, especially when multiple interactions affect the same data over time.
• Well-defined responsibilities
  State management logic lives in Redux Toolkit, while the DHTMLX Gantt component focuses solely on rendering and capturing user input. This separation keeps the codebase cleaner and easier to reason about.
• Scalable architecture
  By organizing the state into feature-based slices, Redux Toolkit allows the Gantt application to grow without becoming difficult to maintain. New features can be added incrementally while preserving a clear and structured codebase.

Understanding why DHTMLX Gantt for React and Redux Toolkit work well together is only part of the story. Next, we’ll move from theory to practice and explore how this integration is implemented step by step.

Key Integration Steps for Connecting DHTMLX React Gantt with Redux Toolkit

At this stage, the foundational concepts behind this integration (callbacks, slices, actions, and reducers) should already be familiar. Now it’s time to look at how these elements interact in practice to provide reliable and predictable state management for a React-based Gantt chart. Specifically, we’ll focus on how the Redux infrastructure is assembled (store and slice) and how state updates from different sources are processed consistently.

Building the Redux State Layer

From the Redux perspective, two building blocks define the state management architecture for a DHTMLX Gantt project: the Redux store and the Gantt slice. The store acts as the central repository for all Gantt-related data, while slices encapsulate the logic responsible for modifying that data in response to user interactions and application events.

Together, these elements form a scalable and maintainable foundation for managing Gantt state in React applications.

The first implementation step is creating a centralized Redux store and registering the reducer responsible for handling Gantt-related state. While traditional Redux setups often involve extensive configuration, Redux Toolkit simplifies this process through the configureStore API:

import { configureStore } from '@reduxjs/toolkit';  
import ganttReducer from './ganttSlice';

export const store = configureStore({  
  reducer: {  
    gantt: ganttReducer,  
  },  
});

export type RootState = ReturnType<typeof store.getState>;  
export type AppDispatch = typeof store.dispatch;

The RootState and AppDispatch types are inferred directly from the store instance. These types are later used alongside useSelector and useDispatch hooks to ensure type-safe access to Gantt data and action dispatching within the UI layer.

Defining the Redux Gantt Slice

Next, we describe how Gantt data is stored and updated by implementing a dedicated Redux slice. In this example, the slice manages tasks, links, configuration options such as zoom levels, and undo/redo functionality. Redux Toolkit’s createSlice function is used to define the slice name, initial state, and reducer logic in a concise format. For each reducer, the corresponding action creator is generated automatically.

const ganttSlice = createSlice({
  name: 'gantt',
  initialState,
  reducers: {
    undo(state) {
        ...
    },
    redo(state) {
      ...
    },
    updateTask(state, action: PayloadAction<SerializedTask>) {
      ...
    },
    createTask(state, action: PayloadAction<SerializedTask>) {
      ...
    },
    deleteTask(state, action: PayloadAction<string>) {
      ...
    },
    updateLink(state, action: PayloadAction<Link>) {
      ...
    },
    createLink(state, action: PayloadAction<Link>) {
      ...
    },
    deleteLink(state, action: PayloadAction<string>) {
      ...
    },
    setZoom(state, action: PayloadAction<ZoomLevel>) {
      ...
    },
  },
});

The full implementation of the Gantt slice can be found in the complete DHTMLX Gantt tutorial available in the official documentation.

Key Takeaways from This Setup

• Initial state definition
  The initialState represents the full Gantt data structure stored in Redux and serves as the baseline for all subsequent updates.
• Reducer-driven updates
  Each reducer specifies how the state changes in response to a particular action, including task manipulation, link updates, zoom adjustments, and navigation through state history.
• Auto-generated actions
  Action creators produced by createSlice are dispatched from the UI layer or external controls such as toolbars (covered later).
• Undo/redo support
  State history management is implemented using snapshot-based rollback, enabling straightforward undo and redo functionality.

At this point, the Redux store and Gantt slice together provide a clear, structured mechanism for managing Gantt state. With this foundation in place, the application is ready to handle state updates from both internal Gantt interactions and external UI controls in a consistent way.

Handling Gantt State Updates with Redux Toolkit

Now we reach one of the most practical aspects of the integration: how Redux Toolkit manages state changes coming from different sources. In a React Gantt application, updates can originate either from the Gantt component itself or from external UI elements such as toolbars and controls. Redux Toolkit handles both scenarios using the same transparent and predictable mechanism built around callbacks and props.

Internal updates and external commands follow a single data flow, making all state transitions easy to track and debug.

Processing Internal Changes from the Gantt Chart

Whenever a user edits a task, creates a dependency, or removes an item directly in the Gantt chart, the application needs to capture this event and reflect it in the global state. This communication happens through the data.save callback exposed by the DHTMLX Gantt component.

const data: ReactGanttProps['data'] = useMemo(
 () => ({
   save: (entity, action, payload, id) => {
     if (entity === 'task') {
       const task = payload as SerializedTask;
       if (action === 'update') {
         dispatch(updateTask(task));
       } else if (action === 'create') {
         dispatch(createTask(task));
       } else if (action === 'delete') {
         dispatch(deleteTask(String(id)));
       }
     } else if (entity === 'link') {
     ... //similar logic for links
     }
   },
 }),
 [dispatch]
);

The data.save callback supplies detailed context about each modification, including:

• entity–the type of element being changed (task or link)
• action–the operation performed (create, update, or delete)
• payload–the data associated with the change
• id – the unique identifier of the affected item

Based on the received parameters, the callback dispatches the appropriate Redux action. This approach ensures that all internal Gantt updates are immediately reflected in the centralized Redux store, without relying on local component state.

For a more detailed explanation of the data.save mechanism, refer to the corresponding section in the official documentation.

Syncing the Gantt UI with Redux State

Once Redux processes an update, the Gantt component receives the latest state through props. The required pieces of data (tasks, links, and configuration) are extracted from the store using the useSelector hook:

const { tasks, links, config } = useSelector((state: RootState) => state.gantt);

Any change in the Redux state automatically triggers a re-render, ensuring that the Gantt chart always reflects the current application state without manual synchronization.

With this setup, state updates in a React Gantt application follow a clear and consistent sequence:

Gantt interaction → Redux action → reducer execution → store update → Gantt receives new state → UI re-render

This predictable cycle allows both internal chart interactions and external UI controls to coexist within the same state management model, providing stability and clarity as the application grows.

Controlling the Gantt Chart through an External Toolbar

One of the key advantages of integrating DHTMLX Gantt with Redux Toolkit is the ability to manipulate the chart state from external UI elements. This allows developers to build flexible, feature-rich React project management interfaces while maintaining a single, predictable data flow. Let’s see how this works using a custom toolbar with undo, redo, and zoom capabilities.

Toolbar Setup and Callbacks

The toolbar receives the current zoom level as a prop and exposes callback functions for user actions:

export interface ToolbarProps {  
  onUndo?: () => void;  
  onRedo?: () => void;  
  onZoom?: (level: ZoomLevel) => void;  
  currentZoom?: ZoomLevel;  
}

Whenever a user clicks a toolbar button, the corresponding callback is invoked:

<Button onClick={() => onUndo?.()}>
  <UndoIcon />
</Button>

<Button onClick={() => onRedo?.()}>
  <RedoIcon />
</Button>
// Additional buttons as needed

Connecting Toolbar Actions to Redux

These callback functions are linked to Redux actions, ensuring that the toolbar can update the centralized Gantt state:

const handleUndo = useCallback(() => {  
  dispatch(undo());  
}, [dispatch]);

const handleRedo = useCallback(() => {  
  dispatch(redo());  
}, [dispatch]);

const handleZoomIn = useCallback(  
  (newZoom: ZoomLevel) => {  
    dispatch(setZoom(newZoom));  
  },  
  [dispatch]  
);

Using useCallback for dispatch handlers helps prevent unnecessary re-renders. When an action is dispatched, Redux updates the corresponding slice, keeping the Gantt state in sync with toolbar interactions.

Finally, the Gantt chart is rendered alongside the toolbar:

return (
  <div style={{ height: '100%', display: 'flex', flexDirection: 'column' }}>
    <Toolbar
      onUndo={handleUndo}
      onRedo={handleRedo}
      onZoom={handleZoomIn}
      currentZoom={config.zoom.current}
    />

    <ReactGantt
      tasks={tasks}
      links={links}
      config={ganttConfig}
      templates={templates}
      data={data}
      ref={ganttRef}
    />
  </div>
);

This setup ensures that all state changes, whether triggered by direct chart interactions or toolbar buttons, flow through the same Redux-controlled cycle, maintaining consistency and predictability.

For a complete step-by-step guide, check the official DHTMLX Gantt documentation or explore the working example on GitHub.

Wrapping-Up

Combining DHTMLX Gantt for React with Redux Toolkit creates a clear and reliable state management framework for handling complex project data. Whether changes originate from direct interactions within the Gantt chart or through external toolbar controls, Redux ensures every update is processed consistently and reflected immediately in the UI. This integration allows development teams to build robust React-based project management applications while keeping the user interface decoupled from business logic, promoting maintainability and scalability.

As AI becomes a natural part of modern development workflows, teams are increasingly looking for practical integration patterns, not just generic chatbots. One common challenge is converting free-text user requests into safe, predictable configuration changes for complex UI components. DHTMLX Gantt illustrates this problem well: it exposes a rich set of configuration options and theme variables, but experimenting with different layouts or visual styles can be time-consuming when done manually.

A practical solution is to introduce a thin AI layer that accepts targeted instructions in plain English and translates them into structured configuration updates. The key principle is to keep the configurable surface intentionally small and well-defined, while letting the AI model handle the mapping from natural language to JSON. In this tutorial, you’ll learn how to add such a smart design assistant to an existing DHTMLX-based JavaScript Gantt chart — without rebuilding or refactoring the entire UI.

Demo Overview: Architecture and Interaction Model

This guide is based on the official AI Gantt Theme Builder demo created by the DHTMLX team.

The demo application uses a simple, purpose-driven layout:

• A Gantt chart with project data displayed on the left
• An assistant panel on the right, featuring Chat and Code tabs

This structure encourages experimentation. Instead of editing stylesheets or configuration files directly, users can describe the desired visual changes in plain English and immediately see the results applied to the chart.

Typical requests might include:

• Applying a warmer color palette
• Increasing row or task height
• Making dependency links more visually prominent

The complete demo source code and technology stack details are available in the official GitHub repository.

End-to-End Flow: From User Intent to UI Update

Before diving into implementation, it helps to understand how the system processes a request:

1. A user describes a desired visual or layout change in the Chat tab
2. The frontend forwards the request, along with the current Gantt state, to the backend
3. The backend contextualizes and constrains the request before sending it to the LLM
4. The AI model produces a structured JSON response using predefined tool functions
5. The frontend applies the resulting configuration and styling updates in real time

What makes this flow reliable is the transformation of free-form language into deterministic, executable instructions. This conversion is handled using the OpenAI API (or a compatible LLM) via the function-calling (tool-calling) mechanism.

With that foundation in place, let’s walk through the implementation step by step.

Designing a Frontend Ready for AI Interaction

The frontend’s role in this system is deliberately focused. It does not interpret user intent or make decisions — it simply relays intent, applies validated updates, and reflects changes visually.

Initializing the Gantt Chart and Styling Model

The first step is initializing the DHTMLX Gantt component and configuring its columns, plugins, and helpers in the main.js file:

const gantt = Gantt.getGanttInstance();
gantt.config.columns = [
  { name: 'wbs', label: 'WBS', width: 60, resize: true, template: gantt.getWBSCode },
  { name: 'text', label: 'Task name', tree: true, width: 250, resize: true },
  { name: 'start_date', align: 'center', width: 100, resize: true },
  { name: 'duration', align: 'center', width: 80, resize: true },
  { name: 'add', width: 40 },
];
gantt.plugins({
  auto_scheduling: true,
  undo: true,
  export_api: true,
  marker: true,
  tooltip: true,
});

gantt.config.auto_scheduling = true;
gantt.config.open_tree_initially = true;
gantt.config.auto_types = true;
gantt.config.scale_height = 60;
gantt.config.link_radius = 4;
initZoom(gantt);
fitTaskText(gantt);

DHTMLX Gantt styling is controlled through two complementary layers:

• CSS variables, which define colors, fonts, and visual accents
• The gantt.config object, which controls structural properties such as row height, task height, and link width

Because both layers support runtime updates, AI-generated changes can be applied instantly, without reloading the page or reinitializing the component.

To support incremental changes, the demo keeps track of the current theme and configuration state. New AI-generated values are merged into the existing setup rather than replacing it entirely, ensuring that previous adjustments are preserved.

Note: The demo currently uses temporary message storage. This setup anticipates future support for full conversation history, including user prompts, AI responses, and executed tool calls.

Assistant Interface: Chat and Code tabs

The AI assistant panel is split into two tabs with clearly separated responsibilities.

The Chat tab handles natural-language interaction. It is built on a lightweight, embeddable chat widget that sends user prompts to the backend and displays AI responses.

...
  // Initialize the chat widget with dependencies
export const initChat = ({ socket, runCommand, getTheme, getConfigs }) => {
 
  // Create and set up the chat UI
    const chatWidgetContainer = document.querySelector('#chat-tab');
    chatWidgetContainer.dataset.id = '0';

    chatWidgetContainer.innerHTML = `
      <div id="chat-popup" class="relative left-0 bottom-0 h-full w-full bg-white rounded-md shadow-md flex flex-col transition-all">
        <div id="chat-header" class="flex justify-between items-center p-4 bg-gray-800 text-white rounded-t-md">
          <h3 class="m-0 text-lg">DHX Assistant</h3>
           <button data-micromodal-trigger="modal-1" class="help-btn">?</button>
        </div>
        <div id="chat-messages" class="flex-1 p-4 overflow-y-auto text-base"></div>
        <div id="loader" class="hidden justify-start mb-3">
          <div class="spinner m-auto"></div>
        </div>
        <div id="chat-input-container" class="p-4 border-t border-gray-200">
          <div class="flex space-x-4 items-center">
            <input type="text" id="chat-input" class="flex-1 border border-gray-300 rounded-md px-4 py-2 outline-none w-3/4" placeholder="Type your message...">
            <button id="chat-submit" class="bg-gray-800 text-white rounded-md px-4 py-2 cursor-pointer">Send</button>
          </div>
        </div>
      </div>
   `;
...

The widget configuration can be found in the corresponding demo file. In addition to basic messaging, it can suggest follow-up actions and guide users toward more precise requests.

The Code tab becomes relevant after changes are applied. It allows users to inspect, and optionally refine, the generated CSS variables and configuration values using dedicated editors managed by the ThemeManager.

initEditors() {
    this.initCssEditor();
    this.initConfigEditor();
  }

  initCssEditor() {
    require.config({ paths: { vs: "https://cdn.jsdelivr.net/npm/monaco-editor@0.34.1/min/vs" } });
    require(["vs/editor/editor.main"], () => {
      this.cssEditor = monaco.editor.create(document.getElementById("css-editor-container"), {
        value: this.originalThemeCSS,
        language: "css",
        theme: "vs-dark",
        automaticLayout: true,
        readOnly: false,
      });


      this.setupEditorEvents(this.cssEditor, "css");
    });
  }

  initConfigEditor() {
    require.config({ paths: { vs: "https://cdn.jsdelivr.net/npm/monaco-editor@0.34.1/min/vs" } });
    require(["vs/editor/editor.main"], () => {
      this.configEditor = monaco.editor.create(document.getElementById("config-editor-container"), {
        value: this.originalThemeConfigs,
        language: "javascript",
        theme: "vs-dark",
        automaticLayout: true,
        readOnly: false,
      });

      this.setupEditorEvents(this.configEditor, "config");
    });
  }

The ThemeManager stores both the initial and modified code and applies updates in real time.

setupEditorEvents(editor, type) {
  editor.onDidChangeModelContent(() => {
    const value = editor.getValue();
    this[`editedTheme${type === "css" ? "CSS" : "Configs"}`] = value;


    this.updateButtonsState(type);
    this.applyThemeOnFly();
  });

  document.querySelector(`[data-editor="${type}"].copy-editor-btn`).addEventListener("click", () => {
    this.copyContent(type);
  });

  document.querySelector(`[data-editor="${type}"].save-editor-btn`).addEventListener("click", () => {
    this.saveChanges(type);
  });


  document.querySelector(`[data-editor="${type}"].cancel-editor-btn`).addEventListener("click", () => {
    this.cancelChanges(type);
  });
 }

It also supports Save, Cancel, and Copy actions. When changes are confirmed, they are routed back into the application through the same command execution mechanism used by the AI.

Forwarding User Requests to the Backend

When a user submits a prompt, the frontend sends it to the backend via a WebSocket connection established with Socket.IO:

const SOCKET_URL = import.meta.env.VITE_SOCKET_URL || `${window.location.origin}`;
const socket = io(SOCKET_URL);

Along with the prompt, the frontend includes the current Gantt theme and configuration state:

function sendUserMessage(message) {
  displayUser(message);
   
  const payload = {
    message,
    theme: getTheme(), // sends current theme state
    configs: getConfigs(), // sends current config state
    };
    socket.emit('user_msg', JSON.stringify(payload)); // sends the payload to the backend via WebSocket
}

From this point onward, the backend assumes responsibility for interpretation, validation, and AI interaction.

Backend Logic: Constraining and Interpreting AI Commands

The backend acts as the system’s trust boundary. Its primary responsibility is to ensure that AI-generated output remains safe, predictable, and limited to approved configuration surfaces.

Defining Allowed Styling Operations

Allowing an AI model to generate arbitrary code would be unsafe. Instead, the backend exposes a controlled set of operations, defined as tool functions, using a strict JSON schema.

In this demo, two primary functions are available:

• set_theme — applies updates to CSS variables and Gantt configuration option

{
  name: "set_theme",
  parameters: {
    type: "object",
    properties: {
      variables: {
        type: "array",
        items: { key: "string", value: "string" }
      },
      configs: {
        type: "array",
        items: { name: "string", value: ["number", "boolean"] }
      }
    }
  }
}

• reset_theme — clears custom styling and restores defaults

{
  type: "function",
  function: {
    name: "reset_theme",
    description: "Reset the current Gantt theme by clearing all custom CSS variables and configs (back to defaults).",
    parameters: {
      type: "object",
      properties: {},
      required: [],
    },
  },
},

These schemas are defined in the schemaList.js file included with the demo project.

Building Context for the AI Model

Before calling the LLM, the backend constructs a system prompt that provides the necessary context while enforcing boundaries. This prompt includes:

• A description of all supported CSS variables
• A complete list of available gantt.config options
• The current theme and configuration state
• Explicit rules governing how changes may be applied

This context is generated by the generateSystemPrompt function and assembled into the final request by talkToLLM.

```
const messages = [
  { role: "system", content: generateSystemPrompt(theme, configs) },
  { role: "user", content: request },
];

const res = await openai.chat.completions.create({
  model: "gpt-5-nano",
  messages,
  tools: schemaList,
});
```

Processing Structured AI Responses

The AI model may return:

• A regular assistant message with no actionable output
• A tool call containing structured instructions for modifying the Gantt chart

{
  "tool": "set_theme",
  "variables": [
    { "key": "--dhx-gantt-task-background", "value": "#dce8ff" },
    { "key": "--dhx-gantt-grid-background", "value": "#f9fbff" }
  ],
  "configs": [
    { "name": "row_height", "value": 42 }
  ]
}

When a tool call is present, the backend serializes the instructions and emits them to the frontend via a tool_call WebSocket event.

Executing AI Instructions in the Browser

At this stage, all logic runs entirely on the client side.

The frontend listens for incoming tool_call events and extracts the command payload:

```
socket.on("tool_call", (callJSON) => {
  const { cmd, params } = JSON.parse(callJSON);
  runCommand(cmd, params);
});
```

The extracted instructions are then executed using the runCommand function:

export default function (gantt, { onThemeSet, onConfigSet }, defaultConfigValues = {}) {
  // handlers for commands defined in /backend/schemaList.js
  return function runCommand(cmd, args) {
    switch (cmd) {
      case "reset_theme":
        const themeStyleId = "dynamic-theme";
        const styleEl = document.getElementById(themeStyleId);
        if (styleEl) {
          styleEl.remove();
        }

        if (onThemeSet) {
          onThemeSet([], cmd);
        }
        if (onConfigSet) {
          onConfigSet([], cmd);
          if (defaultConfigValues.length) {
            defaultConfigValues.forEach((config) => {
              gantt.config[config.name] = config.value;
            });
          }

          gantt.render();
        }

        break;
// ... other commands

      default:
        console.warn("Unknown cmd:", cmd, args);
    }
  };
}

This unified command runner ensures that both AI-generated and manually edited updates follow the same execution path.

As a result, the Gantt chart immediately reflects the requested visual or configuration changes, providing instant feedback to the user.

For full implementation details and source code, refer to the official GitHub repository.

Extending the Demo Toward Production Use

The AI Gantt Theme Builder is intentionally minimal, serving as a reference architecture rather than a finished product. If you plan to build on this approach, several enhancements are worth considering:

• Validation
  Introduce strict schema and whitelist checks for CSS variables and configuration parameters, including range and type validation.
• Ambiguity Handling
  Add confirmation steps for vague or potentially conflicting user requests to prevent unintended changes.
• Conversation Memory
  Persist conversation history to give the AI more contextual awareness across multiple interactions.
• Advanced Features
  Preview modes, collaborative editing, exportable theme packages, and richer chat interfaces (voice input, file uploads) can significantly improve usability.

Together, these improvements can turn the demo into a robust environment for AI-assisted configuration and visualization of complex Gantt interfaces.

Final Thoughts

In this tutorial, you’ve learned how to build an AI-assisted Gantt Theme Builder that interprets natural-language prompts and applies visual updates to DHTMLX-based Gantt charts.

This approach can be extended with validation, smarter handling of ambiguous requests, and additional AI-driven features as your project requirements evolve. The underlying pattern — natural language → structured JSON → UI update — is versatile and can be applied to other scenarios, such as switching between calendars, toggling auto-scheduling modes, and applying predefined configuration presets.

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter.

And before you go, don’t forget to clap and follow the writer️!

How to Add AI-Driven Styling to DHTMLX Gantt was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Greetings, developers and JavaScript enthusiasts! We are back to continue sharing the latest achievements of the DHTMLX team and beyond. At DHTMLX, the past month was marked by the release of DHTMLX Diagram 6.1 and three new demo projects. This digest also covers notable industry updates such as Angular 21, Google’s new Antigravity development platform, and React File Manager from SVAR. Plus, we’ve gathered useful resources to deepen your knowledge in various aspects of modern web development.

New Releases and Updates

Introducing DHTMLX Diagram 6.1

The strong data visualization capabilities of our JavaScript diagramming component have proven to be valuable in many industries, including project management. For instance, the planning stage of many projects includes visualizations of team structures (org chart), project life cycle (flowchart), and decision-making logic (decision tree).

We are excited to present the DHTMLX Diagram 6.1 release, which includes a new mode for planning and organizing project delivery using PERT charts. The mode offers a built-in arrangement algorithm and predefined UI elements that streamline the visualization of project workflows with PERT charts. But the most peculiar thing about this novelty is the possibility to synchronize PERT charts with Gantt charts built with DHTMLX for a more complete project presentation.

Another part of this release is dedicated to new configuration options for keyboard hotkeys and shape manipulations in the DHTMLX Diagram editor. On top of that, the release is also notable for numerous live samples illustrating the practical value of the novelties introduced in v6.1. For complete information about this update, check out the release article.

Discovering New Possibilities for DHTMLX Gantt and Diagram with AI

Once you start experimenting with AI enhancements for web development, it becomes enjoyable to see how seemingly tedious tasks become a no-brainer with the help of LLMs. The DHTMLX team is happy to present three new demos that provide intelligent AI assistants to our JavaScript Gantt and Diagram components. The AI Gantt Maker and AI Gantt Theme Builder enhance the capabilities of our flagship product in creating project structures and styling Gantt charts. The AI Org Chart Builder greatly simplifies visualizing company hierarchies of any complexity. Each demo follows a similar interaction model based on transforming natural language commands (prompts) into LLM-based instructions applied to the UI in real time.

SVAR React File Manager Now Available

SVAR UI released a new React File Manager, an open-source file explorer component with a familiar desktop-like interface. It supports all essential file operations, multiple view modes, file preview sidebar, intuitive navigation, and search capabilities.

Built with React 19 and full TypeScript support, SVAR File Manager helps you create a clean UI for navigating and managing file systems on the web. Available on GitHub under the MIT license.

What’s New in Angular 21

We are not the only ones among software vendors taking practical steps towards smooth adaptation to a more AI-affected web development environment. The Angular team has recently presented the 21st iteration of its framework, which now has a stable MCP server, ensuring AI agents have all the context they need for Angular development. Apart from that, the update includes new experimental Signal Forms that provide a reactive approach to form state management with strong type safety. Improved zoneless change detection contributes to better performance and developer experience. Also, Angular developers now have access to a library of headless UI patterns (Angular Aria) and Vitest as a default test runner. More details about Angular 21 are provided in the release article.

Meet Antigravity: New Agentic Development Platform from Google

Google has recently announced the release of its latest solution, Antigravity, an innovative, agent-first IDE designed to expand the horizons of software development with AI technologies. It provides developers with two modes for working with code: the Editor view and the Manager surface.

If the first one is a familiar AI-enhanced code editor, the second one is a real difference-maker that helps Antigravity to stand out. The Manager surface represents a new interface for managing multiple agents that work asynchronously on different tasks across the IDE, terminal, and browser. Agents generate tangible deliverables called Artifacts (screenshots, walkthroughs, browser recordings, etc.) that make it much easier for developers to verify the results of their work. Antigravity also allows agents to accumulate knowledge from previous tasks. The platform has received mixed reviews following reports of security concerns, yet it is too early to make definitive judgments about Antigravity’s future.

Useful Tips and Articles

Overview of Top Scheduler Components for React

When requested to implement complex functionality such as a scheduling calendar, many dev teams reasonably prefer using specialized UI components to speed up the development process. But choosing the right tool for this purpose is a non-trivial task that requires a serious and thorough approach. If that is your case, this blog post offers an overview of popular React Schedulers from DHTMLX, Bryntum, Syncfusion, DayPilot, and FullCalendar. Here, you will learn about the distinguishing features of these components and their licensing/pricing policies, which should help make the right choice.

What Does It Take to Write Effective agents.md Files for GitHub Copilot

Since recently, developers have been given the opportunity to add several custom agents in agents.md files of GitHub Copilot. In other words, it is possible to create a team of helpers for different tasks, from technical writing to QA and security analysis. Sounds like a great productivity booster, but in practice, many agent files do not work as desired because of their vagueness. This post explains how to properly create custom agents based on the analysis of over 2,500 agents.md files across public repos.

Quick Overview of 18 Useful TypeScript Utility Types

When it comes to transforming and manipulating data types in TypeScript, you will certainly need to use utility types. These predefined constructs allow creating new types by altering existing ones, thereby enhancing code readability and maintainability. This video highlights 18 popular utility types and their use case scenarios.

Six Nontrivial Tricks for Working with Chrome’s DevTools

If you think that the Chrome Developer Tools (aka DevTools) have nothing left to surprise you, think again. Most of the online tutorials on DevTools focus on popular features such as Elements, Console Logs, Performance panel, etc., but there is much more under the hood. DevTools also include many lesser-known, but still impactful capabilities, such as monitoring any function, watching DOM elements for changes, recording and replaying user actions, etc. If you are interested in expanding your knowledge about such DevTools features, check out the material (part 1 and part 2) from Rachel Kaufman.

Comparative Table of Over 100 JavaScript Engines

An average web developer can name 3 or 4 popular JS engines. This list will likely include V8, SpiderMonkey, JavaScriptCore, and Chakra. These engines are widely known and used in major browsers and runtimes today. Those who want to delve into the subject and get acquainted with many other JS engines, have a good chance to do that thanks to the JavaScript Engines Zoo project. It provides a large comparative table of known JavaScript engines.

JavaScript News Digest: Latest Innovations, Updates, and Learning Resources was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.