Manual DOM class toggling versus reactive state binding for Bulma interactive components

Context

Bulma provides interactive component structures—modals, dropdowns, tabs—entirely through CSS classes such as is-active. Because the framework ships without JavaScript, every state change must be reflected in the DOM by the consuming application.

Constraint

A single-page application built with a reactive framework (React, Vue, Svelte) already owns the source of truth for component visibility. The developer must decide whether to let the framework drive Bulma classes directly through declarative bindings or to imperatively toggle classes via refs and effect hooks.

Goal

Determine which approach yields a maintainable synchronization boundary between the framework's state layer and Bulma's CSS-only expectations without introducing duplicate state or timing mismatches.

Questions

1. When using declarative class bindings, how do you handle Bulma components that expect immediate DOM presence for focus trapping or keyboard navigation?
2. Does imperative toggling via refs create a measurable risk of state divergence during rapid updates or server-side rendering hydration?
3. Are there documented patterns in the Bulma community for wrapping native components so the framework treats them as controlled components?