Skip to main content

Common mistakes

These are the errors agents make most often with Bryntum, drawn from real integrations. Installing the skill and MCP server prevents most of them — but it's worth knowing what to look for when you review an agent's code.

CSS and theming​

Using SASS/SCSS​

Bryntum 7+ ships plain CSS only. Agents trained on older examples reach for .scss imports or @use. There is no SASS build step.

Importing only the theme​

A theme file like svalbard-light.css is not enough on its own. It must be paired with the structural {product}.css, and {product}.css must come first.

/* Correct order */
@import "@bryntum/grid/fontawesome/css/fontawesome.css";
@import "@bryntum/grid/fontawesome/css/solid.css";
@import "@bryntum/grid/grid.css";          /* structural — first */
@import "@bryntum/grid/svalbard-light.css"; /* theme — after */

Legacy single-file theme imports​

grid.stockholm.css and friends are the old v5/v6 format. Don't use them in v7+.

Forgetting FontAwesome​

Icons are no longer auto-bundled. Without the FontAwesome imports, the UI renders with missing glyphs.

Trying to set --b-font-family​

This variable does not exist. To change the font, override Bryntum's hardcoded value directly:

.b-widget { font-family: 'Poppins', sans-serif; }

Packages​

Hallucinated versions​

Agents invent versions that don't exist. Pin an exact, real version (e.g. 7.2.0) — no ^ ranges.

Missing the trial alias pattern​

Trial packages need the npm alias so imports stay standard:

npm install @bryntum/scheduler@npm:@bryntum/scheduler-trial@7.2.0

Note: framework wrappers (@bryntum/scheduler-react, etc.) have no -trial suffix — they install directly at the same version.

API hallucination​

The single biggest source of broken code: agents confidently use config options, methods, and events that don't exist or were renamed. The fix is the MCP server — instruct the agent to look up anything it's unsure about rather than guessing from memory.

Also watch for kebab-case class names: it's .b-button-group, not .b-buttongroup.

Sizing​

Bryntum components default to 100% width and a 10em minimum height. Agents often forget the component needs a sized parent, so it renders as a thin strip:

#app {
  margin: 0;
  display: flex;
  flex-direction: column;
  height: 100vh;
}

Framework wiring​

Angular​

New config properties must be bound in the template, not just set in the class:

<bryntum-scheduler [columns]="schedulerProps.columns!"></bryntum-scheduler>

React​

Pass config as JSX props; use a useRef to reach the underlying instance for imperative calls.

Mixing patterns​

Agents sometimes blend vanilla instantiation (new Scheduler({...})) with a framework wrapper. Pick one: the wrapper for React/Angular/Vue, the class for vanilla JS.

Backend / CrudManager​

If the project has a backend, these bugs are common and subtle:

  • Wrong HTTP verbs — loadUrl uses GET, syncUrl uses POST.
  • Phantom IDs persisted to the database — new records arrive with $PhantomId strings. Insert events first, build a phantom→real ID map, resolve references, and return the mapping in the response.
  • Overwriting fields on partial sync — Bryntum only sends changed fields in updated arrays. A fixed UPDATE ... SET col1=?, col2=? statement will null out untouched columns. Build the SET clause dynamically.
  • exceptionDates set to null — it must be [].
  • allDay stored as 0/1 — convert SQLite integers back to booleans in the load response.
  • Vite proxy race — start the backend before Vite, or /api requests return Vite's HTML fallback instead of JSON.

Review checklist​

Before accepting an agent's Bryntum work:

  • Plain CSS, no SASS
  • FontAwesome + structural {product}.css + theme, in that order
  • Exact, real package version with the trial alias if using trial
  • Component has a sized parent
  • Framework wrapper used consistently (no mixed patterns)
  • Config/API names verified against the MCP server, not invented
  • Backend: correct verbs, phantom-ID handling, dynamic partial updates