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

Don't remove original DOM node #18

Closed
syropian opened this issue Aug 4, 2016 · 7 comments
Closed

Don't remove original DOM node #18

syropian opened this issue Aug 4, 2016 · 7 comments
Labels
enhancement Pull request that improves existing functionality question

Comments

@syropian
Copy link

syropian commented Aug 4, 2016

Frameworks like Vue.js rely on certain DOM nodes to not be removed by third-party code to work properly. (See vuejs/vue#3302). I think simply hiding the original DOM node would be a better option here. Thoughts?

@jshjohnson
Copy link
Collaborator

I'm not sure about this - this was a design decision I made early on based on performance concerns. Although it's unlikely, a user could potentially add and remove as many items as they wish (unless it's a single select box) meaning the DOM could get needlessly large. I would be interested to see what performs better: moving the element entirely or hiding it.

@syropian
Copy link
Author

syropian commented Aug 4, 2016

Can't really speak for performance, but it would also simplify the destroy() method (which I noticed wasn't in the docs 😉 ) as you don't have to shift around a bunch of markup, just unhide the original el, and nuke the generated stuff.

I'd love to write a Vue wrapper for this, but at the moment, it just doesn't work, due to the way it touches the original DOM node.

@jshjohnson
Copy link
Collaborator

jshjohnson commented Aug 5, 2016

So if I was to test this with hidden elements instead would that need to
apply to everything (choices, items, groups and hidden select options)?

On an aside, thanks for the heads up - I'm updating the docs now!

@jshjohnson jshjohnson added enhancement Pull request that improves existing functionality question labels Aug 5, 2016
@syropian
Copy link
Author

syropian commented Aug 5, 2016

Hm, maybe I miscommunicated what I meant. I just meant hide the original element you pass into the constructor, with display:none; as opposed to removing it from the DOM.

@jshjohnson
Copy link
Collaborator

jshjohnson commented Aug 5, 2016

Oh sorry! In that case, the original element is already set to display: none;. See the screenshot below:

Hidden element

@syropian
Copy link
Author

syropian commented Aug 5, 2016

Ah ok, so I think it's still a problem as it wraps the source element, instead of appending all the generated DOM adjacent to it. I don't have a deep understanding of how Vue's internal update system works but Evan (creator of it) said:

Vue's update algorithm is built upon the assumption that the DOM structure is not to be altered by arbitrary 3rd party code.

As a workaround instead of not wrapping it you could clone it, so you have both a wrapped element for easier selector referencing internally, but there'd still be an untouched version of it as well (besides it being hidden). Sorry if that's confusing. I could maybe create a PR to show you what I mean.

@jshjohnson
Copy link
Collaborator

Hmmm, the beauty of wrapping the original element is that you can query for it from the outer container rather than querying the whole document. Looking for adjacent elements is possible but seems awkward to me - especially as I'm looking for ways to trigger the normal select box on mobile so would need the original element contained.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Pull request that improves existing functionality question
Projects
None yet
Development

No branches or pull requests

2 participants