Hi Dan,
> I am intentionally storing and managing own collapse state instead of relying on Daypilot collapse tree due to a technical design decision. Can you please share details?
We are designing a timeline framework. Our framework has shared controller code that is library-agnostic, including the collapse logic. The controller logic will be mapped to specific props at the library level. For example, we have a `getIsExpanded(id)` that can be mapped to `resource > expanded` field.
Our team has a big codebase that for some reason uses multiple libraries for timeline. At some point, we will migrate everything to 1 library that matches our use cases (hopefully it is Daypilot), but we don’t have the capacity to do so at this point.
Here is a high level design:
TimelineFramework (React Component)
-> Controller (React hook > that stores collapse state and actions that collapse/expand etc..)
-> Daypilot React Scheduler (gets the collapsed state and callbacks from Controller above)
-> Another React timeline library (gets the collapsed state and callbacks from Controller above)
-> Another React timeline library Nth (gets the collapsed state and callbacks from Controller above)
Since the controller level already provides all the necessary collapse logic, we won’t need to rely on, nor copy/extract, Daypilot’s internal collapse state.
> The drag and drop operations are not designed to survive an update of the Scheduler. Your code invokes an update by creating a new copy of resources dynamically during row moving. To avoid this problem, this new row.collapse() method implements a safe update of the tree state.
I see. I have tried both approaches:
-
Calling only `scheduler.rows.collapse()`: The scheduler flashes but the UI isn’t reflected with the latest collapse state, assuming this is because react state isn’t updated. The row move is successful without error.
-
Calling both `scheduler.rows.collapse()` and react state update setter: UI is reflected with the latest collapse state, but shows error (as seen the screen recording above) when dropping the row.
I am still looking for a solution where the UI gets reflected with the latest collapse state and row is successfully moved without throwing an error. Maybe a `onRowMoveBegin` as described below might work.
> Yes, you are right - it won’t be reset. I tried to suggest a solution that is as simple as possible. That included dropping activeMovedRowIdRef. My understanding was that it was only needed for the collapse logic. If you need it for something else as well, please let me know.
For sure. If we can’t reset activeMovedRowIdRef once the row move session ends, the immediate next time the same row gets moved, activeMovedRowIdRef will contain the id of this row, meaning the collapse siblings call won’t be triggered.
if(activeMovedRowIdRef.current !== args.row.id) { // -> The id is the same
collapseSiblings(args.row.id); // -> This won't be called because
activeMovedRowIdRef is never reset.
activeMovedRowIdRef.current = args.row.id;
}
Our drag and drop flow is as follows:
-
User presses and hold onto the remove move handler/icon
-
Because `onRowMoving` is being called continuously as position changes, we keep track of `activeMovedRowIdRef`.
- If it’s a new row move session, we collapse its siblings and assign `activeMovedRowIdRef` the current row’s id.
- This is to avoid continuously calling `collapseSiblings` while moving the same row to a new position.
-
Once user drops the row, reset `activeMovedRowIdRef` inside `onRowMove`. This step won’t be completed if user drops outside of the scheduler.
———
Bottom line is we are unable detect when a row move session begins with just `onRowMoving`.
I am looking for something like a `onRowMoveBegin` that is triggered only once before the move session truly begins, and it should update the Scheduler, if necessary, before starting the row move session.
// Called (before `onRowMoving`?)
onRowMoveBegin(args){
// No need to track `activeMovedRowIdRef`
// Scheduler updates state before beginning a new row move session
setCollapseState(args.row.id);
}
Our product deals with potentially very deeply nested tree with hundreds of resources, so collapsing sibilings before moving the row is required for UX enhancement purpose.