Our pure JavaScript Scheduler component


Post by simpl2 »

Hi Bryntum team,

I'm currently in the middle of migrating our app from Bryntum v6 to v7 — and it's been a pretty painful journey so far. This particular bug cost us a lot of debugging time because it's very difficult to reproduce consistently. It only manifests under specific conditions (certain data volume, reduced row height, multiple collapsed groups restored on init), I almost pushed this into production before spotting the error in the console during final checks.

In v6, our group collapse/expand persistence worked flawlessly. After upgrading to v7.2.2, the same code path crashes during initialisation.

I've put together a minimal reproduction project (based on the official vue-3-vite/basic example) with demo data that reliably triggers the bug. The data structure mirrors our production setup.

Version

  • Bryntum SchedulerPro: 7.2.2
  • Framework: Vue 3 + Vite

Summary

TypeError: Cannot read properties of undefined (reading 'bottom') is thrown in RowManager.insert() when programmatically collapsing groups via features.group.toggleCollapse() after setting resourceStore.data.

Once the error is thrown, group collapsing/expanding stops working entirely. The scheduler gets into a broken state where clicking group headers no longer toggles them. The only way to recover is a full page reload and resetting the persisted data. From a user perspective, this means the scheduler becomes unusable until they clear their browser state.

Our Use Case

We persist the scheduler's UI state (collapsed groups, row height, sort order) and restore it when the user navigates back. This is a standard pattern — nothing exotic. On initialization:

  1. Scheduler is created and painted
  2. resourceStore.data is populated with resources (89 across 7 groups)
  3. rowHeight is restored from persisted settings (e.g. 40px instead of default 50px)
  4. Previously collapsed groups are restored by calling features.group.toggleCollapse(groupId, true) for each persisted group

This worked in v6. In v7, it crashes.

Reproduction

A full reproduction project is attached.

  1. npm install && npm run dev
  2. Change row height to MIDDLE (40)
  3. Collapse "Keine Gruppe" (53 resources)
  4. Click "Navigate Away & Back" (simulates route navigation — destroys and re-creates the scheduler)
  5. Open the browser console — observe:
TypeError: Cannot read properties of undefined (reading 'bottom')
    at RowManager.insert (schedulerpro.module.js)

Workaround

The Grid base class defaults include transition: { toggleGroup: true }
Disabling the group toggle animation prevents the buggy RowManager.insert() path:

// In scheduler config:
transition: {
    toggleGroup: false
}

This removes the collapse/expand animation for all group toggles, which is acceptable as a temporary workaround but not ideal for UX. Also, this may just be a lucky shot that works for our current data setup — we can't guarantee it won't break with a different number of resources or groups.

Is there a recommended way to save and restore group collapse state? Should we be using a different API for this, or handling it at a different point in the scheduler lifecycle?

Also — would a Tree structure (with parent/child resource hierarchy) be better suited for our use case?
Any guidance would be greatly appreciated!

Thank you for looking into this. Happy to provide any additional information needed.

Attachments
group-collapse-basic.zip
(411.91 KiB) Downloaded 135 times

Post by mats »

Sorry to hear about the painful upgrade to v7. Did you encounter more problems than the bug you mention above? We'd be very interested in any feedback you can share (lacking upgrade help docs, bugs, CSS issues etc).

The bug you mention is already fixed btw, and slated for next patch release. https://github.com/bryntum/support/issues/12907


Post by simpl2 »

Hi Mats,

Thank you for the quick response , and great to hear the bug is resolved.

Could you share an estimated release date for the next patch? Our development pipeline is currently blocked on this migration. Any timeline would really help us plan on our side.

Other Migration Troubles

Since you asked for broader feedback, i'll try to scratch a few things from the top of my mind.

What went good

Basically the CSS theming refactoring, well documented, fully migrated by Claude Code. Also we coulde reduce a lot of our custom styles.

What broke instantly

The bellow points required manuall/agentic inestigation to discover the gaps - not documented breaking changes.

  • eventStore must now live inside project - In v6 we configured eventStore (with lazyLoad, modelClass, removeUnassignedEvent, etc.) as a top-level scheduler prop. In v7 this silently stops working

  • ViewPreset header renderer TypeScript mismatch - The v7 .d.ts declares the header renderer callback as (data: object) => void, but at runtime Bryntum still passes positional args (startDate, endDate, cellData, index) - same as v6. We had to add @ts-expect-error to keep our custom header renderers working. The docs are lying too - https://bryntum.com/products/schedulerpro/docs/api/Scheduler/preset/ViewPreset#defining-custom-header-rows

  • Filtering/sorting/grouping flow broke - toggleCollapse now returns a promise In v6, collapsing groups was synchronous and order-independent. In v7, calling collapse before sort or filter completes, caused crashes. We had to carefully reorder our initialization: sort first, then await collapse, and add try/catch guards.

