[Feature Request] Add expansion state properties and an expansion changed event for Splitter panes

[jsakamotoIGJP]

Thank you for providing the new Splitter component. It looks very useful for building resizable layouts. I would like to request a way to access and control the collapsed state of each pane as a public state.

Proposed API

I would like to request public APIs for the expansion state of Splitter panes.

Properties

• start-expansion
• end-expansion

These properties would allow applications to explicitly set and read whether a pane is expanded or collapsed.

Event

• igcExpansionChanged

This event would be fired whenever a user collapses or expands a pane. Applications could use this event to save the user's preferred layout, for example in localStorage, and restore it later.

Why this is needed

Currently, the Splitter provides the toggle() method, but I cannot find a way to read the current expansion state of a pane.

Because users can also collapse and expand panes by direct interaction, application code cannot reliably know whether toggle() will collapse or expand a pane.

As a result, applications cannot make decisions based on the current pane state.

Public expansion state properties would allow applications to inspect the current state and control pane behavior in a predictable way.

Scenario 1

I want to implement behavior such as the following.

"If the pane is already expanded, do nothing. If the pane is collapsed, expand it."

At the moment, this is difficult because the current expansion state is not available through a public API.

Using toggle() is not sufficient because the application cannot know in advance whether the pane will be expanded or collapsed.

Scenario 2

I want to persist the user's preferred layout and restore it when they revisit the page.

For example, an application may save whether a pane is expanded or collapsed in localStorage. When the page is opened again, the application should restore the same state automatically.

This requires both a way to read and set the current expansion state and an event that notifies the application when the user changes that state.

Thank you for considering this improvement.

[rkaraivanov]

@jsakamotoIGJP
A reasonable feature request. We will aim to include it in the next minor release of the package.

[rkaraivanov]

@jsakamotoIGJP

You can check out/try the new feature in the branch of this PR. There is a story showing off a persistent scenario or build the package locally and try it in your own application.

One deviation from your proposal is that the properties are renamed to startCollapsed/endCollapsed. The other components follow the pattern described here:

For a boolean property to be configurable from an attribute, it must default to false. If it defaults to true, you cannot set it to false from markup, since the presence of the attribute, with or without a value, equates to true. This is the standard behavior for attributes in the web platform.

[jsakamotoIGJP]

Hello @rkaraivanov,
Thank you very much for the very quick work on this! I really appreciate it. It works very well.

About the property names, I completely agree that the naming in your pull request is better than my original suggestion.

I also tried the "Persisted Layout" story. Despite its name, it only saves and restores the collapsed state, so I updated it to handle the pane size as well and sent pull request #2301. I would be happy if you could take a look.

However, while doing that, I found another point that may need improvement for real-world use. When a pane is collapsed, startSize and endSize become "auto", and that value is saved. You can see this behavior in the story from #2301.

1. Drag the splitter bar and reload; then the last position is restored (This is expected behavior)
2. Next, collapse the start pane and reload. It is restored as collapsed (this is expected behavior as well). But when I expand it again, the splitter bar jumps back to the center. I would expect the last dragged position.

An application can work around this because resizing and collapsing are separate events, but the code becomes more complicated than it should be.

The feature I asked for here looks like it was implemented well in the PR. Still, I think there is another problem I mentioned above that is practical. Would you like me to open a new issue asking that startSize and endSize keep their values while a pane is collapsed?

[jsakamotoIGJP]

@rkaraivanov
Just after posting the comment above, another idea came to my mind. Maybe it would be nice if only igcResizeEnd was also fired when a pane is collapsed or expanded.

In the story, I had to subscribe to two events and call the same handler to save the layout (the collapsed state and the pane size). With a single event, that part would become much simpler. In other words, a unified "layout changed" event might be what we really need.

Sorry for bringing this up afterward. I wish I had thought of it earlier.