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

Direct answer

Prefer declarative class bindings driven by the framework's state. Bind is-active from a single boolean such as isOpen, and reserve imperative ref toggling for rare cases where code outside the framework owns the element. This keeps one source of truth and prevents Bulma's CSS from falling out of sync with the component lifecycle.

Assumptions

This assumes a React, Vue, or Svelte SPA using Bulma 0.9.x or 1.x, where Bulma supplies only CSS and the framework owns visibility. If a third-party Bulma JavaScript plugin also toggles is-active, the two writers will conflict regardless of the binding method.

Confirmed facts versus likely explanation

Confirmed: Bulma ships no JavaScript, so modal, dropdown, and tab visibility depends entirely on classes such as is-active. Reactive frameworks reconcile the DOM from state, so declarative binding makes the DOM a pure reflection of that state.

Likely explanation: Imperative toggling through refs works for isolated clicks, but during rapid updates the framework's next render can overwrite manually set classes. During server-side rendering hydration, client-side imperative changes before hydration completes can cause class flicker or hydration mismatches.

Sub-question answers

1. Focus trapping and keyboard navigation with declarative bindings

Bulma's CSS does not manage focus, ARIA attributes, or keyboard behavior. After the framework applies is-active, run focus management in a lifecycle hook that executes after mount and after isOpen changes—for example, useEffect in React, onMounted in Vue, or onMount in Svelte. Ensure the modal or dropdown node exists in the DOM before attaching listeners or moving focus. Conditional rendering or a portal can guarantee DOM presence before the hook runs.

2. State divergence risk from imperative toggling

Yes. Refs bypass the framework's reconciliation cycle. If a rapid state update triggers a re-render while a ref-based handler is pending, the framework may restore the class derived from state and overwrite the manual toggle. With SSR, the server HTML reflects server state; imperative client toggles before hydration can produce a mismatch between the hydrated DOM and the client's first render, causing flicker or a hydration error. Declarative bindings eliminate this because the class is computed during every render pass.

3. Controlled component wrapping patterns

Community practice wraps Bulma markup in a framework component that accepts isOpen or value and conditionally renders is-active. The wrapper centralizes ARIA attributes, focus management, and class logic so consumers treat it as a controlled component. Example pattern:

function BulmaModal({ isOpen, onClose, children }) {
  return (
    
      
      {children}
      
    
  );
}

Implementation steps

1. Declare one source of truth for visibility, such as const [isOpen, setIsOpen] = useState(false).
2. Bind is-active declaratively from that state on every render.
3. Add keyboard and focus handlers in a lifecycle hook that runs after mount and when isOpen changes.
4. If using SSR, render the same class on the server so the hydration payload matches the client's initial state.
5. Verify with rapid toggles and a screen reader or accessibility inspector that focus and ARIA behave as expected.

Diagnostic detail

If you are using server-side rendering with hydration, imperative toggling can cause hydration flicker before the client takes over. This does not change the core recommendation, but it raises the risk of manual DOM writes.