Splitter: size of panes should be updated taking into account their limitations on splitter resize#32862
Conversation
There was a problem hiding this comment.
Pull request overview
Updates Splitter’s dimension-change handling so pane sizes/layout are recalculated in a way that respects pane constraints (min/max/fixed sizes) when the splitter is resized, and expands the QUnit coverage for these scenarios.
Changes:
- Reorders
_dimensionChanged()to recalculate layout, apply it to DOM, then update stored item sizes. - Updates an existing resizing test expectation to match the new constraint-aware behavior.
- Adds a set of new tests validating that
minSize/maxSizeconstraints are respected after splitter width changes.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/devextreme/testing/tests/DevExpress.ui.widgets/splitter.tests.js | Updates one existing resize test and adds new cases covering constraint enforcement after dimension changes. |
| packages/devextreme/js/__internal/ui/splitter/splitter.ts | Changes dimension-change flow to apply the recalculated layout before persisting new pane sizes. |
| _dimensionChanged(): void { | ||
| this._updateItemSizes(); | ||
|
|
||
| this._layout = this._getDefaultLayoutBasedOnSize(); | ||
| this._applyStylesFromLayout(this._layout); | ||
|
|
||
| this._updateItemSizes(); |
There was a problem hiding this comment.
_dimensionChanged() now recalculates layout and applies flex styles before updating item sizes. If width/height is changed while the splitter is hidden or detached, getElementSize() can be 0 while _getResizeHandlesSize() is non-zero, which can produce negative ratios in convertSizeToRatio() and an invalid layout that then gets applied to the DOM. Consider guarding _dimensionChanged similarly to _resizeHandler/_renderItems (e.g., if not attached/visible, set _shouldRecalculateLayout = true and return without applying styles), so the layout is recalculated once the component becomes visible.
| const originalSize = this._initialPaneSizes[index]; | ||
|
|
||
| if (isDefined(originalSize)) { | ||
| const fixedPx = tryConvertToNumber(originalSize, elementSize) ?? px; |
| const fallback = findLastVisibleExpandedItemIndex(items); | ||
|
|
||
| if (fallback !== -1) { | ||
| pixels[fallback] += remaining; |
pharret31
force-pushed
the
26_1_3660-splitter-size-of-panes-should-be-updated-taking-into-account-their-limitations-on-splitter-resize
branch
from
cac954d to
49bbb53
Compare
| if (eligiblePaneIndices.length === 0) { | ||
| const fallback = findLastVisibleExpandedItemIndex(items); | ||
|
|
||
| if (fallback !== -1) { |
There was a problem hiding this comment.
In _distributeRemainingPixels, the fallback path applies pixels[fallback] += remaining even when remaining is negative. If all panes are already clamped at their minSize (or fixed size), eligiblePaneIndices becomes empty and this can drive the fallback pane size below 0 (and below its min/max), resulting in negative flexGrow/sizes. Suggestion: only apply the fallback when remaining > 0 (extra space), and when remaining < 0 just stop distributing (allow overflow) or clamp the fallback so it cannot go below 0/minSize.
| if (fallback !== -1) { | |
| if (fallback !== -1 && remaining > 0) { |
No description provided.