Skip to content
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

Destroy doesn't put original select back #298

Closed
SampsonCrowley opened this issue Dec 1, 2017 · 14 comments
Closed

Destroy doesn't put original select back #298

SampsonCrowley opened this issue Dec 1, 2017 · 14 comments

Comments

@SampsonCrowley
Copy link

SampsonCrowley commented Dec 1, 2017

Scenario I have a normal select box with class 'searchable' and normal html options (no ajax).

a choices instance is created:

choices = new Choices('select.searchable')

I destroy the choices instance

choices.destroy()

NOW, the Docs say that my select tag should be back to its original state.

HOWEVER instead, the select box is left blank (i.e no options in list)

@jshjohnson
Copy link
Collaborator

Hey are you able to send me a JSFiddle or a Codepen highlighting the problem please?

@SampsonCrowley
Copy link
Author

I will when I get some free time. Currently I'm just storing the options for every select before it's instantiated, then putting the original back from my own variables

@DonGissel
Copy link

DonGissel commented Dec 11, 2017

I can easily reproduce this as well. It's very inconvenient! Here ya go:

https://jsfiddle.net/5ggLd0kp/1/

@SampsonCrowley
Copy link
Author

@DonGissel yep that is exactly the issue. Nice and concise fiddle

@jshjohnson
Copy link
Collaborator

Thanks for the jsfiddle. This isn't so much a bug as it is a missing piece of functionality!

Out of interest, would you expect destroy() to restore select options as they were before Choices was initiated? Or would you expect it to create options based on the state of Choices - including which options have been selected etc?

@DonGissel
Copy link

Well, it emptying the original <select> I would very much classify as a bug. ;-)

That being said, I can see valid points for both restoring original state and persisting the new state. Perhaps a boolean option could be passed to destroy() to determine whether or not to update the original element, with the default being not to (false)?

@SampsonCrowley
Copy link
Author

I would say this is definitely classified as a bug, since the Docs say that on destroy, the element is put back to its original state

as for whether is should revert back to original, or new persisted state, the default in my opinion for a destroy function should be the original state

A flag to persist the current state would be helpful however

@warrebuysse
Copy link

@jshjohnson What is the progress on this?

@jshjohnson
Copy link
Collaborator

This has been fixed on the develop branch and will go out in the next release 👍

@smoockpp
Copy link

When that release is planned to happen... quite keen to get that functionality working, otherwise I'll have to fork it and do it myself

@DV8FromTheWorld
Copy link

DV8FromTheWorld commented Sep 8, 2018

I also need this functionality to be released. Would be nice to have some kind of timeline.

@perifer
Copy link

perifer commented Mar 21, 2019

This seems to be an issue in 6.0.3, see updated example: https://jsfiddle.net/pco03evt/

Should this be re-opened?

@filip-jk
Copy link

This is still a glitch in 8.0.0...

@jshjohnson
Copy link
Collaborator

This is still a glitch in 8.0.0...

See #574

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants