-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(modal): OpenCloseComponent emits when setting --calcite-duration-factor
to 0
#5326
fix(modal): OpenCloseComponent emits when setting --calcite-duration-factor
to 0
#5326
Conversation
…nsitionDurationProp === 0s
…-transition-duration-0
…-transition-duration-0
…-transition-duration-0
…rop by parsing an aggregate properties string from .getPropertyValue(transition) query
…-transition-duration-0
…dundant typing, and give more info on how/when the function should be used
…-transition-duration-0
…gle function call onToggleOpenCloseComponent(this)
… a single way for handling both the duration > 0 and duration === 0 cases
…-transition-duration-0
…once invoked. Remove the openModal() when component loads as this won't be needed in this pattern
…-transition-duration-0
…-transition-duration-0
…-transition-duration-0
@@ -134,6 +130,7 @@ export class Modal | |||
setUpLoadableComponent(this); | |||
// when modal initially renders, if active was set we need to open as watcher doesn't fire | |||
if (this.open) { | |||
onToggleOpenCloseComponent(this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling this here will emit these events on load of the component. Is there some history on why we are emitting on load here? Usually for components, we don't emit events initially, we start emitting after load on user interaction.
If this is intentional, the test will need to be updated to expect the event to be called initially.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The discussion on this is moved to #4398.
This PR has been automatically marked as stale because it has not had recent activity. Please close your PR if it is no longer relevant. Thank you for your contributions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some issues and questions to resolve here.
…-transition-duration-0
…-transition-duration-0
…it the test for emitting on inital render to one with duration and one with none
…-transition-duration-0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good @Elijbet !! Nice work!!! 🎉
Related Issue: #5206
All (before)open/close events are now emitted on modal regardless of transition duration.
Add the
onToggleUnanimatedComponent
function to theopenCloseComponent Interface
to query props on thetransitionEl
. Use that to get thetransition-duration
on theopenTransitionProp
, which in the case of modal it’s theopacity
. This will allow us to emit the open/close and beforeOpen/beforeClose events in cases whereopacity
transition duration is set to 0.Because calling computed style forces a layout, we use
readTask()
instead which schedules a DOM-read task. The provided callback will be executed at the best moment to perform DOM reads without causing layout thrashing as per Stencil docs.Updated to rework
openCloseComponent Interface
to call one function instead of 3 separate calls in every component by removing connect/disconnect and event listener mapping logic and passing argumentonce
to.addEventListener
ontransitionEl
instead.