Changelog v1.0.36 — Per‑instance isolation & teardown

Date: 2025-10-16
Build: 1.0.36+2268

Each rendered calendar now has its own runtime context and event store by default. No more cross‑page “bleeding” when navigating in Nuxt/Vue — unless you explicitly opt into sharing by reusing the same singletonId.

🆕 Added

1) Per-instance context singletonId)

All internal singletons and the runtime FullSchedulerOptions are namespaced by singletonId.

• Omit the prop to get automatic isolation (a unique id is generated).

• Pass a fixed singletonId to share lifecycle/state across multiple calendars if you want that behavior.

    <FullScheduler :full-scheduler-options="opts" />                 <!-- isolated (auto id) -->
<FullScheduler :full-scheduler-options="optsA" singleton-id="A"/> <!-- shared between A's -->
<FullScheduler :full-scheduler-options="optsB" singleton-id="A"/> <!-- shares with A -->

  

2) Deterministic teardown

New destroy helpers are called on component unmount:

• destroyCalendarEventsManagerSingleton(id)

• destroyConfiguablesSingleton(id) / destroyConfigurablesGettersSingleton(id) / destroyConfigurablesSettersSingleton(id)

• destroyEventDragHandlerApiSingleton(id) / destroyEventResizeHandlerApiSingleton(id) / destroyMouseTimeHandlerApiSingleton(id)

• destroyThemeSingleton(id)

• FullSchedulerOptions.destroySingleton(id)

This prevents cross-route residue and memory leaks.

3) Prop is forwarded to child pieces

singletonId is passed through to: FullSchedulerMouseTime, FullSchedulerResizer, VirtualScroller, and FullSchedulerEventContainer to keep the whole tree scoped.

🔧 Improved

Safe defaults

The Vue wrapper now generates a unique singletonId generateUniqueString()) when none is provided and wires it through all composables automatically.

API signatures

Internal composables accept { singletonId }.
FullSchedulerOptions.registerSingleton/getSingleton/destroySingleton now require an explicit id. The top‑level component keeps this backward‑compatible by auto‑supplying one.

🐛 Fixed

Event bleed across routes / tabs

Calling addEvents no longer appends items from a previous page. Each calendar maintains its private event store, unless you intentionally reuse the same singletonId.

🧭 Migration guide

• Typical usage: No action needed. The component isolates itself by default.

• If you intentionally want a shared lifecycle/state: pass the same singleton-id string to the calendars you want to couple.

• **If you consume internal composables directly:** add the singletonId parameter and, on unmount, call the matching destroy*Singleton(id) helpers.

📌 Meta

• Scope: runtime options, composables, teardown, Nuxt/Vue navigation behavior

• Breaking changes: none for standard component usage; internal composable signatures gained singletonId.