Semantic-ui: Destroy modal?

[tmikaeld]

Seems it isn't documented and it isn't working?

http://jsfiddle.net/Ln57snr5/

[jlukic]

Modal destroy does teardown correctly, I'm not sure why your example isnt working. I'll take a peek

[mariusk]

+1 for @Wangable's comment. This bug hit me in a React app I'm writing, where the modal stopped working after a component was unmounted and remounted again. The callbacks (onApprove etc) simply were not being called. The solution was to call remove on the modal in the componentWillUnmount method. Then everything seems to work as expected.

[JonathanRosado]

I encountered something very similar to what @mariusk describes. The modal eventually reaches a "dead" state where none of callbacks are called.

[jlukic]

The dimmer was not properly removing events in destroy. I've also modified the element namespace variable to make the code a little simpler to read.

[coolblabla]

@jlukic http://jsfiddle.net/Ln57snr5/
still haven't fixed in next branch?

[franciscolourenco]

2.2.3 is still affected http://jsfiddle.net/y80eLgau/

[cyberbobs]

@jlukic 2.2.6 is affected too http://jsfiddle.net/k286azas/

[larvanitis]

This issue should be re-opened until properly fixed.

[isawk]

we used an if/else statement to manage the modal, this way if it was ever created we just execute model("show") else it is created from scratch.

if (typeof mdlComponentVar != 'undefined'){
//show if we had already created before     
 mdlComponentVar.modal( "show" );
}else {
//create otherwise
  var mdlComponentVar = ...
}

[jlukic]

I'll revisit this issue.

[paradissimon]

Yes please properly fix this. When the modal is closed, I'd like to have them totally removed from the DOM. I am creating them dynamically in a SPA app and can't afford to leak/have multiple instance of the same dialog lying around.

[jlukic]

Since the modal DOM is not created from initialize it would be unexpected for it to be removed from DOM on destroy.

I think a solution similar to @isawk above makes sense to me, and is similar to what I currently do in my implementation on private projects.

If anyone has suggestions for how SUI can handle this without causing unexpected behaviors for people who arent using libs with tightly managed lifecycle i'd be willing to listen

[paradissimon]

I ended up manually removing all modals from thé dom before displaying
another one. Seems to work fine on my case.

Le 29 déc. 2016 2:20 PM, "Jack Lukic" [e-mail] a écrit :

Since the modal DOM is not created from initialize it would be unexpected
for it to be removed from DOM on destroy.

I think a solution similar to @isawk https://github.com/isawk above
makes sense to me, and is similar to what I currently do in my
implementation on private projects.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Semantic-Org/Semantic-UI/issues/3200#issuecomment-269679285,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPJl_ZqaqN35vpmAWL46DME60G2gxVzks5rNAgEgaJpZM4GQwwd
.

[nix1]

Since the modal DOM is not created from initialize it would be unexpected for it to be removed from DOM on destroy.

@jlukic Perhaps not removed, but since the original DOM is modified, can I get it back to the initial state?
I easily end up with an empty active dimmer, which was not there initially.

[geemang2000]

This still seems to be a valid issue

[mariusk]

As my previous suggestion either did not work, or at some time stopped working, we did another look today to try to work around it. This time we found a workaround where we instead of explicitely calling hide, we return true from the onApprove method. Seems the state handling in the modal component gets a bit lost when we try to control showing and hiding explicitely.

[sido420]

This could become a breaking change for many apps, so whenever its implemented (if ever), we also need a boolean setting that tells Semantic not to destroy the DOM element on hide.

destory_on_hide: false