What still blocks us

  • Row height change + virtual rendering - Dynamically switching row heights (we have LOW/MIDDLE/HIGH presets) now requires extra care. In v7, after changing row height, the virtual renderer might remove grouping or cut off some resources. We had to add scrollToTop() before applying height changes to work around this and trigger resources re-render, saves us in 95% cases

  • Events permanently removed after resource filtering - This one is heavy. Filtering out some resources - whether via the built-in column filters or our custom resource-type/group filters - occasionally removes events from the scheduler permanently. Resetting the filters brings back the resources, but the events are gone. We don't have a clear reproduction yet, but it happens consistently enough.


Post by alex.l »

Could you share an estimated release date for the next patch?

We release every 2-3 weeks.

eventStore must now live inside project

Should be working
https://bryntum.com/products/schedulerpro/docs/api/SchedulerPro/view/SchedulerPro#config-eventStore

What steps to reproduce this?

ViewPreset header renderer TypeScript mismatch

https://github.com/bryntum/support/issues/12922

Filtering/sorting/grouping flow broke

This is another problem with toggleCollapse? Steps to reproduce?

Events permanently removed after resource filtering -

Did you report this before? Any steps to reproduce in our demos?

All the best,
Alex Lazarev

How to ask for help? Please read our Support Policy


Post by mats »

@simpl2 Thanks for the extensive feedback. If there's any way you can share code and/or test cases for the blockers you encountered during upgrade, we'd make it our top prio to get them fixed.


Post by simpl2 »

alex.l wrote: Thu Apr 02, 2026 6:52 pm

Did you report this before? Any steps to reproduce in our demos?

Not reported, these issues are fresh in our setup, encountered during the migration.

Cannot reproduce in demos. Our setup is quite complex: we have up to three different schedulers in the view with different configurations (switching on the fly), as well as filters, groups and lazy loading. I assume that a combination of configured features and loaded data may cause the above issues under specific circumstances.

Nevertheless, I can demonstrate disappearing events to you! The demo is attached: you need to zoom out (one level should be enough) and klick on "Navigate Away & Back" - the events will disappear.

It's not exactly what i'm facing in our set up, but might be related, and seems like a bug too.

For this issue, I suggest waiting for the patch release and then reporting back. Regarding other issues, I'll try to provide more reliable reproductions and report them in separate tickets.

Attachments
basic.zip
(38.3 KiB) Downloaded 112 times

Post by alex.l »

Hi,

Thank you for the report and clear description! Here is a ticket to track the status: https://github.com/bryntum/support/issues/12956

Anything else we could help you with?

All the best,
Alex Lazarev

How to ask for help? Please read our Support Policy


Post by simpl2 »

Hi team,

thanks for looking into this!

We've just updated to v7.2.3 and can confirm the group-collapsing bug is still present. You can download the first attached repro, bump Bryntum to 7.2.3, and follow the reproduction.

Could you confirm this is the same bug you were targeting in the referenced GitHub issue?


Post by alex.l »

Hi,

Could you please review the screencast and validate if I did something wrong following your steps to reproduce? I do not see errors in console. But "Middle" btn is pre-selected when I reset state, so it might require to do something else?

Attachments
Screen Recording 2026-04-10 at 19.55.20.mov
(16.6 MiB) Downloaded 87 times

All the best,
Alex Lazarev

How to ask for help? Please read our Support Policy


Post by simpl2 »

Hey Alex,

I had to test it on different devices before I could reproduce the bug. Since we're dealing with a virtual scrollbar here, the conditions have to be met very precisely. The window height is crucial in this case.

In my instance, I can easily reproduce the bug with a window hight of 1289px in the Chrome browser. If I make the window a little smaller, the error doesn't occur in the console. Maybe you should test it with this window height as well.

I have attached a recording showing the issue in Safari. Also, the Claude Code investigation included in basic reproduction might be helpful to spot the bug.

Attachments
Screen Recording 2026-04-13 at 08.20.06.mov
(2.36 MiB) Downloaded 76 times

Post Reply