Side navigation
#13400 closed feature (duplicate)
Opened February 06, 2013 11:52AM UTC
Closed March 07, 2014 02:38PM UTC
Last modified June 25, 2014 06:10PM UTC
.replaceWith() with .detach() instead of .remove()
Reported by: | anonymous | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | git |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
I would like to propose a version of .replaceWith()
that doesn't do .remove()
but .detach()
instead.
The problem is that the .remove()
call in .replaceWith()
removes all data and events attached to the element. When putting the element back in the DOM at a later time, it is often useful to still have the data/events bound.
Attachments (0)
Change History (10)
Changed February 06, 2013 01:20PM UTC by comment:1
resolution: | → wontfix |
---|---|
status: | new → closed |
Changed February 28, 2013 01:50PM UTC by comment:2
Just for the record, I don't think it's that rare...
The need arises for example when implementing a 'wizard-like' navigation. You need to replace the contents of a node each time 'next' is clicked, but when 'back' is clicked you still want the original contents with their event handlers in place.
Changed August 30, 2013 06:25PM UTC by comment:3
Just came across this issue, because I want to toggle content upon click whereas the toggle "switch" is part of the content. In this case, it would be useful to just replace one element with another without losing attached event handlers.
Changed October 30, 2013 08:39AM UTC by comment:4
I also just came to this. Navigation using scroll fix headings, when the user scrolls to a point header.replaceWith(placeholder) and fix the heading, but event handlers get lost. Had to do header.before(placeholder).detach(). Not the end of the world I suppose.
Changed January 16, 2014 07:15AM UTC by comment:5
I think the last comment meant to say the solution is
placeholder.insertBefore(header);
header.detach();
It doesn't make sense otherwise.
Changed January 31, 2014 01:49PM UTC by comment:6
I too came across the requirement to keep events en-tacked using replaceWith. It seems as though this would be a very simple fix, no?
...this
jQuery( this ).remove(); parent.insertBefore( elem, next );
... would become
if ( detach ) { jQuery( this ).detach(); parent.insertBefore( elem, next ); }
Then there could be two functions. One for detach and another for the normal replaceWith (both of which call the private function using the detach flag that actually does the work).
Changed March 07, 2014 02:37PM UTC by comment:8
resolution: | wontfix |
---|---|
status: | closed → reopened |
Changed March 07, 2014 02:38PM UTC by comment:9
Changed June 25, 2014 06:10PM UTC by comment:10
In case anyone arrives here as I did looking for a quick alternative to replaceWith() that keeps attached events, it can be done using a combination of existing functions in the current API:
this:
old.replaceWith( new );
can be changed to:
old.before( new ).detach();
Both return a handle to the removed element, so depending on the use case it should be pretty simple to change.
It's not a case of just leaving data and events "in place" on the old element. Since you're *replacing* the element, the only way to do this would be to copy the data and events from the replaced element.
Since we've gone seven years without anyone requesting this, I think it's rare enough that you should just manage it in the app, either by using delegated events or re-attaching them.