Resource Planning Board

A planning board is not a dashboard. A dashboard reads; this one writes. The schedule above can be changed from two places at once, by dragging a bar on the timeline or by retyping a cell in the table, and the third panel is recomputed from whatever the other two left behind.

That single difference, edits flowing back into the data rather than out of it, changes almost every decision in the wiring. The sales analytics dashboard is the read-only version of this problem and its central device, a re-entrancy guard, turns out to be unnecessary here. This page is about what replaces it.

Everything below was measured against apexgantt 3.18.1 and apex-grid 3.5.0 in a browser rather than read out of the type definitions.

Why can the Gantt not be the source of truth?

Because it will not give the tasks back.

There is no getTasks() on the instance. getState() exists, and it returns the UI state only: zoom, scroll position, collapsed rows, selection, sort, filter rules, column widths and order. Not one task.

Object.keys(gantt.getState())
// ['version','zoom','scroll','collapsed','selected',
//  'sort','filterRules','quickFilter','group','columnWidths','columnOrder']

So when a reader drags a bar, the new dates exist in exactly one place: the event payload. The handler either copies them somewhere durable or they are gone, and the next thing that re-renders the component will quietly put the bar back where it started.

That forces the shape of the whole application. One array is the truth, both components are views over it, and every edit is a write to the array followed by a repaint. The Gantt is never asked what it thinks the schedule is.

let tasks = [ /* the only copy that counts */ ]

function commit(label, mutate) {
  const before = structuredClone(tasks)
  mutate()
  undoStack.push({ label, before, after: structuredClone(tasks) })
  redoStack.length = 0
  repaint(label)
}

Why is there no re-entrancy guard?

The read-only dashboard needs one because setting a selection in code makes the component emit the same event a user click emits, so the first click ping-pongs. Write-back looks like it should be worse: two components, both writing to each other.

It is not, and the reason is worth measuring rather than assuming. Neither product's write API raises the event its own user gesture raises.

Action	What the Gantt emits	What the grid emits
User drags a bar	taskDragged, then historyChange	nothing
gantt.updateTask(id, {...})	historyChange only	nothing
User edits a cell	nothing	cellValueChanging, then cellValueChanged
grid.data = rows	nothing	nothing at all

taskDragged, taskResized and cellValueChanged are therefore user-only signals. A repaint cannot come back as an edit, so there is no loop to guard against and no applying flag anywhere in this app.

That is a property of these two libraries, measured on these two versions, not a general law. It is also the kind of thing to re-check rather than inherit: the map component in the other showcase does echo, which is exactly why that page needs the guard this one does not.

Which undo stack wins?

Both products ship one, and their defaults disagree.

	Records by default	Option
ApexGantt	Yes	history: { enabled: false }
ApexGrid	No	editing: { history: { enabled: true } }

Left alone, you get an undo that works for half the edits: drag a bar and the Gantt can undo it, retype a cell and nothing can. Worse, a single commit in this app touches both components, so two independent stacks would record two entries for one user action and then disagree about which to pop first.

The deciding detail is that the Gantt's historyChange payload carries no task id:

{ kind: 'undo', canUndo: true, canRedo: true, undoSize: 2,
  redoSize: 1, topUndoLabel: 'Update task t2', timestamp: 1790702324564 }

A label, not an identity. Combined with the absence of getTasks(), an undo performed inside the Gantt is unresyncable: you know something changed, you cannot find out what, and you cannot read the result. So both built-in stacks are switched off and history lives over the model, where one entry means one user action and undoing is just swapping the array back.

One measured wrinkle. Disabling the Gantt's history does stop the recording, undoSize stays at 0 and canUndo() stays false, but historyChange still fires on every mutation with kind: 'record'. A toolbar wired to that event has to read canUndo off the payload rather than treat the event itself as proof that something was recorded.

Where do you reject a value the user typed?

Before it is written, and there is exactly one opportunity.

cellValueChanging.data is documented as a live reference to the row object inside grid.data, and it is: the grid writes the new value into that object in place. Since the app seeds grid.data from the model, the row the grid is holding and the row the model is holding are the same object, which is convenient until you want to refuse an edit.

// Measured: the row in grid.data IS the model's row object.
grid.data[0] === tasks[0]          // true
grid.data[0].progress = 99
tasks[0].progress                   // 99

By the time cellValueChanged fires, the value is already in the model. So validation belongs in cellValueChanging, which is cancellable:

grid.addEventListener('cellValueChanging', (e) => {
  const { key, newValue } = e.detail
  if (key === 'assignee' && !(newValue in TEAM)) {
    e.preventDefault()   // rolls the candidate back, editor stays open
  }
})

Type a name that is not on the team and the board says so instead of silently creating a fourth person with no capacity.

What does each product actually do here?

The division is by job, not by data. All three are looking at the same array.

Product	Owns	Never does
ApexGantt	Time. Bars, dependencies, dragging and resizing. Its task list is cut to a single label column through columnConfig so it is not a second table.	Hold the schedule. It is repainted from the model, never queried for it.
ApexGrid	Typing. The editable columns, validation, and the tabular read of the same tasks.	Own its own history, or keep a private copy of a row.
ApexCharts	Derivation. Person-days per week against a capacity line, recomputed on every commit.	Store anything. Delete the chart and no information is lost.

The capacity line is the clearest statement of that last row. It is not a field on a task; it is CAPACITY, a constant, compared against a number the app adds up from dates at repaint time. Nothing persists it, so nothing can disagree with it.

What one edit costs

A repaint could rewrite every task on every commit. This one diffs first, so a drag produces a single call:

const painted = new Map(tasks.map((t) => [t.id, viewKey(t)]))

for (const t of tasks) {
  const key = viewKey(t)              // start|end|progress|assignee
  if (painted.get(t.id) === key) continue
  painted.set(t.id, key)
  gantt.updateTask(t.id, { /* ... */ })
}

Seeding painted from the series the Gantt was constructed with is what keeps the first repaint from being a storm of no-op writes. The grid is different: grid.data is reassigned wholesale every time, because the component diffs its own rows and, as measured above, the assignment raises no events.

One thing updateTask will not tolerate is an unknown id. It throws Task with ID <id> not found rather than ignoring it, so adding or removing a task means re-rendering the Gantt, not calling updateTask in a loop and hoping.

Installing the three

npm install apexgantt apex-grid apexcharts

import ApexGantt from 'apexgantt'
import 'apex-grid/define'      // registers <apex-grid>
import ApexCharts from 'apexcharts'

ApexGantt.setLicense('YOUR-KEY')

Only ApexGantt needs a key. The grid is a custom element, so it is registered by importing rather than constructed, and the chart is constructed against a DOM node in the usual way.

Which plans cover this?

Product	Plan
ApexCharts.js	Community and up, so covered by the under-$2M waiver
ApexGrid	Community and up, same
ApexGantt	Premium and up

ApexGantt is the one that sets the floor for this application. Community is the entry plan and is free for organizations under $2M USD in annual revenue; at or above that it is a paid licence like the others. Nothing in the family is open source, and source published on GitHub is not an open licence. All three render in full without a key, watermarked, so the board above can be rebuilt on your own data before any of that matters. The pricing page has the matrix.

The read-only version of this problem, where the guard is the whole story