feat(shell-panel): allow programmatic updates of --calcite-shell-panel-height/width after user resize
#12993
Conversation
…lling interaction APIs, drop describe block and wrapper for test case
… in a similar fashion
Elijbet
added
the
pr ready for visual snapshots
| } | ||
|
|
||
| :host([layout="horizontal"]) .content { | ||
| --calcite-internal-shell-panel-height: var(--calcite-shell-panel-height); |
There was a problem hiding this comment.
Is there a reason this was removed for the default scale but not the large/small scales?
| } | ||
|
|
||
| :host([layout="vertical"]:not([display-mode="float-all"])) .content { | ||
| inline-size: var(--calcite-internal-shell-panel-width); |
There was a problem hiding this comment.
I'm not sure why this is updated only for the inline-size but not the max/min sizes? Would be nice for these to be consistent. Either all use the internal var or don't.
| const property = | ||
| type === "blockSize" ? "--calcite-shell-panel-height" : "--calcite-shell-panel-width"; | ||
|
|
||
| this.el.style.setProperty(property, size !== null ? `${rounded}px` : null); |
There was a problem hiding this comment.
Maybe we shouldn't set this as a public token on the host of the component. If we do this, then we are modifying the host light DOM styles.
This is cool and it works great but I wonder about any issues setting this CSS token on the host of the component. If we do this, we are modifying the host's light DOM. Do you have any thoughts here @jcfranco @macandcheese?
Usually our tokens are not bi-directional like this. They are top-down cascading like CSS intended.
We may need to rethink this and decide what takes priority here? Is it the token or any resizing a user does? Overriding a token may not be as straight forward as I had originally thought.
There was a problem hiding this comment.
Good question - are there alternatives setups that could support this? The use case makes sense but this would be a new approach.
There was a problem hiding this comment.
Here's what the issue says...
It would be helpful to be able to programmatically set the height and width of the resizable panel so that the panel can be initialized with a set height or width, and so that it can support actions to maximise the size of the panel, or shrink it to a default size.
Won't the existing vars work for the scenario above? If they need to be able to persist a users resize we could just emit an event during resize so they could store the values and apply them to the vars but that wouldn't be for this issue. To me, this issue seems invalid as it should already be supported to specify the initial width/height.
So the way it works now is that the default sizes come from the CSS vars. When a user resizes we override the css vars by setting block/inline sizes on the element.
IF we need a way for the developer to override what a user has done via resize then we likely need properties for that BUT I don't see a good use case for this. A user's defined resize should take precedence.
There was a problem hiding this comment.
He did provide use cases where it makes sense after resize, though: “reset to default size” or “maximize panel”. In this scenario the user could be overriding their own settings.
There was a problem hiding this comment.
In that scenario, maybe a method to reset resize would be best. Then it would fallback to using whatever the token value is.
Elijbet
removed
the
pr ready for visual snapshots
3 participants
Related Issue: #10568
Summary
Expand
--calcite-shell-panel-heightand--calcite-shell-panel-widthtokens to support programmatic dimension updates after the user's manual resize.