Skip to content

feat(kanban): add pre-card-change hook to intercept drag/drop transitions #665

Description

@diyor28

Summary

Add an optional pre-card-change hook to the scaffold kanban component so application code can inspect a drag/drop transition and cancel the default HTMX post when a custom flow is needed.

Problem

The current kanban component always posts the card change immediately after drag/drop. That works well for simple status transitions, but some transitions need extra user input before they can be completed.

A concrete example is EAI CRM Kasko requests:

  • moving a card from draft or rejected to waiting-approval should not silently change status
  • the user must first choose/upload files and submit through a form flow

Today this can be implemented at the page layer by intercepting the outgoing HTMX request, reverting the card in the DOM, and opening a drawer. That works, but it is not the cleanest long-term integration point.

Proposal

Add a small extension point to kanban card changes, for example:

  • optional BeforeCardChange hook / callback
  • hook receives cardKey, oldCol, newCol, oldIndex, newIndex
  • hook can allow default behavior or cancel it
  • if canceled, app code can run a custom flow such as opening a drawer/modal/form

Why this helps

  • avoids page-specific request interception hacks
  • avoids manual DOM rollback in app templates
  • keeps drag/drop extension behavior close to the kanban component itself
  • makes advanced workflows reusable across modules

Requirements

  • existing behavior should remain the default
  • no breaking changes for current kanban consumers
  • should still support the current HTMX-based post flow when no hook is configured

Example use cases

  • open upload drawer before allowing a move
  • require confirmation before entering a sensitive status
  • block unsupported transitions on the client with a custom message
  • route some transitions to custom forms instead of direct state change

Context

This came up while adding kanban boards in EAI CRM for SOS, Kasko requests, and payouts. SOS and payouts can use direct transitions, but Kasko has one transition that requires additional form input, which exposed the missing extension point.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions