Background

In our recent "modernize Angular split" PR, we encountered significant issues with the existing collapse/expand feature, particularly when collapsing to a non-zero value. This behavior is not intuitive for a split library. Consequently, we propose developing a true snap feature from the ground up, leveraging the enhancements from the "modernize" PR for easier maintenance.

Community Input

We seek feedback from the community on the following:

• How do you currently use the collapse/expand feature?

• Would a snap feature better serve your needs?

• What are your use cases for collapsing to a non-zero size?

• Will this proposal meet your requirements?

High-Level Proposal

Our snap feature aims to:

1. Function independently without requiring state synchronization by the developer.

2. Provide easy state-saving mechanisms when needed.

3. Support both visible and @ifbased snapping.

4. Facilitate the restoration of a snapped area to its pre-snap size (likely requiring state management).

5. Adhere to maxSize and lockSize constraints.

6. Allow configuration of snap feature enablement.

The proposed snap feature will emulate the snapping behavior of VS Code. When dragging an area with a defined minSize, it will snap when the pointer reaches half of the area size. At this point, the gutter remains visible, implying the area has zero size. If the pointer moves past half the area minSize towards expansion, the area snaps back to the minSize and grows from there. Releasing the pointer at the snap position commits the snap, similar to current size changes.

Upon snapping, the area's visibility will automatically be set to false internally. Developers can choose to update their visible state or remove the area using @if.

Notable changes

The current event SplitGutterInteractionEvent will change in the case of drag end to a more specific event (SplitGutterDragEndEvent) containing two important properties to describe the snap.

1. snapAwareSizes - As the area visibility changed to false, the regular event’s sizes array will include less elements than before. This new property will describe the new sizes array while maintaining the snapped area size. In every drag end event with no snap involved - the sizes array and the snapAwareSizes will be the same.

2. snappedAreaIndex - This will be the index of the area that snapped. In every drag end event with no snap involved - the snappedAreaIndex will be -1.

For example:

Considering a percent based split with the following area sizes: [40, 20, 40], the user snaps the first area. At this point the sizes array on the drag end event will be [60, 40] as the first area snapped. But, snapAwareSizes will be [40, 60, 40] to allow the same index access and the old area size if needed and snappedAreaIndex will be 0.

Request for Feedback

We believe this behavior will provide a good alternative to the old collapse feature and will allow the developer the freedom to choose how to handle the snap that occured.

We value your insights and feedback on this proposal. Please share your experiences and thoughts to help us refine and implement a feature that best meets the community's needs.